I've been up and down this forum. Where can I find info on dumping the canon firmware, decrypting and loading into IDA (or similiar)?This is particularly for the recent 650D firmware release. I've some experience with C/C++, uControllers and the like and would be very interested in joining development to move things forward.Thanks

g3ggo - is it universal that we can always load ROM1 to 0xF8000000? I saw this post, but no other clear (that I saw) note on the correct location of ROM1. I saw a reference that indicated ROM0 may be fixed in size on all cameras, so this makes sense, but I did not find a hadcy table or note about both rome.

Just want to be sure - any advice welcome as I get started going through the ROMs.

The best option is to check the Makefile / stubs of each platform as it defines the correct ROM start address.Note that some (all?) digicV models also relocate some functions into RAM at boot (check from RAM_OFFSET stub)

flash (ROM1) on normal cameras starts at 0xF8000000 and is either 0x00800000, 0x01000000 ox 0x02000000 large.after that size it repeats over and over. canon uses this intentionally for bootloader reset vector that must be found on 0xFFFF0000.at 0xF0000000 is ROM0 which is rarely used. (flash ic usually not populated, just on 5d2 iirc)if not populated, reading there will give some random noise or fading bits.

the REAL_IC i explained is ROM1 at 0xF8000000.same applies to any ROM0 (like on 5D2/3) - it starts at 0xF0000000.

why i am so sure?a) flashes are "selected" by "chip enable" lines. those are electronic logics.since computers are built, those chip enable lines are driven by N/AND gates that compare the uppermost address bits.guess why RAM is at 0x0xxxxxxx, uncached RAM at 0x4xxxxxxx, FPGAs at 0x8xxxxxxx, IOs at 0xCxxxxxxx and flash at 0xFxxxxxxx...they use the upper 4 bits as selector for the device. RAM, FPGA, IO, flash etc.

b) there are *no* registers that control memory mapping on our CPUs. those you talk of are just cachable and execution bits.nothing more. i implemented them in my emulator. i read ARM_ARM.PDF quite often.i know that ARM *can* have a MMU, but just read the system identification registers via MCR...we have *no* model with a MMU.

about memory maps.well the ROM0 physically starts at 0xF0000000, but canon seems to *use* the mirror image at 0xF0800000.just check the ROM size - its 0x00800000, so canon uses the first mirror image.there is no real reason. they could compile the software with 0xF7000000 too and it will work the same.

those mirror images are explicitely used by canon for reason on ROM1.as said, ARM requires reset vector at address 0xFFFF0000.but for the main firmware they could choose any address.

but:i dont say that it will always be like this. there might be models that have 4 flashes (i dont think that will ever happen)or models that have only one flash and that starts at 0xF0000000 and repeats until 0xFFFFFFFF. (no subselection)i just say that there is no kind of random flash mapping somewhere in memory.

also:where the code jumps to, so which mirror image mirror of the available ones canon chose, depends on camera model.as said, we have to check where the code jumps to by looking at absolute addresses in flash.i prefer to follow the whole code execution flow and to know which code jumps where.if that is 0xF80C0000, 0xFF0C0000 or 0xFC0C0000 is something *not* important for dumping.its just important when you load the file in IDA - and that is done *after* dumping the flashes.

conclusion:so when dumping memories, dump ROM0 at 0xF0000000 - 0xF1000000 and ROM1 at 0xF8000000-0xFA000000.then check when the memory content repeats.on 5D3 you will see 0xF0000000 and 0xF0080000 will contain the same data -> then you have your flash size for ROM0.and 0xF8000000 and 0xF9000000 contain the same data -> now you have your flash size for ROM1

there is *no* reason why to dump 256 megabytes from a location where the least models have any flash.and if there is any flash, its a cheap 8MiB one.

Thanks to all involved. this is very helpful...maybe in time it can all become a 'formal' wiki page. Sorry if I missed other posts, and I appreciate the refresher. Getting up to speed is a little daunting, but I will get there.

I second marekk's note about being sure how to get the addresses...any 'spoon feeding' is appreciated by those of us getting started. Platform differences make it just that much more confusing too...(mac/linux/windows)...but I will get my mac in shape eventually...:-)

If somebody finds IDA too expensive or too difficult to use there is a simple tool for disassembling the ARM code, find stubs, compare different cameras' fw, etc.It's ARMu written by me.http://armu.pel.hu

After loading the ROM, you will most likely need to load additional blobs, copied by Canon firmware from ROM into RAM and executed from there. You can find these by running the ROM in QEMU with "-d romcpy" (or just look them up in the QEMU test suite log).

Getting around:- find out where the bootloader code jumps to main firmware- follow the startup code in main firmware until you find "cstart" (it calls bzero32, then passes init_task as parameter to create_init_task)- look up something that resembles a debug message, passed as third argument (in R2) to a function called thousands of times (that's DebugMsg)- look up something that resembles a task name (e.g. GuiMainTask, CSMgrTask) and find task_create- look up AllocateMemory (usually prints NG AllocateMemory and calls GetMemoryInformation on failure)- look up the "Illegal inter" string and find out who calls it (you'll find the interrupt handler; there's one for each DryOS core in the firmware)- look up some more functions with the Finding Stubs tutorial.

./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb- you get an IDC file with lots of named functions (saved directly from the GDB script)- for example, on EOSM2, you get over 1000 named functions (not including state objects) and nearly 5800 functions total (including state object functions, named after the state machine + position in the state matrix)- Thumb functions are handled, too (tested on 80D, EOSM5 and 5D3 Eeko secondary core)