## Re: 40D firmware decryption

Expand Messages
• I checked, there is not that much of continuous text. But there is a way out, we can generalize the method. Suppose we have split the text into blocks of
Message 1 of 19 , Dec 20, 2007
• 0 Attachment
I checked, there is not that much of continuous text.
But there is a way out, we can generalize the method.

Suppose we have split the text into blocks of 512*513 bytes, say A, B,
C, ...
Now xor every pair together to obtain A^B, A^C, etc.
By finding clear text, like english (or some other language) strings,
we can find segments in say A^B, where either A or B must be 0.
Typically, from the text, we can say derive which one it is, because,
say B^C also shows some text, or because A^C shows the same text, or
because strings are related (e.g. text having to do with printing,
network, or other).

From this, we get many segments of zeros.

Now let the keys be K and L, of length 512 and 513 resp.
Suppose position i in A is proven to be zero.
Then we know that

Kk^Ll^0 = Ai, k = i % 512, l = i % 513.

This gives us a system of equation of 512+513 = 1025 variables Kk and Ll.

In this system, we can choose one value still freely.
If we know say Kk, we can compute Ll, and from this possibly some
other Kk', etc.
If the system is rich enough, we can compute all key values.

If not, we are left with some unknown values. If there are relatively
few of them, we can decode the fir file with the ones we know, leaving
us with some undecoded entries. Typically, there will be some of these
holes inside strings, were we can deduce the missing letters (like in
a string Shut.er). From this, we get more keys and we can proceed with
the extended system, hoping we will ventually have enough positions to
solve all.

Well, this is what I am currently doing...

Lex

--- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
<szaber@...> wrote:
>
> The same for 400D except for the first 32 bytes which is not
> encrypted. The same goes for 40D but it has more unencrypted data
> there.
>
> My only problem with the method is how to get the 1024 bytes of
> continuous plain text. I haven't checked, yet, but I'm not sure if
> it's always feasible to find the pieces to create that much continuous
> plain text...
• By the way, I see many strings in languages I do not know well enough to be sure that all characters are correct. I may need some help if I cannot find enough
Message 2 of 19 , Dec 20, 2007
• 0 Attachment
By the way, I see many strings in languages I do not know well enough
to be sure that all characters are correct. I may need some help if I
cannot find enough keys in identifying strings in foreigh languages.

Also, text in say eastern European languages contain non-ascii
characters which I cannot dsiplay correctly at the moment.
Anyone knowing how to view those on a Linux box?
• Most likely, they ll just be hi-bit-set (i.e. 128dec or 0x80)... though there is a chance that they could be multi-byte. Check out
Message 3 of 19 , Dec 20, 2007
• 0 Attachment
Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)... though there is a chance that they could be multi-byte.
Check out http://en.wikipedia.org/wiki/Unicode
On Thu, 20 Dec 2007 21:46:22 -0000
"soldeersmurfje" <a.augusteijn1@...> wrote:

> By the way, I see many strings in languages I do not know well enough
> to be sure that all characters are correct. I may need some help if I
> cannot find enough keys in identifying strings in foreigh languages.
>
> Also, text in say eastern European languages contain non-ascii
> characters which I cannot dsiplay correctly at the moment.
> Anyone knowing how to view those on a Linux box?
>
>
>
>
>
>
>
>
>
• I hope so. But looking at the set of languages supported by the 40D, there are even eastern languages, probably Japanese, Korean, Chinese and one other. Also
Message 4 of 19 , Dec 20, 2007
• 0 Attachment
I hope so. But looking at the set of languages supported by the 40D,
there are even eastern languages, probably Japanese, Korean, Chinese
and one other. Also there is Greek and Russian.
It could still be one byte, if the decoding is dependent on the
language setting.

--- In canondigicamhacking@yahoogroups.com, James Washer <washer@...>
wrote:
>
> Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)...
though there is a chance that they could be multi-byte.
> Check out http://en.wikipedia.org/wiki/Unicode
• I doubt kanji fits in a single byte... On Thu, 20 Dec 2007 22:46:17 -0000
Message 5 of 19 , Dec 20, 2007
• 0 Attachment
I doubt kanji fits in a single byte...

On Thu, 20 Dec 2007 22:46:17 -0000
"soldeersmurfje" <a.augusteijn1@...> wrote:

> I hope so. But looking at the set of languages supported by the 40D,
> there are even eastern languages, probably Japanese, Korean, Chinese
> and one other. Also there is Greek and Russian.
> It could still be one byte, if the decoding is dependent on the
> language setting.
>
>
> --- In canondigicamhacking@yahoogroups.com, James Washer <washer@...>
> wrote:
> >
> > Most likely, they'll just be hi-bit-set (i.e. >128dec or 0x80)...
> though there is a chance that they could be multi-byte.
> > Check out http://en.wikipedia.org/wiki/Unicode
>
>
>
>
>
>
>
>
>
• So, when you are ready, let me know! I will be interested in (re)using your code :) I have also started to write the code but I won t be able to work on it in
Message 6 of 19 , Dec 20, 2007
• 0 Attachment
So, when you are ready, let me know! I will be interested in (re)using

I have also started to write the code but I won't be able to work on
it in the next week and I suppose you will be ready with it by that
time...

Szabi

