PDA

View Full Version : Fixing the UTV integrity checks



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

CyberJaak
06-01-2003, 03:31 PM
great work alldeadhomiez. Hopefully others will follow your lead and post their findings so we can give this project a jump-start. Here's some of my guesses about the byte-swapping on the drive. The following was based on ASCII text found on the drive and is not based on fact but rather on assumptions. All addresses are in LBA format (divide by 200h for sector #).

FSno @ 15480600 (some hard drives have it at 13480600, an offset of 2000000)

byte-bounded swap: from 15482600 to 15800BFF (uncompressed, clean ASCII)

15800C00 to 158015FF ????

word-bounded swap: from 15801600 to 158D9E00 (compressed? not clean ASCII, many '' chars within ASCII text)

word-bounded swap: from 158DA000 to 158F16BF (uncompressed, clean ASCII)

word-bounded swap: from 158F16C0 to 15A4F62F (compressed? not clean ASCII, many '' chars within ASCII text)

interleaved swap: from 15A4F630 to 15A5DCBF (uncompressed, 01 23 45 67 89 AB CD EF -> 45 67 CD EF 01 23 89 AB)

unknown: from 15A5DCC0 to 15A5DD2F ??

word-bounded swap: from 15A5DD30 to 1661ED6F (compressed? not clean ASCII, many '' chars within ASCII text)

next data @ 17480800


Anyone who can correct the above assumptions are encouraged to do so.


-CyberJaak

satchmoe
06-01-2003, 07:34 PM
Depending on where your image is either 13480600 or 15480600
the info for the mounted partitions within the image is 381000
plus the base in 3.5 or 39000 plus base in 3.7 everthing from that point needs to be word swapped i.e. 16bit swap then 32bit swap
before that point just 16bit swap (byte swap) as far as I know all mounted partions are word swapped this includes the fat partitions. offset to those are found at 178c1000
and yes all files in the 3 mounted partitions within the image are compressed.

centorian
06-02-2003, 03:26 PM
Just in case you guys didnt know, Windows CE is Wide character, meaning ASCII is in 2 bytes format. :eek:

This i why you see ''