Ghosts in the ROM
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.
m68k-elf-objcopy --change-addresses=0x400000 --redefine-sym _binary_mac_se_bin_start=rom --strip-symbol _binary_mac_se_bin_size --strip-symbol _binary_mac_se_bin_end -I binary -O elf32-m68k -B m68k roms/mac-se.bin roms/mac-se.elf
Looking at the easter egg function address with m68k-elf-objdump -D roms/mac-se.elf, we see:
41d89a: 4eba 0018 jsr %pc@(41d8b4 <rom+0x1d8b4>) 41d89e: 5847 addqw #4,%d7 41d8a0: 0287 0000 000c andil #12,%d7 41d8a6: 6100 002e bsrw 41d8d6 <rom+0x1d8d6> 41d8aa: 307c 00b5 moveaw #181,%a0 41d8ae: a03b 0120073 41d8b0: 4efa ffec jmp %pc@(41d89e <rom+0x1d89e>)
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”:
void easter_egg(void)
{
func_41d8b4();
while (1)
{
d7 = (d7 + 4) & 0xC;
func_0x41d8d6();
_Delay(181);
}
}
The first function that this calls is 0x41d8b4:
41d8b4: 31fc ffff 0b9e movew #-1,b9e 41d8ba: 594f subqw #4,%sp 41d8bc: 2f3c 6262 6d63 movel #1650617699,%sp@- 41d8c2: 4267 clrw %sp@- 41d8c4: a9a0 0124640 41d8c6: 201f movel %sp@+,%d0 41d8c8: 6700 0050 beqw 41d91a <rom+0x1d91a> 41d8cc: 2040 moveal %d0,%a0 41d8ce: 21d0 0a78 movel %a0@,a78 41d8d2: 7e00 moveq #0,%d7 41d8d4: 4e75 rts ... 41d91a: a9ff 0124777
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:
001af3e: 5041 434b 0002 006a 7463 736c 0000 008e PACK...jtcsl.... 001af4e: 6262 6d63 0000 009a 5345 5244 0000 00a6 bbmc....SERD.... 001af5e: 4452 5652 0004 00b2 4344 4546 0001 00ee DRVR....CDEF.... 001af6e: 4b43 4852 0000 0106 4b4d 4150 0000 0112 KCHR....KMAP.... 001af7e: 4d42 4446 0000 011e 4d44 4546 0000 012a MBDF....MDEF...* 001af8e: 5744 4546 0001 0136 4355 5253 0003 014e WDEF...6CURS...N 001af9e: 464f 4e54 0004 017e 0005 ffff 5801 b122 FONT...~....X.." 001afae: 0000 0000 0004 ffff 5801 c188 0000 0000 ........X....... 001afbe: 0007 ffff 5801 d348 0000 0000 0000 ffff ....X..H........ 001afce: 5801 d896 0000 0000 0000 ffff 5801 d924 X...........X..$
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.
Moving on to func_0x41d8d6(), with psudeo-code interspersed:
41d8d6: moveal a78,%a0
41d8da: addaw %d7,%a0
41d8dc: movel %a0@,%d3 d3 = _a78[d7];
41d8de: movel a78,a7c
41d8e4: addl %d3,a7c _a7c = _a78 + d3;
41d8e8: movel 824,a80 _a80 = _824 // ScrnBase
41d8ee: movel #340,%d3 d3 = 340;
do {
41d8f4: pea a7c
41d8f8: pea a80
41d8fc: movew #72,%sp@- // 72 * 8 == 576 bits
41d900: a8d0 _UnpackBits(&_a7c, &_a80, 72)
41d902: subql #8,a80 _a80 -= 8;
41d906: dbf %d3,41d8f4 } while (d3--)
41d90a: pea a7c
41d90e: pea a80
41d912: movew #64,%sp@-
41d916: a8d0 _Unpackbits(&_a7c, &_a80, 64);
41d918: rts return;
Rewriting these three functions entire code in something more like C:
void draw_bitmap(const uint8_t * packed)
{
uint8_t * fb = _ScrnBase;
for (int y = 0 ; y < 340 ; y++)
{
_UnpackBits(&packed, &fb, 72);
fb -= 8;
}
_UnpackBits(&packed, &fb, 64);
}
void easter_egg(void)
{
const uint8_t ** bbmc = _GetResource('bbmc');
if (!bbmc)
halt();
int image = 0;
while (1)
{
draw_bitmap(bbmc[i]);
i = (i + 1) % 4;
_Delay(181);
}
}
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:
001d920: 0000 0064 0000 0018 0000 5618 0000 a71c ...d......V..... 001d930: 0000 f700 0001 4281 0000 0000 30aa 552a ......B.....0.U* 001d940: 52a5 294a 5294 a529 4a52 2449 1224 44a9 R.)JR..)JR$I.$D.
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!
for offset in 1D93C 22F3C 28040 2D024; do off_decimal=`echo 16i $offset p | dc` ../unpackbits.py $off_decimal 5000 < mac-se.bin | ../hex2png -w 576 -y 384 -s 24576 | convert -crop 512x341+0+0 - 0x$offset.png done
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…
0031ba0: 00b9 00b9 0000 c000 08fc 0000 0068 600a .............h`. 0031bb0: 0000 5345 5244 0000 0003 487a 0074 487a ..SERD....Hz.tHz 0031bc0: 0058 487a 003c 487a 0020 76fa 3003 a53d .XHz.<Hz. v.0..= 0031bd0: a029 2050 225f 20c9 30d1 30bc 0003 5343 .) P"_ .0.0...SC
These images are still copyright Apple Computer, of course. That means they have been:
It’s cool that you guys found these! I have to say- it’s pretty well documented, but cool nonetheless.
More info and images here:http://www.flickr.com/photos/damianward/3300112470/
jeeze, next thing you know you’ll be telling us that dogcow is dog+cow
you kids, that is a documented easter egg back in the day! its easier to get to: https://discussions.apple.com/thread/122367?start=0&tstart=0 now you just get offa my lawn!
Thank you. Came here to say this.
You know you’re old when something that is “common knowledge” to you is a major mystery, dumpster dive and hacking project for someone else.
What gets me is that he didn’t recognize RLE the moment he saw it.
Kids today!
you know you’re ignorant when something that is “common knowledge” to someone only a few years older, is a major mystery, dumpster dive and hacking project for you. youth is know excuse for not learning the history of your field 🙂
You know you are an idiot when you are unable to give proper recognition for some tech success or achievement, even if it was “common knowledge” for others or not. Some people still get happy when they get to crack winzip themselves, you know.
you’re off the point – “common knowledge” in this discussion clearly does not refer to the technical procedure, it refers to the easter egg itself. clearly, the author of this article were not aware that this easter egg was extremely well documented.
look: it is o.k. to climb mont blanc. thousands have done it, thousands will do it. however, what would we make of someone who climbed mont blanc BECAUSE he or she did not know there was a cable car?
I remember typing the code into my Mac SE to view these pictures back in the early 90s. Thanks for the link to that Apple discussion – it brought back fun memories.
The programmer’s switch! Our computer lab in high school were all Mac Plus machines and I carried a programmer’s switch everywhere I went. Oh man, such awesome memories.
That’s a funny memory! We had a 68k assembler class at Ohio State on Mac Plus machines. But they never taught people how to use Macsbug and there were no programmer switches installed. So I started showing people how to stick anything handy in there to find it. Of course, reset was an occasional danger in those cases and the lab machines booted to a RAM disk, so people had to be extra sure to save to floppy or potentially lose their work.
I think the whole point of the exercise was to practice some digital archeology, not because no one knows what the folks who worked on the Mac SE looked like 😛
Read the article again. The author clearly knew about the Easter egg but wanted to do some independent digital archeology and have some fun. “Reports of the easter egg said that it could be found by jumping to address 0x41D89A. I was able…”
I don’t know them personally, but Andy Hertzfeld has a small gallery of the original & early Macintosh team members that should identify most (if not all) of them:
http://www.folklore.org/ProjectView.py?project=Macintosh&gallery=1
The stories he recounts on the site that he later had published also are definitely worth a read.
The link is invalid, any help there?
off the top of my head:
first picture:
??, Bill Bruffey, ??
??, Ed Tecot, Tony Leung
Alan Oppenheimer,??, ??
third picture:
??, ??,??
Jack McHenry (RIP), Bob Bailey, ??, Dave Fung
??,Brian Howard (RIP),??
–al (AAPL 1986-2005)
Top picture, top row, 2nd is Brian McGhie, aka BBM.
Al knows way more of these folks than I do, but here’s a couple:
– Second picture, middle back is *definitely* MIchael Tchao
– Third picture, back row, on the right – could that be Jimbo? (Jim Nichols)
Hi Al!
– yeff
Here are a few more names, from Ed Tecot
http://www.flickr.com/photos/osr/7828783866/
Cary Clark Tom Jennings Bill Bruffey Steve Flowers
Ed Tecot Tony Leung
Alan Oppenheimer Frank Leahy Amy Rapport
http://www.flickr.com/photos/osr/7828783760/
? ? Michael Tchao ? ? Jay Patel
? ? Charlie Oppenheimer
Hi Folks, I just came upon this site and found my picture from the Mac SE easter egg. That is me (Marjory B. Kaptanoglu) next to Frank Leahy, not Amy Rapport. I wrote the text editing software that went into the SE and the Macintosh II. Later, as someone above pointed out, I worked on MacDraw II. Hope that clears things up a bit!
Margie
Cary Clark Tom Jennings Bill Bruffey Steve Flowers
Ed Tecot Tony Leung
Alan Oppenheimer Frank Leahy Amy Rapport
? ? Michael Tchao ? ? Jay Patel
? ? Charlie Oppenheimer
third picture:
??, ??,??
Jack McHenry (RIP), Bob Bailey, ??, Dave Fung
Rich Castro, Brian Howard (RIP),??
“what appears to be some sort of structure”
It’s called a ROM Resource, “bbmc” is Brian McGhee, the person on the left in the back row of the first image you decoded. Before the system was running from disk, if you needed a resource they were kept in ROM as a set of ROM resources.
I’m chuckling at whomever voted this down. Lulz…
I can identify all of those people:
dorks
Sorry for those offended, but this comment really made me laugh. I’m equally dorky though, because I knew the code to type into my Mac SE and get these pictures back in the 90s.
So you are yet another dork!
No, they’re ROMulans
No, they’re ROMulans
I can identify all of those people:
dorks
THIS JUST FUCKING AWSMMM GUYZ 😀 m/
Awesome. Awesome, awesome, awesome, awesome, awesome.
Great stuff, Hudson.
I ran the diffusion-dithered 1-bit images through a few Photoshop filters and came up with the following restorations:
http://disco.bu.edu/~tsl/temp/GhostsInTheROM-restored.png
Wow, that’s pretty cool, how did you do it?
It’s called “blur”. Maybe with a bit of unsharp mask afterwards.
I bow down to your awesomeness
Didn’t you just stick in original images? Some details (fine-grained patters on shirts etc.) appear “too correct”. Otherwise, kudos to you and programmers at Adobe.
That noise is quantization noise (it’s a monochrome image!), and the restoration included dither. Nothing unexpected here.
Working link: https://www.letemsvetemapplem.eu/wp-content/uploads/2012/08/GhostsInTheROM-restored.png
“JCSLWRLBBMABOEMTDAHJTCFJLMBKCRCLAKEHBRDCDAFSHFT” appears to be a list of programmers. When we would make changes to the source code, we would put our initials by the check-in comment (I am EHB).
Some of these people are pictured, but not all
JC – ?
SL – ?
WRL – Wayne R Loofburrow
BBM – Brian B McGhie
ABO – Alan B Oppenheimer
EMT – Ed M Tecot
DAH – ?
JTC – Jerome T Coonen
FJL – Frank J Leahy
MBK – Marjorie B Kaptanoglu
CRC – Cary R Clark
LAK – Larry A Kenyon
EHB – Ernie H Beernink
RDC – Rich D Castro
DAF – Dave A Fung
SHFT – ?
That’s great, thanks! It appears 280 times in the ROM from 0x3CBA8 all the way to 0x3FFFF, so I guess there wasn’t enough room for another image and it was another way to fill in the space.
Here is another message from one of the senior Mac ROM guys
I think your guess of Amy Rapport is incorrect, I think that’s actually Marjorie B Kaptanoglu Not sure what ROM code she worked on, I recall that she was working on MacDraw.
I think I can unravel the ROM initials string mystery, it was a repeating string that filled all unused ROM space, and the “discoverers” started the string in the middle of one of the initials, and to add more confusion, there was one two-letter initial.
J -“Jennings” move to the end
CSL – C.S. “Tony” Leung
WRL – Wayne R Loofburrow
BBM – Brian B McGhie
ABO – Alan B Oppenheimer
EMT – Ed M Tecot
DAH – Dave A Holzer
JTC – Jerome T Coonen
FJL – Frank J Leahy
MBK – Marjorie B Kaptanoglu
CRC – Cary R Clark
LAK – Larry A Kenyon
EHB – Ernie H Beernink
RDC – Rich D Castro
DAF – Dave A Fung
SHF – Steven H Flowers
TJ – Tom Jennings
Yes, this list looks correct; I recognize most of the names. Indeed, that is me (Marjory B. Kaptanoglu) next to Frank Leahy. I wrote the text editing software that went into the SE and the Macintosh II. Later I worked on MacDraw II.
Margie
I put the pictures in ROM. Unfortunately, I was gone the day of the pictures. So when I got the data, I added myself in the back of the first picture. Notice the lighting is different for my head than for the other heads. Great memories!
Brilliant move, sir! Easter eggs were a valuable tool for getting me and my friends more interested in the machines that would shape our future. We traded them like Pokemon cards! Yours was easily one of the most impressive. Knowing the interrupt code off the top of your head marked you as an über nerd to be feared by ill-prepared comp sci teachers. (mu ha ha)
@Al – Pretty sure Jack McHenry is still with us.
you’re right, sorry about that!
http://www.gastongazette.com/articles/linda-15075-jack-mchenry.html
LoseThos source files are LTF documents. They can include graphics.
Similar story about three Microware (now Radisys) engineers stuffing their grins onto the Tandy / Radio Shack Color Computer 3 ROM -> http://www.cocopedia.com/wiki/index.php/CoCo3_Easter_Egg
I mean you guys know that this wasn’t a secret right? It’s been a known easter egg for like… um forever?
I’ll refer you to XKCD: http://xkcd.com/1053/
Love that comic. Fantastic way to make that point.
Back in that era several computer owners I knew would make bootleg Macs out of Atari ST computers, Mac roms, and David Small’s Magic Sac cartridge. Power Without The Price, lol.
Back in that era several computer owners I knew would make bootleg Macs out of Atari ST computers, Mac roms, and David Small’s Magic Sac cartridge. Power Without The Price, lol.
Here’s the better question – how did they digitize images in those days?
I can’t say for sure what they did here, but back on the apple ii+ i believe it was , for a computer project in school we had a camera that would snap pictures and bring them into the computer.
Thunderscan was a serviceable solution (ugh)
and Koala MacVision (the one with the two funky dials on it) for video.
For more vintage Mac fun, get a copy of ResEdit! I used to have a HyperCard stack that pulled these images out of ROM. Good times!
Very cool, nice work and find!
http://www.retrocomputing.net/info/siti/apple_repair/www.whoopis.com/computer_repair/SecretROMStuff.pdf
Entering a ‘code’ to get the images..fprint(big_whoop), reverse engineering the code to get them…fprint(FREAKIN_AWESOME).
Frakin’ @*!&$? system. Anyhoo.. entering a ‘code’ to display the pics..fprint(“big_whoop”); reverse engineering the code to do so..fprint(“FREAKIN_AWESOME”)
They had digital cameras back then?
It was probably a paper photo scanned using http://www.folklore.org/StoryView.py?project=Macintosh&story=Thunderscan.txt. That would be my guess, anyway.
Sort of. I remember back in 1987 or so we had a Macvision thingy that could produce similar pictures. You fed it composite video from an NTSC camera and after adjusting two dials on the Macvision box, out popped a low-res monochrome pic on the Mac screen. IIRC you had to provide a relatively still picture or it would look smeary thanks to the slow hardware.
Yep. And you had to usually do it twice, once for practice as you dialed in the contrast and brightness on the fly, it took about 5 seconds to scan, then you’d guard those dials with a vengeance as you clicked the “real” scan.
i´m reading the notice from argentina (you don´t know where it is for sure) but this is very funny and amazing all of this, isn´t it??
you’re not alone…
definitely not alone
I do!. I am reading this from Chile (which is not part of Mexico)
Another chilean here, hello 🙂
also from Argentina, quilmes, bsas.
I have restored the image even further for more detail
http://oi45.tinypic.com/9fr90l.jpg
There is no “zoom and enhance” in the real world, I think the middle version is still the best.
Maybe its help:http://www.mymac.com/img/features/slideshow-SE-Neale.jpg
http://www.tineye.com/search/2f858cde6b87f1a70b273ee3fba77b731e2b5891/
I am in the second picture just behind Lori Garfinkle who I believe was on the Packaging team at Apple. I kept this method of bringing up the pics – use the debugger and type “G 41D89A” and then hit return. Great to see this again after so many years. Jim Dumont, Mac SE Project Coordinator