Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

HFS Easter Egg

I came across these postings on Info-Mac a while ago and thought you might enjoy reading about how one finds a deeply buried Easter Egg.

Francois Grieu: I have discovered an obscure Easter Egg in the System 7 implementation of HFS.

When the Macintosh requests a disk because it's off-line, there are provisions for displaying a hidden message.

Try it!! Rename a disk exactly to:

     KMEG JJ KS      (this is 8 uppercase letters and 2

Eject the disk with command-E so that you have a gray icon of it on the desktop. Now double-click on something in the disk and check out dialog box that wants the disk back. Oh well, it's only a message...

Question: Who are dnf and ksct?

Difficult problem: what's the name of their disk?

David N. Feldman: Congratulations - you have not only found the HFS Easter Egg in System 7, you've managed to do it in a way only vaguely imagined by the author of the egg.

To answer your questions, dnf and ksct are David N. Feldman and Kenny S. C. Tung, the two Apple Engineers responsible for the extensions to HFS under System 7. The name of their disk is a bit less complicated than you make it out to be. You see, that string is triggered off of a checksum of the disk name. The intended disk name is "Like Wow Man. HFS For 7.0!" (the space after the period is an option space, just to be arbitrary) Your string, "KMEG JJ KS" just happens to have the same checksum, and so is greeted with the same message.

When I wrote the patch at Apple, I wondered (ever so briefly) what the chances of a collision in the checksum space were. You have answered the question. For your interest, check out the code hanging off the pointer at $3EA in lomem. You should quickly catch the innocuous subroutine call which calculates the checksum.

Francois Grieu: Thanks for your kind answer, and for relieving my curiosity. Here is more on the checksum algorithm, and how I found this Easter Egg.

As you may recall, the checksum algorithm zeroes D1, then does,

     ADD.B   (A0)+,D1    ;add new byte from disk name
     ROL.L   #3,D1       ;spread it around for each character in
                          the disk name,

and finally tests D1 against $7609F56D.

The chances that a random name (over 10 characters long) matches the checksum is about one in 4000 million. Assuming a disk name per day per 10 million users for five years, the odds are that about four names would trigger the recognition. In practice, it's even less likely, for people tend to choose short names and the shortest name that matches is nine characters long, or 10 restricting to usual characters.

As a matter of fact, I didn't find the string "KMEG JJ KS" by mere chance; rather, I happened to break into the debugger at a location close to the checksum code, and got my eye caught by the CMPI.L #$7609F56D,D1. I took that as a late weekend puzzle. I found how it was called, and wrote a small program to construct matching strings.

The program uses a simple heuristic varying the string (replacing wildcards in a template with characters taken from a chosen set) to minimize the bit distance with the checksum. The program finds matches within fraction of a second, because two nearly identical names tend to make nearly identical checksums.

"KMEG JJ KS" is just a short, reasonably mnemonic string that worked. Another names that triggers the Easter Egg is "Hello world JS N A DTP".

Using my algorithm, it's nearly impossible that I could ever reconstruct "Like Wow Man. HFS For 7.0!", especially with the option-space after the period.


READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <>
Special thanks to Tripp Frohlichstein, Joyce Mastboom, James Sanborn,
and Tom Bickle for their generous support!