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 »

How I cracked the iTunes 7 DRM, Pt IV

Success was close enough to smell, but not to taste. Succeeding in a debugger with all your (razor-sharp) wits about you, and teaching a computer how to do the same are two very different things. DRMBugger and DLLBugger were still in a state of throwaway code and the project had almost nothing in the way of an interface.

This is where Visual C# came into play. While I’m no expert (and I certainly wasn’t at the time), anybody with conversational C++ can quite quickly pick it up and produce a convincing GUI in no time. But with any new toy comes the compulsion to wear it out, and I soon found myself wasting a week getting the DisaRM GUI perfect. I really have nobody to blame but myself, but the friend who suggested I mimic the iTunes GUI (mentioning no names, Dave) helped to send the project rolling in entirely the wrong direction. Unfortunately, I wasn’t quite prepared for the OOP-mania that is C# and so the controls I created are a little too interdependent for me to release their source code, and that’s a shame, because my iTunesListBox, iTunesScrollBar and iTunesProgressBar classes are true works of art.

With that distraction out of the way, I got to porting the DLL injection code from C++ to C#. If you’ve ever used the Win32 API from C#, you’ll know how much of a pain it is to translate all those function prototypes (somewhat reminiscent of VB 6) and you’ll have some sympathy for me having to do thirty of the bastards. If I had thought things through beforehand then I’d have left this close-to-the-metal business in a C++ DLL where it belongs, but we live and learn.

Getting the iTunes library track-listing and extracting the DRMed tracks was a lesson in elementary XML-parsing (take a look in %MyMusic%/iTunes/iTunes Music Library.xml if you don’t believe me). The next step is to extract the DRM keys.

If I’d taken more time to debug I’m sure a cleaner way to do this would have presented itself, but I settled for launching each of the encrypted files into the Windows shell (so that iTunes begins to play it) and extracting each key via a hook installed in the iTunes process’s decrypter function. The keys are piped back to DisaRM and everybody’s happy (with the possible exception of the user, who has just heard the first second of each protected track in their library while seeing the iTunes window frantically pop in and out of focus). It won’t mean too much without context, but here’s the rather confusing C++ source for the hook, from DLLBugger. The unnecessarily complex conditional statement at the start is checks the stream contents to make sure that it is indeed drawing the key from the right track.

long __cdecl HookDecrypt(char* buffer, long length, RijndaelKey** key) {
    if (new_file) {
        // Track Changed
        long copy_length = min(length, LENGTH_AAC_DATA_TO_SAMPLE);
        std::fill(port_last_track_first_data, port_last_track_first_data + LENGTH_AAC_DATA_TO_SAMPLE, 0);
        std::copy(buffer, buffer + copy_length, port_last_track_first_data);
        port_last_track_first_decrypt_length = length;
        new_file = false;
        port_new_file = true;
    }
    port_last_key = **key;
    return (hook_decrypt_func(buffer, length, key));
}

With this done, all the ingredients are present. DisaRM knows the locations of the protected files and the keys needed to decrypt them. Next is to manipulate iTunes into doing the dirty on its own DRM.

Posted in RCE | 2 Comments »

Drawing on another Direct3D program’s viewport

Update: See the post for the new version.

The theme of the moment is DLL hooking, and so I thought I’d present an applied example. I already explained how Fraps works, and since I’ve recently been roped into writing a similar tool for a stranger, I thought I’d share the wealth. There isn’t much new material here, but people like examples with source code, so you can download the DLL source (C++) from the project page.

If you don’t know how to inject this DLL into a foreign process, then you’ll need to read my previous post or wait for the injection framework I’m working on. But once it’s injected call the Initialise method, via CreateRemoteThread or otherwise, to install the hooks. It works with any program that uses IDirect3DDevice9::Present (or IDirect3DSwapChain::Present) to render, which is probably all of the DirectX 9 games. Similarly, invoke Release to remove the hooks. The source is fairly self-explanatory, with a few exceptions.

