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

HF10 & HV30 (Digic DV II) decrypted!

  • 215 Replies
  • 141302 Views
Re: HF10 (Digic DV II) decrypting...
« Reply #10 on: 11 / June / 2008, 16:56:46 »
Advertisements
Ok, it seems this key has no much relation to 512x513 key, but the funny thing is that it has some similarities (if you'll layout 512x513 into the linear).

I'm still not sure it is fully valid, because I've constructed it half manually. But, at least it works :]]

Attached.

Re: HF10 (Digic DV II) decrypting...
« Reply #11 on: 12 / June / 2008, 01:14:20 »
yeah it works... that saved me a lot of time, thanks :)

Re: HF10 (Digic DV II) decrypting...
« Reply #12 on: 12 / June / 2008, 04:40:26 »
I just figured out the algorithm that they used in combination with the two 300D keys to encrypt the file... will post some code later.

*

Offline kmaage

  • *
  • 12
  • HV20, Norway, Newborn, Software Developer
Re: HF10 (Digic DV II) decrypting...
« Reply #13 on: 12 / June / 2008, 05:27:49 »
c-letter: Thanks so much for your work!

Wiesel: "I just figured out the algorithm" Do you mean that the work that c-letter did manually can actually be expressed as an algorithm? Does the algorithm give the exact same results as c-letter's code?

So, this means that compiling and running decrypt_hf100.c against VEE1.FIM I get a decoded firmware file (which we're pretty sure is valid), ready for disassembly and examination? (or should I wait until Wiesel has posted his code?)


*

Offline mx3

  • ****
  • 372
Re: HF10 (Digic DV II) decrypting...
« Reply #14 on: 12 / June / 2008, 05:31:23 »
So, this means that compiling and running decrypt_hf100.c against VEE1.FIM I get a decoded firmware file (which we're pretty sure is valid), ready for disassembly and examination? (or should I wait until Wiesel has posted his code?)
c-letter did good job (I wonder how could he do it...)
and his decryptor has nothing to do with 300D

IMHO there can't be beter decrypter than c-letter's
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

Re: HF10 (Digic DV II) decrypting...
« Reply #15 on: 12 / June / 2008, 05:54:39 »
Wiesel: "I just figured out the algorithm" Do you mean that the work that c-letter did manually can actually be expressed as an algorithm? Does the algorithm give the exact same results as c-letter's code?

Yes that's right... it's an algorithm based on the two 300D keys. I did a quick comparison and my result is the came as c-letters so his manually constructed xor-table is 100% right.

*

Offline mx3

  • ****
  • 372
Re: HF10 (Digic DV II) decrypting...
« Reply #16 on: 12 / June / 2008, 06:09:08 »
it's an algorithm based on the two 300D keys. I did a quick comparison and my result is the came as c-letters so his manually constructed xor-table is 100% right.

well.
very strange results
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

Re: HF10 (Digic DV II) decrypting...
« Reply #17 on: 12 / June / 2008, 06:16:41 »
Here's an enhanced version with an option to omit the unencrypted file header like c-letter's version does. The only difference now is that c-letter's version adds 3776 bytes to the end which shouldn't be there.

Btw. c-letter, I'm not trying to downplay your work, it's just for the matter of completeness.  :-[


*

Offline mx3

  • ****
  • 372
Re: HF10 (Digic DV II) decrypting...
« Reply #18 on: 12 / June / 2008, 06:26:51 »
The only difference now is that c-letter's version adds 3776 bytes to the end which shouldn't be there.
agree.
8352656 - 0x10010 = 8287104

Btw. c-letter, I'm not trying to downplay your work, it's just for the matter of completeness.  :-[
it is not competition.
your work compliments each others


anyway.
strange results.
can you explain what is going on?
what length of cipher block ?
according to c-letter it is 0x1040
and he would not be able do decrypt thing otherwise
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

Re: HF10 (Digic DV II) decrypted!
« Reply #19 on: 12 / June / 2008, 07:47:00 »
They used the first 64 bytes of key1 and the first 65 bytes of key2. key 1 and 2 are the 300D keys which are originally 512 and 513 bytes long.

The algorithm works in a cycle with two counterrotating inner cycles, as follows:
Code: [Select]
do

  decode 64 bytes, begin with key1[ 0] and key2[ 0]
  decode  1 bytes, begin with key1[ 0] and key2[64]
  decode 63 bytes, begin with key1[ 1] and key2[ 0]
  decode  2 bytes, begin with key1[ 0] and key2[63]
  decode 62 bytes, begin with key1[ 2] and key2[ 0]
  decode  3 bytes, begin with key1[ 0] and key2[62]
  decode 61 bytes, begin with key1[ 3] and key2[ 0]
  decode  4 bytes, begin with key1[ 0] and key2[61]
  .
  .
  .
  decode  2 bytes, begin with key1[62] and key2[ 0]
  decode 63 bytes, begin with key1[ 0] and key2[ 2]
  decode  1 bytes, begin with key1[63] and key2[ 0]
  decode 64 bytes, begin with key1[ 0] and key2[ 1]

while decodedbytes != 0

If you just blindly calculate it, the resulting one-dimensional cipher block is 4160 bytes long, which is c-letter's size (0x1040 = 4160).
« Last Edit: 12 / June / 2008, 07:50:17 by Wiesel »

 

Related Topics