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...