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

HF10 & HV30 (Digic DV II) decrypted!

  • 215 Replies
  • 141030 Views
*

Offline cail

  • *
  • 49
Re: HF10 (Digic DV II) decrypted!
« Reply #30 on: 18 / June / 2008, 09:47:57 »
Advertisements
Tracking the USB interface is really useful,
here is a good story on how USB may be cracked: Pure Digital / CVS Disposable Digital Camcorder

The problem is that I guess it is nearly impossible to crack USB from "outside".
We anyway need a kind of 'backdoor secret' to be understood from the firmware code.
And to do this the analysis should be deepened.

Attached is an archive with some tools:
It contains:
 - An improved decryptor, which now separates the file onto two sections.
 - IDA scripts from CHDK slightly modified to help in the analysis
 - IDA m32r recompiled and fixed disassembler plugin.

Any help is welcome! :)

*

Offline Yin

  • *
  • 3
Re: HF10 (Digic DV II) decrypted!
« Reply #31 on: 19 / June / 2008, 02:51:37 »
Basically i was looking for any indications that the HF100 supports DFU via USB. So what is DFU? DFU stands for "Device Firmware Upgrade" and would provide access for downloading and uploading Firmware files from / to an USB device. (see http://www.usb.org/developers/devclass_docs/usbdfu10.pdf) This way would have been cool but it seems the HF100 does not support this.

*

Offline cail

  • *
  • 49
Re: HF10 (Digic DV II) decrypted!
« Reply #32 on: 21 / June / 2008, 16:58:12 »
Some sum-up of known facts:

HF10/100 Firmware Analysis - CHDK Wiki


Re: HF10 (Digic DV II) decrypted!
« Reply #33 on: 24 / July / 2008, 10:33:19 »
I posted some details on the HV30 page as a firmware update for that is also available. How can I help ? I have a background in embedded systems too. This probably uses vxWorks 5.4 - an older vxWorks version without memory protection..
I own a HV20 but would be willing to get a HV30 for testing..
CHDK used for a Bullet-time sequence
Welcome to mishra.tv productions


Re: HF10 (Digic DV II) decrypted!
« Reply #34 on: 27 / July / 2008, 19:28:15 »
I posted some details on the HV30 page as a firmware update for that is also available.

here's a decrypter for the HV30 firmware... they used the same key/algorithm that was used for the HF10, just a few parameters had to be adjusted.

*

Offline cail

  • *
  • 49
Re: HF10 (Digic DV II) decrypted!
« Reply #35 on: 27 / July / 2008, 19:41:38 »
Big fun is here.

The processor is Fujitsu FR71, some references gives MB8AA101 chipset.

Firmware layout is similar to HF100, 0x200000 piece of data, and then code section to be loaded at 0x4000000.

Not sure about OS, however "DRYOSV2" string exists in the f/w.

*

Offline cail

  • *
  • 49
Re: HF10 (Digic DV II) decrypted!
« Reply #36 on: 28 / July / 2008, 05:40:40 »

Re: HF10 (Digic DV II) decrypted!
« Reply #37 on: 28 / July / 2008, 13:38:37 »
The problem is that I guess it is nearly impossible to crack USB from "outside".
We anyway need a kind of 'backdoor secret' to be understood from the firmware code.

I just had some time to read the articles about that hack, that sounds very interesting... I don't have my cam with me this week but I guess I'll try that next week.


The processor is Fujitsu FR71...

What I have wondered with the HF10 FW as well, how do you find out the exact processor model?


Not sure about OS, however "DRYOSV2" string exists in the f/w.

That string exists in both FWs, and since Canon says they use it for their video cams I think we can safely assume that this is the right OS.

Btw, I was just searching for file names and stuff and came over some devices and paths, strangely some are unix style, and some are dos style. Could that maybe mean that DryOS is based on a unix/linux kernel and those dos style paths are to access the FAT storage devices? (A text file with the paths is attached)


edit: what I forgot earlier... what if there's no USB backdoor?
« Last Edit: 28 / July / 2008, 14:12:41 by Wiesel »


*

Offline cail

  • *
  • 49
Re: HF10 (Digic DV II) decrypted!
« Reply #38 on: 28 / July / 2008, 16:41:09 »
What I have wondered with the HF10 FW as well, how do you find out the exact processor model?
Thats the easiest thing. Both FW have strings with list of registers - using them the processor line could be easily googled. Then, at most any compiler includes processor specific libraries which contain strings with IDs. For HV30 thats a FR71 and mainboard id MB8AA101.

BTW, both of them are not listed in official fujitsu docs, this means they could be designed specially for canon (or even by canon).


Btw, I was just searching for file names and stuff and came over some devices and paths, strangely some are unix style, and some are dos style. Could that maybe mean that DryOS is based on a unix/linux kernel and those dos style paths are to access the FAT storage devices? (A text file with the paths is attached)
Yes, thats strange. However, from my CHDK experience, embedded systems often offer a simplified model for file IO, and it could be easily mixed with dos/unix styles.

edit: what I forgot earlier... what if there's no USB backdoor?
Good question. We have to find it.
The best option we may wish is to have something similar to autoload feature we have in powershot CHDK now. To find it out we need a way to extract and understand ram layout and bootloader area.

So, IDA f/w analysis is the main  point we can do now, imho.

Re: HF10 (Digic DV II) decrypted!
« Reply #39 on: 28 / July / 2008, 17:16:53 »
Thats the easiest thing. Both FW have strings with list of registers - using them the processor line could be easily googled. Then, at most any compiler includes processor specific libraries which contain strings with IDs. For HV30 thats a FR71 and mainboard id MB8AA101.

Unbelievable, I would've never imagined that it's that easy... I mean there are so many processors that chances are high that many have the same amount af registers and register names, but I just tried it myself and yeah I found out the processor in a couple of minutes. thanks!


So, IDA f/w analysis is the main  point we can do now, imho.

Ok so does that mean that we have to find a way to inject code into the firmware that reads out the bootloader and ram, upload it to the cam by the firmware upgrade mechanism, and then search the bootloader for an autoload mechanism?

 

Related Topics