Macintosh IIci Easter Egg Hunt
There is an easter egg hidden in the Macintosh IIci: You set the system date to 20. September 1989 (the release date of the machine), reboot and press Command + Option + c + i. If you done all correctly, you get an image of the IIci development team.
I was curious where the IIci easter egg was stored in ROM. So I downloaded the ROM and as a first try, I ran it through a custom script, that creates a pixel for every byte in the ROM file and chooses its intensity according to the byte value. This is what came out:
I could not recognize any bitmap patterns on the resulting image, so no luck with this method.
Then I tried binwalk, a tool that identifies known file headers. For example, it can extract JPEG images from the later Power Mac ROMs. But no results here either:
So it was time to fire up a disassembler and start with reverse engineering. I use an old version of IDA Pro for this.
As a starting point, there is a great article for Macintosh ROM hacking, available on www.bigmessowires.com.
First step is to load the ROM correctly in the disassembler: The ROM is 512 KB in size and the IIci maps it to address 0x40800000. So you need to load the ROM at 0x40800000. I also created a RAM segment of 2 MB in size:
When you reverse engineer something, it is tremendously helpful to have names for addresses in ROM that describe them. It turns out, there is a ROM map file for the IIci in some releases of the Macintosh Programmers Workshop (this was Apples development software package). I found it on the MPW-GM release:
I ended up creating IDA specific Python expressions from this file, that define the names in IDA.
Armed with address names, I tried to find the code section, that was responsible for drawing the easter egg picture.
I looked for names that could be involved in the easter egg logic. Names related to drawing, key input or date checks. However, all interesting routines I found, seemed not to be called by any code that looked like the easter egg code.
Interestingly there is a routine called TODEEPSHIT. Wondering how this name came about 🤔...
Anyhow, I switched strategy and started at the entry point of the ROM and work my way down. Then suddenly something else caught my attention. What are these magenta colored names?
Then it came to my mind: These must be the A-traps, the Macintosh way of doing syscalls. Very nice, that IDA automatically recognized and translated them.
Now I had another lead: I could look for A-trap names that might be used in the easter egg code. I found a list of all A-traps in the MacAlmanac II.
DrawPicture immediately caught my attention. It translates to the hex value 0xA8F6, a value I could search for in the ROM:
Great only 4 candidates to check. The last routine at 0x40847524 looked the most promising. The A-trap names show, that it draws a rectangle and a picture with some framing.
This routine is only called once in the ROM. The call is located in the code section right above at 0x408474d0 and is named INITOVERPATCH. Before calling the draw routine, the code first branches to the subroutine at 0x408474d8 which compares a lot of RAM data with intermediate values. Now I was pretty sure that this is the easter egg code.
To better understand what the compares actually do, I also added names of known RAM locations to IDA. I pulled them from the MacAlmanac II and the Macros.r file (located in the MacsBug resource folder on the MPW 3 CD-ROM). The memory locations that are checked are named KeyMap and Time. So, exactly what is needed for the easter egg code to work.
To verify everything, I went to the IIci, hit the interrupt key, which brings up a small debugger. There I entered G 40847524:
This instructs the CPU to GO to the address that draws the easter egg image. The checks for the correct date and pressed keys are not relevant, as they happen in the other routine. After hitting enter, we got this:
Cool, a little bit offset, but the picture still made it to the screen. Now we can trigger the easter egg whenever we want.
The next step was to extract the picture data from the ROM.
By browsing the Inside Macintosh books, I found out that the DrawPicture A-trap, that is used here to draw the picture, requires PICT resources as input.
PICT resources start either with the hex sequence 0x110101 for PICT1 or 0x001102ff for PICT2. So I searched for these values in the ROM, but could not find any. I assumed that the image data is stored scrambled in ROM and that the code decompresses or just descrambles it before putting it on display.
So I looked again at the code in IDA and saw that the draw routine 0x40847524 calls another routine located at 0x408475f2. Note that the first instruction loads the address 0x4084777e into register a1. Upon which data is loaded and processed. This means that the address 0x4084777e most probably is the address of the scrambled image data and that this routine unscrambles it.
To verify this, I copied the code of the routine and the section of the ROM that contains the scrambled data and put together a program for EASy68K, an Motorola 68000 emulator. I use an emulator, because it helps me a lot understanding machine code. You can step through it and inspect the registers and memory values as you go.
After running the program, I dumped the unscrambled data from RAM and opened it with Preview on macOS.
There it is, the IIci easter egg image, in its full low-res 256 color glory!
Now an idea came to my mind: What if we write a Python script that mimics this descramble routine and check if we can extract valid PICT resources from other Macintosh ROM images. Maybe we discover easter egg images nobody knows about yet.
It took me a while to get the script together, the obscure bfexts assembly instruction boggled my mind quite a bit. It was already late and the script was quite slow, so I started it and went to bed. The next morning I was excited to check what the computer came up with. Following images were extracted:
The first is the IIci picture that is also contained in the IIfx ROM.
The second is a picture that is contained in Quadra 700 and 950 ROMs. I found out that this Reign of Terror easter egg is already documented on the Internet.
So quite a bummer, I hoped at least for one unknown easter egg. 🙁
This was in February 2022, in October 2022 I started writing this page to share the project on the Internet. I was polishing the scripts before publishing them, when I realized: The extraction script only checks for PICT2 and not for PICT1 resources.
So I went ahead and implemented the PICT1 file extraction and ran it over all ROMs again. Apart from the previous PICT2 matches and some invalid ones, one new image appeared:
It's contained in the Quadra 610/650 and Centris 610/650 ROMs. I never saw it and also could not find anything regarding it on the Internet.
Even though the image is a bit lame, as it only contains text, it was still cool to find at least one unknown easter egg 🥳!
Now the last step was to check in the code and see how the easter egg can be triggered.
I loaded the Centris ROM and searched for the DrawPicture trap to find the easter egg code and the according check routine. I found it at 0x4084f154:
With the help of trusty old EASy68K I could reverse how it works. The routine is similar like the one found in the Quadra ROMs and is a bit more complicated than the one on the IIci. Instead of having a check for every key, it loops through a list of 4 byte values (easteregg_keymap_values), that define which bit on which offset on the keymap has to be set.
The keycodes are documented in the Inside Macintosh books. By looking them up, I could figure out that ESC + l + f + w needs to be pressed on boot.
To verify this, I reached out the 68kmla.org community, and after one day we had this easter egg confirmed. Many thanks to them!
It was interesting to do the reverse engineering on the ROMs and I was very happy finding an unknown easter egg on the second attempt!
If you want to try it yourself, you can download all the scripts from https://github.com/nerdprojects/macintosh-rom-easteregg-hunt.
And an idea for the future could be to look for sound resources in the Macintosh ROMs 😉.