The Collaborative RCE Tool Library

I had decided to unofficially shut up shop for what remains of the year, but I just can’t keep quiet about this. For those of you who don’t already know, dELTA over at Woodmann’s RCE forums has created what I’ll describe as the most important RCE development since IDA 4.9. It’s not a tool, but an interactive database of potentially every one you will ever need.

The Collaborative RCE Tool Library

It’s already rather complete, but if you feel anything is missing then it needn’t be for very long. Take a look, download what you need, learn what you can and maybe give something back.

See you in the new year.

Posted in RCE | No Comments »

Vaughn Of The Dead Pt III: Some small-fry

Since we last spoke, Vaughn has seen very little action. The problem is not the week or so of down-time he’s experienced, but the fact that his virtual environment lives inside my computer. While the virtual PC itself is about as safe as a chainsaw-piñata, the internet connection to which it is bridged is protected by the firewalls and antivirus of my computer and router. This is such an elementary design-flaw that I was tempted to keep it quiet, but let’s move on and never speak of it again. The problem has gone unfixed since I discovered it (a fortnight ago) and, as this is the lowest-priority project on my agenda, it will probably remain so for a little while. At least until I work out why my router’s demilitarised-zone setting seems to do absolutely nothing.

Anyway, a piece of malware found its way into my possession via a different medium, and so I kept my side of the bargain and gave it to Vaughn. But don’t get too excited - this adware trojan is so uninteresting that none of the antivirus companies bothered to give it an identity any more unique than ‘Generic Delphi Downloader’. (yes, that’s right, Delphi). I still don’t know where it came from (after China).

The original infection was on my rarely-used laptop. First came the mysterious popup advertisements, then the rogue ‘Add Favourite’ dialog boxes. Both coincided with the installation of Internet Explorer 7 and so - being a long-time Firefox convert - I didn’t take too much notice. But when the activity persisted even after IE7 had been removed from the picture, I took a peek at my process list. Windows’s Task Manager showed nothing suspicious - mainly because it is borderline-useless - but OllyDbg’s attach menu showed up seven instances of svchost.exe. If you know anything about Windows Services, you’ll know that these are nothing more than user-mode process that house DLL-based shared-service modules. At least that’s true of the six instances resident at “%systemroot%/system32″, but the one at “%ProgramFiles%/Internet Explorer” was rather more spurious.

A brief analysis showed that this file (with the ‘hidden’ and ’system’ file attributes set) was compiled by Borland Delphi 7.0 and that despite its obviously trojan nature, the process - true to its name - actually did host a Windows Service. Only, a bad one. After familiarising myself with the verbose assembly produced by Delphi (like any other very-high-level language) and the fastcall-esque nature of the internals, I produced a flow-chart of the trojan’s life-cycle.

• Initialise the Delphi run-time library.
• Get the executable path and set the file attributes to ‘SYSTEM | HIDDEN’.
• Look for a service named ‘windownetpker’. If none such is registered with the system, create it.
  

  If you look for this service in the administrative tools, you’ll see it just points straight back at the same executable file. It hides under the name ‘Window Image Worker’, which is presumably supposed to resemble the legitimate ‘Windows Image Acquisition’. Naturally, it is set to auto-start.

• If the service isn’t running, start it.
• Check the user-name of the process environment and determine how the process was launched.
  

  When a program is launched manually, this user-name is that of whoever is logged in. But when launched as a service, GetUserName returns ‘SYSTEM’, or in certain cases ‘LOCAL SERVICE’. By comparing against these two the trojan works out whether it is supposed to act as a service or just a plain and filthy malware executable.

• In the normal-user case, clean up and quit. Otherwise, enter the secondary phase, idling in a service event-handling loop.
  

  It is made quite clear in the MSDN documentation that, when launched, a service should not do anything before calling StartServiceCtrlDispatcher. Not only does our trojan violate this, but it also goes through all the unnecessary work of installing and starting the service, even when it probably is the service. Now, I’m quite happy for people to infect my computer without consent but they breaking the rules is just plain rude.

The call to CreateServiceA:

The service payload isn’t much more interesting. It opens up a few UDP ports (starting from 1025), establishes a TCP connection with cpk4.easy78.cn (HTTP) and waits for the spam to come rolling in. When such an item does come along, the service displays a popup (usually offering ‘great savings’ on something or other) or attempts to add a page to your IE Favourites. The mundaneness was all too much for me and so I didn’t probe much further, but the trojan doesn’t seem to use any suspicious APIs and it even gives you the offer to ‘Cancel’ the popup ads. A little courtesy goes a long way.

That’s all I have to say about ‘Generic Delphi Downloader’ and any other ‘generic’ downloaders that I may run into in future. Here’s hoping that something truly wicked finds its way to me before too long. And for the record, I don’t have any problems with Delphi. It just struck me as an odd choice for the task.

Posted in RCE | No Comments »

How I cracked the iTunes 7 DRM, Pt V

