|Author:||Lord Crass (guest: search)|
|Date:||Wed, Jun 15th, 2011 @ 23:16 ( . )|
The drive code that is uploaded can be anything the programmer wants it to be and is easily changed if a particular routine was unreliable. I was referring more to the C64 code, which is amazingly well protected.
There p-code is decrypted as it is called. The VM itself (along with the p-code again) is encrypted. The routine that decrypts the VM is encrypted as well, using the entire (encrypted) VM as the decryption key. Once the drive-side protection passes, the drive code loads in 2 encrypted sectors from track 18 which decrypts to one sector of code. That code then loads and decrypts 3 other encrypted sectors on track 18 which becomes the drive code of the V-Max loader that is used to load the main game.
It's the routine that decrypts the VM which is the rough part though. It's a giant mess of spaghetti code, throwing addresses and values all over the place. It's deliberately inefficient to confuse you. While decrypting, it's using $1800 bytes of extra data I'm guessing as some kind of checksum that regurgitates into the decryption routine, because if you alter even one byte of the encrypted VM code, the rest of it decrypts as garbage. This decrypt routine is over 4K in code size alone (not including that $1800 bytes of "junk"), and is almost VM-like itself. Just to give you an idea of how much useless crap is in there to throw you off, the decrypt code I wrote that decodes the VM is only 26 bytes, and the code to re-encrypt the VM is 32 bytes. The code mess does more than just decrypt though, so you can't just skip over it.
This is one of those cases where letting the game code load in, finding the entry point, then saving it off to disk and putting in your own loader is FAR easier than attacking the protection head-on.
An appropriate message in the spaghetti code:
"DON'T WASTE YOURTIME"
--* Star Rank Boxing V2
6/16/2011 @ 02:57--Lord Crass
--- 0 Users Online --- 0 Recent Unique Posters