ROM DUMP - A practical guide

Note: All credit goes to ablbd. This is just a translation.

This article will focus on practical methods to make a backup copy of your device's ROM image.

In the case of a PNA/PDA, the "ROM (Read Only Memory)" is actually placed on a rewritable medium. Manufactures (especially for the PDA and iPhone) publish on their own sites from time to time upgrades for their devices. For instance, you can buy a device with WINCE5 and later they offer you the possibility to upgrade to WINCE6 or even above. What those companies publish is a new ROM which will replace the old one, offering improvements and superior performances.

To ensure that a ROM image can be boot-able, it needs to fulfill some conditions:
- to have the format that the boot-loader is waiting for.
- to have a name that the boot-loader it recognizes and accepts; in principle, a particular type of device can claim a specific "case sensitive" name.
- the boot-loader must be intact.



This last aspect is extremely important to ensure that in the event that the new version of the ROM does not work, you can return anytime to the previous version. Of course the boot-loader can be also changed, but in the case that something goes wrong the device becomes unusable. Not really unusable, but close. Your only option will become JTAG flashing, but let's hope we don't get there...

[JITAG Flashing: Inside every PNA/PDA there are some connection points that you can link to a PC's parallel port through an interface. The interface is needed because of the mains voltage is 3.3V for PPC but for PC is 5V (on ports). In the case of certain models its relatively easy to find the JTAG connection, in other cases these points of connection can be very well hidden. Once found, you must also find which connection corresponds to which signal. Your PC runs a driver for JTAG, accessing directly the NAND flash and can rewrite the boot-loader and the ROM. Usually after flashing the boot-loader you switch to a LAN connection, since communications via JTAG is extremely slow and the transfer of the ROM image would take a lot of time.]

After this small introduction, let's get into the subject and review some of the methods used to extract the ROM from a PDA/PNA.

This can be done remotely (using a PC), or directly on the device. As a general recommendation, the remote method is preferred and only in extreme cases, the internal method must be used. Both methods presented will produce the copies of the partition where the ROM image resides.

There are utilities that copy parts of RAM, but they have several disadvantages:
- we will find in the dump with certainty only those parts of the ROM that are XIP (execute in place); the rest of the files (let's call them standard) may be in other locations than the memory area you want to copy;
- in RAM, memory pages are adjusted (a page is 4096 bytes) and any relocatable module will be loaded at the beginning of a new page, even if the previous page is almost empty.


1) Remote method:

Prerequisite: the device MUST have a working ActiveSync connection.

a) In most cases, the "tools" package by itsme(http://www.xs4all.nl/~itsme/projects/xda/tools.html) will be perfect.

Download the latest zip and extract the files in an easy accessible folder. I recommend creating a second folder, with short name and also in the root of the drive (e.g. Rom), where to put the binary image of the ROM and some other files. Connect the device through ActiveSync and manual copy "itsutils.dll" to \Windows folder of the device. In case of a message that there is not enough memory, the problem is fixed just for those who have access to the device's control panel. Those who do not have the device unlocked, or at least access to the desktop (for PNAs), either they'll have to unlock it or they'll have to give up the ROM copying. Into the device's control panel click on "System" and then "Memory". You'll have a slider set towards the left; move it towards the center, hit OK and the copy operation will go without problems.

Open a command prompt window on the PC (Start, Run then type in "cmd") and go to the folder where you have unzipped the utilities. If you have an SD card inside the PNA/PDA, remove it as to not clutter the data, although it's not mandatory. In the command line type:

"pdocread -l"

(Note: I use quotation marks in order to see where you end the command + parameters; you type the command WITHOUT the quotation marks). This command will list all the remote drives, partitions present on each drive and the length of each partition. From the size of the partitions 0 and/or 1 you may find out where the ROM is (usually it is around 32MB, but the newest, for WINCE6 can have 64MB).

An example of the output:
979.75M (0x3d3c0000) DSK1:
| 1.10M (0x119600) Part00
| 31.02M (0x1f04000) Part01
| 944.63M (0x3b0a2600) Part02
| 3.00M (0x300000) Part03
........

It is clear from the listing that the ROM is located in Part01, so we will continue with this one. Usually partition 3 contains the hive registry and partition 2 is the user data. The figures in the parentheses contain the exact size of the partition, as it is computed using the data from the MBR. Assuming that you have created a folder D:\Rom, the command line that always works is:

"pdocread -d DSK1: -n 1 -w 0 0x1f04000 d:\rom\p01.bin"

After the -d follows the disk name as shown by the previous command. No matter what name appears there, you must use it exactly as shown; -n 1 is the partition number, partition 1; if you want a dump partition 0, replace 1 with 0; -w tells the program to use the Windows API; the first figure represents the start byte for the dump and the second one how many bytes we want to be copied (it's better to copy the entire partition, so from the first listing you use the value from within parentheses).

If all goes well, you'll have in the "d:\rom" folder a file (called by myself part01.bin, but it can have any name) that contains the raw data of the drive. In the command line, the order of the parameters does not matter, but after them the order of values is mandatory: 1 - start address, 2 - length (how many bytes we want to copy) and 3 - the name of the file for dump. The start address and the length can be given either in decimal or hex (0xValue) values. If you omit the second value (length), the default value is 512 bytes. There may be variations of "pdocread", for instance to use the flashdrv.dll file. If you just type "pdocread" without any parameters, you'll get all the possible options (a sort of help).

***Warning: pdocread can also write the internal flash disk, use it only for reading!!!***


2) Internal method.

It is used if for some obscure reasons pdocread does not work or if there is no possibility of connecting the device via ActiveSync (device connects just as "Mass storage"). In this situation, you will need a program called DiskRW (http://www.filestube.com/f84afcfb0ff6681603ea/go.html). It is a very good program, well made, but again, warning: as the name implies, it can also write the flash disk!

Copy the executable to the SD card and before starting it up, activate the SIP keyboard because you will need it later, and DislRW doesn't do it for you. You will see at the top a menu; first choose "Info", where you will collect the information regarding the length of the partitions. Select your flash disk (appears with the name DSK1:) and open the branch "Partition Information". Choose the partition which is the most probable to contain the ROM (32 MB or larger, or 64 MB or larger for CE6) and make note of the length (Size = ... ...) for both partitions 0 and 1; the value is a decimal number and can be used as such. After that, go to the initial "Read/Write" window and:

a) *** LEAVE CHECKED the option ReadDisk ***
b) for Store chose DSK1
c) for Offset leave the value 0 (for partition 0) or enter the length of partition 0 if you want to copy partition 1
d) for "Length" input the length of the chosen partition
e) Select a path and name the file in the "Output" window; extension .bin or. raw;
f) click on the "Read" button and wait until the copying is finished

