This page is a wiki. Please login or create an account to begin editing.


10 posts / 0 new
Last post
Temporary Joe's picture
Offline
Joined: 2009 Nov 14
Reverse-engineering Mac games

There's been a lot of discussion of reverse-engineering Nintendo games to create workable assembly code, but is there a way/movement to reverse-engineer Mac games? There's a lot of ResEdit things one can work with, but a lot of that is in hex code that isn't immediately obvious how to manipulate.

Comments

snes1423's picture
Offline
Joined: 2020 May 13

I have an uncle who tried doing that but on a apple ii back in the 80’s until he had to go to court for it for piracy

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Can cost for the right tools, but see posts in here, from powermax's post and down.

BootSector's picture
Offline
Joined: 2018 Feb 18

This certainly doesn't mean that there isn't anything going on with this but at least I haven't personally heard much on it. It might just be I don't run in the right circles though. However, I suspect there isn't much going on though and I'll offer some thoughts on why.

First, sad but true, I think our community of vintage Macintosh enthusiasts in much smaller than Nintendo's fan base. So, fewer folks overall results in even fewer who have the time, expertise, and the desire to undertake something like that. The fraction of those fan engaged in this would be very small as it is so it might be minuscule to the point of nonexistence in the smaller community.

Second, there is some nuance to this since I know there is a lot of disassembly of software for NES, SNES, and the like going on. This stands in contrast to decompilation that is also happening and similiar but is something different. Simply put, disassembly would be turning software that was originally written in assembly language (basically symbolic machine code) back into assembly language. This is relatively simple to do just reversing the CPU's op codes one-to-one and infering their meaning. So anyone with some skill and enough effort could do this for the older software written in this way. Everything up to the SNES (and I think even a few N64 titles--maybe) so there's a lot that can be done here.

Some Macintosh was written in assembly so this could done here too. But, the original default language for Mac development was the higher-level Pascal language and later C and C++. These programs could also be disassembled but it would probably be pretty unsatisfying because it wouldn't return the code back to anything like the original source code in the higher-level language. Just an assembly representation of what the C (or Pascal) compiler ended up spitting out.

I am by no means an expert on this the last part but there is also "decompilation" which can turn the code back into higher level source code which is what we'd really want. Recent high-profile projects like the Super Mario 64 reversing project (not to be confused with the source leak) used this method. In some cases game developers accidentally also left debug information in the final release binaries which can make this process even more effective and easier to do.

But, my understanding is that this generally requires a decompilation tool which is tuned to know and recognized the types of code structures that were generated by the particular compiler originally used to compile the program. Since MPW, CodeWarrior, and the like are all long obsolete I suspect that the road block is simply nothing like that exists so it's probably a non-starter.

Duality's picture
Offline
Joined: 2014 Mar 1

[...] my understanding is that this generally requires a decompilation tool which is tuned to know and recognized the types of code structures that were generated by the particular compiler originally used to compile the program. Since MPW, CodeWarrior, and the like are all long obsolete I suspect that the road block is simply nothing like that exists so it's probably a non-starter.

There is, was, and still remains MacNosy. See the thread MTT linked to above, which touches on IDA and modern bits too.

It was recently used to fix a volume issue in the Mac port of MechWarrior 2.

Certainly there's nothing actively preventing people from using it. It's just a fairly low base of people that want to, or have the time.

adespoton's picture
Offline
Joined: 2015 Feb 15

Personally, I have a lack of time, so I taught my kids how to use the tools. Right now though, they don't have the inclination and are instead using their expertise to reverse engineer obfuscated javascript and do odd things with modern binary filetypes. But I'll be getting an OS 9 system set up in a common area over Christmas so they have the challenge of having to patch the software before they can see what it does Smile

Duality's picture
Offline
Joined: 2014 Mar 1

Ah, JavaScript. Smile Seems most people into twiddling bits get a background in that, or Linux kernel development. Feels like it's stayed that way for about a decade, somehow.

Wishing them and you luck.

OpenSourceMac's picture
Offline
Joined: 2019 Jan 21

It's the same with any runtime. The data is in machine code, only occasionally will a string be visible, or if you have a utility that can interpret image code, that you can hack the ROM. The resource fork just makes it WAY EASIER because on most other platforms, that data would be contained inside the ROM too. Most often, it is about changing some small thing like all the Red Crosses in Doom that had to get changed to pills after The National Red Cross trademarked the former (LAME). Assembly code is MUCH more complicated.

What you are describing is almost as easily done by just playing and cataloguing all of the game's reactions (scripting) and rebuilding from the ground up. Debugging symbols help, if left in, but to simply go from a finished runtime to source-code is like buying a finished pie from the bakery and then making the recipe - pretty hard.

OpenSourceMac's picture
Offline
Joined: 2019 Jan 21

P.S. Several of us here tried to hack this one, because of a lack of a working serial, and we spent days to no avail. https://macintoshgarden.org/games/pyramad

You could see where buying the game encrypted a hash based on the customer's name, credit-card number & address. We tried removing the obvious unlock check, replacing the "Unlocked" variable in all the places that would look to see if it was unlocked and long-story short, we never cracked it. Someone just posted a version that will run from a disk image, and one of these days, I plan to compare it to the original to see what the differences are. This kind of thing is like trying to solve a murder case.

adespoton's picture
Offline
Joined: 2015 Feb 15

Hmm... I might have a go at 1.5se and see if I can remove the logic that checks for the CD. I'm really slow at PPC analysis though; with 68k I could usually identify the important instructions in a hex dump.