• It’s not safe for 64-bit consumption, though this should be obvious.
• While there’s no reason it can’t be made to work with Unicode, I’ve written everything in ASCII, for simplicity.
• By default, the DLL will increase its own reference count to prevent it being unloaded prior to termination of the host process. This is because there is a small risk of the DLL being unloaded by one thread, while a hooked function in another returns to the now dead memory. I figured that it’s best to waste a little bit of everybody’s memory than to crash unnecessarily.
• The d3d9.dll function addresses (and prologues) are hard-coded, or at least their offsets are. While this may look very unprofessional and rather risky, I can assure you that it’s quite safe. The alternative would be to hack up some virtual-function tables and that’s a whole other story for a whole other post.
• You may notice that the compiled DLL is dependent upon D3DX. This isn’t necessary for the hook itself, but I used ID3DXFont in my example for demonstrative purposes. The only reason I mention this is that there is no way to guarantee the existence of any D3DX DLLs on a DirectX 9 machine, and distributing them yourself is in violation of the DirectX Runtime EULA. So if you happen to need to distribute this code, you’ll either need to carry the huge runtime installer around, or avoid using D3DX altogether.

Update:

• The soft-hooks used here will cause problems with PunkBuster if applied to any of its monitored functions. If you need to do this then you’ll have to be a bit cleverer.
• The source assumes that the graphics device will never become invalid. If you suspect that this isn’t the case (which will be true for any full-screen game at a minimum) then you’ll need to add the appropriate sanity checks (see IDirect3DDevice9::TestCooperativeLevel) before attempting to render anything, lest you want to crash and burn.

Posted in Game Programming, RCE | 35 Comments »

Case study: Fraps

One of the topics that I often find myself bluffing through on GameDev is Direct3D hooking. In particular, how to display an overlay of your own on the window of another Direct3D program, often a commercial game. It’s pretty clear that the simplest method would involve somehow hooking the call to IDirect3DDevice8/9/10::Present, but the details are a little sketchy, particularly when you throw anti-hack systems into the mix. To be quite honest, I wasn’t sure I’d have been able to write a scalable hook that wouldn’t cause any incompatibilities - at least not without doing some very immoral things. So when I found out that Fraps has been doing exactly this for years, and that it somehow manages to avoid angering PunkBuster and other such systems, I decided to investigate.

What is Fraps?

Simply put, it’s a profiling and video-capture tool for PC games. As well as providing the ability to capture a video stream from any Direct3D 8/9/10, DirectDraw or OpenGL program, it can display real-time performance statistics (frame-rate and such) by means of an overlay on the game’s window (or full-screen display).

Remarkably, Fraps seems to handle the hacky side of all this automatically, with no fuss. It will dig its claws into any compatible game, whether it was started before or after Fraps. Yet if you investigate the state of DirectX and OpenGL’s DLLs on disk (in system32), they remain untouched at all times.

So how does it work?

Well it could be a whole lot worse, but I wasn’t thrilled to find out that every process running on my system had an instance of Fraps.dll loaded. It’s not so much the 106kB footprint that bothers me, but the performance and stability concerns. Anyway, my suspicions that this DLL was ‘infecting’ all processes via a system-wide hook were soon confirmed when OllyDbg caught Fraps.exe making a call to SetWindowsHookEx.

SetWindowsHookEx(WH_CBT, &FrapsProcCBT, hModuleFrapsDLL, 0);

So in one fell swoop, Fraps guarantees that Windows will load a copy of Fraps.dll into every process currently running, as well as those created in future. Moreover, the function FrapsProcCBT will be called by that process each time it attempts to create, destroy, show, hide, move or resize a window. Now this may seem like the perfect solution to a difficult problem, but it’s rather wasteful considering that most processes run window-driven interfaces, and only very few involve DirectX or OpenGL.

How should it work?

