Mac protection

So, I spent some time studying the facilities built into OSX that would be used by loaders, decryptors, and the like as the basis of copy protection.  If you are used to protections on the PC under windows, then the Mac appears to be a dream come true for protection tourists.

I decided to try to implement a simple protection of the sort I detailed in a previous post.  It would be architected as follows:

A simple loader application would load a 2nd application in a suspended state, locate it's initial entry point, and remove the INT 3 ($CC) instruction that I had put there.  Once this was done, it would launch the app, and allow it to run.  (Which would simply print "Hello World", and exit).  An adequate proof of concept I thought.   Since OSX is BSD based, I could just use the POSIX stuff, right?  Start an app, use the apple extension to start it suspended, and then just go read/write the spawned applications memory.

That's where the problems started.  Evidently, there has been LOTS of activity on OSX with regards to trojans, rootkits, and the like.  These have forced Apple to lock up lots of avenues into the kernel, and they've sealed off lots of tools that you would need to do good things.  So, this means that most of the casual gaming protections I've seen on the Mac are shameful.  As I mention elsewhere on this blog, the preferred method appears to be this:  Make the loader, and license enforcer, 1 application, and it's the app that gets executed when you use the launcher.  The game's main executable is renamed, and/or hidden.  (Such tactics as its name starting with a ".", so that it's not shown when you ls the files in the bundle.  If it's not THAT technique, then it's "rename the executable to look like a data file".  Anyway, where this leads is that you 1st run the loader, and it verifies your license, and then it execs the game.  No in memory patching, NOTHING.  It just simply launches the game.  So, to crack these games, you just delete the loader, and rename the game to match what the loader used to be called.

I'll definitely be keeping my eye on Mac protections from now on, as this is somewhat fascinating to me!  Stop trojans, and malware, and also stop most protection methods.

Learn a real language!

OK, just looked at an app for a friend.  It's a tool that helps fix corrupted video files.  A quick glance through the files included in the archive shows that it uses MOSTLY open source utils to do the heavy lifting, while it is simply a GUI that checks the licenses, and pulls the strings.  The protection on this application was a simple serial number, and without a valid number, it would only do 50% of the file.  The main executable was pretty straightforward.  Matter of fact, a little TOO straightforward.  Ease of understanding is your enemy if you're facing me.  So, watching the code, I see that they open a file with an extension of .elua.  First, I thought my eyes were playing tricks on me, and it was just the EULA (End User License Agreement), which is normally a text file telling you the rights you give up by choosing to use the program.  Not in this case, this was actually a .elua file.  So, I see them open the file, get the file size, malloc a buffer for it, and then read it in.  Then, there is a STUPID decrypt loop.  I kid you not, the C code for it probably looked like this:

for(x = 0; x < fileSize; x++)
{
buffer[x] ^= 0x4F;
buffer[x] -= 0x16;
}

it was simply an xor with 4F, and a subtract 16h.  I guess it keeps the prying eyes out, but that's about all.  They had written the code to DO this feat of software engineering in C, so they could have just as easily have used one of the REAL encryption functions from openssl or something.  Anyway, it gets worse.  What this file is, is the code for the GUI, in LUA!  Yes, I know some video games do some things in LUA, but if you can write the C code to decrypt your file, and call the LUA interpreter to handle it, you should be able to spend the 20 minutes it would take to learn how to do the rest of the GUI in C++ under MFC.  It's not the most involved GUI in the world.  It's really rather simple.  Since this company is still in business I can't point you to the program, or their site, but trust me.  The main app has about 6 buttons on it, and none of them does anything involved.  So, back to the story.  We now know what's going on, so I whip up a quick application to read their file, and spit out an unencrypted version of it for my perusal.  And it has the string table, and fun things like that.  A function that gets info about your machine for pseudo-finger printing so that they can *in theory* lock the application to your computer.  Function to check to see if you have a license file, to read it in.  To check that your serial number in the license file is valid, etc.  All the things that you would expect.  So, I look at their code to handle the license file.  Here are the steps:

open file
read in file, up to 100 bytes!

grab the 1st 4 bytes.  (Yes, only 4).

Build a string from the last 4 digits of your fingerprint code.  (9 - digit 3) (9 - digit 1) (9 - digit 4) (9 - digit 2)

Compare this generated code to the code that you entered. Oh also compare it to the fixed value 4475.

If either of these matches, LICENSE IS GOOD!  FULL VERSION!

*FACEPALM*  They had a reasonable idea going along, and then 4 digits?  Seriously?  Backdoor code left in by the developer?  WHY?  And in LUA, where any jackleg can come along, decrypt the file, and see your original source.  Just pathetic!

****UPDATE****

I did a little more digging, and the situation gets a little MORE pathetic.  I thought about this, and considered "Maybe they know nothing about C, and this was their only way to make a product!  They found some code online that let them embedded a LUA VM, and launch their code, and the load/decrypt was all that they could muster."  In which case, I can kinda understand their suckage.  Not so kemosabe.  As they like to say in the NFL, "Upon further review".  I spent a few minutes digging into the application that launches their script.  It's not JUST a launcher!  It contains a library of functions in a custom namespace that they call from inside their LUA script.  What really triggered this, is I was curious to find out how their "Machine ID" function worked.  So, they have the chops to develop an entire library of utility functions in C, on windows AND Mac!  Yet they can't be bothered to develop a GUI in something other than LUA.  And, as I typed that last sentence, it hit me.  This is the worlds lamest cross-platform application.  Develop the GUI once in LUA, write stock C code, compile it on windows, and mac, and ship it.  OK, well, moving on.  So where DOES this vaunted Machine ID come from?  Why from here:  "SELECT ReleaseDate FROM Win32_BIOS"  I should check the Mac version, since this facility isn't available on the Mac.  Stay tuned.  This could be epic!

Casual Gaming Protections

Over the years, I've been fortunate to see lots of protections on so called "Casual Gaming" games. These are the games like Bejeweled, and that ilk. Generally, these games are written by a company, and provided to several online "publishers", who distribute them. Reflexive.com, Yahoo Games, people like that.

 Well, the games are provided in their original unprotected "ready to run" form, and the individual publishers add their own protection to them to enforce their "60 minute free trial" restrictions. The quality of this publisher applied protection varies wildly. I will touch on some of the ones that I have seen in this posting.

  Generally speaking, there are 2 types of protections in use. The first one is where the publisher uses some "off the shelf" protection to either manage the entirety of the trial, or at least in an attempt to thwart circumvention of their trial system. These are things like the Armadillo protection system from Silicon Realms, and systems of that type. Generally, these are more successful than if the publisher had written the whole thing from scratch, as more than likely, the game author isn't going to be an authority on copy protection, and that job should be left to the professionals (As you'll see in the OTHER category a little later). The problem with these "solutions" is that MANY MANY tools exist online for removing, stripping, or at least circumventing them. As mentioned elsewhere on this blog, that is one of the perils of off the shelf protection.

  This class also includes more of a hybrid system, where the company develops a protection on their own, and uses the packer/protector over the top to at least act as a speed bump (sleeping policeman if you will) to the would be hackers. But these suffer the same fate as the full blown systems mentioned previously. These packers run the gamut from the fully commercial ASProtect, down to the lowly open source UPX. And, ultimately, if you are counting on a packer to protect you, you truly have no protection at all.

  The other type, is the entirely self written protection system. These are the ones that I'll be spending the most time talking about in this post, as to me, they're the most hilarious. I'm not trying to pan ALL of them, as I've seen some that weren't bad! I saw one that did 2 asm instructions, and a jmp, over and over and over. Very reminiscent of the old floppy based protection called SuperLock. (I have a copy of that around here somewhere). It also goes through a couple of layers of decryption, and unpacking, and runs code from inside itself, so it plugs the obvious "memory dump" holes. Honestly, I forget who had this protection, but it was pretty good. Now, with that one out of the way, we can move on to the others.

  There are a couple of publishers who share the idea that renaming the .exe to something else, and setting the "hidden" attribute on the file is enough to stop piracy. I kid you not! When you install the game, they install everything, and create a shortcut on the desktop. This shortcut leads to their monolithic loader that keeps track of your time playing, and how much time you have left, etc. It also has intrinsic ads, and serves as your gateway to download more of their games. It also features code that loads, and runs the game from it's super secret location. (The root of the game install directory). The solution to this protection is ALMOST as bad as Popeye mentioned in previous posts, and just barely better than Superman also mentioned elsewhere. So, the method to "crack" these games, is to rename the .exe back to .exe, and update the shortcut's target. TA DA! (Shaking head).

  We've now covered the good, and the bad, which brings us to the most popular technique. This one utilizes a technique where the code at the initial entry point is removed/encrypted/scrambled in the game, and the loader/time tracker replaces it at runtime. It creates the task suspended, and then through WriteProcessMemory they replace the garbage at the OEP with the correct (original) code, and then perform a ResumeThread to launch the game. This was a pretty cool idea back in 2004 when I first saw it, but this is 2012, and it seems to be becoming MORE popular, not less. I've found derivatives of this idea in *3* different companies protection schemes. And NO, packing you loader with ASProtect doesn't help. It also doesn't help if your ASProtected loader loads an ASProtected .dll to do all the work. It all results in the same thing. An API hook eats your lunch, and allows someone to dump out the data, or in some cases, (like mine), I copy your "altered" game to a new name, and replace the correct bytes "on the fly" as the loader runs.

  The only thing worse than these windows protections, are their Mac counterparts. Say you have a game called "Fool's Errand". You have a bundle that holds all the files, and it contains the loader, named "Fool's Errand", and all the support files. Among these is a copy of the REAL executable, UNTOUCHED. Just renamed to something that's supposed to blend in with the other files. The downfall of all of these is when you launch the game, and from a terminal do a simple "ps x", and see 2 things running. 1 the loader "Fool's Errand", and something else, from the same bundle, called "data". Once you see that, you exit the game, delete the loader, rename data to Fool's Errand, and play forever. Just simply pathetic!

I saw a well designed protection!

I know that normally in this space I rant about how bad this protection was, or how pathetic THAT protection was. But this post will be different. I recently had the opportunity to see an amazingly well designed protection system. Strangest of all, it was a homegrown protection written by what looks like a small developer. No, I don't know the name of the protection, and I won't tell you what packages it was on, but I'll tell you ABOUT it. The packages are both from the same source, a presumably small independent developer who produced a package to aid in the generation, and distribution of test taking tutors. Say you want to get you Linux+ certification, you can go to the web, and buy their package, and it'll help you study for the test. The target installs, and presents you with a single .exe. A quick scan tells you that it's an encapsulated Java application, with an executable launcher. A quick search, and you can pull out the whole jar file that is the program, and a quick unzip later, and you have all the .class files. Run them through decompiler of your choice, and you'll soon see that they've been obfuscated. While the obfuscated code is difficult to follow, the error messages that the application prints leads you to the right place in record time. You can see that a particular function gets called, and it's return value means the code you entered is bad, or that you're running in demo mode, or that your trial has expired. So, now a quick note. I've never learned Java. C/C++, yes, Java? No. So, that means that I have to consult the web for parameters to APIs, or what a particular API itself does. So, I see the application getting a resource, and using it in what looks like a way that would tell me EVERYTHING. So, I google the string. And what I find, is absolutely shocking. I find the COMPLETE source to the package. ALL OF IT. For whatever reason, the developer at this company kept his Eclipse workspace on the web server machine. A quick "wget", and I had the complete source, with comments, and even notes to their customers describing how their protection works. Game over, right? NO. And here's why. The protection is well designed. When you hit their website, if you opt for the demo, you get that. A demo package, with only 10 questions. (Out of who knows HOW many for the regular package). If you don't BUY a test, you can't get the executable, and all the questions. That's good idea number 1. If a pirate can't TOUCH your app., he can't crack/pirate it. Number 2. Once you get the package, you also get a serial number. When you run the app., the first thing you are presented with, is a registration box asking for that serial number that you were given. It takes this, and grabs some stats like your MB serial number, your MAC address, etc., and interlaces all this data into a packet that it sends to their registration server. The registration server returns the time period that your application is authorized for, and, (Drumroll please), the AES key to decrypt the questions database. This data is all interlaced together, and BASE64'd for the trip. The client application pulls the packet apart, save the dates, and the key for the questions, and boom. Off you go. Now, as a pirate, I'm all about weaknesses in the system. YES, you could prolong the license period forever. YES, you could buy all the tests once, and pull the private key out, and release them at once. (That would probably be kinda obvious though). As part of the glob that I downloaded, there were all the tools to be used by the customers to enter test questions into the questions database, and, the private keys for a bunch that already exist. So, in THEORY, if you could get all the applications, you could release them all without having to BUY them. But, this takes us back to problem #1. You don't get the application if you don't BUY it first. So, on a tour de force level, this protection scheme is relatively low tech, but it is above all, EFFECTIVE. So, good job who ever you are that wrote it!

Sometimes I think you should have to have a license to write protection.

Tonight's application was a database monitoring application written mostly in unobfuscated java. Is this 1999 and no one told me? I mean SERIOUSLY. And the thing that made it all that much better was that this code runs under Tomcat, and while running something called Jasper, it spit out .java versions of some of the important files. I didn't even have to decompile them! (shaking head). OK, so here's how it all works. You get a license key from the vendor when you register your trial, or buy a license from them. It comes in the form of a string of characters that you copy & paste into a form in the program. (It's all web based evidently). This license key contains a server name if you buy a license, or a string that they identify later as the "trial sentinel", and a number. This number is the time since the epoch in milliseconds for when your trial, or license expires. At runtime, in just about every module, they load this string from the key file, decrypt it, and pull the 2 halves out. (There is a delineation character between the fields). Then, they simply compare the time to now, if it comes back negative, your license has expired, and you need to get a new one.

So, as you see, the lynch pin of this WHOLE protection boils down to a simple string decryption routine. It was written in java as well, and unobfuscated for your reversing pleasure. A little while examining it, and I was able to write my very own ENcrypter, so that I can now make license files till the cows come home. Here's the pertinent code:


void EncryptString(char *s)
{
char temp[1026];
char output[2049];
unsigned char x, y;
unsigned char len = (strlen(s) & 0xFF);

memset(temp, 0x00, 1026);
memset(output, 0x00, 2049);

temp[0] = len ^ 0x95;
temp[1] = s[0] ^ 0x95;
temp[2] = s[1] ^ 0x59;

for(x = 3; x <= len; x++)
{
temp[x] = s[x - 1] ^ temp[x - 3];
}

for(x = 0, y = 0; x <= len; x++)
{
output[y++] = ((temp[x] & 0xF0) >> 4) | 0x40;
output[y++] = (temp[x] & 0x0F) | 0x40;
}

printf("[%s]\n", output);
}

The 1st byte of the license is the LENGTH xor'd with 0x95, followed by the serverID, followed by the expiration time. They do a pseudo rolling encryption where the value of THIS byte is xor'd with the value of another byte in the string, (3 bytes away). Once they have this, they simply walk through the string, pull out the upper nibble, shift it right, and OR it with 0x40, as that makes it printable, and then pull the lower nibble, and OR it with 0x40. Then, save those bytes, and move along. So, the resulting string ends up being twice as long as the actual payload.

I can only hope that these guys kick ass on database applications, and that it works better than their attempt at protection. Maybe they're finally wising up, and are only trying to "keep the honest people honest", as that's about all this scheme would do.

Linux "Driverless dongles"

