HF10 & HV30 (Digic DV II) decrypted!

Jollyrogerxp

The FW I am working on is the HV30, I cannot test on any other cameras, thanks for offering though...

Wiesel

I recently got a broken HF100 from fellow HV20 forums member Rumple... here's shots of the mainboard and the i/o board. I just made a quick google research and could identify many of the chips in there, but not all of them... what I'm specifically missing is the mips core...

Btw. there's also a (debug?) port attached to the mainboard, it is hidden in the battery compartment unter that little rectangular plastic cover beside the serial number sticker... I can't believe nobody has seen it before. You can see the white plug on the bottom left of the mainboard.

Wiesel

i/o board picture...

cail

Wiesel, I've seen a similar plug on my HV10. Its also accessible from under battery area, but hidden with plastic.
I'm not quite good in hardware, but this could be anything from serial port to jtag port or some custom proprietary link.

BTW, since you have Flash chips, there is a chance they could be read with a ROM reader 😉

Wiesel

cail
BTW, since you have Flash chips, there is a chance they could be read with a ROM reader 😉

Do you have access to such a ROM reader? I don't :/

Another note... I have identified nearly all the chips in the cam and have saved it somewhere but can't find it anymore, but I just remembered that the H264 encoder is limited to 20mbps. That's why the 24mbps hack failed, and also the reason why the information that someone supposedly got from Canon, that HF11 firmware (if ever released) works on the HF10(0) with 24mbps as well, is probably bulls**t. So this is the proof that the HF10(0) and HF11 hardware are not the same.

edit: I found my notes and have updated the wiki: http://chdk.wikia.com/wiki/HF10/HF100

cail

I think the cost is quite small for this piece of hardware, more important is that without hardware experience it'll be quite a tricky task. Finding some hardware guy with the ROM reader could really help us.

Here: http://www.willem.org/cgi-bin/yabb22/YaBB.pl?num=1178306714 it is stated, that at least willem eprom programmer kit is able to read our ROM chip (SST39VF1601)

Another funny hardware hack I've heard people apply, is finding an existing USB flash drive with exactly the same chip (that could be quite possible), then replace the chip on a board and just plugging it into USB 😉

gl

Hi everyone,

I'm in charge of supporting the HV firmware hack over on HV20.com. I'm an HV20 user (I actually shoot in 3D with an attachment) and also a longtime C++ programmer.

We've been gathering a fund to help make the hack happen (for full details see the 1st post in our thread). Recently a member there has donated an NTSC HV30 to jollyrogerxp, and he's just had some great success:

1) The PAL firmware you've been working on successfully flashed onto the NTSC model, but kept it an NTSC cam - so the firmware will work on either (but doesn't convert between them).

2) jolly also defeated the version check and was able to flash the same firmware twice!

I'll let him fill in the details, but it's looking good. We'd now love to find a way to dump the cam's firmware, and of course we'd love a way to boot mods from the SD card (as happens in the CHDK firmware) so that we can eliminate the bricking risk and get more people trying stuff. And getting the HV20 firmware read out would be great, so people like me can take a crack at it.

Everyone on HV20.com is really enthusiastic about making this happen, we'll try to help if we can. And feel free to drop in and say hello 😀.

Jollyrogerxp

Update: I injected my very first routine written from scratch into an unused area of the FW, and by running it as a callback of an unused PTP command I have managed to dump the upper 2MB of firmware that the MIPS core uses to a file on the SD card.

At a first glance the upper part seems to contain some general purpose (libc) routines like file strings and memory operations, file open, read, write, close, etc.
This should make it easier to analyze the whole MIPS firmware, which in turn could give us more chances of finding some exploitable routines.

Cheers,

Jolly

Soultrape

Great work dude - Great work

Keep it up <3

gl

Just a thought re. the PAL firmware working on the NTSC cam... it's of course possible that the patch doesn't contain any code specific to the frame format, so it might just be lucky that it works on the NTSC cam (or that it doesn't convert it!).

And it also makes sense that any libc style routines aren't included in the patch as any bugs are more likely in Canon's main code.

jolly, how did you manage to create the dump file on the SD card?

Wiesel

gl
Just a thought re. the PAL firmware working on the NTSC cam... it's of course possible that the patch doesn't contain any code specific to the frame format, so it might just be lucky that it works on the NTSC cam (or that it doesn't convert it!).

I think the fact that the firmware update contains all PAL and NTSC related bitmaps is a strong hint that the firmware is universal. At least on the HF10 series, the only difference between the two regions is the frame rate anyway. The interesting hardware circuits like the a/v codec and hdmi interface are all universal so I guess there's no reason to develop two different firmwares (except to prevent an easy hack or save space if necessary).
The HV30 has the SD mode as additional difference, but since we're in the digital domain here where the only difference is the size of the frame (compared to different signal formats and encoding in the analog domain), I can hardly believe that the hardware is really different like some Canon tech supposedly said.

There might be a single switch somewhere that decides between the two regions, or they might compile the firmware differently for each target. But I see really no reason why an update (assuming it contains region specific code) or a complete image shouldn't be able to get a NTSC model to record PAL video and vice versa.

gl
jolly, how did you manage to create the dump file on the SD card?

I'm also interested how you achieved it. Did you utilize the file routines of the OS or did you just write the data straight to the card's address space without accounting the file system?

Jollyrogerxp

To create the dump I did the following:
- I analyzed the disassembly to find fcntl's open, close, seek, read, write routines (the difficult part was to identify them, as they are NOT in the update FW, but in the upper 2MB part)
- I found the code that responds to the USB PTP protocol commands.
- I wrote in assembly a routine that opens a file, writes to it from a memory address, closes it.
- I hooked into PTP command 1001 (Get Device Info) "stealing" a subroutine call and redirected it to my code, run it, and then execute the original subroutine.

This way my code executes when connecting the camera to my laptop, without disrupting any other process.

Next step will be to hook it up to an unused PTP command instead, such that I can trigger it by sending that command.

Jolly

Jollyrogerxp

Some more updates:

1) I put together a small toolchain based on PSPSDK (The Sony PSP also uses a MIPS CPU) that allows me to write custom routines in C, compile them and inject them into the original FW.
It is pretty raw, but this way it is much quicker to experiment with stuff...

2) I dumped a good chunk of RAM, 2MB from address 0x200000 and 64KB from 0xFFFD0000; these places should contain some interesting information about what goes on in the camera, and will also allow me where in RAM I can place some code to execute if I need to.

