Friday, January 28, 2005

Kram hurdles

Looking for "good" keys didn't work, there are no bit permutations that show noticeably better applicability than others, the only thing I found is that a 0x22 final xor is significantly more common, which is good on one side, but not that good on the other side because it cannot be the ONLY xor - there must be others.

The manual decryption by comparison with the other sets is almost complete, CPU #2 is 100% while CPU #1 is maybe 75%. The code is different in a few places because this version doesn't have the MCU, and actually there seems to be a large chunk of code in the encrypted version that isn't in the others, so I might not be able to do a complete decryption if I don't break the encryption algorithm.

One interesting thing to note is that the code has been reassembled with a different assembler, which generates different (but equivalent) instructions in some cases. Here is an example:

not encrypted version:

D08D: CE B8 D3      LDU   #$B8D3
D090: EC 84 LDD ,X
D092: 81 29 CMPA #$29
encrypted version:

D082: CE B8 D3      LDU   #$B8D3
D085: EC 00 LDD $0000,X
D087: 81 29 CMPA #$29
the middle instruction does the same thing but with a different opcode.

Yesterday I verified that bytes at the same address are decrypted in the same way, and that in that case changing one bit in the encrypted value changes one bit in the decrypted value. Tomorrow I will try pairs of addresses only differing by one bit, and see if there is a similar regularity. From what I could see, however, I'm not very optimistic.

1 comment:

Anonymous said...

That's a bit shitty - to find that already exists. And worse: only one entry ... a few years ago!

Anyway, good luck on this blog!