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

HF10 & HV30 (Digic DV II) decrypted!

  • 213 Replies
Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #190 on: 09 / June / 2009, 09:35:58 »
Hi terig,

it would be excellent if you could send me the sources, let me know when/where you can send them to me.

I have also written a 1394 client for linux to experiment, and it is of course much easier to retrieve the rom configuration.
After some fighting I managed to install Ubuntu, and the raw1394 lib makes it very easy to communicate with the camera and retrieve the device information structure, inclusing the vendor/model string.


« Last Edit: 09 / June / 2009, 10:02:21 by Jollyrogerxp »

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #191 on: 09 / June / 2009, 10:42:01 »
Ok, will send the sources,

To answer your question about the memory layout,  it seems like 17XXXXX addresses contain global data used by various tasks, most of it gets initialized sometimes during the setup of the system.

For example 0x1c4 bytes are copied from 0x4075318 0x1725E00 and are used by the 1394 video subsystem. Control ROM is a part of this and it starts at 0x01725ED4. It matches the values I retrieved using the 1394 connection except for the model name and the hash values that get calculated later.

Immediately after that block, starting 0x1725FC4  is a block of memory used by the shell.

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #192 on: 09 / June / 2009, 21:27:15 »
thanks for your comments, they match with what we have found ourselves, so it is good to see we weren't wrong...

Let me know how/when you can provide the win32 sources, in the mean time I will proceed experimenting with the linux-based client.


Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #193 on: 25 / June / 2009, 00:14:35 »
Hi Jolly,

I investigated the FCP subsystem a bit, here's the results. You might know this already but better to dump it here then forget it in any case.

-Fcp handler method is at 0x040C95A2
-Few instructions into this method another method is called to copy the fcp request data
-Request data is stored at 0x017212C0, this buffer can host 4 blocks of 1<<9 (512) bytes
-Counter denoting the current block is at 0x01725FB5
-Method is simple from here, first a type of request is determined, then the type of device, then the message is pushed into the fcp command queue to be handled by the main loop in the fcp task (in a separate thread).
-Hence if you want to intercept fcp request hook into this method, your data will be at 0x017212C0+(1<<9)*@0x01725FB5
-You probably don't want to inject too much code here, this is a callback and not sure what will happen if it hangs/takes long time to finish.


Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #194 on: 25 / June / 2009, 20:30:58 »
This is excellent, I did find the main FCP thread, but I didn't really have any time to check the main FCP handler, this is really good information.
I am looking at some OSD stuff, I found a lot of the LCD drawing code, lines, rectangle filling, font drawing, strings, symbols, a bit of everything...

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #195 on: 01 / July / 2009, 07:46:08 »
Unfortunately I don't have time to look at the FCP right now, I am working on the OSD dialogs, and on the PAL/NTSC switches, I will get back to the FCP as soon as I can...

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #196 on: 01 / July / 2009, 22:37:14 »
OK Jolly,

I'd be interested to hear the progress on the PAL/NTSC switches too, I traced most of them back to ROM, to me this indicates (together with dissasembling the flashing code) that the firmware is universal but the update is applied differently depending on the type.

Also, did you figure out how are camcorder key presses mapped to OSD actions? Been trying to enable service mode, but no luck so far.

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #197 on: 02 / July / 2009, 14:20:29 »
One of these days it would be good to have a chat about the PAL/NTSC switches if you can, please get online.

The firmware is definitely universal, but I believe the region setting is part of the initialization process somewhere.

I am not 100% sure and you may absolutely be correct, but I dumped the address space 0x04000000 where the main ROM is and the dump is EXACTLY identical to the firmware image contained in the update file, besides some parts in the low part of the ROM where it looks like the update process copies the part of the firmware that actually performs the flashing.

As for the service mode, because some actions are mapped to some easy to obtain keypresses, I might modify the firmware to enter service mode when one of these keypresses are performed, like turning on the camera in CAMERA mode.

I haven't started looking for the keypress management code yet, right now I am looking at something else...

« Last Edit: 02 / July / 2009, 14:23:31 by Jollyrogerxp »

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #198 on: 02 / July / 2009, 19:12:50 »
OK will try to catch you,

Here's some of my notes regarding flags:

As far as I can tell this is the most widely used PAL/NTSC flag is the byte at 0x00150027, the logic is if (x>>6)&1 the NTSC else PAL. This is referenced all over the place, the only write I could find happens very early in the OS initialization when the 0x34 bytes get copied from 0x406dcf4 to 0x150000, hence the original value of the flag is in rom at 0x0406DD1B.

This value is zero in the firmware update i'm looking at, hence the flashed camera should be PAL, in particular it should report "HV 30" instead of "VIXIA HV 30" as the model, but it's doesn't as you said before.

You should figure out what the values of 0x0406DD1B and 0x00150027 are in a running camera (preferably for both pal and ntsc models) ... then we'll know better where to look.

Re: HF10 & HV30 (Digic DV II) decrypted!
« Reply #199 on: 02 / July / 2009, 21:15:10 »
Ok good, 0x00150027 is the one I have been looking at since the beginning, so it's good to have a second opinion.

It is in my opinion the flag that all the others propagate from, and so it is the one we need to watch.
The running NTSC camera has 0xCC in 0x00150027, whereas the PAL camera (dumped yesterday thanks to a fellow owner in the UK) has 0x8C.

I know that the 0x34 bytes at 0x00150000 come from ROM, and they contain 0x00 at that position even in the ROM dump, that is why I have tried to follow up the procedures in the camera initialization to see where the flag is tested for the first time after the 0x34 bytes have been copied.
That considerably narrows down the parts of code where the flag could be set, unless of course it gets set by another device that shares that piece of address space, as from my dumps it looks like 0x00150000 might be a set of MMIO registers which is only 0x40 bytes long, and that repeats itself all the way up to 0x0015FFFF.

Reading those locations (0x00150040-0x0015FFFF) very similar values come out for all the positions in the 0x40 bytes, except for a few that vary, which could well be some registers that change in between every read that I perform for the dump.

We need to investigate it further...



Related Topics