According to the NetBSD/macppc FAQ, Open Firmware “is part of the boot ROMs in most PowerPC-based Macintosh systems, and we use it to load the kernel from disk or network.”

Turns out, “most PowerPC-based Macintosh systems” happens to include the Pippin. If you have the rare keyboard/tablet (or an ADB keyboard via the AppleJack dongle) attached and hold down Command-Option-O-F at startup, the Pippin boots to an Open Firmware prompt. However, you won’t see anything on screen because it outputs to a serial console by default; specifically, all console I/O is handled through the GeoPort. My Mac Plus happens to sit next to my Pippin, so tonight I temporarily switched my ImageWriter II’s cable over, booted both machines, and fired up ZTerm.

The following is what I discovered.

Open Firmware, PipPCI.
To continue booting the MacOS type:
BYE
To continue booting from the default boot device type:
BOOT
 ok
0 > dev / ls
FF829230: /PowerPC,603@0
FF829B28: /chosen@0
FF829C58: /memory@0
FF829DA0: /openprom@0
FF829E60: /AAPL,ROM@FFC00000
FF82A088: /options@0
FF82A528: /aliases@0
FF82A6F0: /packages@0
FF82A778:   /deblocker@0,0
FF82AF78:   /disk-label@0,0
FF82B4B8:   /obp-tftp@0,0
FF82D8F8:   /mac-files@0,0
FF82E0F0:   /mac-parts@0,0
FF82E850:   /aix-boot@0,0
FF82ECC8:   /fat-files@0,0
FF830298:   /iso-9660-files@0,0
FF830BE0:   /xcoff-loader@0,0
FF8315A0:   /terminal-emulator@0,0
FF831638: /aspen@F2000000
FF832900:   /gc@10
FF832D38:     /scc@13000
FF832E90:       /ch-a@13020
FF833540:       /ch-b@13000
FF833BF0:     /awacs@14000
FF833CD8:     /swim3@15000
FF834DE0:     /via-cuda@16000
FF835970:       /adb@0,0
FF835A60:         /keyboard@0,0
FF8361B0:         /mouse@1,0
FF836260:       /pram@0,0
FF836310:       /rtc@0,0
FF8367D8:       /power-mgt@0,0
FF836898:     /mesh@18000
FF838418:       /sd@0,0
FF839048:       /st@0,0
FF839CC8:     /nvram@1D000
FF839DA0: /taos@F0800000
FF839EC8: /aspenmemory@F8000000
 ok
0 > dev /openprom  ok
0 > .properties
name                    openprom
model                   Open Firmware, PipPCI.
relative-addressing

 ok
0 > printenv auto-boot?

auto-boot?          true                true
 ok
0 > printenv use-nvramrc?

use-nvramrc?        false               false
 ok
0 > printenv real-base

real-base           -1                  -1
 ok
0 > printenv load-base

load-base           4000                4000
 ok
0 > printenv boot-device

boot-device         /AAPL,ROM           /AAPL,ROM
 ok
0 > printenv boot-file

boot-file
 ok
0 > printenv input-device

input-device        ttya                ttya
 ok
0 > printenv output-device

output-device       ttya                ttya
 ok
0 > printenv nvramrc

nvramrc
 ok
0 > printenv boot-command

boot-command        boot                boot
 ok
0 > bye

This dump was generated on my @WORLD Pippin with ROM 1.2. Some observations:

• OF doesn't report a version number, instead reporting "PipPCI" in its place. Searching the ROM for strings reveals "June 28, 1996" as the latest date I could find, so whatever Apple was using in its Power Macs at that time I imagine is what is running here.
• The ROM is located at 0xFFC00000, which follows what I've seen from hardcoded addresses I've found.
• "taos" is the video hardware starting at 0xF0800000. I'm not sure offhand if that address is the base of video memory, but I do know from the Pegasus Prime code that taos does allow for writing directly to VRAM.
• There is a TFTP package(!)—wonder how it works?
• The Pippin has a SWIM III chip onboard. There is an official floppy drive expansion dock and an unofficial floppy drive expansion board, both of which appear to be "dumb" hardware that merely connect a drive directly to pins of the Pippin's X-PCI connector on the underside of the system. The drive itself is powered and controlled entirely by hardware already built in to the Pippin. However, as far as I know, the SWIM II and later floppy controllers (including the SWIM III) lack the low-level access necessary for HD20 support, so large drives emulated by hardware such as the Floppy Emu will not work.

