On Sat, Jun 15, 2002 at 01:52:34 +0400, Valeriy E. Ushakov wrote:

> I have reverse engineered SunRay flash image and I think it's not
> possible to boot NetBSD on it without soldering work.  Sun images are
> DSA-signed so the only way to make it execute external code is by
> mounting a buffer overflow or crypto attack against SunRay bootstrap
> code.  So the only practical alternative is to replace the flash chip
> with a PLCC socket that you can plug a custom flash into.

Well, to give a little bit more details.

The image starts with bootstrapping code - the part I mostly worked
on.  Then there are two embedded, optionally compressed images that I
haven't done much investigation on.  From a quick look, one is a flash
updater and the other is the actual "OS".  Bootstrap code uncompresses
the embedded image and verifies its integrity before launching it.
Ethernet address of the box is in the flash too, in the boostrap area.
[Decompression routine from the disassembled bootstrap code was
directly recyclable to decompress embedded images].

Actually, I'm speculating about DSA.  I have approximately zero crypto
clue, and reverse enginnering big chunks of compiled code (as opposed
to handwritten assembler) is no fun, especially if the code is doing
bignums.  What makes me think it's DSA is that there's "DSA1" magic
string in the "signatures".  The code contains bignum stuff (judging
by error message strings in the image).  All images contain an array
of blobs that are probably public keys that it accepts.  Each key has
a string label and the "signature" contains a label of the key that
was used to sign it, so bootstrap code checks the label on the
signature, find the entry in its array of keys, and calls a routine to
"verify" the "signature".  The next step in conforming that theory is
to write a signature verifier using openssl.

That said, I'm not particulary interested in further working in that
direction.  While SunRay is cute, I don't want to waste my time on
attacking its boot code or doing hardware hacks.  If you want a cute
microSPARC-IIep box - get Krups at approx. 1/3 the price.  Look ma, no
soldering. ;)

PS: Hmm, on the second thought...  thanks, Don, for bringing up the
topic of manufacturing.  I don't have actual unit, so I'm speculating
here, but microSPARC-IIep systems has *two* flashes.  One is at PCI
(flashprom at ebus), that in Krups contains the OFW.  The other one is
a flash simm that in Krups contains JavaOS.  The flash simm (hi,
Allen!) is directly accessible by the CPU starting at phys addr
0x20000000 and there are CPU registers that controls flash access
speed &c.

The SunRay bootstrap code knows about both flashes.  It runs from
flash simm, but it also checks flashprom at ebus for an image to
start.  So, perhaps, for initial manufacturing flashprom at ebus was
used to flash the flash simm and there might be hope to force the
board to boot from flashprom and a way to stick a flashprom w/out
excessive hardware hacking.  Can anyone with SunRay take a set of good
hi-res pictures of the board?

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen