Fab tackles a Mac program.

While not technically my FIRST Mac app, this was an interesting diversion if nothing else. The first app was a Mac port of a protection system that I had conquered on the windows side YEARS before, and I knew it intimately. SO that didn't really count. Some of my friends used this app at the office, but would like to have a copy at home so as to become more proficient with it. So, out of sheer boredom, I decided to have a look at it. What I found excited me. If ALL Mac apps are this easy, I might have to start taking requests!

First a few notes about Mac apps in general. Most of the more modern apps are compiled for both x86 and PPC chips, and the resultant output files are stuffed into a single file together for distribution. So, I did both versions. Now, not being a PPC hacker, that took a few minutes, but the mistakes that they made in the x86 version were also present in the PPC version, so it was a lot easier than it should have been.

In this particular case, (and I hope all others!), the way that the Mac compiler generates executables, and probably the whole underlying architecture of OSX makes reversing MUCH simpler. It's almost like there's an API for everything! To wit, this code looks odd enough, nothing really to see here, right?

__text:000DB4CB mov eax, ds:off_1D2514

__text:000DB4D0 mov [esp], eax

__text:000DB4D3 call _objc_msgSend

If you checkout off_1D2514, you discover that it's a pointer to NSConditionLock. So, spend a few minutes labeling all these "pointers to message names", and the disassembly starts to look VERY different!

Of course, if the particular program that you're working on uses a license file protection technique, and offers a demo version, then it could be even easier. It could have a function like this:

char __cdecl _XXApplication_isDemo_()

{

return *pTrialByte == 3;

}

Variable name was supplied by me, function name was left in the executable by them. Don't get me wrong, I certainly APPRECIATE it! ;-)

So with this function telling me not only what variable in memory was responsible for determining the trial/registered status of the app, but also what the value was that was interpreted as being a trial, it allowed me to make a simple fix. Just locate all the places in memory where this memory location was set. I.E.

__text:000E0453 mov ds:TrialByte, 3

A little more tracing showed me that a value of "1" in TrialByte meant that the app was registered, and happy. So a simple search revealed 3 places where a value other than "1" was being placed in this location. A simple change of "2" to "1", and a couple of "3" to "1" changes, and we were done.

I heard that! You said "What about the PPC version?". Well, I found much the same code there:

__text:0000B470 __XXApplication_isDemo_:

__text:0000B470 lis %rtoc, ((pTrialByte+0x10000)@h)

__text:0000B474 lwz %rtoc, pTrialByte@l(%rtoc)

__text:0000B478 lwz %r3, 0(%rtoc)

__text:0000B47C xori %r3, %r3, 3

__text:0000B480 subfic %r0, %r3, 0

__text:0000B484 adde %r3, %r0, %r3

__text:0000B488 blr

__text:0000B488 # End of function __XXApplication_isDemo_

This is our handy function for locating the variable, and what do you know? A quick search shows that there are 3 places that need to be patched to make it work. The same as the x86 version.

25th Anniversary of cracking/Reversing

This very night, 25 years ago, I became "Fabulous Furlough".

I was hacking on a C-64 game in my best friend's basement at 2425 Vale Lane in Nashville on that faithful night. I don't recall where we GOT this game, but I do remember that it had several "Error 23" checks on the disk, and I fixed the first bunch, and we tried to load it, and it failed. So, I had to go search for another one. Found it, and the crack was done, then came the "putting my name on the loading screen" part. I found this nice line near the top of the loading screen, and counted the characters that were available there. 27. Prior to this game, I had just been "Chris from The Dream Team". (No, not THAT dream team, the name came from the fact that my friend was a good hardware hacker, and when you put us together, we were in essence, a "dream team".)

So, I needed a new name. I worked out that "Broken by" was 9 characters, and needed something to call myself. I have no idea where the inspiration for Fabulous Furlough came from. It just popped into my head, I counted up the characters, and it fit. I laughed, and loaded up the sector editor, and did it.

Then loaded the game to make sure it still worked, it did, and from that point on, I was Fabulous Furlough.

And here we are, 25 years later.

Special thanks to the late Mike Jackson (MTJ!). Without you, I would never have learned this great skill. May you rest in peace buddy, I'll always miss you.

-FF

What good does that do me?