Now I haven’t tested this, but a much cleaner way to achieve the same goal would be for Fraps.exe to periodically poll EnumProcesses and EnumProcessModules, so as to determine the processes that actually need hooking. Installing the hooks into these specific processes would require no more work but would save the OS some effort and limit the worst-case-scenario disaster-zone to DirectX and OpenGL applications, which is a considerably smaller domain than almost everything. In Fraps’s defence, the code makes extensive use of IsBadReadPtr and suchlike, and I’ve never heard of it causing any trouble, but nevertheless, the best way to prevent your DLL from crashing someone else’s program is to make sure it never gets loaded.

What does the hook do?

All events but window activation and focus-acquisition (HCBT_ACTIVATE, HCBT_SETFOCUS) fall through the hook chain (CallNextHookEx). But in either of these cases, Fraps.dll goes on to look for a supported graphical interface.

Rather achronologically, the first thing it does at this point is a bunch of string-processing to capitalise and isolate the executable image’s file name. Presumably, the writers would have used GetProcessImageFileName, but bringing psapi.dll along to the party for this reason alone would be borderline-criminal.

Next, GetModuleHandleA is called on opengl32.dll, d3d8.dll, d3d9.dll, dxgi.dll and ddraw.dll. If all return NULL, then there is no work to do and the function returns. But if any of these modules are found, Fraps.dll gets straight to installing its function hooks. The hooks are simply JMP operations assembled ad-hoc at the beginning of IDirect3DDevice9::Release and Present (and presumably the equivalent functions belonging to the other APIs). Now, I was rather surprised to find that PunkBuster has no problem with such crude, unsubtle behaviour, but it’s possible that there is some agreement between the two developers.

That’s almost everything, but one problem remains. Nothing will be drawn to the screen unless d3d9!Present is called, and installation of the patch renders the original functions useless. It is for this reason IAT hooking is preferable to the patch method being used here, but from what I gather PunkBuster periodically ‘fixes’ the IAT of its client process, so that’s no-go. Fraps gets around this little inconvenience in the messy, but reliable way that you’d expect: each time the proxy Present function fires, it removes the patch, calls the original function, and restores the patch.

Here’s some untested C++ concept-code I threw together for the IDirect3DDevice9::Present case. The unbraced snippet installs a patch at address_d3d9_Present (use GetProcAddress) to redirect it to PresentHook. I’ve omitted the patch-removal code, along with a whole load of sanity-checking that really shouldn’t be left out in such a risky situation. Don’t use my laziness as an excuse.

// Calculate offset
DWORD from_int = reinterpret_cast <DWORD> (address_d3d9_Present);
DWORD to_int = reinterpret_cast <DWORD> (&PresentHook);
 
// This version of the JMP instruction takes an address relative
// to the current address, and it is 5 bytes long
// So the relative offset is 'to - from - 5'
// Don't worry about the unsigned DWORD underflowing
DWORD offset = to_int - from_int - 5;
 
// Assemble the patch at the beginning of Present
const unsigned char jmp = 0xE9; // The opcode for a 32-bit rel JMP
 
unsigned char* ip = reinterpret_cast <unsigned char*> (address_d3d9_Present);
*ip = jmp;
*(reinterpret_cast <DWORD*> (ip + 1)) = offset;
 
HRESULT __cdecl PresentHook(const RECT* pSourceRect, const RECT* pDestRect, HWND hDestWindowOverride, const RGNDATA* pDirtyRegion) {
    IDirect3dDevice9* device;
    __asm MOV device, ECX;
 
    // Do anything that needs to be done before Present gets called
 
    // Remove the Present hook
    HRESULT return_value = Present(pSourceRect, pDestRect, hDestWindowOverride, pDirtyRegion);
    // Reinstall the Present hook
 
    // Do anything that needs to be done after Present gets called
    return return_value;
}

Posted in Game Programming, RCE | 8 Comments »