Having the raw data file on the PC (copied from the device), you have to make sure that it contains tho full ROM. To do this, the fastest way it's offered also by itsme (given the link above, choose "dumprom"). The file needs a library (nkcompr.lib, from platform builder) that you can also find it there. You can merge it with the rest of the utilities and then type in the command window:

"dumprom -5 d:\rom\p01.bin -d d:\rom >p01.txt"

The first path points to the binary image obtained in the previous step, and the second is the path to a folder where the files from the ROM image will be extracted (the folder must already be created). The p01.txt file will contain the report of dumprom; the relevant lines are the first few, which begin with "img" and some values. Don't mind the error message after the "img", it's normal. Further the list shows in detail where to find each component of the ROM, which of them are of type "module" and which are "file". You can verify if the files from your device's \Windows folder are the same as the ones that can be found in the directory where you unpacked the ROM with dumprom (in this case d:\rom). If yes, it means that the entire rom exist somewhere in the raw file and the approach was successful. It is good to keep the .txt file generated by dumprom, because you will need it in the future. If you were unable to find absolutely all the files from your \Windows folder, means that the ROM copy is incomplete and it makes no sense to go ahead with this tutorial.

*** Warning: Windows Explorer from your device must be set to show both system and hidden files; you will not be able to see all the files from the "\Windows" folder through an ActiveSync connecton, you must use the Windows Explorer from the device. ***

The raw file can be cleaned up easily by using a hex editor. For this purpose the most simple to use it's "WinHex" (freeware, search on Google; does not require installation on your PC, just to be in the same folder with the DLL's from the package).

You have the detailed method for finding the beginning of the ROM image in the article Almost everything about Wayteq 770 GPS navigator, we won't go through it again here.

It is possible that in the dumped image you will not find the sequence "FE 03 00 EA" (jump to the secondary boot-loader), because the jump address might be different, or because it is transmitted as a parameter to the boot-loader. In this case the things get complicated, but not too much. Read the part about the MBR from the article and calculate the address of the ROM header by multiplying the position of the first block indicated by the partition that we are interested in with 0x200. Check though that at offset 0x40 you have the magic string "ECEC".

When you find the ROM's start address, move the cursor 1 byte to the left, meaning its on the previous byte and from the "Edit" menu select "Delete TO cursor". After this operation, the sequence FE 03 00 EA (if it's there) must begin at address 0x0 in hex editor and the first occurrence of the string "ECEC" must be at 0x40. All we have to do is to find the offset where the ROM ends. To do this, open the .txt file generated by dumprom and from the first line make a note of the "base address". Regardless of how many images it finds (img), the base address stays the same. Now go to the end of the .txt file and make a note of the "rom end", or of the first value for "unknown" and round it up till the address is multiple of 0x200. For instance, if the rom end = 0x8df28928, final value will be 0x8DF28B00.