The story so far: Part 1, Part 2, Part 3, Part 4.
The remainder of this project consisted of developing the interface and injection DLL in parallel. This all went fairly smoothly, so I’ll present a summary of the workings.

• Two programs are involved:
  • DLLBugger.dll - a C++ toolkit DLL designed for injection into iTunes. It sniffs out DRM keys as they are passed to the MP4-playing subroutine, exposes a variety of methods for inter-process communication, and invokes iTunes’s decrypter function when ordered to do so.
    The peculiar name is something of a relic from the DLL’s twin program, who unfortunately didn’t make it this far.
  • DisaRM.exe - a C# GUI responsible for locating the iTunes process (launching it, if necessary), injecting DLLBugger, parsing the database, asking the user which tracks to unlock, and overseeing the decryption process as performed by DLLBugger within the iTunes address-space.
• When launched, DisaRM immediately loads DLLBugger into its own address-space. Next, it launches iTunes.exe and acquires a handle to the process. From here DLLBugger is injected into iTunes. Having the DLL present in both processes makes for an ‘easy’ way to communicate data back-and-forth (using a shared PE segment). As it turned out, there was no need to use the Win32 debugging API and so DRMBugger.exe outlived its usefulness.
• Because I had never written anything involving inter-process communication before, I was quite unprepared for the volume of work required to make this shared-segment approach successful. So it wasn’t before familiarising myself with semaphores and planning out how everything could be made to work with exchange limited to POD, that a rudimentary communication state-machine was implemented.
• DLLBugger exports twelve functions:

  bool CreateHooks(void* decrypt_call, void* decrypt_func, void* cfw_call);
   
  DWORD InjectMain(void *lpParam);
   
  void* GetRemoteProcAddress(LPCSTR lpModuleName, LPCSTR lpProcName);
   
  bool KillRemoteThread(HANDLE hRemoteThread);
   
  bool RemoteDecrypt(wchar_t* in_name, wchar_t* out_name, RijndaelKey key);
   
  RijndaelKey GetLastKey();
   
  void SetStoredKey(RijndaelKey key);
   
  void RemoveHooks();
   
  long GetLastTrackFirstLength();
   
  char* GetLastTrackFirstData(long* buffer_size);
   
  WCHAR* GetLastAudioFileName();
   
  bool PollNewFile();

• Passing hard-coded addresses (I know, yuck), DisaRM invokes CreateHooks in the iTunes process. This installs hooks in Kernel32!CreateFileW, iTunes!Decrypt and iTunes!_PlayMP4+_CallToDecrypter (the point at which the previous function is called). Now any attempts to load a track or decrypt a chunk of AAC will be intercepted.
• After DisaRM has loaded and displayed the protected subset of the iTunes library, the user chooses which tracks to unlock and hits the ‘Get Keys’ button. This triggers DisaRM to launch the first track into iTunes, causing a call to CreateFileW to be intercepted by the DLL. The arguments are stored and execution is allowed to continue. With this, DLLBugger has a good idea which track will be playing at any given time. Once iTunes has loaded the protected MP4 file, determined its decryption key and done whatever else it does, it necessarily makes a call to the Decrypt function. Naturally, this too is intercepted by our DLL and we begin to generate a mapping of file-names to DRM keys. Sanity checks exist in the form of GetLastTrackFirstLength, GetLastTrackFirstData, GetLastKey, and GetLastAudioFileName. Once the confidence level is high enough (as all this business is done asynchronously by iTunes and it isn’t safe to assume too much about the order of events) DLLBugger reports back to DisaRM, and the next track is launched. In this way, DisaRM learns the keys for each file it needs to decrypt.
• Provided everything went smoothly, the DisaRM displays the keys alongside the track name, artist, album and such (this was initially useful for debugging purposes, but I left it in because it looks kinda cool). The user gets a chance to reconsider before hitting the ‘Remove DRM’ button. Because what DRM-removal tool would be complete without one?
• The decryption process itself is relatively straightforward. A single call to RemoteDecrypt from DisaRM creates a new thread in iTunes, which opens up the MP4 file and parses the data to find the stbl atom. This part of the file lists the offsets and sizes of each chunk of AAC data (’cause they come in chunks, you know) among other things. For each chunk, the thread calls the Decrypt function, passing the appropriate offset, size and key. With the stream decrypted, some offensive atoms are removed and the file is made to look like it never had any DRM in the first place. DLLBugger saves the result to disk and that’s that.

I’ll take this opportunity to apologise to any Mac users who were hoping to learn something about the iTunes DRM from this series. Clearly, I didn’t reverse-engineer the protocol to any substantial degree and so none of the methods described port very far away from Windows XP. Maybe another time.

A few things were learned over the four weeks I spent. Here are just a few:

