| |
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? |
|
... 48 posts hidden. Click here to view all posts....
|
| |
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.
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
