The Pippin never really had a fair chance at life. Produced by Bandai under license to Apple, it was too expensive for a gaming console yet overshadowed in the computer market by full desktop machines. The system suffered a bit of an identity crisis as well: Was it for gaming? The Internet? Neither? Both? Pippin was one of those late-90s, pre-Jobs Apple experiments that didn’t take the world by storm and as such is largely ignored by retro gaming and computing enthusiasts.
Which is, of course, why I have one. 😀
Essentially a Power Mac 6100/66 crammed into a set-top box, in my opinion the Pippin packs a bit more power than a lot of folks realize. The Pippin had the most success in Japan, and most titles developed for it were localized for that region. Unfortunately many of those titles were authored in Macromedia Director and did little to show off the capabilities of the console. There were a number of third parties lined up to develop English software for the system in 1996 and early 1997, but this was also the era of Nintendo 64 and PlayStation, so Pippin was cancelled before many of these titles would ever ship—in some cases even before projects got off the ground. One of those titles was Presto Studios’ The Journeyman Project: Pegasus Prime, which I’ve had and continue to enjoy the tremendous honor of maintaining a modern rerelease for Windows, macOS, and Linux. Pegasus Prime almost didn’t ship at all—that Pippin was based on the Macintosh platform allowed Bandai to publish it for Power Macs instead, where certainly the returns were more promising. A number of Pippin discs could run on Macs—this was in fact a hallmark of the system. But this could also go both ways—if Pippin software is also Mac software, then shouldn’t the reverse be true? Why isn’t there a homebrew scene for the Pippin?
The only built-in software shipped with the Pippin came in the form of a circuit board with four megabytes of ROM that fit into a slot on the logic board inside the system’s case. The Pippin itself has no built-in operating system—each title shipped on one or more bootable CD-ROM discs containing a modified version of System 7.5.2. In a time before ubiquitous broadband Internet access like we have today, this allowed Bandai/Apple to provide upgrades and new features in software without having to download patches or release new hardware. But only titles that were signed or “Pippinized” by Apple could boot the system. This was done less to combat piracy (as the CDs themselves were and continue to be easily duplicated), but more to control the library, limiting the selection of titles to those produced by officially licensed developers. This is not that different from how Sony, Microsoft, and Nintendo prepare software for their respective consoles today. While the check for Pippinized discs could be skipped on test or retail kits using a special dongle provided by Apple (extremely hard to find today), development units came with a special ROM that removes the check entirely, allowing programmers to more conveniently test and debug multiple revisions before finally reaching “Gold Master” status and sending their final CDs off to be signed and pressed.
There were a couple different ROM board PCB styles—very early developers typically would get pre-production hardware with a ROM board populated with erasable Flash chips. These developers would periodically be asked to send their boards back to Apple to be reflashed with the latest ROM revision. Once the ROM was finalized and the Pippin went into production, boards shipped populated with mask ROM chips that could not be rewritten. I know of two developer ROMs, plus three ROM revisions that were released with retail consoles: 1.0 (white atMark Pippins in Japan), 1.2 (black @WORLD Pippins in the US and late atMarks), and 1.3 (very late Pippins). I have images of these three retail ROMs plus an image of the “GM Flash” developer ROM; I have never seen a retail ROM 1.1. As ROM 1.3 only shipped with a small number of Pippin units late in the system’s lifecycle, it is very rare but represents the last revision of the Pippin ROM, culminating a number of bug fixes and other changes.
ROM 1.3 also… I am told… removes the authentication check at boot, much like the developer ROMs do. 😉
I want to find out how. 😀
Power Macs produced in 1998 or later boot from Open Firmware and tend to have their ROMs loaded from a file on disk and loaded into RAM—the “New World” model. Earlier Power Macs like the Pippin also boot from Open Firmware but still have a ROM burned into a physical chip or chips attached to the logic board—the “Old World” model. Open Firmware is contained within the last 1MB of these ROMs, and overall its job is to start the 68LC040 emulator and use it to boot the rest of the ROM, which is written predominantly in 68K. Thus, the first 3MB of an Old World ROM is straight 68K code, mostly comprising the Mac Toolbox APIs and some necessary drivers for booting the system and loading the OS from a startup device. These drivers can be found in what are known as “resources”—self-contained chunks of data addressed by a four-byte “type” and a two-byte ID (or occasionally a human-readable name as a Pascal string). Resources aren’t just segments of code—they can contain any type of data such as pictures, icons, sounds, and fonts, just to name a few.
I’m quite familiar with resources—my earliest work on Pegasus Prime involved reverse-engineering some custom resource formats developed to hold metadata about the game’s QuickTime-based animations. I did some work a number of months ago trying to reverse-engineer the MacWorks XL ROM for the Apple Lisa, in an effort to port the HD20-enabled .Sony driver to it so my Floppy Emu could boot it (One of these days I should revisit that and do a writeup about it, but that project is definitely on the backburner). In the course of dissecting that ROM, I learned a lot about the Mac boot process and how the ROM’s address space in general is laid out. For example, the first four bytes of a 68K Mac ROM consist of a checksum of the ROM’s contents. Four bytes at offset 4 provide a reset vector, which the Mac uses to boot. And, at offset $1A, four bytes provide an offset to where the ROM’s resources are stored. An easy first step to understanding a Mac ROM—or in this case, that of a Pippin—would be to extract its resources and examine them in a tool such as ResEdit.
Either my Google-fu is failing me, or nobody has yet written a utility that will extract the resources from an OldWorld Mac ROM image. Sigh– I guess if you want something done,… 😉
— Keith Kaisershot (@ablitter) June 6, 2018
I think one of the reasons why I couldn’t readily find a utility that took a binary ROM image and spit out a .rsrc file is that the way resources are stored in the ROM has changed since the earliest Macs. The Mac Plus ROM, for example, literally stores a resource map as one would find in an actual resource fork or .rsrc file—quite simple. By the time of the Pippin, though, this had changed to a slightly more complicated scheme. I spent a few hours last night successfully reverse-engineering this and then halfway through writing an extraction tool before the evening got too late. This evening, I was greeted by a pleasant surprise:
https://t.co/ltBt5zgqYR Just committed part of my "tools" folder. Use https://t.co/k6r6gKzILP
— Elliot Nunn (@elliotnunn) June 7, 2018
– The initials “kc” and the name “Kurt” are used for padding—these refer to Kurt Clark, presumably an engineer at Apple at the time.
– Open Firmware contains strings referencing TFTP in all the ROM revisions I have. Maybe the Pippin can boot from TFTP somehow, bypassing the authentication check?
– Gary Davidian’s 68LC040 emulator and Eric Traut’s dynarec can both be found after Open Firmware in the last 1MB of the ROM. Maybe they can be replaced with the versions found in Connectix’s Speed Doubler, saving the need for loading that INIT into RAM?
– All four ROMs contain the resources for the blinking ? and X floppy icons, as well as the recognizable Happy Mac. These icons are shown during the boot process on a real Mac but unused on the Pippin.
– There are two PPC-based ‘ndrv’ resources: .Display_Video_Apple_Control (to drive the “taos” graphics hardware) and .DAVInput, which might be used with the rear RCA audio jacks. The Pippin doesn’t have any video input capabilities, but the Power Mac 6100AV did… maybe .DAVInput and some of its associated hardware is borrowed from that machine?
– There are five 68K-based ‘DRVR’ resources—.rdrvr (for the internal 128KB of Flash storage), .AppleCD, .Sound, .Sony, .AppleSoundInput, and .EDisk. The latter two are a bit interesting—.AppleSoundInput because it’s either used for the rear audio jacks or the internal connection to the CD-ROM drive’s audio, and .EDisk because it suggests the existence of a ROM disk somewhere.
– The CD-ROM driver is identical between the GM Flash and 1.0 ROMs. But then there are major changes going into 1.2—in addition to code changes, a new drive model appears to be added to a whitelist: the Matshita CR-8006, a.k.a. the Apple CD 600e. But then, in 1.3, the whitelist reverts back to that of 1.0, while incorporating additional code changes. I’ve successfully got a Toshiba DVD-ROM drive to boot my @WORLD, so I’m not entirely sure what this whitelist is used for yet.
More to come as I dig deeper…
Very cool !
For the optical drive, there is a weird things : when i have tried to install a 8x or 12x driver (from Apple) on my Pippin with 1.2 ROM, i can’t open the tray with the button, and the games with Audio CD track (Racing Days, i have not find another title with that) will not boot.
But with the 1.3 ROM, it works (tested with 8x, 12x and 24x drive from Apple).
Actually, two things : there is White Atmark japanese console withe ROM 1.2 (my first Pippin has a 1.2 ROM, and the console was never opened). And you *can* launch CD without authentication on 1.3 ROM (it’s not supposedly)
Thanks for the clarification re: the 1.2 and 1.3 ROMs, Dandu– I have edited the text accordingly. 🙂
Your experience with the tray button matches mine. I had almost written off my Toshiba drive as a viable option as a result. Good to know it’s resolved with the 1.3, though I haven’t yet tested with Racing Days. I’d like to verify it’s a problem with the ROM and not the hardware. It would be wonderful if the Pippin could accept other SCSI optical drives, including DVD. 🙂
Excellent sleuthing! Are you planning to burn your own Pippin-compatible CD images once you figure out how the check works? Here’s a bit of info from my experience with the classic Mac OS — hope it helps!
While I was mucking around with OS 9 on the Mac mini I looked closely at the early-boot 68k code in the ROM. This “Start Manager” code is part of a huge chunk of 68k code that lives immediately between the start of ROM and the ROM resources. Between the Mac II and NewWorld, the StartMgr didn’t change a lot. This patent application (!!), under “Trampoline Code”, actually describes how it works very well.
https://patents.google.com/patent/US6434695
I suggest looking at the function FindStartupDevice. You can probably find the machine code corresponding to this function in a Pippin ROM by searching for the sequence 7E 00 29 78, then counting backwards by twelve bytes.
My understanding of the authentication is that the file system map is digested and signed with a strong RSA key. I don’t know how likely it is that I’ll be able to crack it (I hear it’s a 1024-bit key) but if I can find a workaround then yes, homebrew on this system is my ultimate goal.
Thanks for the pointers! I’ve already started looking at the early boot code, which is very similar to the code found in the late Quadra ROMs. Good to know that it hasn’t changed much since the Mac II– Paul Pratt has some formatting files available for the II that will make reading its ROM much easier and thus save me some time comparing it to the Pippin.
It only checks the file system map? Not the file system itself? Could you replace the contents of a file without causing a signature violation?
Also, when are the nvram patches run in relation to the signature?
Could you stick in a nvram script that disables it?
The time it takes to get from a cold boot to the startup screen– indicating valid boot media– is way too short to suggest it hashes the entire filesystem. I suppose you could in-place edit the bytes of individual files with a disk editor and it would still pass the check, but that’s pretty inflexible and doesn’t allow for the addition of new files. The signature check happens very late in the initial startup process– literally immediately before a decision is made to advance to the “happy Mac” or not. It’s not done as part of Open Firmware.
I suggest looking into the various drivers that are contained on the disk. The Driver Descriptor Map might be useful. There is also something called the “Patch Partition”, which appears to contain code run around the right time in the boot process (not much(any?) documentation on it).
If you can add code to the right place on disk (I’m not sure exactly what you would have to do), it would get run a little bit before the signature check takes place. From there, you could sabotage it somehow. The simple way of doing that would be to have all the remaining startup code (minus the check) on the disk (you would have to adjust addresses and stuff so it works), so that the check never gets run. There are probably more elegant ways of doing that, such as faking the existence of the dongle. I don’t know what they are because I don’t have the code.
After a bit of searching, I found the documentation for the patch partition in the middle of this giant technote: https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1189.html
It appears that you can definitely have sections of code that are run from the cd before boot is attempted. You might even be able to get Drive Setup to install a custom patch for you (by sticking the right resources into it).
Unfortunately, it doesn’t look like it is easy to mess with the authentication code directly at that point. I would suggest installing a hook in a trap you know is called by the authentication code. Maybe _GetResource if you know a particular resource is only used in the auth code. Maybe you patch a filesystem trap so your code is run in the middle of the auth routine when it searches for the authentication file.
If you want to try to “crack” the console, i suppose you must try to search the “Tuscon” ISO. It’s a Mac OS ISO for Pippin, and there is many software and things on it. It’s interessant because it’s a homebrew (or btw not a commercial softare) but there is authentication file.
I suppose that one guy find a way to crack the Pippin to make this ISO.
I have a very strong inkling that the “Tuscon” disc was done internally at Apple (possibly also Bandai or Katz Media), leaked out to the Internet at some point, and is not a homebrew done by someone who has cracked the system. A few reasons for this theory:
– The newest files on the disc are dated September 1998. The Pippin console was cancelled in 1997, but Katz Media continued to support the platform under contractual obligations until eventually going under at the end of 1998. It stands to reason then that the signing server (or *a* signing server– who knows if it continued to live at Apple) would remain active while Katz fulfilled their promise.
– There are some suspicious-looking files on the disc, like a Bandai demo app named “BDE Self Running D5 16bit” and two files in the Preferences folder named “Apple R&P Lib Reseller 1.0 DDB” and “Apple R&P Lib Reseller 1.0 DDF” (Desktop files it appears). Seems unlikely an external homebrewer would have made a point to include these files (Why would they have them in the first place?), especially the latter two which look like they’re present by accident.
– In the intervening 20 years, no information about where or how this disc was produced has surfaced. Stranger things have happened, sure, but I’m inclined to believe there’s a simple explanation. 😉
This is beyond cool. I always wished for somebody to finally crack the Pippin security, so that we could have our own custom Pippinized CDs with PPC games, running on a stock console, without any dongles…
Hello there. I have a Pippin atmark that I’m trying to resurrect so that way I can finally play super marathon. The optical drive died on it, so I was wondering if it’s at all possible to use a scsi2sd interface with it. If you could offer any advice, I would greatly appreciate it.
It’s complicated, because many things depend from button and ROM. For the Pippin, the best way is to install a classic Apple SCSI CD-ROM (600i, 4x, aka CR-504). I have tried with many SCSI drive, and it will work… or not. The result depend from the ROM. With a 1.2 ROM, a 8x (or better) drive from Apple can’t read Audio and certain games will not work (like Racing Days). With 1.3 ROM, it work.