Mac-SE Easter Egg

From Trammell Hudson's Projects

While digging through dumps generated from the Apple Mac SE ROM images we noticed that there was a large amount of non-code, non-audio data. Adam Mayer tested different stride widths and found that at 67 bytes (536 pixels across) there appeared to be some sort of image data that clearly was a picture of people. The rest of the image was skewed and distorted, so we knew that it wasn't stored as an uncompressed bitmap.

After some investigation, we were able to decode the scrambled mess above and turn it into the full image with a hidden message from "Thu, Nov 20, 1986":

Read on for the reverse engineering details of how we recovered this and the other three photographs stored in the ROM, and some information about the Motorola 68000 era Macintosh.

We found this Macintosh SE on the side of the road in Brooklyn and carried it to NYC Resistor. It boots, but lacks any media, so we decided to do some further digital archeology.

We removed the two ROM chips (the ones in the middle of the board, above the VLSI ASIC that is the Integrated Woz Machine) and dumped them with my PROMdate device. The pinout for the chips is the same as the M27C512 PROM, but with the Vpp pin reused for A17. Since it is a mask ROM that can't be reprogrammed there is no need for the programming pin (Thanks, Nick!). This exapnds the address space to 128 KB (1024 kilobits) compared to the 64 KB of the M27C512 programmable ROM.

The m68k has a 16-bit wide bus, so each 128 KB 8-bit ROM has half a word and they need to be merged into a single 256 KB binary file. We knew we had a good dump and merge when strings on the file contained human readable textlike "Chicago", "PACK" and "CDEF" (if you have the byte order wrong these will be "APKC", etc).

Reports of the easter egg said that it could be found by jumping to address 0x41D89A. I was able to boot the ROMs in Mini vMac and confirm that these were indeed the secret images that had already been discovered. That could have been the end of it, but we wanted to know how they were stored and displayed, and to be able to look for any other surprises stored in the ROM, so further investigation was required.

To disassemble the ROM, I found it easiest to convert the raw binary dump to an ELF file so that objdump will process it. We know from history that the ROM was mapped to address 0x0040_0000 (24 MB) in memory, so we set the starting address of the ELF file there. IDA Pro is another great tool for doing exactly this sort of reverse engineering, but we're using free software for this analysis.

The 0xa03b instruction is odd -- Motorola reserved all instructions that start with 0xA, so this it is not a legal m68k instruction. Instead it will trigger an illegal instruction trap, and the trap handler looks at the next word and vectors to the appropriate handler. This A-line or A-trap is the official way to enter the Macintosh Toolbox and saves significant code space over the normal system call methods. This list of codes tells us that it is _Delay and that the value in %a0 will be used as an argument for how long to delay. We'll be refering to this list again to understand what is going on in the assembly code.
Based on this we can translate this function into something like "C":

This makes the A-line call 0xA9A0, or _GetResource(0x62626d63) and sets 0xb9e, the RomInsertFlag to instruct the search function to look in the ROM tables. If the resource get fails it jumps to a debugger trap (0xA9FF), which halts the machine. Otherwise it zeros %d7 and reads the address of the resource from the address returned by _GetResource and writes that value into the global memory location 0xa78 (AppleScratch).

If you speak ASCII, the constant might look interesting. It is a multi-byte character 'bbmc', which you might have noticed in the strings output at offset 0x1af4e, in what appears to be some sort of structure:

As of now we don't know how to decode the structure, nor what %a0 points to when it is dereferenced into the global at 0xa78. We'll come back to that later, but it clearly has something to do with 0x009A and the bit in red at 0x1AFDA.

Adam found the format expected by _UnpackBits defined in PackBits on wikipedia, and wrote a python unpackbits.py that can be given the offsets of the images in the ROM. So the last piece of the puzzle was to figure out where they are located.

And this is where I cheated... Based on a binary search of the image space using unpackbits.py, I found that the first one started at 0x1d93c. Looking slightly earlier in the ROM dump, I saw:

That 0x0000_0018 looks right; 0x1D924 + 0x18 = 0x1D93C. And immediately afterwards are additional offsets that look like the right spacing for the other bitmaps. That puts the others at 0x22F3C, 0x28040, 0x2D024 and something unused at 0x31BA5. Looking back at the ROM dump from the region of the resource definition, we even see an offset that points to 0x5801D924. (Don't be fooled by the leading 0x58 -- the Mac SE only had 24-bit addresses, so it will be ignored by the CPU).

Running Adam's tool, combined with my hex2png on the regions produced success for the four images!

So here is the team that twenty five years ago found space in the ROM to include their own images as an easter egg. Can anyone identify them? Where are they now? Are they "JCSLWRLBBMABOEMTDAHJTCFJLMBKCRCLAKEHBRDCDAFSHFT"? If you do know who they are, please send them our thanks for a fun puzzle!

What is in that fifth region? It didn't seem to have any image data of note, but it might be audio based on the strings in the ROM. Perhaps that's a project for later...