>> Decryption Challenge <<

[Don_Adan]

I checked a few closer Moonquake ROM.
Only one file (131216 bytes long) at $80000 offset is available. Rest of data is unused (repeated parts). Unknown (strange) crypt method, no $FF value inside file.

[RedskullDC]

Originally Posted by Ed Cruse

Here's my executable and encrypted text file.

Encrypt.exe is a CLI program, if you type "encrypt ?" it will print the args template.

Hi Ed,

I had a brief look through the source.
Now *that* is a worthy challenge
Will take a little time...

Out of curiosity, what did you write it in?

Doesn't look like hand coded 68K (forgive me if I'm wrong).

Cheers,
Red

[StingRay]

Originally Posted by RedskullDC

Out of curiosity, what did you write it in?

Looks like compiled C code to me.

[Ed Cruse]

RedSkull:

Sting Ray is correct, it's compiled C code. Compiled C code does look funny, I sit there and look at it and wonder why it did what it did. Lets face it, humans are smarter then computers. The program does use CRC256, CRC128, and CRC64, and those routines are written in assembly. If more info is needed like how things work, let me know and I'll try to fill you in.

As a hint, the random generator outputs 64 bits which are all xor to 64 bits of data.

[RedskullDC]

Originally Posted by Ed Cruse

Sting Ray is correct, it's compiled C code. Compiled C code does look funny, I sit there and look at it and wonder why it did what it did.

Hi Ed,

Sorry, I should have been more specific.

I was actually wondering what compiler you used to create it?

I don't recongise the startup code for example. Thought it may have been HiSoft BASIC or something...

