HF10 & HV30 (Digic DV II) decrypted!

Wiesel

Jollyrogerxp
This is brilliant, we need to make sure the HV30 decoder is updated accordingly too.

I think most of what I found in the first section of the HV30 firmware should be also valid for the HF10, so it would be good to begin inspecting that piece of MIPS32 code/data to decide some places to start injecting custom code.

Yes I can verify that the first section of the hf10 fw is mips32 code as well.

bassie666

Hi peeps,

I have a hf100 and am willing to test new firmware, I asume it would be able to run hf11 24mbps 😉
Don't know much about checksum programming but do want to test and help if needed.

Cheers

Rob

Jollyrogerxp

Wiesel

Jollyrogerxp
This is brilliant, we need to make sure the HV30 decoder is updated accordingly too.

I think most of what I found in the first section of the HV30 firmware should be also valid for the HF10, so it would be good to begin inspecting that piece of MIPS32 code/data to decide some places to start injecting custom code.

Yes I can verify that the first section of the hf10 fw is mips32 code as well.

Wiesel, we should really start cross-referencing our research rather than pressing on in parallel directions, that way I think we can be more effective.

Cheers,

Jollyroger

kage

From looking at the photos of the PCB that Sprawler posted a couple of things stand out. I can't make out the value of the canned CMOS clock OSC but the MCU closest to it will most likely be the core. From a PCB designers view, you want the traces between the MCU and the OSC as short as possible to keep parasitic capacitance to a minimum. It's difficult to say if it's the MB87Q1211 next to it, or another part on the adjacent side of the PCB.

The 24.576Mhz xtal reference (sawtooth gen) is most likely used for graphic encoding/decoding. So the smaller MB8 here is probably a dedicated co-processor. The orientation also infers that both Fujitsu parts have their clock input lines close to pin 1.

The MB87Q1211 is probably the main MPU. There will probably be blocks of the firmware that are to be loaded into other co-processors on the board. With this in mind care should be taken to identify the code blocks and disassemble them independently or keep the co-processor binaries intact. Even though theses 2 parts are Fujitsu MB87 series even a slight change in the mapping of each parts internal peripherals will result in confusion.

kage

laoyang

The MB87Qxxxx is 0.11?m ASIC Standard Cell
http://edevice.fujitsu.com/fj/MARCOM/find/19-5j/pdf/19_5j_5.pdf
http://edevice.fujitsu.com/jp/datasheet/j-ds/j620208.pdf

kage

Hi Laoyang,

The CPU/DSP section of the datasheet lists ARM9, ARM7TDM. I'm assuming that you can read the datasheet, as it is not in my native english. Are you sure that the core is not synthesized ? If so scratch what I said previously.

K

Jollyrogerxp

Right now it looks pretty clear that at least one of the cores is a MIPS derivative, as one part of the FW update containing the USB and SD/MMC drivers seems to be MIPS32 code.
Another core (on the HV30) is a Fujitsu FR71, which seems to be the one that controls the main camera functionality.

As for the other parts, there could be additional code/data spread in the FW that is to be directed to other processors/DSPs on the board, we haven't seen it yet, but it could well be in there somewhere, in the data sections that haven't been mapped/recognised yet...

Obviously the various parts need separate disassembly/analysis to avoid compromising the functionality.

Jollyroger

Wiesel

Jollyrogerxp
This is brilliant, we need to make sure the HV30 decoder is updated accordingly too.

Here's my "universial decrypter", it detects the camera model and crypts the file accordingly... there are also options to split the file into sections and calculate a new checksum.

ud.c

14.61KB

Jollyrogerxp

Superb! Now I just need a HV30 to play with 😀

We should try to start dumping the area above 0xBFDC0000 of the MIPS32 core, as that part contains all of the OS specific code for that core, so we can see how we can load some code up and run it more easily.
Also it could give us some hints on how to run something on an unmodified camera, as we don't have any FW for the HV20 for example...

Please let me know when you have some time for a MSN chat!

Jollyroger

lunaticlabs

Pardon my ignorance as far as using IDA and disassembling this. The processor is a Mitsubishi M32R right? Which variation of the processor did you use? You also said the code starts at offset 0x04000000, but the firmware binary isn't that large. Are you mapping the sections to different addresses?

Jollyrogerxp

lunaticlabs
Pardon my ignorance as far as using IDA and disassembling this. The processor is a Mitsubishi M32R right? Which variation of the processor did you use? You also said the code starts at offset 0x04000000, but the firmware binary isn't that large. Are you mapping the sections to different addresses?

On the HF10 the processor is a M32R, whereas on the HV30 the processor is a FR71 (or so it seems).

The FW file contains several sections of code/data; these sections are loaded to specific places in the processor's address space, it is apparent by looking at the cross references that are present in the data and code.
So yes the various pieces of binary are mapped to different addresses, more specifically it looks like for both processors the first section is mapped to 0x04000000.

There is a different section which composes the first 0x00200000 bytes of the FW update file in both the update files for the HF10 and HV30. Recently we discovered that this section contains data and code for a different processor core (MIPS) and it seems to be mapped to the address 0xBFA00000.

Cheers,

Jollyroger

Jollyrogerxp

Ok my current problem is that I have a HV20 so I cannot really try any FW modifications until we manage to find a way to run code on an unmodified camera, which in turn is something non trivial on it as we don't have any FW for it yet...

cail

From our private talk with Jollyroger:

Jollyrogerxp wrote:
At the moment as I said I am a little stuck as I don't have a HV30 to experiment with, so I am thinking about what else I can do.
One thing is to analyze further all the routines in the MIPS code that handle the PTP, and trying to check if there is any way we can use a buffer overflow exploit there...

Yeah, thats also a problem for me with the HV30 unavailability. I've heard some rumours in hv20 community to help to find us an partially broken hv30 to experiment. This could allow us to modify existing firmware and force it f.e. to dump memory via usb directly (or via miniSD card). That technically can be done, since we now can fix the CRC.

Without memory dump and layout understanding it'll be quite difficult to find a way to inject code using any kind of exploit IMHO (but of course it's still possible for someone lucky).

Wiesel

cail
I've heard some rumours in hv20 community to help to find us an partially broken hv30 to experiment. This could allow us to modify existing firmware and force it f.e. to dump memory via usb directly (or via miniSD card). That technically can be done, since we now can fix the CRC.

This was my original intention but the current situation is that I got a repair guarantee from "_gl" on the HV20 forums, which means that I'd get the collected money to fund a potentially needed repair if my cam gets bricked by a firmware update. But I have an HF10.

kafeero

Hey everyone.
I am a member of HV20.com and I would like to help in any way possible. I have an HV30 and if you send me instructions, I may be able to test it out.

Jollyrogerxp

Hi kafeero, the problem is that we would need to experiment with several modifications of the fw and the process of sending you something to flash, then waiting for the results and repeating the process on and on takes a very long time...

vorob

HF10 & HV30 (Digic DV II) decrypted, but where is result of this?) Any firmware that will give me possibility to capture 24mbit on my HF100 for example 😀

vorob

Hello, any life here?)

Jollyrogerxp

Hello vorob, unfortunately I am stuck with not having any hardware to test with.
We have arrived at a point where we can modify some small pieces of the firmware and try dumping more firmware, the missing parts, but neither myself nor Wiesel have any hardware to test this.

lunaticlabs

I am willing to test it, and I have an HF100. Do you want to send me what you want to test?

« Previous Page Next Page »