For hexadecimal calculations use your Window's Calculator set to "Scientific" and with the Hex radio button checked. From the rounded rom_end's value subtract the base_address's value and have your hex editor go to the absolute address resulted from this subtraction (from "Address" menu select "Goto", and have "Hex" checked). To not make any mistakes, copy and paste the result from your Calculator into the Search window. From the position where the cursor is in your hex editor, go to "Edit" menu and select "Delete FROM cursor", then "File" menu and "Save As".

I suggest that the name of the saved file to contain a description of the device whose ROM you have copied, in order to distinguish it from other ROM images you have, and an extension .IMG or .nb0 (NBzero), because what you have there will be recognized by the boot-loader with one of these extensions and a special name that differs from device to device. To verify if everything is ok, you could run again "dumprom" on this last file. Make sure there are no other error messages in the listing and if the files that are extracted are the same in number with those extracted first time from the .bin (raw) image. If this last check is successful, it means that you are in possession of a ROM image that can be loaded into a device identical to the one from which it was extracted.

The "cleaning" method above is the minimal one. Most of the times the ROM image is fairly long, filled with a lot of "00". As an alternative to rounding, place the cursor in your hex editor at the exact address from calculation (rom end) and go up towards higher addresses until you see some data (non-zero values). Those are no longer part of the ROM image, so go back byte by byte so that the cursor is on the last zero value and check the address indicated by hex editor, which should be something like xxxFFFFF. Go forward one byte (on the first non-zero value) and apply the command "Delete from cursor" and then save. All ROM images available on the sites for certain devices will have exactly this length, because they have included the "00" values. Although it implies a bit more work and attention, it's worth doing it this way.

NOTE: THE base address of the dumprom's .txt file will be the same only for VALID images. If dumprom finds invalid headers, a message will appear in regards to that at the beginning and the base address will differ in regards with the others, don't use this one.

NOTE: An invalid header does not necessarily mean that you have a wrong dump. I came across something like that and I made countless verifications, reaching the conclusion that the header was made deliberately invalid because the ROM image had a suite of DLL's for debug from platform builder and they were to lazy to generate a ROM image without them. I've tried even to re-validate that header (first on the ROM dump for dumprom and then on the device). Here's an example:

img 00000000 : hdr=8cd39508 base=8cb50000 commandlineoffset=8cb50000
img 00400000 : hdr=820e35c4 base=81c00000 commandlineoffset=81c00000
img 00a00000 : hdr=834bba84 base=81c00000 commandlineoffset=81c00000
ERROR: could not find pointer for ofs 8cd39508 invalid romhdr ofs 8cd3950

Notice that the first entry is invalid and is mentioned as "invalid romhdr" and as well as an ERROR and the base address is a different value in regards with the following 2 valid inputs. The valid images contain absolutely all the files from the \Windows folder, that's why it is recommended to check bit by bit the files from the ROM dump with those
from \windows.

A few words about the files extracted by dumprom:

a) Executables (.exe) may be used in any other device as they are, provided that they're dependencies are met;

b) As a general rule, DLL's CANNOT BE USED on other devices or even on their own device, because they are missing the relocation table. In the dumprom listing they have the attribute "modent". Exceptions are for those DLL's (it might be none) that in the dumprom listing appear as "filent", in which case they can be ported to other devices if needed.

c) There are several files with the extension .hv (one of which boot.hv). All together can be used for restoring the default registry. Procedure: launch the PC program CeRegEditor ( http://ceregeditor.mdsoft.pl/) and from the "File" menu select "New". After that from the "Edit" menu select "Import" for each .hv file and then save in the same manner as the image ("Save as…" indicating the device from which it originates). ** Warning: don't skip any .hv file, otherwise you'll have only a partial image of the registry *** From this moment you are in possession of the entire registry as it came from the factory, which can be used to restore the original settings. There may be many other reasons you want to return to the factory settings. If you have a working activesync connection, you can restore the original registry in 2 minutes using CeRegEditor connected to your device and selecting "Tools" -> "Backup/Restore" -> "Restore" then choosing the file you've previously saved. At the next hard reset the device will be like when you have switched it on for the first time. The operation can be done using an internal Registry editor too, in which case you copy the file to the device with the extension changed to .reg. From the Registry editor's menu you choose "Import registry". This method though will not delete any additional keys but will only change the values for the keys already present in the file saved previously.

These being said, have a happy "dump-ing"!