| |
The Shadow
Registered: Oct 2007
Posts: 304 |
EOR file coders
Someone once told me that it is impossible to open a file which was coded with an EOR coder. With todays machines, is there any conceivable way that an EOR coded file can be placed into a PC and descrambled? |
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
Could you explain a bit more what an EOR coded file is, or provide examples? Unless it's some strange form of one-time-pad, you should be able to analyze and possibly decrypt the data (And I'd gladly help you out just for the challenge of it). |
| |
Ymgve
Registered: May 2002
Posts: 84 |
After some quick digging I've found one tool that does EOR (EOR Maker V1.0), and also it seems like Turbo Assembler has support for EORing source files. In both cases only a single byte is used as the EOR value, so even brute forcing should be easy to do. |
| |
Marauder/GSS
Account closed
Registered: Jul 2006
Posts: 224 |
If you just pack your files with a simple RLE-packer, it's still possible to change bytes in the file, so a lamer still could alter text in the file - like it was done in some releases *g*
That's the reason why I have put a EOR-code into some of my old crunchers, like Marauder Cruncher-Coder-Linker V2.0
Ofcoz breaking a file EORed with a single value is very easy... (c;
If you use more EOR values it's ofcoz "harder" to break, but still possible to do if you find/know the decrypt-routine, hehe |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
If you consider EOR loops in some protection software than most of code I've seen is based on 1 byte value (key to be correct with cryptography theory) so bruteforcing it is not a problem but usually finding the key by analyzing loader is also easy.
Another case is when you have just data file without any decryption code. If the encryption key is the same length as input file than it is not possible to decrypt it. However most c64 tools I've seen either were based on 1 byte key or key based on user input (password) with limited length. This means that you can use trivial attacks to decrypt file and recover key.
|
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
tlr made De-Coder that can decode files protected by some programs. |
| |
Marauder/GSS
Account closed
Registered: Jul 2006
Posts: 224 |
if you know/have some bytes of the original (decrypted) content, then I guess you could find out the keys... if you don't know I think it's hard to find out if the key uses more than one value...
*edit: last question was a silly one...*LOL* where's that black 'n hot brew... coffeeeeee (c;
does that 'Vigenère variants' work also on non-alphabetic text ? I guess so, then it's maybe possible to do... |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
EOR encoded with a single byte would be no problem to break, encoded with a password gets tougher, but still very possible.
One game preview I cracked was encrypted with a password, which from memory was "GLORIOUS", but the programmer made a silly mistake in crunching both the viewable first part and the encrypted game with the same cruncher. Made my job so much easier having that known bit of data to work from.
|
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
The good file coders I remember use an 8 byte system (The length of the password). If say someone were to 8 byte EOR code a file and remove the decoder, is there any possible way that a PC could crack it? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: The good file coders I remember use an 8 byte system (The length of the password). If say someone were to 8 byte EOR code a file and remove the decoder, is there any possible way that a PC could crack it?
Yes, probably. Especially if the file is in the normal ordering except for EOR:ing with a sequence of 8 bytes repeated.
De-Coder cracks those by assuming certain statistics of a particular byte value occuring.
I calculated those statistics from several thousands of files.
The length of the key is determined by an incidence check.
Key finding takes only ~15 seconds on a c64. :)
The algorithm used by J-Coder V1.0 and Encoder V1.0 is harder to break. It only does substitution per byte but in a fairly complex way.
Maybe someone with more insight into crypt analysis can break it?
@Marauder: yes, non alphabetic text works too. There is a disc of examples in the release you can try. A few have ctrl-chars in the password.
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: The good file coders I remember use an 8 byte system (The length of the password). If say someone were to 8 byte EOR code a file and remove the decoder, is there any possible way that a PC could crack it?
This is actually one of most basic and simple attacks on ciphers. Take a look here for some info: http://en.wikipedia.org/wiki/XOR_cipher |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: This is actually one of most basic and simple attacks on ciphers. Take a look here for some info: http://en.wikipedia.org/wiki/XOR_cipher
Knowing the length of the key helps a bit.
As the data is byte oriented it's probably easiest to treat this as a Vigenère of length 8.
You then solve this as 8 independent XOR-ciphers starting at bytes 0-7, with the spacing of 8 bytes between each value.
|
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
Is there any known technique of scrambling which would be impossible to break? |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
Quote: Is there any known technique of scrambling which would be impossible to break?
I've toyed with the idea of converting to 6502 the 6805 version of Twofish found here: http://www.schneier.com/twofish-download.html
This would be more along the lines of what you are seeking, and AFAIK it is still an unbreakable cipher.
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
The strength of the encryption relies of the length of the keyword, but also on the algorithm if the plaintext is guessable. Especially XOR/EOR algorithms are vulnerable to a known plaintext attack - if you know the final program is getting allocated to 0801, there's a pretty big chance the first bytes will contain the BASIC line for SYS [some number]. Which increases the chance of recovering the key exponentially. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: The strength of the encryption relies of the length of the keyword, but also on the algorithm if the plaintext is guessable. Especially XOR/EOR algorithms are vulnerable to a known plaintext attack - if you know the final program is getting allocated to 0801, there's a pretty big chance the first bytes will contain the BASIC line for SYS [some number]. Which increases the chance of recovering the key exponentially.
I built individual statistics for the SYS line in my first attempts but it turned out too short to make useful statistics.
If you are using some kind of heuristics (or manual work) it can probably be useful.
What I do is analyze the statistics of the first and last 512 bytes of the file.
This was chosen on the assumption that one of those will contain a chunk of 6502 code. (usually a decruncher)
This turned out quite effective!
Adding special handling of the SYS line doesn't seem to gain enough to make it worth it.
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I got inspired and hacked this up yesterday: Crack me!
Try to find the password. :)
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
Got it :) I wonder if this is the first time that algorithm has been done on the C64. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I would think that this is the first, but you never know... :)
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: I would think that this is the first, but you never know... :)
I didn't have time to really look at it but peeking at decryption loop I can confirm that I've never seen it on c64 - at least not in protection code. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I posted the answer now.
The encryption algorithm implemented is AES-128 (ECB). |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: I posted the answer now.
The encryption algorithm implemented is AES-128 (ECB).
Damn! I whish I had more time to really take a look at it before you posted the answer. Great challenge BTW :D |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
It seems that there are a number of us who enjoy this sort of challenge, so what I'm wondering is this: Are there any old encrypted productions that still have not had their protection broken yet? And if you know of one, post the link here so it can be seen to.
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: It seems that there are a number of us who enjoy this sort of challenge, so what I'm wondering is this: Are there any old encrypted productions that still have not had their protection broken yet? And if you know of one, post the link here so it can be seen to.
I don't think there is much left to crack - this why new releases are more fixes and crunchning, unless somebody will code a new challenge. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I don't think there is much left to crack - this why new releases are more fixes and crunchning, unless somebody will code a new challenge.
Something tells me you can expect one tomorrow... ;) |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Something tells me you can expect one tomorrow... ;)
Cool - I'm working right now on something different - not encryption based code to crack but some protection based on different tricks. |
| |
Ymgve
Registered: May 2002
Posts: 84 |
Shame on you, tlr - you uploaded Crack me too! and didn't post it here :) |
| |
Ymgve
Registered: May 2002
Posts: 84 |
nevermind |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Only Ymgve has cracked it.
Are you really going to let him be the only one? ;) |
| |
enthusi
Registered: May 2004
Posts: 677 |
dunno if anyone cares.
Well 1 byte EOR arent all too protective for obvious reasons.
A key the size of the data is well-known and some moron is selling it on teh net :)
And any EOR coding is simple to decypher (as in finding the key) if you know part of the original content OR have a non-RLE file and i.e. rows of equal sequences.
Those are likely to have been 00,00,00 etc and will contain the key in RAW format! So EOR only makes real sense when combined with other stuff somehow. I.e. (x-)tea or so.
Ask Hanno :)
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
As I tried cracking instead of guessing this time, I imported it into my 6502 emulator, and chewed through $212121 to $5f5f5f looking for $08 at $0802 and $9e at $0805 (i.e. your average basic sys line). No love :(
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: As I tried cracking instead of guessing this time, I imported it into my 6502 emulator, and chewed through $212121 to $5f5f5f looking for $08 at $0802 and $9e at $0805 (i.e. your average basic sys line). No love :(
Good work but it needs a little more effort to bring love. :)
Added a hint here: Crack me too! |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
OK, so I expanded the search to emu_mem[0x0802] == 0x08, 6 <= emu_mem[0x0801] <= 86, emu_mem[(0x0800 | emu_mem[0x0801]) - 1] == 0, aka a proper basic line. Still no love :/
I need to verify that my emu produces the same output as vice.
I wish I had more time to work on this...
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
Just a small hint: The decryption code sets $0800 to zero, so what that address decrypts to is irrelevant. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: As I tried cracking instead of guessing this time, I imported it into my 6502 emulator, and chewed through $212121 to $5f5f5f looking for $08 at $0802 and $9e at $0805 (i.e. your average basic sys line). No love :(
Cracking vs. Guessing philosophy. Isn't this just automated guessing? :D |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: OK, so I expanded the search to emu_mem[0x0802] == 0x08, 6 <= emu_mem[0x0801] <= 86, emu_mem[(0x0800 | emu_mem[0x0801]) - 1] == 0, aka a proper basic line. Still no love :/
I need to verify that my emu produces the same output as vice.
I wish I had more time to work on this...
Added another hint: Crack me too!
And when you solve it, it does bring some love! :)
Ymgve knows the secret. ;) |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
Been working along similar lines to Magervalp, and as he says, no love. Using VICE have scanned all possible password combinations ranging from #$202020 to #$5f5f5f, checking for results where $0801 is equal to #$08. Now I've come to conclude the following possibilities in order from least to most likely.
A) The BASIC line is very non-standard and $0801 is something other than #$08.
B) I need to expand the range of my search.
or
C) My password scanning program completely sucks.
[EDIT] Wrote the above before I saw the latest hint, looks like I may need to re-think which is most likely. :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
wouldnt it be faster to crack it instead of guessing? |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
Another edit, I really was checking $0802, not $0801. It's early morning here...
Oswald: To me it seems that in the case of strong encryption like this, but with a relatively weak password that the brute force approach would be the fastest (and most likely the only) way to get results. Provided that is you know something that will be in the resulting decrypted code, which appears to be the problem I'm having now.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Another edit, I really was checking $0802, not $0801. It's early morning here...
Oswald: To me it seems that in the case of strong encryption like this, but with a relatively weak password that the brute force approach would be the fastest (and most likely the only) way to get results. Provided that is you know something that will be in the resulting decrypted code, which appears to be the problem I'm having now.
Not that I've checked this thoroughly but wouldn't it be smarter to try to exploit the bad-key check as a comparator for knowing if you got correct data or not in the brute force scan? |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Not that I've checked this thoroughly but wouldn't it be smarter to try to exploit the bad-key check as a comparator for knowing if you got correct data or not in the brute force scan?
The bad key check is implemented properly, so it doesn't confirm or deny :) It's a timer IRQ that fires if the program crashes. I assume that the decrypted program disables the IRQ on startup.
TLR: munged basic? Truly evil. That makes it hard to write a function that decides if the decryption worked - I guess I have to execute the code and see if it disables the IRQ, but that means adding a lot more stuff to my barebones emulator...
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Added todays hint: Crack me too!
@MagerValp: I didn't know code could be evil... ;) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Sadly I haven't had time to work on it. I confirmed that my emulator produces the same output as VICE though, which is good.
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Added another hint... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I guess most gave up on this so I'm giving the pw this evening unless someone says they are still trying. :)
It's apparent that Ymgve chose a really good strategy for cracking it!
When I got the correct answer reported only 5 hours after release I thought I might had accidentally made the challenge way too easy. ;)
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Posted the answer: Crack me too! |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
Tried brute force attack myself and failed, since searching for #$08 at $0802 gave far too many results to sort through (have just confirmed "2,4" was in my list of results, damn!). Also tried looking for POKE565xx in the decrypted code (for disabling CIA timer), but TLR cleverly hid that, as I suspected when no results were found.
I'll be interested to hear a report from Ymgve as to what his method of attack was.
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
I actually found it by doing a bit of statistics. One of my ideas was to count the number of digit characters in the first 128 bytes, and then the "2,4" combination showed up with 45 out of 128 bytes being digits. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Nice work Ymgve!
My next step would have been code execution and a breakpoint on the basic SYS command and the error routine, but I didn't have the time to implement it. Would it have worked?
|
| |
Ymgve
Registered: May 2002
Posts: 84 |
Yeah, detecting changes to the error routine should work. He never actually uses a SYS command. He POKEs a small program into memory, hooks the error message vector, then executes a syntax error. There's also no numbers larger than 3 digits, all addresses are created through obfuscated math. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Nasty! :)
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Nasty! :)
Thanks. :)
I've added the decrypted payload data for people to check out:
http://noname.c64.org/csdb/getinternalfile.php/55441/payload.prg
One attack vector I thought would be usable was statistics in some form. 6502 instruction statistics for instance.
I tried to make the basic stub hard to identify but the Ymgves digit statistics was a very clever idea... :)
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
I wonder...
Seems the only successful cracks were done using statistics, but what if you make the final correct result look like complete garbage (somewhat even distribution of bytes), wouldn't that be a bitch to crack? |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
Excellent idea! |
| |
Mace
Registered: May 2002
Posts: 1799 |
I don't see the use of that.
Part of hacking is getting access to useful data.
It's more than finding the code alone.
What could be a nice solution in between is if the decoded data is raw crunched data that needs to be decrunched.
You can at least test if the data is correct, but you won't find it directly after finding the right code. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I am not sure, but I think Burglar didn't seriously suggest that someone make a garbage sequence of bytes hard to crack, but rather than if you for example add series of trash bytes in between wellformed parts of code/data (and then pack it or so) to skew the statistical distribution in various ways, then this might be much harder to crack.
...or perhaps it was my turn to misunderstand now. :) |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quote: I am not sure, but I think Burglar didn't seriously suggest that someone make a garbage sequence of bytes hard to crack, but rather than if you for example add series of trash bytes in between wellformed parts of code/data (and then pack it or so) to skew the statistical distribution in various ways, then this might be much harder to crack.
...or perhaps it was my turn to misunderstand now. :)
frantic, you understood it perfectly well ;) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Aaaah, ok, now I understand too :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I am not sure, but I think Burglar didn't seriously suggest that someone make a garbage sequence of bytes hard to crack, but rather than if you for example add series of trash bytes in between wellformed parts of code/data (and then pack it or so) to skew the statistical distribution in various ways, then this might be much harder to crack.
...or perhaps it was my turn to misunderstand now. :)
That's the reason I only RLE packed the payload. Otherwise it might have gotten too hard.
As with all obfuscation exercises I left a wide hole somewhere else though, i.e leaving a rather large amount of digits in the basic stub.
A really hard challenge would use a full length password on a packed payload.
If you use a suitable chained cipher mode and shuffle the data (e.g start in the middle and wrap) it will be very hard to identify the plain text without decoding a lot of the data.
|
