Revision as of 19:45, 5 December 2021

So you want to make your own Infini-D 4.5 render farm from old Macs? Congratulations. You’ve embarked on a journey of discovery that few have enjoyed. Once I was like you; completely unaware of the joys of networking old macs together to make bad computer generated images of checkerboard floors with floating raytraced spheres. Until a friendly internet stranger decided to bestow upon me the gift of the Infini-D 4.5 Network License Serial Number and the teachings of the Retro Render Farm. Now I am productive, creative, and especially more efficient; and I think you will be too. Are you ready?

Below is some of the wisdom the internet stranger shared with me to get a Retro Render Farm started:

You'll need at least TWO Mac OS 9 capable machines.

Main machine:

- a full copy of Infini-D installed, with both an application serial number, and a network serial number supplied (both available at the link).

Worker machines:

-On these machines you only need the engine and control panel.

QUIRK: you have to move "Infini-D 4.5 Engine" out of the "Network Rendering Software" folder and into the same folder as "Infini-D 4.5 Resources.rsr"!

Alternatively, you can move "Infini-D 4.5 Resources.rsr" into the "Network Rendering Software" folder.

If both computers are on the same network (either TCP/IP or AppleTalk) the main machine will see the worker. Once this happens, the two will try and communicate.

This occurs on Application launch if a Network serial number has already been entered or right after the Network SN is added.

When the communication begins a blank error message will appear on the worker machine and one of two error messages will appear on the master under the Engines tab: Agent Malfunction or Incompatible Version.

Be sure to set a computer name and owner in the File Sharing control panel. You don't actually have to turn on File Sharing nor Program Sharing though. ID uses the network name to say which host is connect to which slave. I also did all this without enabling TCP/IP within ID.

This is the IBM PowerPC Instruction set manual I referenced to figure out what each instruction does: https://www.ibm.com/docs/en/aix/7.2?topic=reference-instruction-set

This is the Macintosh Toolbox Essentials manual I referenced for possible breakpoints in MacsBug: https://mirror.informatimago.com/next/developer.apple.com/documentation/mac/Toolbox/Toolbox-227.html

I'm going to use these two acronyms in this email: ID - Infini-D IDA - Interactive Disassembler (a reverse engineering program by HexRays)

=

There are three steps to getting the network (or any) serial number:

1 - Find the check algorithm 2 - Figure out what the algorithm does 3 - Write a keygen based on the algorithm

=

1 - Find the check algorithm (debugging*.mp4)

=

Every program is a series of CPU instructions. By using MacsBug (one of the few tools available at the time), it is possible to see the assembly-language CPU instructions as the program is running. By stepping through these instructions, we can peek under the hood of the application and see exactly how the computer's memory is being manipulated. Groups of instructions are called subroutines ("functions" in higher-level programming languages). If we can find the subroutine for the check algorithm, we can analyze its instructions and see the math behind the serial number validation.

Figuring out where exactly the instructions are for the check algorithm is quite difficult. ID has over 14,000 subroutines, each having dozens or hundreds of instructions! Which one is the check algorithm? We can narrow it down by setting strategic breakpoints in MacsBug. In the videos, I'm setting a breakpoint (bp) on NewCWindow. This is the MacOS subroutine that ID calls to create the "Bad Serial Number" dialog box. I then step through the instructions until I get to the end of the NewCWindow routine (a blr instruction is the end of a routine). I'm now back in the assembly instructions for ID and I see the address is now 3E21F220. This should be the address of the instruction called immediately after NewCWindow. If I can go back through the instructions and subroutines, I'll eventually get to the routine that says, "This serial number is bad, show the alert (call NewCWindow); or, this serial number is good, add it to the list."

I now switch over to IDA. IDA is a modern tool that aids in reverse engineering. It disassembles the entire program at once. It's killer feature is the Graph View, which breaks routines up into blocks, showing where different locations will branch off into one another within the routine. In IDA, I go to the entry point of the subroutine calling NewCWindow and see what other subroutines call this one. There are two. I then set a breakpoint in MacsBug on the address of each subroutine to see which one breaks when I try and add the serial number. The first one doesn't break so I don't have to worry about it -- it must be used somewhere else in the program and have nothing to do with the serial number check. The second one does break! I then go to the top of that subroutine and repeat the process, seeing which routines are being called when I click the plus button in ID.

=

2 - Figure out what the algorithm does (ida*.mp4, macsbug*.mp4)

=

With a lot of trial and error and bit of luck, eventually I get to a routine that looks like it's doing a ton math and there's tons of branching. It's huge. I might even see the serial number I entered right there in plain sight in MacsBug in a register (the numbers down the left column in MacsBug). We've finally found something a check algorithm candidate, so we have to go through it instruction by instruction in both IDA and MacsBug to see the memory and see the disassembly. IDA also includes a decompiler, which creates C-like pseudocode based on the disassembly. This is getting close to the original source code, but nothing is meaningfully named, just var1, var2, etc. This window is very convenient since it's easy to add comments and is usually easier to digest than pages of assembly instructions. As we go through each instruction in both programs, we can start to give meaningful names to variables, name sub-routines, and add comments to the decompilation. Slowly the algorithm becomes clearer. As we follow along, we can see where the program will branch if a certain calculation means the serial number is good, or where the result of a calculation equates to a bad serial number. It might be making sure that the seventh character of the serial number is a 1 (if not, it immediately exits the subroutine and shows an alert), or it might be doing something more intensive like adding up all the digits, dividing by a particular number, and then checking to see if the remainder is zero (if not, it quickly exits again).

=

3 - Write a keygen based on the algorithm (keygen*.mp4)

=

Once we have figured out the algorithm, we simplify it (usually they're obfuscated to confuse/deter/slow/anger reverse engineers) and write it in our own software: a keygen. A keygen feeds random numbers through the algorithm, returning only numbers that satisfy all the checks. Since even the slowest computer can check tens of thousands of random numbers a second, we quickly find valid serial numbers. We can even narrow down the guessing if we know certain numbers have to be within a certain range -- we better make sure that the seventh character is always 1!

And that's pretty much it. It's an incredibly difficult, complicated, and involved process. I hope I've done a decent job explaining it at a high level. If you have any questions or need me to film anything else, I'll be glad to help.