• Writing an inter-process communication framework is not a task to be taken lightly, no matter how little of it you think you need.
• C# is excellent for GUI development and awful at low-level hackery. But when you have a shiny new hammer, everything starts to look like a nail.
• Over-engineering a solution is as bad as under-engineering it. I’m sure I could have saved myself a fortnight if I hadn’t bothered writing that debugger I didn’t need.
• A profiler can be an excellent RCE tool. If I’d only thought to profile a few seconds of each of m4p and m4a playback, I could have isolated the decrypter function in minutes, rather than days.
• QuickTime is horrible.

So that marks the end of this series of posts. I can assure you, though, that I haven’t nearly reached the end of the story.

Posted in RCE | 2 Comments »

Protecting your game against the hackers

How should I best spend my valuable time, money and man-power so as to keep those dastardly crackers at bay, and the money rolling in? There are so many commercial protection schemes out there; some cheap and some certainly not, but they all seem to be compromised… Is it really worth all that money? Or should I maybe set one of my most talented programmers on the task for a couple of weeks? At least that way, my security will be truly unique. All I know is that the more pirated copies of my game are made, the more of my revenue goes down the drain!

Stop! If this sounds familiar then I beg you to hear me out, even though you probably won’t like it. I’ve spent plenty of time reverse-engineering games in the company of the black-hats and I’ve seen the situation from both sides of the fence. Here’s your chance to learn from the mistakes of thousands before you and save some money in the process. At least, that goes for everybody to whom this next paragraph doesn’t apply.

If you’re writing a multiplayer client-server game and your interest is in keeping the hackers from ruining everyone else’s fun, then the solution is simple (although it needs to be understood from the beginning of development): Any code that can be taken advantage of must go on the server side. No matter how much time and intelligence you have, the hacker collective has more, and so sensitive code in the client application is a disaster waiting to happen. For example, if the client program is responsible for his own collision detection, then you are responsible when your paying customers complain about their enemies walking through walls. Once you’ve made sure that your design ensures the client can’t cheat, no matter what data it sends the server’s way, your job is done.

But for the rest of you, who are concerned about illicit copying, things are even simpler. Let’s suppose I am a software pirate, for a moment. Then here are some facts:

• If I can run your program, then I can disassemble it. If I can disassemble it, then I can reverse-engineer it.
• If your game isn’t worth hacking, I won’t try, and your efforts will go to waste.
• If your game is worth hacking, then I will try to hack it, and given sufficient time and motivation I will succeed. At this point, your protection scheme is worth nothing. It only takes one successful hack, and the cat is out of the bag.
• There are many hackers working on any popular commercial protection scheme at any moment, and once we’ve cracked one sample, the method extends with relative ease.
• The more effective a protection is, the more popular it will become and the more attention it will get from us bad guys. Together with the last point, this places a limit on the value of any commercial protector.
• It is very, very easy to slip up when writing such a system. All but the best-thought-out, most thoroughly-tested schemes (generally written by those with years of experience) boil down to a single conditional jump somewhere along the line. Once I find this Achilles’ heel, I win.

And here are some commonly upheld non-facts:

• If somebody is prepared to steal your game, then they are prepared to buy it in the absence of a crack.
• Protection schemes reliably keep a game safe from crackers long enough to ride out the majority of its public consumption.
• Protection schemes reliably keep a game safe from crackers for at least a few days.

So both buying and home-brewing a protection are bad ideas? Not at all, they’re just not as good as they sound. A shop-bought PE-protector is an excellent investment if you deem its level of protection worth the value on the price-tag. But you’ll be investing in a false economy by fooling yourself into believing that this level of protection is anything more than ‘a week’s head-start from release’ or simply ‘keeping honest people honest’. And home-brewed protections are a very good idea, just keep them simple. If it’s going to be cracked anyway, then keep it as simple as possible. Why not restrict yourself to the five man-minutes it takes to check for the presence of your game’s CD?

1. Enumerate the disc-drives on the system.
2. Find the one that contains your game’s CD, by checking for a specifically-named file
3. Check the file’s attributes, to make sure that it is read-only.

If something goes wrong at any point in this sequence, then you simply demand the user puts the CD in the drive, and loop. Now, even a half-witted hacker will circumvent this in minutes, but it’s enough to keep the layman in check, and that’s all you want.

Update: I hate CD-swapping as much as the next man, and so if you can bear it I’d recommend you avoid this too. The ideal solution is a server-based disposable serial database system, but most developers don’t have a server lying around to dedicate to this cause. If you do decide to use a CD-check, then at least be reasonable and disable it after a few days of successful use.

So now that you’ve saved yourself the hundreds or thousands of dollars you were about to give to Silicon Realms or Macrovision, you can afford to spend more on getting your game perfect, and that is what the consumer is happy to pay for. All that’s left is to price your game appropriately, and this means doing a little market research. Once we remove from the equation the user who pirates everything (the type you can do nothing about and should disregard), the situation is extremely simple:

If the user wants and can afford your game, then he’ll consider buying it.
If he has pirated it then he didn’t consider it worth paying for.

Posted in Game Programming | 11 Comments »