In part 1 of this series of posts, Daniel suggested taking a look at the role the SCSI Manager plays in the Mac’s—and by extension, the Pippin’s—startup process. I took a break from examining the auth check code to dissect how the SCSI Manager behaves at startup on the Pippin, with the ultimate goal to discover if an exploit was even possible. After all, from my initial search of the ROM it’s clear that Apple had patched part of the boot process to only allow starting up from the internal CD-ROM drive—who’s to say there aren’t further patches deep in the SCSI code?

The tl;dr is that, after careful examination, I have determined that the SCSI code in the Pippin’s boot process is for the most part unchanged compared to a Mac of the same era. However I’m not yet sure if a “patch partition”-based exploit is possible.

---

Most of what follows I garnered from the “Monster Disk Driver Technote,” a mirror of which can be found here:
http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn1189.html

Every SCSI-equipped Mac for the most part follows the same procedure for booting from a SCSI device:

1. It looks for a valid Driver Descriptor Map in the first 512-byte block
2. Loads the device’s driver(s) according to the information found in the DDM
3. Mounts the disk’s HFS partition
4. Loads the boot blocks from the startup volume and executes them

This has been the case since SCSI was introduced to the Macintosh line with the Mac Plus in 1986. Previously, Macs had primarily booted from floppy disk and occasionally from a non-SCSI hard drive such as the HD20 or HyperDrive (but usually with help from a boot floppy). In either event, the Mac had no concept of drive “partitions” or even “volumes” in the modern sense—the MFS file system consumed the entire disk, and that was it.

The Apple Partition Map, introduced at the same time SCSI arrived on the Mac, changes this behavior by placing the primary file system in its own partition. On a high level, the Mac sees the volume as its own big disk, but the APM also allows device drivers to live in their own partitions rather than in INIT files as was done with the HD20. This moves their load time to much earlier in the boot process independent of the System Software and—critically—eschews the need for a separate boot disk. The SCSI code in ROM recognizes the presence of an APM, loads the driver(s) directly from disk, then locates and boots a startup volume. In this way, Macs can boot directly from a hard drive, a CD-ROM drive, or any SCSI-capable storage medium so long as it has the proper drivers preconfigured.

What does all of this have to do with the Pippin? Well, the Pippin’s only internal storage is its 128KB of non-volatile Flash memory, and even if the Pippin ROM was written to look there for an OS, 128KB is barely enough to boot the original Macintosh—never mind the System 7.5-based OS that Pippin titles shipped with. Instead, the Pippin boots from its internal (SCSI) CD-ROM drive, presumably calling into the SCSI Manager to load any device drivers followed by mounting the HFS partition, verifying the contents of the “PippinAuthenticationFile,” then continuing to boot the OS if everything checks out.

Wait a minute…

Before searching for an operating system, the SCSI Manager is supposed to load device drivers directly from disk according to the Driver Descriptor Map. It does a basic checksum verification, then… executes them! They run before the auth check!

At least, in theory.

I took a look at the “Pippin Network CD” (product ID BDB-002) that originally shipped with the 1.0 Atmark units in Japan. I chose this particular disc because of two things: 1) It has an Apple Partition Map and 2) It contains a very small device driver partition with plenty of extra room in which I could hack a “proof-of-concept.” I rustled out the original driver from an ISO image of the disc with a hex editor, then added some code that does the equivalent of while (!Button());. I then recalculated my hacked driver’s checksum using a quick program I wrote, poked the driver (and its proper checksum) back into the ISO, burned it to disc, booted my Pippin with it, and…

It booted directly to the login screen.

This tells me that one of two things might be happening:

1. The Pippin’s version of the SCSI Manager in ROM does not in fact load device drivers from disc. The SCSI Manager does a number of checks before it determines that it needs to load drivers for a particular device, and it’s possible that the Pippin fails one of those checks, possibly intentionally. In this case, it may be that the driver lives in ROM and any drivers on Pippin discs exist for the benefit of mounting on actual Macs, where the hardware isn’t fixed and device drivers would be more necessary. Also, only a handful of Pippin discs have partition maps; the majority of them are formatted as a flat HFS volume. What does the SCSI Manager do in that case? Where do the requisite device drivers come from?
2. I screwed up hacking my driver code into the disc image before burning it. 😛

Unfortunately, when I mount this disc on my Power Mac G3 in Mac OS 9.2.2, my driver code doesn’t run there either. There must be some condition(s) under which the SCSI Manager will skip loading drivers from a CD-ROM mastered with them.

Looks like I have some more digging to do…