This is kind of a follow up for the next story down. So, I wrote the tool to grab the unprotected game executable, and make a new package with it. It worked, I was happy! I sent it to my friend with the Mac, and he reports back that it won't run. After a few iterations via e-mail, he tells me that he has an older PPC MacBook. I wrote this code on an Intel based Hackintosh. (Dell D610 that runs MacOS 10.5). So, my options were to recompile it for PPC, make a FAT executable that houses BOTH executable formats, or something else. I of course opted for option C. In this case, that turned out to be "Write the fixer app in PERL". PERL has been my hobby language for a LONG time, so I figured I'd give it a shot, and see what I could do. Basically, I took the C code functions, and rewrote each of them in PERL, and then just called them in the correct order. Works like a charm! I think this is my first "cross-platform" crack.

That's not my platform!

Recently I've been stalking this company that distributes games written by 3rd parties. I won't mention their name because I'm having too much fun with them! ;-)

So here's how it all began. My wife plays a lot of PC based puzzle games. Some people work crossword puzzles, some others crack software, she plays puzzle games. So, back in 2005 she found a game that she liked called Mystery case files huntsville. She downloaded it, and asked me to extend her trial time. So, I went looking for a crack. (Why reinvent the wheel if it's already been done?) And I found one. So, I tried it, and it didn't work. Well, that pissed me off, and I decided to have a look at it. I ran it through IDA (my disassembler of choice), and began looking at the code. It was pretty straightforward, they loaded the game into memory without executing it, read a chunk out, decrypted it, wrote it back, and the executed the game. I then looked a little further, and found where they checked to see if you had purchased the game. I kid you not, the function was called "HasProductBeenPurchased", and returned TRUE or FALSE. Basically YES or NO. This was in a .DLL, so I made the simple change to make it always return TRUE (yes). Ran the game, nothing. Exited. I dug through their loader a little more, and found that they were doing an MD5 over the DLL to keep people like me from doing what I was trying to do. The only problem is, the loader itself didn't have any such protection, so I just made it jump like it had received a TRUE retun value, and she was playing along happily, but I was now intrigued! SURELY this was just a single instance of bad protection! I went back to their site, and saw that they had about 100 games available for download. I grabbed a couple, installed them, and looked at the loaders. The loaders were almost all the same! It turns out that this weak protection was on ALMOST ALL of their games. The only exceptions were what was probably the FIRST games they released, and they didn't have the loader system perfected yet, so they just had the game authors call "HasProductBeenPurchased" from inside the game's executable, and then they packed it with a packer called ASProtect. I decided that I was going to write a tool to let my wife register her own games when she wanted to. So, I wrote a loader that allowed me to get around the ASProtect games, and a patcher that allowed me to patch the OTHER games, and a stripper that removed their protection completely.

