How udumper works

Udumper searches RAM for a specific pattern that is known to be associated with a function that writes raw sectors to the SD card (called wr in the udumper code, and WriteSDCard in CHDK)

It then calls the function (possibly after zeroing some RAM, for reasons described later).

udumper is a hack

Important stuff

udumper and WriteSDCard don't know anything about the filesystem. Udumper just writes the data starting at START_SECTOR. It's up to the user to either read this from the raw partition, or arrange for it to fall somewhere in a valid file. This is typically accomplished by putting creating a large file full of zeros called EMPTY.DUM after formatting the SD card. * WriteSDCard is complex function, which uses different memory locations, semaphores etc. In other words, it expects to be run as part of a functioning OS. In udumper, it is called after part of the OS data structure has been trashed by loading the udumper image.

The camera will appear dead (black screen, no LEDs) if udumper succeeds. It will crash after udumper is finished. Wait a minute before removing the cards and batteries.

DISKBOOT.BIN

udumper relies the automatic booting of a file called DISKBOOT.BIN. See Bootable_SD_card for a description of how the card is made bootable. Attempts to run udumper with the "firmware update method" method have not been successful. This may be due to differences in state of canon OS data left in memory, but has not been investigated thoroughly.

Canon has used a variety of encodings for diskboot images. The original (vxworks or dryos in the cardtricks distribution) is just an unencoded executable. Later cameras use one of several different encodings. The dancingbits tool in the chdk source distribution can be used to encode these files. Note: cameras requiring an encoded DISKBOOT.BIN will ignored an unencoded DISKBOOT.BIN, but they will attempt to load and execute any encoded DISKBOOT.BIN, even if it is encoded using the wrong method. This means that a camera requiring an encoded diskboot will boot normally (with a "card locked" message) if an unencoded diskboot is used, but will crash if an incorrect coding is used. Since udumpers normal operation it indistinguishable from a crash, it is difficult to tell if the correct encoding has been found.