Embedded Linux based internet appliance keygen - Follow up!

The publisher of the software package that I mentioned in a previous post entitled " Embedded Linux based internet appliance keygen" just published an update.  So, I grabbed the pertinent file (the shared object) and threw it into IDA.  A quick cursory glace shows that in one aspect they STILL haven't learned their lesson.  As they still don't strip it before shipping it.  So, all the important functions "VerifyKey" "IsTrialKey", etc. are still labeled automatically by IDA.  And it looks like their algorithm is still the same for computing the keys.

BUT!  Maybe they've learned something.  Now, when you enter a key, they package it up, and send it to their webserver for verification.   How do I know this?  Simple!  There's now a function called "SendActivationRequest".  And, a quick spin through that function shows that it builds a nice URL, with a hashed component, and the normal sections for serial number, etc.  Then, they use libcurl to send this to themselves for verification.

Could I whack this step, and make it always assume that it succeeded?  Sure, but the truth is.  There's NO WAY, short of a FULL tracing of all the possible code paths, to know that they don't send this data somewhere else, at some random time.  And, since this isn't a "warez" release for the world, and just a mod for some friends, I don't want to be responsible for them getting in trouble for using it.  So, I'm not going to touch this new version.

The device that this code runs on, HAS to be connected to the network, and in some cases, the internet.  So, short of blocking all the companies IPs/domains in the firewall, you just can't be sure.

Lastly, they now appear to have *2* blacklists for unauthorized serial numbers.  The normal "compile time" one.  (list of them is in the .so itself), and they also now have a list on their server.  How do I know this?  Maybe it could be because of the function called "UpdateOnlineBlacklist".

So, there you have it.  Some people DO pay attention, and learn, while others do the same thing over and over.  Or worse yet, rely on some 3rd party to do it for them.

Who bases their product on Mozilla? (I mean, OTHER than Firefox?)

Today's entry is a nameless application that's based on Mozilla's framework.  I'm not sure WHY they did it this way, but it posed some interesting challenges.  To start with, the initial application launcher didn't appear to actually DO anything, and then exited.  I can only assume it did some sort of magic behind the scenes to kick off the application, and then it exits.  It's very small, so I guess that's all it NEEDED to do.  What was kinda interesting, is that it was named the same name as the main executable.  So, if you looked at a task list, you would assume it was the launcher, and not the main application itself.

Once I found the main application, I threw it into IDA like normal, and that reveals nothing worthwhile from the outset, but running it with "Break on DLL load" was VERY informative.  The program loads the usual suspects, and then loads yet ANOTHER xxlicense.dll.  (Name changed to protect the innocent).  I exit the application, and go find xxlicense.dll.  Turns out, it's a screaming 23KB.  At least the LAST target attempted to thwart me by putting their licensing code in a HUGE .dll to make it harder to locate the pertinent bits.  Not so this time.  It's all right there in black and white.  Sorta.  So, I toss that file into IDA, it disassembles nicely, and I figure I'll just go to the exports list, and find the functions that I'm interested in, and start there.  To my surprise, the exports list is almost empty.  It contains 2 entries:  DllEntryPoint, and NSModule.  I've seen this sort of thing in the past when I was tinkering with a COM object's .dll.  So what's going on here?  Well, Mozilla has it's own list of methods that it uses, and IDA doesn't know about them.  (Or at least *I* don't know how to make IDA know about them.)  Either way.  So, no hints about what the functions are named.  We'll have to do it the hard way.  I open the file in Hex Workshop, and examine the strings contained inside.  There are lots of good ones!  I pick a nice one like "'License file ',27h,'%s',27h,' does not exist',0".  Go back to IDA, search for it, and boom.  I now have a pointer back to where the license file is opened.  A careful study of the function shows that it simply opens the file, and calls fgets in a loop to read all the contents into a buffer, after which, it closes the file.  Using IDA's cross reference feature, I see that this function is called from *1* place.  I go to that function, and see that it reads the license file into a buffer, and then passes the buffer to a function that processes it.

It appears that the "fields" in the license are all text, separated by bar "|" characters.  So, there is code to find the first bar, and copy from that point to the end of the license, to a new variable.  They then pass a pointer to this buffer to another function.

In the text area, there are some strings of garbage that aren't ASCII strings.  This always makes me suspicious.  In this case, it was warranted.  We have this:

loc_72AD1730 r
.data:72AD7061                 db 0E0h ; a
.data:72AD7062                 db 0E6h ; µ
.data:72AD7063                 db 0F7h ; ˜
.data:72AD7064                 db 0E0h ; a
.data:72AD7065                 db 0F1h ; ±
.data:72AD7066                 db 0EEh ; e
.data:72AD7067                 db 0E2h ; G
.data:72AD7068                 db 0E7h ; t
.data:72AD7069                 db 0EEh ; e
.data:72AD706A                 db 0E0h ; a
.data:72AD706B                 db 0FCh ; n

