Re: Revisiting... secret keys and Easter eggs

[Hot Rod <hotrod.apple2@gmail.com>]

On Thursday, September 20, 2012 12:01:29 AM UTC-5, xorxif wrote:
> This is the type of stuff I've been interested in since I was a kid and 
> 
> captured my imagination about what COULD be contained in these little 
> 
> secret corners of programs.
> 
> 
> 
> In addition to recompiling all your notes on what things you did find 
> 
> hidden over the years, I think it would be really interesting if you 
> 
> could explain HOW you search for them, because the basic process and 
> 
> thinking behind finding them, I think, could be applied to a search for 
> 
> those types of secrets in almost any program, for any platform, with the 
> 
> specifics being of course more relevant to platforms that are 6502 based.
> 
> 
> 
> I'm really looking forward to your forthcoming posts on this, thanks!
> 
> 
> 
> - xorxif

Hmm, fair enough question.

In the 80's, I went about it using just a handful of approaches.
a) Tracing the code.
b) Searching memory.
c) Searching the disk.

Tracing the code was somewhat incidental to boot tracing, but often since that would lead you up through the beginning of a program, any setup/initial input routines were readily examined.

With portions of the code loaded in from disk, or during runtime, an alternative would be to just search RAM rather than trace it.  This was sometimes faster, but also sometimes needed for portions of code that weren't always present in RAM (got loaded from disk), or were encoded on disk.

Searching the disk was just a matter of doing a sector by sector examination using a tool like The Inspector.

Now, searching for what?  In the case of true secret keys, typically this would be instances of the softswitch addresses ($C000, $C010) for keyboard. Then where those are found, examining the code around them to see what the logic is.  In some cases it's very straightforward: the code reads the keyboard and compares to some supported values.  If any of the compared values are 'unusual' (e.g. a control key, or undocumented input value), then either trace what they do and/or try them (usually just trying them is sufficient). Often it's a series of keys, to be entered in the correct order.

But sometimes it's not so easy.  The softswitch address use can be obfuscated (e.g., zero page indirect, offset indirect).  Sometimes the keyboard scan is mixed in with a larger loop that is handling several items (sound, animation) such that resolving the keypress is done elsewhere.  In the 80's, these required more tracing and breakpoints.

On an Enhanced //e, there is a memory search function available in monitor (the 'S' command), so searching RAM for certain values was easier.

When searching disks, looking for the keyboard address was also possible, as was looking for unusual text.  If unusual text was found, then the question was whether there was a means to invoke it.  That led to looking at more code.

But keyboard is not the only means to invoke secrets.  There are some that are done via the paddle/joystick values and buttons only (or in combination with keyboard).  Similar approaches, but now including those softswitches.

After a while, scanning through disks and looking for 'unusual' things got pretty quick.  It's not so bad to tell the difference between machine code, shape tables, pictures, text, packed pictures, etc. (I would also look for shape tables and extract the shapes sometimes).  Looking for disk routines was also done this way.

It was very helpful to have written assembly language games though, since you end up knowing how it all ends up looking like in memory, and what's really needed to handle user input.  Finding those 'signatures' in other programs gets easier then.

That said, it's far easier now, since with the emulators you can just set a breakpoint on $C000 or $C010 and follow what happens from there.  The current list of secret keys is still maybe ~150 programs (just a guess, haven't tallied it), which I think statistically suggests we haven't found them all yet. My current focus though is on Easter eggs that are original to programs (not added ones in cracks).  There are some pretty neat ones (Jim Nitchal's shape editor hidden in Archon still being my personal favorite I think).

Hope that helps.

]HR