| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Jun 12th, 2011 @ 23:29 ( . ) |
When documenting the drive-side protection on Star Rank Boxing v2 and Championship Baseball, I only briefly looked at the C64-side of this protection. Deeper inspection reveals it to be a virtual machine protection, like the early EA FAT track loader that's documented on this site. The p-code instruction loader sits in an IRQ handler. The purpose of it is to obfuscate the uploading of code to the drive (M-W/M-E, etc) in order to trigger the protection. Stack tricks up the wazoo. More investigation is needed though to see what else it can do. By looking at the instruction table, there appears to be 20 instructions. If you've ever looked at the copy program parameters for these two titles, you've probably noticed they're a bit...different. Now you know why. The SRB parameter on Maverick actually performs a full crack of the game, using the game's own loader to read everything into memory, then saving it off as a 3 file backup (loader plus 2 data files since the size is > 202 blocks). The Championship Baseball parameter also hijacks the loader and winds up bypassing the whole title screen and intro sequence. Another nice job by Harald. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Jun 13th, 2011 @ 19:41 ( . ) |
After going through all of the (encrypted) p-code, it seems that only 8 instructions are used, and they're all straightforward. Once I've cleaned it all up, I'll post an updated, commented disassembly for this protection that covers the virtual machine, p-code, and drive code protection, as well has how to remove all this extra protection while leaving everything else intact (intro title, fast loader, etc) |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Jun 13th, 2011 @ 20:18 ( . ) |
Thanks very much, LordCrass. I was disappointed that the parameter removed the title screen. It seems all the V-MAX V1/V2 variants are more well-protected than the V3. I guess when they "standardized" the protection, they had to weaken it. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, Jun 14th, 2011 @ 02:17 ( . ) |
I managed to get the VM instructions fully documented, and the p-code decrypted and commented. However, the routine that actually decrypts the whole VM itself before running it is one of the nastiest decrypt routines I've seen on the C64 yet. It's just huge. So much for just modifying the p-code code and saving it back... |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, Jun 14th, 2011 @ 10:55 ( . ) |
I took a wild guess and just tried the simple, tried-and-true decrypt loop you see used everywhere (the standard LDA #$key, EOR/STA, loop) and the decrypted code was 50% correct. EOR every odd byte with #$31 after that, and you have completely decrypted code. This makes it simple to re-encrypt too, although I haven't looked for checksums on the encrypted block yet. The decrypt routine does wind up setting some values in the I/O and zero-page areas. Not sure if these values are used as part of the routine, or if they're breadcrumbs for later. When you see that "Still loading, please wait..." screen and wonder what's taking so long, it's this decrypt loop, the uploading of drive code through a VM (x2), decrypting of drive code in the drive itself, and then the execution of the protection checks themselves (x2). I'm surprised this protection wasn't used on more than 2 games considering the effort that must have gone into designing it. The VM has 20 instructions, but SRB only uses 8 of them. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Wed, Jun 15th, 2011 @ 01:53 ( . ) |
I'm no expert, but they probably ran into too many problems with some 1541 or 1571 drives that just weren't compatible enough to pass the protection, the way accolade did on some of their games. Another reason for it's rare use is the price that Harald might have charged for it. |
| 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" |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Jun 16th, 2011 @ 02:57 ( . ) |
I missed it originally, but Star Rank Boxing v1 also has the VM, though it doesn't have the nasty encryption like v2 has. The p-code still has simple encryption. However, the whole VM is simple to bypass in v1. There are also slight differences in it. |