The 1st character of that "string" is accessed inside the function that I'm looking at.  It's copied to a buffer, and then there's code that decrypts it.  It's simply XOR'd with 0xA5.  So, looking at the result yields "SECRETKGBKEY".  :-)  Funny guys!

They have that at the start of their buffer, and then copy the rest of the license over to it.  Once they have it all in the same place, they run a simple MD5 against it.  They save off the resultant hash, and return.  The produced hash is then compared against the 1st "field" of the license they read in from the file.  (The data before the 1st bar).  If it matches?  Code is GOOD!

There is one last thing that they do.  Inside the license text is a VERSION of the product.  "Product9" or "Product5".  Even though the hash matches, that doesn't mean that this license is for this version of the product.  So, they compare it.  (After they decrypt it that is!).  So, to keep you from just reading the strings from the .dll, and knowing what to put in the file, they make you work a LITTLE harder.

The product version string is stored with the high bit set, so that makes it also not a visible string when you look for it.  There is a loop that grabs a byte from this "string", ands it with 0x7F, and then compares it to a character from your license.  If they match, it goes on.  Otherwise, the return value is the same as your run of the mill strcmp.  (-1, 0, 1).  Once you product string matches, you're good to go!

One thing you have to be on the lookout for, it expects the LETTERS in your hash to be LOWERCASE.  Uppercase will cause the compare to fail.

So, the steps to make a license.  Take an existing license (Maybe even from another product from the same company!), change the product name to match what you find in the .DLL.  Replace the hash in the 1st field with SECRETKGBKEY.  Generate an MD5 hash on that, and replace SECRETKGBKEY with the hash.  Save, and enjoy your product!

Embedded Linux based internet appliance keygen

A friend contacted me to tell me that an internet appliance that we both own has some extra functionality in it, if you enable it by entering a key code.  Of course you know that means that I'm interested.  The fact that said appliance is Linux based makes it more special for me, being a Linux hacker at heart.  He sends me some screenshots of the webpages involved, and I start grepping for the strings that I see in the pictures.  I find them, in a strings file.  (Since this app is localized to many different languages, this is to be expected).  I then search for references to that string ID.  And find them in a javascript file.  Of course it's compressed like those JS programmers do.  So, I go to my favorite online JS beautifier site, paste the code in, and viola!  I have readable code.  A quick search with a text editor, and I'm looking at where the "Invalid code entered" box is displayed.  And, I see that it's just a response to an error code.  Some tracing back through the other JS files brings me to a call to a function.  A quick grep for that function tells me that it's not in the JS anymore.  Sounds like we're going in the right direction.

I back out of the JS directory, and find the directory where the .so libraries are stored.  A quick ls of the directory shows me a file called xxlicense.so.  (Name has been changed to protect the innocent).  I toss that into IDA Pro, and see that there are some functions here, but that they call to some centralized function not present in this file.  The list of libraries that this thing loaded was impressive!  The normal ones for glibc, and the like, but also a TON of other libraries.  Not sure if they used them all, or if they were just trying to obfuscate where the protection bits were.  So, I start loading the libs, one at a time, looking for where the functions were that it was calling.  I FINALLY find them in a very large library.  A little digging around shows me that in typical Linux style, they didn't strip the symbols from the library, so not only do I have the names for the EXPORTED functions, but I also have the names of the utility functions used by the exported functions.  A little digging reveals verifyKey.  A cursory glance through here is initially intimidating.  OpenSSL, SHA1, big nums, etc.  All the makings for a genuine nightmare.  But, since you're reading about it here, you know where this is going.

Some further study reveals that the unlock code that you enter is 20 characters long.  They have a list of allowable characters.  (No 0's, O's, 1's, l's, or anything that could be construed as being something else).

char validCharacters[]= {"BCDFGHJKMPQRTVWXY2346789\0"};

These characters are processed one at a time, and a pseudo-summation is performed to generate a key.  The key contains some data, and a checksum of the key.  My mock up of their code looks like this:

      counter = 0;
      do
      {
        BN_mul_word(pOutput, 24);
        keyCharacter = pInput[counter];
        compareCharacter = 'B';
        innerLoopCounter = 0;
        while ( keyCharacter != compareCharacter )
        {
          ++innerLoopCounter;
          if ( innerLoopCounter == 24 )
          {
            innerLoopCounter = -1;
            break;
          }
          compareCharacter = validCharacters[innerLoopCounter];
        }
        ++counter;
        BN_add_word(pOutput, innerLoopCounter);
      }
      while ( counter != length );

