holeepassion: No, SD cards will not make it any easier. I believe the 450D is also DryOS, so it's not going to be the same as 300D, 350D, 20D or 30D...
kwf: I found the same routines. The checksum calculation function is pretty blatant in the bootloader portion of the code. In the application portion, there is a well defined calling structure to detect an FIR file's presence on the CF card, but I could not find a simple checksum calculation routine.
I spent a while trying to figure out exactly how the memory mapped between the code, and the actual memory in the processor (I know it's loaded at 0x1900, but I'm not sure what location in the firmware file gets mapped to 0x1900 -- there are some reference to 'start of data' but I haven't been able to map, say, a menu item text string to where it is actually used in the code), so it's hard to identify what functions are called when (as you mentioned) a C++ member is executed ( -- it may not even be C++, they may have just used function pointer tables all over the place).
There are a lot of places in the data section that have subroutine pointers, but it's hard to tell where they are used. All this isn't really important to getting some hacked code running, as we can use the same "hook" method used by chdk. It is, however, making it a pain to find how the checksum is calculated.
I thought at one point that the same function that decrypted the FIR file might also calculate a checksum, so I tried to identify that function without much luck. I also tried a pattern search on a few variants of the XOR decoding table used in decrypt20D.exe, but didn't come up with anything.
I really wish I knew where all those logging/debugging messages were being printed too (probably a serial port internal to the camera, or maybe they are actived through the USB port somehow for use at Canon).
Things I *do* know about the checksum:
- it is byte-oriented (I can decrement 1 byte, and increment the next byte, and the file passes)
- the same checksum covers the bootloader portion and the firmware portion of the file (I can decrement 1 byte in the firmware portion, and increment a byte in the bootloader portion and it passes)
- the 'S-records' at the end are covered by the checksum also (so it looks like a very large portion of the file, if not the whole thing, is covered).
I haven't figured out if the accumulated sum is stored as 8, 16, 32, etc bits....I did try a quick brute-force method of summing every single byte of the file (minus four) and comparing it to the 32-bit value of the four un-summed bytes (I tried leaving out every possible 32-bit value (eg, 8MB/4 times)), and compared the calculated checksum against the un-summed word in both big and little endian order, but didn't find a match......so either the checksum isn't summed into a 32-bit number, or the whol file is not covered.
I'm starting to really get annoyed at this checksum....