3) I found some flags in RAM that "know" about the region of the camera, and direct some operations of the camera, such as reporting its specific model name ( "Canon HV30" for PAL, "Canon VIXIA HV30" for US, "Canon iVIS HV30" for Japan).
I want to investigate where they get set upon startup, such that perhaps we can infer from this what determines the region of the camera when it boots.

Jolly

Wiesel

Well done! Now I just wish I had a HV30 😉

gl

WieselI think the fact that the firmware update contains all PAL and NTSC related bitmaps is a strong hint that the firmware is universal.

Didn't know that, makes sense.

The HV30 has the SD mode as additional difference, but since we're in the digital domain here where the only difference is the size of the frame (compared to different signal formats and encoding in the analog domain), I can hardly believe that the hardware is really different like some Canon tech supposedly said.

I wouldn't trust that tech either, most guys you talk to in these companies don't know what they're talking about the minute you get off their script (but they all think they do). The only difference could be timing-related (different crystals?) but that seems less likely with digital cams.

Awesome work jolly! Is there a freeware disassembler so we can help study the code?

Embedded Visual C++ 4.0 is free & supports a flavour of MIPS (it was used in earlier Pocket PCs, I still have one and v3.0 installed for it), but I don't know if it's the same architecture?

Jollyrogerxp

I am not sure about good free disassemblers, I still have IDA pro from ages ago when I purchased a license.
As for the compiler, the HV30 uses a MIPS core in big-endian mode, I don't remember if Embedded Visual C supports both endiannesses, but it probably does.
Anyway the gcc based toolchain works well and allows me to output the code in flat form, which makes it easier to embed...

Wiesel: you mentioned the card address space, where did you see it in the HF? I might have seen it at 0x2000000 on the HV30 but I am not sure if it actually is the card or some RAM...

Jolly

Wiesel

gl[...] most guys you talk to in these companies don't know what they're talking about the minute you get off their script (but they all think they do) [...]

Sad, but true.

Jollyrogerxp
Wiesel: you mentioned the card address space, where did you see it in the HF? I might have seen it at 0x2000000 on the HV30 but I am not sure if it actually is the card or some RAM...

Sorry I didn't see it... it was just the only alternative I could think of in case you didn't use the file handling functions.

Jollyrogerxp

Wiesel, as for the moment I am focusing on the MIPS core, it would be nice if you could take a deeper look at the FR71, for example to try to identify where the two cores talk to each other, or to find out how the region gets set.
At address 2E7D8C of the FR71 there seems to be a 0/1 flag that determines the PAL/NTSC menu messages, it would be nice to find out where it gets set at startup, I haven't had any time to look into that...

Ah also, do you use special settings/scripts for IDA to analyze MIPS code?

Cheers,

Jolly

Jollyrogerxp

I have put together a small toolchain for the FR71 too, so I can compile code and hook it into the firmware.

I am using a hook into the hidden menu (rec+photo at turn on) to run code without chances to break other parts of the FW functionality.
So far I haven't been able to write code for the FR71 that produces any kind of tangible output, of course it is easy to change a few strings here and there to be displayed, but that is not the point, I want to dump memory areas that we cannot see in the update file.

It looks like the FR doesn't communuicate with the SD card directly, so we need to understand how the FR and the MIPS talk to each other somehow...

Jolly

Wiesel

Jollyrogerxp
Wiesel, as for the moment I am focusing on the MIPS core, it would be nice if you could take a deeper look at the FR71, for example to try to identify where the two cores talk to each other, or to find out how the region gets set.
At address 2E7D8C of the FR71 there seems to be a 0/1 flag that determines the PAL/NTSC menu messages, it would be nice to find out where it gets set at startup, I haven't had any time to look into that...

I'll take a look into it during the week. Do we actually know why there are two cores? The only references to the FR71 that I've found are image processing ICs of the MB9xxxx series, may this be the case here as well?

Jollyrogerxp
Ah also, do you use special settings/scripts for IDA to analyze MIPS code?

I just have the scripts that Cail posted here a long time ago, you can find them in the chdk repository here: http://tools.assembla.com/chdk/browser/branches/cail-digicdv/hv30_analysis

« Previous Page Next Page »