There are 24 characters in their "safe list". That's why there's a comparison of innerLoopCounter and 24. The 1st character of their list is 'B'. That's why they "pre-load" B into compareCharacter.
 Now, as you see, they don't add the  CHARACTER to the sum, they add the INDEX of the character in their "safe list". And then, multiply the whole thing by 24. (Except for the LAST character). Being that the code is 20 characters long, this yields a valid number in the 46-91 bit range. That's why they use the BN (Big Number) functionality from OpenSSL. Once this is done, they then slice, and dice the results. The upper 45 bits are a SHA1 hash of the lower 46 bits. And the lower 46 bits contains 31 bits of serial number, and 4 bits of license count, and 11 unused bits. Since we understand all of this, we simply need to do things in the REVERSE order to make our keygen. So, we take a serial number, and number of licenses, and shift those into place. Generate a SHA1 of that half, truncate it to 45 bits, and slap it into the TOP half. THEN comes the interesting part. Reversing the function you see above. It took me a while to figure out exactly how to do it, since brute forcing 24^19th didn't seem like something that I would like to do on a regular basis. The way that I came to understand what would be the final technique was to start with a code of 00000000000000000001. I looked at the output. Then, I moved the 1 to the left, like this: 00000000000000000010. Looked at THAT value. I did that all the way across, and examined the values. It came out as 1 * 24 ^nth. (Where nth represents the position of the 1 character in the string).

 This triggered a thought. What if we do the LEFT most character first. And by DO, I mean divide it by 24^19th, use the result as the index into the character array, and then work on the remainder.

 So, I whipped up code to do that. It looks like this:

  // Set the divisor to 24^19
  BN_set_word(result, 24);
  BN_set_word(remainder, 19);
  BN_exp(rollingDivisor, result, remainder, ctx);

  // Process each digit (codes are 20 digits long)
  while ( count < 20 )
  {
    // If we make it to 0, just spit out B's for the rest (or hot fire).
    if ( BN_is_zero(code) )
    {
      outputCode[count++] = 'B';
      continue;
    }

    // Divide the code by the divisor
    BN_div(result, remainder, code, rollingDivisor, ctx);

    // The remainder becomes the new code
    BN_copy(code, remainder);

    // Adjust the divisor
    BN_div_word(rollingDivisor, 24);

    // Value should be in the realm of 0-23
    if ( BN_num_bits(result) > 5)
    {
      printf("Something is broken, too many bits\n");
      goto Exit;
    }

    // Horrible hack because BN_bn2bin didn't appear to want to work.
    index = atoi(BN_bn2dec(result));

    // Save the letter of the code
    outputCode[count++] = validCharacters[index];
  }

I ran it, and it worked! Some additional digging was required, as the target application also maintains an internal blacklist of codes. I'm not sure if these are codes that they've seen shared online, or what the deal is, but there's a list of 40-some codes. So, I added code to verify that the entered code isn't in the blacklisted code. And lastly, the serial number that you select at generation time has to be within some defined ranges as well. So, added some quick code to verify that, and there you have it. An embedded Linux based internet appliance keygen.

Cross platform code sharing

Recently, I've had the opportunity to examine a massively cross-platform application that's compiled for Windows, Linux, OSX, HP-UX, Solaris, AIX, etc.  I've been in the software world long enough to know that companies like to write code ONCE, and then compile it on different platforms with a little platform specific "shim" code, and then ship it.  It makes PERFECT sense to do this, as you can have all your bugs fixed in a shared tree, and only have to fix them once.  It's even BETTER when you can leverage this work with a protection vendor who offers a protection system that runs on all your target platforms, as it allows you to write your protection code only once.

But therein lies the problem.  Various compilers on various OSes do things differently.  For instance, the MAC compiler might leave in the debugging info and tell me that that random byte in program memory is really called "licenseObtained".  And, once I know that, I can do an XREF on that memory location, and find the 2 places that it's written to.  The first writes a "1" there, and exits the function, and the other writes a "0" there, and drops to a function that displays a messagebox with a message that it was "unable to obtain a license".  When this happens, it doesn't matter that the compilers on the other platforms removed this label.  The cat is firmly out of the bag.

I heard that!  You said "Big deal, you found a variable's name in one version of the application, how does that doom all the OTHER platforms?"  Simple!  The function that made the decision on the value to write to that memory location also read an environment variable that isn't read anywhere else in the code.  So, you simply search for that string in memory, find where it's accessed, and that leads you back to the function.  On ALL the platforms.  Also, it helps when you don't strip your binaries, and I see that the function is named "LicenseCheck".  In this case, you load the application into IDA, let it run for a while, and then tell it to GOTO "LicenseCheck", and there you are.

There are a MULTITUDE of protection failures on display in this application, but the application itself is a great tool.  And, I will admit that it's completely possible that the authors don't care about these failures, as protection is there solely "to keep the honest people honest".  I can respect that!  As someone who has seen the nastiest protection circumvented easily, it makes sense to not spend a ton of time/money trying to protect your application, as really, protection isn't your core business, and a minority of your business customers would use a pirated version, so it's not WORTH it.

But, there you have it.  The perils of sharing the same codebase on a multitude of platforms.

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!