Some notes on more modern digic dv. FWIW, I do not have any of these cams, don't do much with video, and have no plan to develop anything for them. I'm just recording information that has come out of discussion in IRC in case someone finds it useful in the future.
@Wiesel's tool posted above works on Digic DV 6 firmware updates. Observations below are based on xf705 v 1.0.4.1, which is available from Canon sites.
The decrypter identifies this as file format 3, and generates a single output file, which has 5 blobs delimited by VOAX followed by version number and 0 as 32 bit ints.
I split these with the following chdkptp lua
!dump=fsutil.readfile_e('VOA4_decrypted.bin','b')
!chunks=util.string_split(dump,'VOAX\x01\x00\x04\x01\x00\x00\x00\x00',{plain=true,empty=false}) return #chunks
!for i,chunk in ipairs(chunks) do fsutil.writefile_e(chunk,('VOA4_%d.bin'):format(i),'wb') end
There's a trailer at the end of the chunks, but I didn't bother trimming it. Below, chunks are named 1 through 5.
AFAIK chunk 1 is related to encoding, and does not contain code. (srsa_4c: it's a "Canon-style MMU-table, just like the ones on D7 and D8")
The remaining chunks contain thumb2 code. Digic DV 6 appears recognizably related to regular digic 6 (
edit: or Digic 7, since it has an MMU), there are references to Marius, Omar and Zico, and the main code disassembles well using armv7 little endian. It's clearly not from the same codebase as P&S, though there are some shared features (more on those later).
(edit: per srsa4_c "xf705 blobs/disasm that blob3 is for (at least) dual core ARM with MMU")
Chunks 2 and 4 are small and appear to be bootloader/romstarter type stuff (edit: or maybe the flasher?). By size alone, chunks 3 and 5 must be the main code.
Note that unlike P&S firmware updates (but presumably, like earlier DV cams?), the update itself is NOT an executable. Some other thing in the existing firmware must flash the blobs to the appropriate locations (edit: may be wrong).
Chunks 3 and 5 start with recognizable startup code, copying some ROM code and data to memory at 0x100000 and (presumably) TCM at 0xdf003000, as well as zeroing some chunks. This allows identifying the load address of the ROM by identifying what source address results in consistent thunks between the two. This is 0xe0040020
for both chunks 3 and 5. It appears dual Digic DV 6 consists of two separate SOCs, each with its own RAM and ROM, and some communication between them. Chunk 3 appears to be referred to as chip0 or master, and Chunk 5 as chip1 or slave.
The code copied to TCM seems to be DryOS kernel code, similar to regular digic6.
A simple memory map for chunk 3 from the copies and zeros
TCMCODE
adr DF003000
len 0xcf0
file offset = 0xe0db5670 - 0xe0040020 = 0xd75650
RAMCODE
adr 0x00100000
len 0x5237cc
file offset = 0xe0db6360 - 0xe0040020 = 0xd76340
TCM1
adr 0xdf000000
len 0x3000
BSS0
adr 006237cc
len 0x23f0
BSS1
adr 00626248
len 0x7d20c4
Chunk 5 / chip1 is the same, except the sizes/offsets
TCMCODE
addr 0xDF003000
len 0xcf0
file offset 0xE12A3368 - 0xe0040020 = 0x1263348
RAMCODE
adr 0x00100000
len = 00376948 - 00100000 = 0x276948
file offset = 0xe12a4058 - 0xe0040020 = 0x1264038
TCM1
adr 0xdf000000
len 0x3000
BSS0
adr 0x376948
len 0xf84
BSS1
adr 0x377F58
len 52ace0
... to be continued
