HF10 & HV30 (Digic DV II) decrypted! - page 22 - General Discussion and Assistance - CHDK Forum

HF10 & HV30 (Digic DV II) decrypted!

  • 215 Replies
  • 148262 Views
Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #210 on: 28 / February / 2013, 08:09:19 »
Advertisements
Get it before anyone else does. Service manual is here (free!):

http://drop.io/hidden/dvrp2khjrfobjx/asset/Y2Fub24taHYyMC1odjIwZS1zZXJ2aWNlLW1hbnVhbC1yZXBhaXItZ3VpZGUt
emlw


Proves the JTAG is in there. Unfortunately its the not connected spot. You can at least solder wires to it directly or make your own connector. Pinouts for JTAG and schematics are in there as well. As well as "service mode".

Would you please send me the Service manual ?

E-mail: 392240093@qq.com

Thank you very much!

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #211 on: 29 / June / 2013, 06:04:08 »
It's possible to upgrade the CANON HF100 firmware using the latest HF11 firmware (needs hacking).

Using the latest SD-card (class 6) and HF100 (with hacked HF11 firmware) it's possible to get the highest video bitrate (better quality) and additional features.

In practise this means that it's possible to get all the latest features of HF11 on a much cheaper HF100.
It would be great since the latest HF11 (1.0.1.0) & HF100 (1.0.3.0) firmwares enables support for class-10 cards...

Changelog (identical for both, another evidence that HF100 could be replaceable):
Quote
Fixes have been made so that these models are now able to record, play back, and copy movies in FXP mode with SD or SDHC memory cards that have an SD Speed Class of Class 10. Due to the camera system, the characters "Class 10" cannot be displayed on the card information screen in playback mode, but they can be displayed in camera mode.


Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #212 on: 07 / December / 2014, 12:17:49 »
Hey guys,

I recently got nostalgic and updated my universal decrypter to support firmware updates of all models released up until now :)

You can find it in this GitHub repo:
https://github.com/protyposis/CanonCamcorderFirmwareTools

Cheers!

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #213 on: 05 / January / 2017, 07:00:45 »
Trying to resurrect an old thread. Did anyone ever try the PAL/NTSC switch on the HV40? Thinking of using the HV40 with my Ninja Star recorder.
CHDK used for a Bullet-time sequence
Welcome to mishra.tv productions

*

Offline reyalp

  • ******
  • 14125
Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #214 on: 08 / February / 2022, 17:25:57 »
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
Code: [Select]
!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
Code: [Select]
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
Code: [Select]
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
« Last Edit: 31 / May / 2022, 12:46:21 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14125
Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #215 on: 08 / February / 2022, 18:46:47 »
Some general observations. From chunk 3, unless otherwise noted.

Canon Basic appears to be supported, based on string with the usual keywords, references to extend.m and some other possible script file names, and references to creating a script card.

The script card is almost certainly identified using an different mechanism from P&S. Some preliminary analysis suggests the identifier is based on values from SD card registers, which would be unique for a given card (functions called from e011956c). How a script would be activated is unknown.

Event procedures exist. Some names known from P&S like FA.Create, Mecha.Create etc are present, though some appear to be NOP, perhaps kept for compatibility. Eventprocs appear more integrated with a CLI, eventproc tables often include a pointer to a help string in addition to the name and function. Similarly e0338be6 appears to be a registration function that takes a help string in r3.

As mentioned in https://chdk.setepontos.com/index.php?topic=4338.msg147752#msg147752 some of the PTP / eventproc system seems to be present. "InitiateEventProc\n" "ExecuteEventProc\n" exist as string in the xf705 firmware in an area apperently related to PTP. Additionally, a user with an xf605 (a newer digic 7 dv cam, for which there are no public firmware updates) confirmed it supporting the initiate / terminate opcodes in PTP device info (full list attached).

Interestingly, PTP functionality does not appear to be documented on these cams. The function of the USB port(s) is controlled by various menu settings, but nothing in the manual obviously describes typical PTP usage. On the xf605, there is a USB setting called PTP/GPS for use with Canon GP-E2. Using this setting, they reported that attempting to access the camera with
Code: [Select]
gphoto2 --port usb:... --list-config
repeatably caused the camera to crash with a "fan error"  :o

I'm not clear exactly which opcodes gphoto2 --list-config uses, but based on how P&S respond, it appears to include GetObjectHandles. gphoto2 --summary did not crash the cam (and does not issue GetObjectHandles), and neither did connecting chdkptp as shown in the log.

edit:
xf605 "fan error" seems to be caused by gphoto sending canon extension opcodes when it sees a Canon vendor ID (doing this blindly on an entirely different class of camera seems suspect). The last one sent before the crash is  0x911b (EOS_SetUILock), although it's possible some other one is the trigger.

The fan does actually stop when the error happens  :o

Standard PTP commands relating to storage and object handles seem fine.

InitiateEventProc appears to expect a data phase on xf605.

From disassembly, InitiateEventProc in the xf705 firmware does not obviously use a dataphase, and appears to just a set a flag (only needing to be called once, not 3x like P&S) suggesting xf605 may have adopted the new system seen on still cams. 0x9050 and 0x905c are handled differently, with 0x905c setting an additional flag. Strings suggest 0x905c is called InitiateServiceEventProc (e0166ad4).

PTP handling on xf705 seems very different from P&S, instead of having registered handler functions, the logic appears to involve convoluted conditionals statements (starting around e011884e)

On a somewhat related note, there are references to a "service card" which parallels the script card logic.
« Last Edit: 09 / February / 2022, 18:00:45 by reyalp »
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal