Browse Groups

• ## Re: 20D encryption - some details here

(34)
• NextPrevious
• 1. Initial assumption I beleeve that encryption algorithm is same as used in previous versions, and only key are changeg (as it was with S70). So key are
Message 1 of 34 , May 30, 2005
View Source
1. Initial assumption
I beleeve that encryption algorithm is same as used in previous
versions, and only key are changeg (as it was with S70). So key are
repeated each 512*513 bytes. I'm get firmware file and split it into
512*513 bytes pieces, then xor this pieces each other in different
combinations. I can see strings somewhere in results, so assumption
is true.

2. Some encryption algorithm feature
If we xor all 512+513 bytes of both subkeys with same arbitrary byte,
we get same result key because (a xor x) xor (b xor x) == a xor b.
Keep it in mind.

3. That we are needed to restore encryption key ?
We are needed only 1024 bytes of continuous plaintext (equivalent to
1024 bytes of encryption key). Assume for simplicity that we have
first 1024 bytes of key (if we have some other 1024 bytes, we need
XOR first half of it (512 bytes) this second half.
key1 values are equal in same positions of both halves, so in result
first byte is key2[512] xor key2[0], second byte is key2[0] xor key2
[1], and so on up to last byte is key2[510] xor key2[511]. Now
remember algorithm feature and assign arbitrary value to key2[512].
We can then get all key2 and key1 values. These may be not same as
used by Canon, but produce same encryption key. (if we have 1024
bytes of key not at the beginning, we just start not from key2[512],
but from some place at middle of key2).

4. Where to get plaintext
It's simply. We are have many pieces from first step.
If A xor B give us some strings, and A xor C give some other strings
at same place, then there are definitely zeroes at this place in A.
So we only need to find some long enough farment.

--- In canondigicamhacking@yahoogroups.com, Alex Bernstein
<pofig37@g...> wrote:
> Awesome! Would be great to hear how you've accomplished it.
>
> I've noticed that S1IS firmware ended with a long section of FFs, so
> the last thing I've tried last night was to take the tail end of 20D
> firmware starting on 512*513 boundary and XOR it with FFs hoping
that
> this would give me a long section of the key. Unfortunately, that
> didn't lead anywhere, and I gave up and went to sleep as it was past
> 4am. Looking at the firmware decrypted with your decrypter there
are
> no FFs at the end so this indeed was a dead end.
>
> --AlexB
> On 5/30/05, alex_polushin <polushin@n...> wrote:
> > I'm upload working 20D firmware decryptor into files section.
• First of all, is good to see some activity for the newer ARM-based cameras is going on. I ve been dissassembling (using IDA) the firmware updates of the
Message 34 of 34 , Aug 3, 2005
View Source
First of all, is good to see some activity for the newer ARM-based
cameras is going on.
I've been dissassembling (using IDA) the firmware updates of the
Powershot SD400 and SD500. I own an SD300, so first I needed Softice
live-cracking of the updater (was update.exe?) to "convince" to save
the firmware in the SD card (it would check for an SD400/500 and would
fail with my SD300 if not forced).

So I ended up with the firmwares, decrypted them (thanks again Alex
Bernstein and Alex Polushin!!!) and started dissassembling with IDA.

But as you may already know, it is extremelly painful.

Now I see you got some usefull offsets where to start loading to
automate the task a bit. Could you please comment a bit deeper your
findings? (maybe we can do it in the Powershot hacking group)...

I'm still struggling against separating what's pure-camera related
code from that just used by the Vxworks OS...

Any comments on LDA? I've never used it yet... Should I?

Thanks everybody,

Alex, el_yopo. (the third Alex)

--- In canondigicamhacking@yahoogroups.com, Alex Bernstein
<pofig37@g...> wrote:
> No question IDA is great, especially the interactivity aspect of it.
> But once you gain some insight into the structure of the code and
> would like to apply it to the resto of the code, it becomes very
> tedious. I suppose IDC could help, but LDA offered the ultimate
> customizability taking care of RXE references, Canon's EMS
> architecture, etc. Also LDA text files were easier to share than
> unwieldy .idb files. Much of the success of the Undutchables is
> probably due to the work that went into LDA.
>
> That said, I recently took a look at the latest 20D with IDA. It looks
> that if you load the decrypted file at the address 0x800000 it starts
> to disassemble quite nicely as 32-bit little endian ARM code. That
> first part of it seems to be the upgrade procedure itself, that
> possibly copies the rest of the file into different memory regions.
> The next part of the .fir that starts at the offset 0xbc1c0 looks like
> it should be in the memory at the offset 0xFF810000.
>
> --Alex
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.