On Dec 20, 2007 4:43 PM, soldeersmurfje <a.augusteijn1@...> wrote:
>
>
>
>
>
>
> I checked, there is not that much of continuous text.
> But there is a way out, we can generalize the method.
>
> Suppose we have split the text into blocks of 512*513 bytes, say A, B,
> C, ...
> Now xor every pair together to obtain A^B, A^C, etc.
> By finding clear text, like english (or some other language) strings,
> we can find segments in say A^B, where either A or B must be 0.
> Typically, from the text, we can say derive which one it is, because,
> say B^C also shows some text, or because A^C shows the same text, or
> because strings are related (e.g. text having to do with printing,
> network, or other).
>
> From this, we get many segments of zeros.
>
> Now let the keys be K and L, of length 512 and 513 resp.
> Suppose position i in A is proven to be zero.
> Then we know that
>
> Kk^Ll^0 = Ai, k = i % 512, l = i % 513.
>
> This gives us a system of equation of 512+513 = 1025 variables Kk and Ll.
>
> In this system, we can choose one value still freely.
> If we know say Kk, we can compute Ll, and from this possibly some
> other Kk', etc.
> If the system is rich enough, we can compute all key values.
>
> If not, we are left with some unknown values. If there are relatively
> few of them, we can decode the fir file with the ones we know, leaving
> us with some undecoded entries. Typically, there will be some of these
> holes inside strings, were we can deduce the missing letters (like in
> a string Shut.er). From this, we get more keys and we can proceed with
> the extended system, hoping we will ventually have enough positions to
> solve all.
>
> Well, this is what I am currently doing...
>
> Lex
>
> --- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
>
> <szaber@...> wrote:
> >
> > The same for 400D except for the first 32 bytes which is not
> > encrypted. The same goes for 40D but it has more unencrypted data
> > there.
> >
> > My only problem with the method is how to get the 1024 bytes of
> > continuous plain text. I haven't checked, yet, but I'm not sure if
> > it's always feasible to find the pieces to create that much continuous
> > plain text...
>
>

--
DRM: Digital Restrictions Management -- learn about the dangers at
http://www.defectivebydesign.org/what_is_drm
• I am on a short vacation right now. Hopefully I can continue next week. I will release the source code of the analyzer. Lex ... using
Message 7 of 19 , Dec 22, 2007
• 0 Attachment
I am on a short vacation right now.
Hopefully I can continue next week.
I will release the source code of the analyzer.

Lex

--- In canondigicamhacking@yahoogroups.com, "Szabolcs Berecz"
<szaber@...> wrote:
>
> So, when you are ready, let me know! I will be interested in (re)
using
>
> I have also started to write the code but I won't be able to work on
> it in the next week and I suppose you will be ready with it by that
> time...
>
> Szabi
• If you need help to check strings in french, I would be glad to help. Let me know. [Non-text portions of this message have been removed]
Message 8 of 19 , Dec 23, 2007
• 0 Attachment
If you need help to check strings in french, I would be glad to help. Let me know.

[Non-text portions of this message have been removed]
• I can help with Hungarian. Anyway, the way I gonna implement it (not before january) is to dump the strings to a file with position and block information.
Message 9 of 19 , Dec 24, 2007
• 0 Attachment
I can help with Hungarian.

Anyway, the way I gonna implement it (not before january) is to dump
the strings to a file with position and block information. Filter and
fix these by hand and run the decrypter with these strings.
This way the work could be split up between more people. So less
boring work in the end...

Szabi

On Dec 23, 2007 6:34 PM, Jonathan Sylvestre <josylvestre@...> wrote:
>
>
>
>
>
>
> If you need help to check strings in french, I would be glad to help. Let me
> know.
>
> [Non-text portions of this message have been removed]
>
>

--
DRM: Digital Restrictions Management -- learn about the dangers at
http://www.defectivebydesign.org/what_is_drm
• I finished the 40D decryption, no more help needed on finding clear text in the firmware. It appeared I had plenty of text, which helped in detecting any
Message 10 of 19 , Dec 25, 2007
• 0 Attachment
I finished the 40D decryption, no more help needed on finding clear
text in the firmware. It appeared I had plenty of text, which helped
in detecting any inconsistencies, since there was a lot of redundancy.

Now it's Christmas time, but I will publish the decode table soon.

Lex

--- In canondigicamhacking@yahoogroups.com, "soldeersmurfje"
<a.augusteijn1@...> wrote:
>
> I am on a short vacation right now.
> Hopefully I can continue next week.
> I will release the source code of the analyzer.
>
> Lex
• I uploaded the 40D (and 20D, depending on an include file) decrypter to the file section. Merry Xmas! Lex
Message 11 of 19 , Dec 25, 2007
• 0 Attachment
I uploaded the 40D (and 20D, depending on an include file) decrypter
to the file section.

Merry Xmas!

Lex
• ... Good work! :)
Message 12 of 19 , Dec 28, 2007
• 0 Attachment
--- In canondigicamhacking@yahoogroups.com, "soldeersmurfje"
<a.augusteijn1@...> wrote:
>
> I uploaded the 40D (and 20D, depending on an include file) decrypter
> to the file section.
>
> Merry Xmas!
>
> Lex
>

Good work! :)
Your message has been successfully submitted and would be delivered to recipients shortly.