XDA-1 romimage files formats

this is a description of all file formats that can contain romdata.

NBF

this file is usually found in 'official' upgrades, together with a program that is usually named 'programme a.exe', or 'upgrade.exe'

start with a 32 byte header containing
1. device identification
2. '-' as separator
3. language
4. '-' as separator
5. version
6. '-' as separator
7. ?? 007 - another number, probably operator id.
8. '-' as separator
9. a 16 bit checksum, in perl: unpack("%16C*", $data, $otherheaderfields)
  this checksum is stored without leading zeroes.
  the first three '-' separators are included in the sum, the fourth is not.
10. '-' as padding to 32 bytes
followed by the 256K bootloader
followed by the 30.75M os image

the problem with this format is that it is usually used for flashing over a serial or usb line, from a host computer. and it overwrites the most essential part of your device's rom, its bootloader. if something goes wrong here, you will need to resort to more complicated techinques to get your device working again.

NB0

this contains a 256K bootloader image, flashed into rom at offset 0x80000000

note: the .nb files that come with the nbf upgrade tool are NOT bootloaders. if you flash them to your device, you will permanently break it!!

NB1

this contains a 30.75M os image, flashed into rom at offset 0x80040000

NB2

this contains a 31M bootloader + os image, flashed into rom at offset 0x80000000

BIN

this file is generated by microsofts romtools, but I never seen it in an official distribution for xda upgrades.

these files contain most information, several non-contigouos blocks may be present and an entrypoint in the code.

a 7 character signature "B000FF\n" ( that is with 3 zeroes, and ending in a linefeed )
DWORD for image start
DWORD for image length
followd by several records of this format:
1. DWORD with address where this block is to be flashed to
2. DWORD with the length of this block
3. DWORD with the 32 bit checksum of this block, in perl: unpack("%32C*", $data);
4. followed by <length> bytes of data
the last record has address ZERO, in the length the entrypoint into the rom, and ZERO as checksum.

all dwords are stored bigendian/intel byte order

XIP

this is how microsoft intended rom upgrades to be distributed, I have only seen it used on the hp-jornada.

DWORD size this value is the size of the B000FF file
DWORD null
xipentry ( 0x290 bytes )
B000FF file
64 bytes of ?? probably hash or signature?

these files can be flashed using updatexip.exe

the xipentry contains a key of type 0x8003 (CALG_MD5), the 64 bytes ( =512 bits) are the rsa-encrypted md5 hash of the file. a 512 bit rsa key is used.

probably you can create keys with 'makecert.exe', and sign stuff using 'signfile.exe'

example xipentry:

80ec0000      XIPCHAIN_ENTRY.pvAddr     
001788e0      XIPCHAIN_ENTRY.dwLength   
00000000      XIPCHAIN_ENTRY.dwMaxLength
0003          XIPCHAIN_ENTRY.usOrder    
0001          XIPCHAIN_ENTRY.usFlags    
00000000      XIPCHAIN_ENTRY.dwVersion  
"24MAPPS"     XIPCHAIN_ENTRY.szName     
00008003      XIPCHAIN_ENTRY.dwAlgoFlags  = CALG_MD5
00000054      XIPCHAIN_ENTRY.dwKeyLen   
              XIPCHAIN_ENTRY.byPublicKey
06            PUBLICKEYSTRUC.bType        = PUBLICKEYBLOB
02            PUBLICKEYSTRUC.bVersion
0000          PUBLICKEYSTRUC.reserved
00002400      PUBLICKEYSTRUC.aiKeyAlg     = CALG_RSA_SIGN
"RSA1"        RSAPUBKEY.magic
00000200      RSAPUBKEY.bitlen
00010001      RSAPUBKEY.pubexp
              modulusdata
53 c9 1d 0c 35 33 8f a4 df 22 63 ab 1b 48 89 29
3f ad af 36 67 18 13 b1 5e 1c 2c 48 3b 8a 80 d6
4b 90 f8 49 cd e3 bd e0 c1 96 46 61 cf 86 be 44
75 38 2a 62 e6 b0 59 92 59 f9 59 5d 68 66 9b d7

note: to debug updatexip, set HKLM\Software\Microsoft\ROMUpdates LogZones= 0xffffffff
and see \windows\update\updxiplog.txt

splitrom

I wrote this perl script, to handle conversions between several filetypes.
2003-07-16: update, now also allows insertion of memory blocks, and better consistancy verification.