Faery Tale Adventure

Cracking novella protection on The Faery Tale Adventure (c) 1986 MicroIllusions

1.) Introduction
2.) Enumeration
3.) Cracking
4.) Patch the game file on disk
5.) play testing
6.) disclaimer
7.) greets

————————[ Introduction

The Faery Tale Adventure was, to me, one of those great RPGs which was way ahead of its time. In fact it was a big factor which contributed to my finally selling my c64 in the 80’s, in order to purchase an a500. But I digress… the protection was pretty simple to defeat, even without reversing engineering, since it was given in the form of a poem, to which the game expects you to complete by proving the last word for 3 *rhyming* lines. Fail to provide any of these 3 words, and you are dropped to DOS in this copyable, standard AmigaDOS formatted game.

Often, as a kid of 13 years, I could guess the words, which were simple, considering the easy to master rhyme scheme and redundancy of the poem. Nevertheless, I will try to get into the code and demonstrate at least one or more reliable ways to permanently break or bypass this simple protection.

——————————————–[ Enumeration

Naturally the first stage of enumeration is when you attempted to copy the disk (or even load the game) and found (in this case) that it was completely formatted using standard AmigaDOS, and loads from AmigaDOS with no bad tracks, extra tracks or other tricks. After successfully copying this title, you naturally want to boot it up and try to play your backup, but soon become frustrated when you screw up one of the lines and get rudely dumped to DOS:

As soon as you hit return after typing anything but "heed" here, you are dropped to DOS and forced to reboot in order to attempt to play again:

If you type "heed" for this line, you fall through to the next line. Finish 3 lines correctly and the protection screen fades out and this screen fades in shortly followed by the game’s music and start:

So now we have checked out how the protection works and what it looks like when we fail the protection, so it’s time to get our hands dirty.

———————-[ Cracking

load up your original (or Novella protected copy) of The Faery Tale Adventure, wait for the protection screen and enter some word that is not likely to be found in the memory occupied by the game, (something somewhat unique) do not hit return and press the button on your ARIII:

Ok, so this is great news! We’ve typed in "flashtro" and then *without* hitting return, hit the NMI switch on the cart. Next we want to see if perhaps we can determine where (if anywhere) there is some contiguous place in memory that string is being held….I used the "FS" command in Action Replay, which hunts for a string in a range of memory. The good news I mentioned (if you didn’t figure it out from the picture) is the fact that it only found one location. Hey I forgot to have a look at the registers, lets do that:

Yikes! Hope you noticed that. The a0 address register is pointing to our string, which would put a serious damper on what I was about to do, but then since this is a tutorial I guess it would be a good exercise to go through the motions of a "wild goose" chase, something that protections will try to put you through to weed out the lazy. What we’re wanting to try and do next, is find any routines which access the offset in memory where our string is found. On the ARIII we use the "FA" command to do that:

Ok, I took this screen shot right at the beginning of the “FA 293a0” search…it continues to spew spurious hits for quite sometime, and by examining the output, you can easily figure out why. Since a0 is currently equal to our search value, any code which uses a0 (lots of lines) will register a false hit. If you let this search finish the default range of 00000 to 80000 it will take a minute or so to go back to the arIII prompt. But the fix is simple…we change the value of a0 to point to something other than our search string via “R a0 xxxxxxxx” where the x’s are any value you want other than the original a0 value…in my case “293a0”, but your offset may vary. After you do this, Action Replay III automatically displays the registers to verify the changes:

Now try again to find code which accesses your string:

Hey, now this is quite encouraging, only 3 locations found which access our string and they look to be relatively close together in memory. We very well may have found the protection routine(s). We should jot these down on paper for temporary use. In my case:

237b8
237d0
2382e

Don’t forget, your addresses will probably not match exactly what I have here, due to different Amigas, kickstart revisions and other things. Time to start disassembling code around this area to see what we come up with. Ah, and it’s time to restore the a0 register to it’s initial value of 293a0 so:

R a0 293a0

I like to look around the area where I believe the protection might be, just in case I see anything obvious that really stands out. Scrolling down into the vicinity of the subroutine that contains our second string access we find:

See anything interesting here? At the routine starting at 237d0 there is a TST.B followed by a BEQ, and also a CMP.B followed also by a BEQ. In many architectures, whenever you see a comparison (which sets a CPU flag) followed by a conditional branch, you are often looking right at the core of simple protections…but it’s best to try understand what the code is doing, so you don’t miss anything, so lets go ahead and set breakpoints on the addresses where our string is referenced.

After setting the breakpoints, hit ‘x’ to return to the game and type anything. We are wanting to learn a bit more about the routine that kicks in when you fail the protection, and maybe a few other things as well. I decided to look at memory at the places the a0-a3 were pointing at, since the protection code we looked at seemed to be using all three quite often to verify the words we were typing.

Oh shit..what’s this? A2 points to a list of all the words you need to enter in order to pass the protection! Ok kiddies, write these down, throw it in a text file or intro and you are ready to go…or follow me further into the protection scheme and we can try to learn more about how it works, and perhaps a more full proof way to defeat it. So we can guess already that the game protection probably has some sort of table that it uses to index into this short list of strings, after which it could compare a0 (pointing to your entered string) to a2…byte by byte if you noticed from the earlier code examination. So lets find out for sure about that branch I wondered about earlier:

Ok, after a bit of perseverance, it seems like everything is starting to come together nicely.

The address of the user entered string is copied to a0. Then a0 is copied to a3, which we’ve already verified in our register display two pics back. It looks like the first conditional branch is testing to see if there are any more bytes in the legit password by testing for the zero flag via TST.B. If finished we branch to 237f4, which I am guessing will start the game. Any ideas yet? If nonzero we fall through the BEQ and 1 is added to both strings for comparison of the next byte, and also, some register values are shuffled around, which you can easily follow in your monitor with the strategic application of a breakpoint or two. It’s easy to visualize the process of the byte comparison in your monitor:

You get the picture I am sure.

The real heart of the protection seems to happen right at 237e4 ? 237e6. Here we either branch to a routine that does a BRA right back into the loop to keep checking until we’re done, or failing that, we fall through the BEQ at 237e6 to restore the registers, and blow away the stack (by UNLK-ing the stack frame), executing an RTS that returns us to DOS. Could we slap a BRA on that BEQ there at 237e6 (or whatever on your Amiga) to yield a crack of the novella protection? Lets try it:

The opcode for BEQ is 67, and the opcode for BRA is 60. Looks like we may have a one byte crack if this option works:

Ok, so the game seems playable, and you can walk around and fight and everything. But we’ve only been working in memory up to this point, so now it’s time to get out a hex editor and look around on those files on the floppy. Now you could hit this from a lot of different angles, but at this point you should have a hex editor for some platform (such as Hiew for DOS, or Hex Workshop for Windows, Biew for Linux, NewZap for Amiga, etc.). Also, you need to have written down or otherwise saved a string of bytes, on or around the area of code you are endeavoring to patch, enough to keep redundancy at bay to cut down on false positives.

I used: 67 0a 70 00 4c df 0c

…not a whole lot, but it worked, but in general its probably a better idea to save some stuff before and after the area you are patching.

Lets do this.

What’s this? A file on the disk entitled “PassWords”. Well, it’s not a simple text file, but most likely obfuscated using a simple method, if even obfuscated at all, judging by how easy it was to read them all from memory. Just goes to show you that examining the file’s structure and startup-sequence are all part of the enumeration process and really, I should have covered this in that section, but it was a learning experience for me too. I learned a lot more about what the code was doing (and how it was doing it) when I re-cracked the game for this tutorial. I’m not afraid to admit that when I figured out how to bypass this protection a couple years ago, it was primarily through brute force patching BEQ’s until it was fixed.

Ok, it looks like the startup sequence just loads a file called “fmain”, lets take a look in NewZap:

Found our search string of opcodes. Click on the 67 and change to a 60, save, reboot and enjoy! Sometimes the elegant solution is the best.

————————————————————[ Play testing

Ok, that’s up to you, as this was actually one of the biggest RPG’s of its day, and there is actually tons to exploring and do, and there are certain crucial objects that disallow completion of the game if you don’t find them (frustrating). Even with a walkthrough it would take a while to beat, or so I hear. It does however, judging by the NewZap output seem like it would be pretty easy to train…

———–[ Disclaimer

This tutorial was written more for my own learning benefit than anything else. As you can tell I am starting from scratch with Amiga cracking and my knowledge of 680×0 is not very advanced at the moment. I am sure any glaring errors will be met with a firm slapping from those of you who posses great experience, and I will welcome the enlightenment. I hope someone gets something out of this, and maybe at least learns an Action Replay command. Hopefully my next tutorial will be more advanced and possibly have something original to contribute, yet cracking even simple novella checking routines does a lot for the excitement factor and makes me want to learn more.

—————————————————[ Greets

Greets go out to everyone who has given inspiration, encouragement, and help (but not spoon feeding): Wayne Kerr, PMC, M9, Stingray, Photon, all the coders on EAB, everyone on Flashtro.com, Bitfellas, anyone important I forgot.

– plagueis

Publication author

offline 14 years

plagueis

0

Comments: 476Publics: 2Registration: 11-07-2010