alldeadhomiez
05-31-2003, 08:51 PM
NOTE: This is intended to be a technical thread. Posts providing new information or experiences with regard to byte swapping, integrity checks, CE image offsets, ROM/boot operation, etc. are welcomed with open arms here. Posts talking about appliance timers, "how do i reinstall teh 3.5 software," "how do i hack teh DSS," and such are prohibited.
I am working on an UTV at sw version 3.5. I have discovered the following about the integrity checks:
My wince image starts at absolute sector 0xaa403 and is (theoretically) 32 megabytes long. The first sector (as far as I know) is the one that contains the "FSNo" (or is it "NoFS"?) string.
Bytes 08-0b in my image might be a crc or some other type of checksum.
Changing anything starting with byte 8 (haven't tried the lower ones) causes the machine not to boot.
The last byte checked in this image is at offset 0x37ff1b in the wince image. Changing anything prior or equal to that keeps the unit from booting, and changing most anything afterward is harmless. Although I was hoping that the discovery of this offset would shed some light on how the integrity check is performed or help me locate the parameters fed into that function, that has not been the case yet. Please help if you can.
Obviously I still have not been able to find a way to change any bytes in the image. (Is there an easy way to replace the last few bytes with a sequence that generates the same CRC? Byte swapping may complicate this a lot, depending on where in the process it happens.)
I have not been able to figure out the byte swapping technique. For instance, the first bits of text in the CE image appear unswapped, but throughout the image the swapping technique seems to change. Is this relevant or is the checksum/signature calculation separate? Mr. Jaak has posted some very interesting observations on this below - can you find a pattern that we didn't?
Any other comments from anyone else who has looked at these boxes? (Blaknite are you listening? ;)
I am working on an UTV at sw version 3.5. I have discovered the following about the integrity checks:
My wince image starts at absolute sector 0xaa403 and is (theoretically) 32 megabytes long. The first sector (as far as I know) is the one that contains the "FSNo" (or is it "NoFS"?) string.
Bytes 08-0b in my image might be a crc or some other type of checksum.
Changing anything starting with byte 8 (haven't tried the lower ones) causes the machine not to boot.
The last byte checked in this image is at offset 0x37ff1b in the wince image. Changing anything prior or equal to that keeps the unit from booting, and changing most anything afterward is harmless. Although I was hoping that the discovery of this offset would shed some light on how the integrity check is performed or help me locate the parameters fed into that function, that has not been the case yet. Please help if you can.
Obviously I still have not been able to find a way to change any bytes in the image. (Is there an easy way to replace the last few bytes with a sequence that generates the same CRC? Byte swapping may complicate this a lot, depending on where in the process it happens.)
I have not been able to figure out the byte swapping technique. For instance, the first bits of text in the CE image appear unswapped, but throughout the image the swapping technique seems to change. Is this relevant or is the checksum/signature calculation separate? Mr. Jaak has posted some very interesting observations on this below - can you find a pattern that we didn't?
Any other comments from anyone else who has looked at these boxes? (Blaknite are you listening? ;)