> Valeriy E. Ushakov wrote:
> 
> 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].

In light of your comments towards the end of your message, can I
ask *which* flash this particular code is executing out of?  Sorry,
I'm clueless as to what the memory map looks like...

> 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

So, let me make sure I have this straight... the "ebus" flash is where
the machine *starts* (after RESET)?  But, at some point it looks at
the SIMM and (presumably if there is a valid checksum, etc.)
it *executes* the code in the flash SIMM?

Or, do I have this exactly backwards?

Regardless, the SIMM can be altered -- because it is removable (!).
I assume that if it is removed completely, the box "hangs"?  Or,
does it drop into OFW and stay there?

If the ebus flash just looks for a simple checksum (or a magic number
someplace in the SIMM flash), then it should be possible to just
replace the SIMM with a SIMM containing "new" code.  Forget
the crap that Sun imposes on the downloaded images... build
the SIMMs "off line" and just swap them into the machine once
they have been "fixed"   :->

Or, have I misunderstood your description?

> start.  So, perhaps, for initial manufacturing flashprom at ebus was
> used to flash the flash simm and there might be hope to force the

You are then assuming the ebus flash is *almost* treated as a
piece of ROM... i.e. that they count on the SIMM to accept the
actual downloaded code?

> 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?

And, can someone *remove* the SIMM and see what happens
when the box tries to power up?