The Rotate instructions in the CRC routines are pretty much a dead giveaway that they weren't written in "C/C++". Compilers won't emit such instructions (unless you employ inline _asm ROL/ROR's).

Please, no hints! That's cheating.

Cheers,
Red

[Leffmann]

If you're speaking generally then most compilers do emit rotate-instructions, and GCC M68K will certainly do it. It's a matter of detecting constructs like (X<<Y) | (X>>(32-Y)), but since it looks syntactically better with f.ex ROL(X, Y) many people will just write a replacement like that and make it insert assembly directly while at it.

[Don_Adan]

Small update for MoonQuake ROM, 220 bytes at $40000, it can be loader, ByteKiller depacker or unused data.

[Ed Cruse]

Originally Posted by RedskullDC

Hi Ed,

Sorry, I should have been more specific.

I was actually wondering what compiler you used to create it?

I don't recongise the startup code for example. Thought it may have been HiSoft BASIC or something...

The Rotate instructions in the CRC routines are pretty much a dead giveaway that they weren't written in "C/C++". Compilers won't emit such instructions (unless you employ inline _asm ROL/ROR's).

Please, no hints! That's cheating.

Cheers,
Red

It's written in SAS C. The startup code is mine, it's strictly for CLI, no WB. All functins calls are also mine. I used to be an assembly programer, I wrote my own function library and had my own enviroment. When I switched to C I modified the functions to work with C. Basically I use C as a high level assembly language, in my heart I'm an assembly programer, but I like the ease of using C.

I kind of get the feeling you think that by understanding how the program works you'll find the trick to de-encrypting the file. I hate to tell you this but there is no trick, unless there's a flaw in the algorithm. This is what I'm interested in knowing. I wrote the program and I can't crack files encrypted with it. If I had to try I would probably modify the code to try every password combination there is and hope it's a short password, and not the full 32 bytes. Keeping this in mind it would probably be in your best interest to let me help you understand it. Then you can put your efforts into finding the flaws. Of course that's up to you. I can tell you really like a good challenge, and that's good. I also like challenges, this program is one of my challenges and has been in the works for many years.

Good luck.

[Ed Cruse]

Anybody having any luck with cracking my encryption program?

[Lonewolf10]

Not yet. I have been distracted by a few things.


Regards,
Lonewolf10

[RedskullDC]

Hi Ed, et al.

Originally Posted by Ed Cruse

Anybody having any luck with cracking my encryption program?

Made some good progress pulling it to bits, but (like Lonewolf) real life has got in the way the last few days.

Definitely haven't abandoned it....

Cheers,
Red

[Ed Cruse]

Originally Posted by RedskullDC

Hi Ed, et al.


Made some good progress pulling it to bits, but (like Lonewolf) real life has got in the way the last few days.

Definitely haven't abandoned it....

Cheers,
Red

I was just curious, real life does have a tendency to get in the way.

[RedskullDC]

Hi Ed,

Originally Posted by Ed Cruse

Anybody having any luck with cracking my encryption program?

Finished deconstructing the program.

It's quite safe considering the password is not stored inside the encrypted file.
As you mentioned in an earlier post, the only way to crack it is going through all possible combinations of the 32 password bytes:
(256 to power of 32)
or
1.1579208923731619542357098500869e+77 combinations

Since the password is CRC'ed down to 32bits, that gives 4294967296 possible combinations. However, that suggests that there will still be 2.695994666715063979466701508702e+67 password combinations that would decode to the correct CRC combination.

Since you only store 24bits of the 32bit crc'ed password data (plus 8 bits for saving the original file length), this increases the number of passwords that satisfy the password CRC check, but won't actually decode the rest of the file.
Not using the same CRC routine to encode the rest of the file as you do to encode the password means they is no way to confirm which password combination is actually correct.

Adding the datestamp string into the CRC calcs is something of a red herring. As if it wasn't difficult enough already!

Theoretically possible to crack, but will require lots of processor grunt to calculate *potentially correct* password combinations.
The stored length value may offer a way to reduce the number of potentially correct passwords to check. We just need to look for values which are 48 bytes (size of postamble) or less than the encoded file size.

Good stuff!

Cheers,
Red

p.s Someone will likely correct my maths, not my strongpoint.
I must have been away the day they did maths at school

[Ed Cruse]

Originally Posted by RedskullDC

Hi Ed,


Finished deconstructing the program.

It's quite safe considering the password is not stored inside the encrypted file.
As you mentioned in an earlier post, the only way to crack it is going through all possible combinations of the 32 password bytes:
(256 to power of 32)
or
1.1579208923731619542357098500869e+77 combinations

Since the password is CRC'ed down to 32bits, that gives 4294967296 possible combinations. However, that suggests that there will still be 2.695994666715063979466701508702e+67 password combinations that would decode to the correct CRC combination.

Since you only store 24bits of the 32bit crc'ed password data (plus 8 bits for saving the original file length), this increases the number of passwords that satisfy the password CRC check, but won't actually decode the rest of the file.
Not using the same CRC routine to encode the rest of the file as you do to encode the password means they is no way to confirm which password combination is actually correct.

Adding the datestamp string into the CRC calcs is something of a red herring. As if it wasn't difficult enough already!

Theoretically possible to crack, but will require lots of processor grunt to calculate *potentially correct* password combinations.
The stored length value may offer a way to reduce the number of potentially correct passwords to check. We just need to look for values which are 48 bytes (size of postamble) or less than the encoded file size.

Good stuff!

Cheers,
Red

p.s Someone will likely correct my maths, not my strongpoint.
I must have been away the day they did maths at school

I think you need to look at the code some more. Most of what you wrote above I don't recognize as how it works. There are 3 different CRCs in there and I think you are getting them confused. You are right about one thing, the password is not stored in the encrypted file, the user has to know the password that encrypted it. The date stamp at the end is so I don't have to change the password each time I encrypt a file. Everytime I encrypt with the same password I get a totally different key.

I have to admit you did a very good job of disassembling it, that's really hard to do.

I designed the program to be unbreakable even if you have the source code and know exactly how it works. I also designed it so even if you have the key, (encrypting a file full of zeros), you still can't predict anything on either side of the key. That's the design, there could be flaws that prevent that from being true.

If you would like I can send you a detailed explanation of how it works so you can look for flaws.

[pmc]

As an idle viewer of this thread reading the descriptions of your program I just have to say that your method really is a secure encryption scheme.

Kudos to you Ed.

[RedskullDC]

Hi Ed,

Originally Posted by Ed Cruse

I think you need to look at the code some more. Most of what you wrote above I don't recognize as how it works. There are 3 different CRCs in there and I think you are getting them confused. You are right about one thing, the password is not stored in the encrypted file, the user has to know the password that encrypted it. The date stamp at the end is so I don't have to change the password each time I encrypt a file. Everytime I encrypt with the same password I get a totally different key.

I have to admit you did a very good job of disassembling it, that's really hard to do.

I designed the program to be unbreakable even if you have the source code and know exactly how it works. I also designed it so even if you have the key, (encrypting a file full of zeros), you still can't predict anything on either side of the key. That's the design, there could be flaws that prevent that from being true.

If you would like I can send you a detailed explanation of how it works so you can look for flaws.

Sent you a private message with a disassem of the main routine.
Admittedly, I can only describe it in terms of the disassembly, which may at times sound quite different to your original code...

As I mentioned in my previous post, only way to break it is to try all possible password combos. That is near enough to unbreakable

Send the description if you like, but it looks pretty tight to me.

Cheers,
Red.

P.S. I actually reverse engineer software for a living (amongst other things). Not for nefarious purposes I might add, but for the purposes of identifying copyright violations.

[Ed Cruse]

Originally Posted by RedskullDC

Hi Ed,



Sent you a private message with a disassem of the main routine.
Admittedly, I can only describe it in terms of the disassembly, which may at times sound quite different to your original code...

As I mentioned in my previous post, only way to break it is to try all possible password combos. That is near enough to unbreakable

Send the description if you like, but it looks pretty tight to me.

Cheers,
Red.

P.S. I actually reverse engineer software for a living (amongst other things). Not for nefarious purposes I might add, but for the purposes of identifying copyright violations.

Hi Red,

You do this for a living? I'm impressed! I find it difficult to figure out the disassembly output from my compiler, which is a heck of a lot easier then what you had to do.

I'll send you some drawings and a description of the theorey of operation. I was thinking about what you wrote last night, you figured it out pretty well but there's still a number of things that are wrong, like there is no CRC32 in the program. There's only CRC256, 128, 64.

Ed

[Lonewolf10]

Originally Posted by Ed Cruse

I also designed it so even if you have the key, (encrypting a file full of zeros), you still can't predict anything on either side of the key.

That was the first thing I tried


Regards,
Lonewolf10

[Ed Cruse]

Originally Posted by Lonewolf10

That was the first thing I tried

Regards,
Lonewolf10

What were your results, were you able to predict? I'm thinking not, otherwise you would be saying you did.


Is anybody interested in the theory of operation for the encryption program? RedSkull deconstructed the program and did a very good job of it, so I'm working on drawings and short documentation to send to her. I can upload them here.

[Ed Cruse]

I uploaded the theory of operation of the encryption program, I also included the original executable and encrypted file.