Right now, we are still limited by the compression engine implemented by Canon; its output simply happened to be valid for both CR2 and DNG, so we just changed the header and did some minor layout tweaks. Not sure what's the point of using other formats in this case.
If we manage to identify the DSP, that might be a different story.
Some other notes:
I've attempted to verify the hypothesis about 4C XX (relative jumps). On 60D, I did the following changes (works with either Debug -> Memory Browser or as C code):
/* hardcoded for 60D */
uint8_t * jpcore = (void *) ((MEM(0x350A0) + 31) & ~32);
/* original: jpcore[4:5] = 4C 7E => probably jumps to 0x100;
* jpcore[0x30] is in the middle of a string (400D) or spaces (60D)
*/
jpcore[0x5] = (0x30 - 0x4) / 2; /* jump to 0x30 instead */
jpcore[0x30] = 0x4C; /* from 0x30, jump to 0x100 */
jpcore[0x31] = (0x100 - 0x30) / 2;
Result: success (can take photos, can review them).
Next change (on top of the others):
jpcore[0x31] = 0; /* infinite loop */
Result: crash when taking photos (JPCORE interrupt not triggered).
On 60D, I've found the JP62 (H.264) firmware at 0xFF647D70 (initialization visible in QEMU, unlike 5D3). The code frequencies don't seem to match the regular JPCORE at all, so I guess it may be a different architecture.
16-bit codes with 16-bit alignment:
Code 60DJP62
0000: 5288
0ca8: 306
0010: 301
0020: 255
0001: 238
20c0: 149
0c0c: 124
5600: 123
f01d: 113
1ca8: 108