Seems like this would be a good time to explain the process that they use. When an author gives them a game to distribute, they take the executable and run their packager on it. It reads a chunk of the games executable code out, encrypts it, writes it back, and then renames the executable from .exe to .rwg. (I bet it's the authors initials!). They then throw a loader on that does stuff like allow you to purchase the game, it monitors how long you've played, and doesn't allow you to play after your "trial time" has expired. (It will kill the game, and return you to it when your time is up!). They then pack the whole thing up with an installer, and put it on their website. This protection method means that when you press the "play game" button in their loader, that they have to decrypt that chunk of data in memory, and then launch the game from there. What my loader did was, search for, and replace some strategic bytes in their loader with "$CC" bytes (INT 3) bytes which transferred control back to MY program, and I would read the decrypted data out, and make a patch for the game. It was very "old school" if you will, what with all the searching for bytes, and whatnot. They accomplished this reading and writing of memory via a couple of windows functions called ReadProcessMemory, and WriteProcessMemory. They do just what you would think they would. They allow one process to read/write in another processes memory space.

Well, I decided to update my tool, and bring it to the jet age. I used a technique called "IAT Hooking". What this is, is when their loader loads, they load the windows DLLs that house the Read/Write ProcessMemory functions. When they do this, I intercept them, and instead of them getting the addresses of the windows functions, they get the addresses of my "replacement functions". In these functions, I do things like copy the encrypted executable to a new name, find the location where the encrypted code is in that file, and write the unencrypted code out to that location when they get through unencrypting it. And, the best part, It works on every game they have released since 2005! I bet that's close to, if not over 1000 games!

I was very happy with this tool, and figured that I had exploited them as much as I possibly could. I was wrong. Recently I noticed that their site had added a Macintosh section. And, with Macs being Intel based these days, I figured I'd have a look at their loader on that platform, and see if they were doing the same thing. They are, sorta. Only with 50% more braindead free!

The packaging step is the same, read a chunk of the executable out, encrypt it, and write it back. But the loading/running of the game is different, and COMPLETELY STUPID. Instead of loading the game into memory, and making those changes I mentioned above, they actually make a copy of the encrypted executable, read the encrypted data from it, decrypt it, write it back, and then execute it. So, when the game is running, there is a completely UNPROTECTED copy of the executable on your HDD just WAITING for you to make a copy! They rename it slightly, by adding a "." to the front, but very little good THAT does! So, I'm going to write a tool that will find, and copy the unprotected executable to a safe location, and then when the game exits, I'll delete the encrypted version, AND the loader, and put the good version of the game in it's place. Reducing the size of the bundle on your HDD, and letting you play the game forever.

(shaking head)

Idiots.

Some more things that occured to me.  While working for a gaming company, I was asked to have a look at an FPGA design program from Xilinx.  We owned it and all, but they wanted to not have to use the dongle.  I didn't care the reason.  Anyway, when you ran the program, it checked to see that the dongle was there, and if it wasn't it just exited.  If it WAS there, it ran.  And never checked it again unless you stopped the program and started it over.  Really, what was the reason for this?  It was almost like the protection was an afterthought, or demanded by management.

I also did an app called SNMPc.  It had the typical run of the mill Sentinel Pro dongle.  Back in the "old days" the way the dongle worked was this:  You sent it a string (usually a short one), and it sent you back a 16-bit number.  So, SNMPc sent a bunch of strings that were lyrics from Pink Floyd's "Shine on you crazy diamond".  It looked like they used a library for calling the dongle functions, as all the code looked the same.  The way the dongle code existed, was in a .DLL.  Which makes sense, you can distribute it with any app, and not have to change it if you are the Rainbow (The dongle) people.  The problem with that, is that once you have cracked it, you know where everything is inside it, and the next crack is trivial to do.  The way that I did this one, was to look for the places that called the dongle check routine.  (The bytes were the same, so a simple hex search turned them all up).  Then, I looked at what the string was that they were sending to the dongle, and at the compare right after the call to see what they expected to get back, and made a table.  Then, I went into the .DLL, and gutted the dongle check function.  I replaced it with a look-up function that I wrote that compared the sent string to the strings in my table, when it found a match, it returned the corresponding 16-bit value.  DONE!

Sometime, when Google feels like it, if you search for my name "Fabulous Furlough", you'll find a text file "interview" written by some idiot from 1993 or so.  In this file, the interviewer is asking some guy with Razor about the best crackers on the PC.  (in that era).  He says that he wouldn't put me in the top 10 because I never did an interpreter, and I never cracked dongles.  I'd like to take a little space to clear both of these misconceptions up.

Ultima 6 was an interpreter, and I cracked it without help.  (It took 8 hours, but I did it).  I have also cracked VB apps, which are interpreted, and Deadbolt 64 (mentioned elsewhere on this blog).  (And probably a bunch of other stuff that currently slips my mind).  Now, on to the issue with dongles.  During the timeframe in question, what this idiot didn't know was that I was the "secret cracker" for a group called NTA.  (Nocturnal Trading Alliance) out of Phoenix.  Mikeysoft was the head.  They didn't have a cracker, and since THG wasn't interested in doing business apps officially*, we left them to Mikey.  So, during the timeframe that he speaks of, I cracked NUMEROUS copies of 3D Studio, and a bunch of other business apps that were dongled.  So, the Razor guy was a know-nothing idiot who was just shooting his mouth off.  

UPDATE:  TODAY Goggle felt like giving me the link to the idiot's post.  So, here you go:

http://web.textfiles.com/ezines/NAKEDTRUTH/ntm-05.txt

*The reason we weren't interested in business apps was this:  We assumed that if a company lost sales of 1000 copies of a game at $30 each, it wasn't worth the time and hassle to come and find us.  But, on the other hand, if a company lost sales of 1000 copies of a $10,000 program, THEN you have a reason to hunt people down.  (I once downloaded a financial analysis app worth $750K.  No shit.)  Wasn't protected, and came on one (1)  720K floppy.  I have NO idea what it did, but it better have shit gold bars, and farted rainbows for that kind of money.

Some quick hits.

I also cracked games on the Amiga. It being 68000 based, it was a whole new game for me. (Pardon the pun there).

I cracked a bunch of things, but the first was "Empire: War game of the century", and that was only fitting, as it was also the first PC game that I ever cracked. (Using Microsoft's CodeView, and Norton Utilities of all things). But the one game that I really remember was a game called Foundation's Waste. I couldn't tell you what kind of game it was, what the object of the game was or anything, but here is the stuff that I CAN tell you. It had a nasty protection that none of the copiers would copy. I tried everything in my arsenal, and couldn't get a working copy. Best of all, when your copy didn't work, it played Vincent Price's laugh from Michael Jackson's Thriller. I laughed really hard the first time it did it. This was also one of those games that was all based off of sector locations on the disk. There was no real directory, and you just booted the disk to get the game to run. So, I had a tool that would read a sector, and disassemble it. So, I started with the boot sector, went to the next sector that it chained to, and a couple of sectors later, I found the protection check, and the call to the digitzed laughter. I couldn't resist. My crack of the game came up, and played the laugh, and THEN loaded the game and let you play it. I thought it was the ultimate F*CK YOU to the authors who thought they were being cute.

On the PC, another beauty of copy protection was a "port" of Nintendo's Popeye from the arcades. The protection was in a .com file that the included batch file ran. It checked the disk, and if the protection passed, it ran the NORMAL .exe there. Crack? Delete the .com file, and rename the .exe. DONE! A crack without modifying any code.

There was also this game called Mean Streets by Access Software. When you ran it, it checked the key disk in text mode, and if it passed, it THEN switched to graphics mode. It was VERY easy to crack, as you could use debug, codeview, turbo debugger, almost anything, as they didn't change the video mode, which was what stopped you from using most of those tools.

Speaking of Z-80, The Verifone Tranz 380x2

I worked for a company that used a TON of VeriFone credit card terminals. We used the Zon Jr., the Tranz 330, and eventually the Tranz 380x2.

Before I detail the cracking, let me describe the operation of the terminals. The terminals ran a custom language called TCL (Terminal Control Language). It has NOTHING to do with the Linux hosted language of the same name. The memory in the terminals was laid out with an address from 0-999. When you wrote code, you used specific memory locations. For instance, when you press the "1" key, the code in memory location 107 gets kicked off. We nicknamed the code "License Plate Language" for reasons that you'll soon see.

Let's say that you wanted to write some code to get a 5 digit number from the keypad, and store it in memory location 150. The code would look like this:

B5.5
G
P112
K1.5
U150
*K

Now, this code would select a buffer to use (buffer 5), clear it, display what's in memory location 112 (presumably a prompt that said "Enter 5 digits" or some such), then, accept 5 numeric characters from the keypad, store it in 150, and return to idle.

Now, on with the story. We used thousands of these terminals, so our VeriFone salesman was ALWAYS bringing us new stuff. He brought us a new Tranz 380. Nice terminal, it had lots of memory, but it was of the "batch storage" type, not the code storage type, so it was of virtually no use to us. Then, someone at VeriFone got smart, and decided to modify the firmware to take that big glob of memory, and split it. Thus making *2* distinct code banks, and making the terminal act like 2 terminals! (You could load a COMPLETE firmware image on both sides of the unit, and toggle back and forth). For us, this meant that we could do a TON more work on the terminals than previously. But, in the process of writing this new code, they also put in a small form of copy protection. We found this out as the salesman is in the conference room talking to the muckity mucks about this terminal, which was delivered to me. While he was talking to them about the terminal, my friend Mike (now my Co-Worker Mike), and I had opened the unit up (4 phillips head screws), removed the EPROM, and copied it. Put the unit back together, and had it waiting when they came to take it back.

When the firmware in this unit booted, it checked a memory location in the battery backed RAM area, and if a bit was set in it, it continued to boot like normal. BUT, if that bit was CLEAR, it would calculate a "Lock code", and ask you to enter the "Unlock code". When I threw our copied EPROM into my 380, and saw this, I was both shocked, AND delighted! :-)

The terminals ran a Z-80 variant, it MIGHT have been a Z-180. Anyway, so, I whipped out the disassembler, and ran it through the code. This new Lock/Unlock code was at the VERY END of the ROM. (As you could imagine new code was just tacked into the first free space, at the end of the existing code). I studied it, saw the checking of the bit in the memory location, so my quick fix was to made a "Load Chip" (which I had modified the Lock/Unlock code to WRITE that bit into memory), and the normal "Run Chip", which was the normal code which would now find it's bit set, and run like normal. This was a solution to get us going, but not one that really made me happy. So, I released this hack to shipping, who played with it for a while, while I worked on a better solution. I studied their algorithm, and as you'd expect from someone used to writing code to do communications over the modem, and parsing of packets, the protection was VERY simple. As it turns out, I took their verification routine, and re-ordered the instructions so that now, it asked for the LOCK code, and gave you back the unlock code.

I had made a VeriFone Tranz 380x2 Keygen, using their code, and running on THEIR hardware. I thought it was funny, and I had a good time doing it.