Recently, I've had the pleasure to examine the libraries, and implementation code associated with the new generation of "driverless dongles" under Linux. I've examined two different products from different companies, both with the same "feature" on their keys. This feature is the ability to plug it into the box, and not have it require a driver be loaded for your application to work. To facilitate this feat, they simple assign their dongle to the HID (Human Interface Device) class in their USB descriptors, and when it's plugged in, Linux enumerates it, adds it to the tree, and that's that. Then, when the time comes to talk to it from a protected application, you use a library provided by the publisher. It has mostly been this library that has allowed me to gain a full understanding of a key that I've never touched, and another that I have. It seems that both companies, NOT related, and THOUSANDS of miles apart, had the same idea. "Let's use libusb inside our library, so that the code will be simple!". Well, that it is. A little TOO simple. After finding the library online, and tossing it into IDA Pro, I was able to determine that it was libusb, determine the version, and then see how they used it. Now, for your protection to be simple enough that a guy like me can spend about 30 minutes with it, and have a complete grasp of it, is kinda sad.

The pitfalls that I saw included the following:

* Forgetting(?) to strip the symbols from the library before shipping. This allows IDA to label all the functions and makes the whole process MUCH simpler to understand.

* Publishing the entire API spec, and library to the net, so that ANYONE can get a copy of it. I understand that it's a delicate issue of "We want developers to be able to look at how easy it all it". But, you're also giving away the keys to the store at the same time. As this also allowed someone to see where this library is integrated into a customer's program, and have a COMPLETE understanding of the names of the functions, as well as what they do.

* Using libusb. I understand that you want the library to be as simple, yet robust as possible, and that using an available, and THOROUGHLY tested lib makes that process much easier, but it also makes the reverse engineering process much easier as well.

I heard you saying "Those are all interesting things, but what do these holes allow me to do?". Well, here's what I was able to do. I developed a driver that registered itself with the USB stack as a dongle. Then, when the applications enumerated the devices, they found ME, assumed I was a key, and began talking to me. A VERY little debugging of the target application, and I was able to return the "right" answers to the applications challenges.

Once I acquired my own key of the 2nd type, I was able to write a VERY SMALL driver (400 lines of C code!), that was able to intercept all communications with the dongle, and "change" the data that my dongle was returning that wouldn't match what the application was expecting. (Login passwords that the dongle requires, GUIDs, etc.) So, now, the target application runs with a key that isn't the right one. It even reads the memory from the key, and everything else that it's supposed to do, and has no idea that I'm there.

I could write a BOOK on how bad the code was in the target application, but even had that NOT been the case, this still would have been an easy crack job.

If you are just starting Linux reverse engineering, and are faced with a dongle, I *HIGHLY* recommend that you look into an option called "usbfs_snoop". You can find it under the /proc tree. This will show you what types of IOCTLs are being sent to the key. Pair that up with strace, and you have a potent 1-2 punch.

Great moments in protection failure!

It seems that more and more these days I find protection to talk about here only because of the epic badness of it. I'm sure there's some good out there, but I haven't seen any of it lately. Anyway, on with today's installment of "Great moments in protection failure!"

Looking through an anonymous application that does a whole boat load of decryption of data from a source. The main application was compiled, and released with the symbols still in it, so IDA gives me not only function names, but function prototypes, and in a few places, variable names. You know, this could be a simple mistake, and crap happens, so I'll cut them some slack on this, as this isn't even the failure in question.

While digging through the application and analyzing the encryption bits (the only things really interesting in there to be honest), I find that the guts of the encryption routines have been pseudo-obfuscated. I'm assuming that this code is from a library that probably came this way from the original manufacturer. By the looks of it, it's some tool that they run after they compile the library, and it changes all the non-exported function names in the library to a long string of hex characters. For example, they might have a function named "000b00f05c86d185". So, when you're looking at the disassembly, you see:

call _00b00f05c86d185

This is fine, and a good idea if you're trying to hide what your functions do, but now to the facepalm moment.

In this code, they call the obfuscated functions, and if they return an error value, they print a nice debug string that contains all the details about the error. Including the original name of the function!

So, all their attempted obfuscation is undermined by their proficient use of error messages.

Let's use our example function from above. You'd see something like this (in C pseudo-code).

if(00b00f05c86d185() != 1)
{
printf("GetKeyValue() returned error\n");
return 1;
}

Gee. I wonder what the REAL name of "00b00f05c86d185" is?