How I cracked the iTunes 7 DRM, Pt III

After last time’s failure, things started to become personal. I started exploring all kinds of new avenues and employing many techniques that aren’t so commonly used. In parallel, I drew up a map of the inner-workings of iTunes 7.0.2.16 and began coding up a framework from which to launch a full-scale attack once I knew how.

The program map was an uninteresting flow-chart full of hex strings (mostly addresses of key points) and crossings-out, but the framework was quite a sight to behold. I had no idea that it was such heavy overkill at the time, but so as to keep all bases covered I ended up with two distinct but inseparably linked programs, codenamed DRMBugger and DLLBugger.

DLLBugger is a tool-kit DLL, designed for injection into iTunes so I could execute arbitrary code from within its address-space and hook functions to my heart’s content.

DRMBugger is a purpose-built debugger. When you fire it up, it locates and attaches to any running instance of iTunes as a user-mode debugger, keeping track of all internal goings-on. It wouldn’t take much effort to convert this into a full-blown ring3 debugger, as it has support for module and memory-page enumeration, hardware breakpoints and run-tracing, along with a rather unreliable disassembler.

With the combined power of these two, iTunes was truly at the mercy of my twisted will. If only I knew what I needed to make it do.

My First Stream

I can’t emphasise enough just how much code is executed in the seemingly idle state of iTunes’s AAC playback, but for days on end I would see OllyDbg’s familiar disassembly window whenever I closed my eyes. After tracing backwards, forwards, using stochastic pausing to find the bottlenecks (like a primitive manual code-profiler), comparing run-traces and hit-traces and analysing dead-listings of programs known to use QuickTime’s DRM code; I finally struck gold.

At 0×0062914D, iTunes.exe (7.0.2.16 for Windows XP) calls a function at 0×005C1B20, passing a pointer to a structure containing the address of an encrypted chunk of AAC, along with a pointer to the pseudo-1024-bit decryption key. It was pretty clear that the AAC data was an entire chunk as defined in the stbl atom directory. It was also evident that the key is retrieved from ‘Documents and Settings\All Users\Application Data\Apple Computer\iTunes\SC Info\SC Info.sidb’ using some of the udta atom’s values as an index. I could have investigated this further, but decided that the details are unimportant if DLLBugger can just use this function black-box-style.

So I got straight to writing an inline patch. The idea was simple: Each time this ‘decrypt’ function is called, dump the decrypted buffer to a previously VirtualAlloced array. And sure enough, after waiting for my protected track to play beginning-to-end, I ended up with an encryption-free copy of the AAC stream. I was confident that this had worked, as the data chunks looked the part, according to my limited knowledge of AAC format, but it wasn’t so straightforward to verify. Decrypting the stream is the hard part, sure, but this stream is useless without the remainder of the MP4 file to house it. I spent a little while in a hex-editor piecing things back together and wasn’t surprised when iTunes refused to play the new file. As far as iTunes was concerned, the MP4 file (even with its new m4a extension) still had all the descriptors of an encrypted file, and as you’d expect, decrypting the stream twice didn’t produce anything meaningful.

Fortunately, this frustrating period didn’t last too long. I had to remove all evidence of DRM-related atoms before things got up-and-running, but that means only overwriting a contiguous block of the file with zeros. As it happened, I had already written a fairly complete atom parsing engine into DRMBugger, so rather than let this go to waste, I took things a step further and removed & reshuffled some of these atoms so that the resulting file was indistinguishable from a true ‘m4a’. Reassuringly, the file played just fine in WMP, WinAmp and VLC, as well as iTunes, so things were really starting to look up. The only problem is that it had taken me two and a half hours to remove the DRM from this file (a little trivia: it was ‘The Rejection’ by Dangerous Muse). The next thing on the agenda, after a night of celebration, was to automate the process.

Posted in RCE | 2 Comments »

DLL injection via CreateRemoteThread

This isn’t exactly news, but I thought I’d briefly run through the now standard method of injecting a DLL of your choice into an arbitrary process under 32-bit Windows. It will serve as a foundation for the upcoming post on function hooking via DLL injection.

So you have analysed a target program, know how it works and what you’d like to make it do, but there isn’t enough room for an inline patch. Or maybe you need to hook an existing function in order to spy on or modify data being passed back and forth. Perhaps add some functionality or a status window? If any of this sounds familiar then you should consider DLL-based code-injection. It is the cleanest method of injection (if there ever were such a thing) and it offers a lot of scalability and maintainability that a quick-and-dirty inline/diversion patch lacks.

The idea is simple, but very clever. We abuse CreateRemoteThread to call LoadLibrary on a string that was injected by means of WriteProcessMemory. The method hinges on the fact that LoadLibrary takes a single parameter. In eight steps:

1. Locate the target process in terms of its process-id. Depending on the situation, any of EnumProcesses, CreateProcess, FindWindow and GetWindowThreadProcessId may come in handy.
2. Acquire a handle to it by calling OpenProcess. This isn’t necessary in certain cases, such as when the target is spawned using CreateProcess, which returns a handle automatically.
3. Allocate some space in the target process for a string containing the path of the DLL, using VirtualAllocEx. Remember to make enough room if using Unicode strings.
4. Fill the new buffer out with the path of the DLL by means of a call to WriteProcessMemory.
5. Call GetProcAddress to get a pointer to LoadLibrary. While there are no guarantees in the Win32 process specification that this function will be in the same place for every process, a little reverse-engineering and common-sense makes it a very safe bet. If the next XP Hotfix were to change the base of kernel32, user32 or ntdll - none of which are relocatable - then a considerable amount of both Microsoft and non-Microsoft code will break and all hell would break loose.
6. Call CreateRemoteThread on the target process, passing the address of LoadLibrary as the LPTHREAD_START_ROUTINE and the address of the newly initialised string buffer as the parameter. Technically, CreateRemoteThread wasn’t designed to deal with this, but in terms of implementation everything is kosher.
7. When LoadLibrary returns, the thread terminates with the return-value as its exit code. So if we call GetExitCodeThread, the result will be the base of the DLL in the target process, or NULL if the call failed.
8. VirtualFreeEx will take care of the now useless string buffer and the process handle should be freed if no more magic needs doing.

This seems like quite a lot of work for such a common operation, so it’s a good idea to code it up in a reusable way. Here’s the implementation as pasted from the DLL-hooking interface I’m working on:

HMODULE DLLInjection::InjectDLL(DWORD process_id) {
    // Open Process
    process_handle = OpenProcess(PROCESS_ALL_ACCESS, false, process_id);
    if (process_handle == 0) return NULL;
 
    // Allocate space for string to contain the DLL Path
    SIZE_T path_length = dll_path.size() + 1;
    void* remote_buffer = VirtualAllocEx(process_handle, NULL, path_length * sizeof(char), MEM_COMMIT, PAGE_READWRITE);
 
    bool success = false;
    if (remote_buffer != NULL) {
        SIZE_T bytes_written = 0;
        WriteProcessMemory(process_handle, remote_buffer, dll_path.c_str(), path_length, &bytes_written);
        if (bytes_written == path_length) {
            DWORD thread_id = 0;
            HMODULE kernel32 = GetModuleHandleA("Kernel32");
            LPTHREAD_START_ROUTINE remote_lla = reinterpret_cast <LPTHREAD_START_ROUTINE> (GetProcAddress(kernel32, "LoadLibraryA"));
            if (remote_lla != NULL) {
                HANDLE thread = CreateRemoteThread(process_handle, NULL, 0, remote_lla, reinterpret_cast <void*> (remote_buffer), 0, &thread_id);
                if (thread != NULL && thread_id != 0) {
                    WaitForSingleObject(thread, 5000);
                    DWORD exit_code = 0;
                    GetExitCodeThread(thread, &exit_code);
                    if (exit_code != 0) {
                        success = true;
                        remote_base = reinterpret_cast <void*> (exit_code);
                    }
                }
            }
        }
        VirtualFreeEx(process_handle, remote_buffer, dll_path.size() + 1, MEM_RELEASE);
    }
 
    if (success) return reinterpret_cast <HMODULE> (remote_base);
    return NULL; // Fail
}

Posted in RCE | 2 Comments »

How I cracked the iTunes 7 DRM, Pt II

So I had the motivation; it was time for action. The first step in undertaking such a large project is to research: Research like a maniac until Google dries up. It took me three days (on top of work) until I was happy that there was no more pre-invented wheel to take advantage of. The fruits of my labour boiled down to two busy flowcharts, each occupying a full page, which I kept pinned at head-level on the notice-board next to me for the following six weeks. Unfortunately, they seem to have been lost in the process of moving back from university, which isn’t surprising considering how much paper is ‘archived’ after finals.

Just to make sure everyone’s on the same page, here’s a quick overview of some of my findings:

• The iTunes Store’s music is distributed exclusively under their ‘m4p’ file extension, as opposed to ‘m4a’ which is the default for music encoded by iTunes. Presumably, ‘a’ stands for ‘audio’ and ‘p’ for ‘protected audio’.
• There is nothing special about an m4a file other than the extension. It is just a common or garden MP4 file with a single AAC audio stream.
• MP4 files consist of a nested structure of ‘atoms’, which are variable-sized general-purpose binary data structures whose contents are identified by a four-character string. There was very little available information about the atomic structure of m4p files, so I had to throw together a C# program to display the tree of identifiers (96kB exe download).
• Deep inside this tree-structure lies the ‘mdat’ atom containing the AAC audio stream, which occupies the majority of the file.
• The only consistent differences between an ‘m4a’ and an ‘m4p’ are:
  • The AAC stream is encrypted for DRMed files, using a proprietary variant of the Rijndael cipher.
  • An ‘iods’ (Initial Object Descriptor) atom is present only for protected files (at moov/mvhd/iods). This turns out to be insignificant for our purposes, but from what I gather it is generated by the software that installs the protection scheme, to store some information about the original file.
  • The seemingly innocent ‘udta’ (User Data) atom contains a rogue null dword to trick most atom viewers into thinking it has no contents.
  • The DRMed ‘moov/udta/meta/ilst’ atom actually contains a whole new set of undocumented atoms that tell iTunes all about your iTunes Store account, encryption keys and so on.

The first hurdle was convincing iTunes to run under a debugger. Many released programs don’t like the idea of being debugged, ’cause it almost always means bad news. Fortunately, iTunes didn’t put up much of a fight and after NOPing a couple of calls to IsDebuggerPresent, iTunes and OllyDbg became like peas and carrots.

In the absence of any meaningful variable or function names (other than imported DLL functions), my first thought was to trace backwards from the opening of the media file towards the decryption routine. From here, I could analyse the algorithm and attempt to rewrite it to decrypt the files on disc. So I started out with a breakpoint on CreateFileW, to catch the point where iTunes loads in the ‘m4p’ file, waited for kernel32.dll to do its thing, then set a conditional breakpoint on ReadFileExW (the extended version is used because the file is read asynchronously). This landed me immediately in QuickTime’s audio-playback engine. I spent a while flicking back-and-forth between QuickTime and iTunes code before I found a very loop-heavy function full of SSE instructions. It could only be the decryption routine or, more likely, the AAC decoder. After an hour or so of manual stepping and comparing run traces of m4p and m4a playback, I determined that it was indeed the AAC decoder, and began to get a good feel for the intricate details of the playback engine.

This is the part where I omit a day’s worth of results, because the minute I realised that what I’d been analysing for what felt like forever was actually just a tiny fraction of the system I’d set out to understand, I fled like a little girl. This monster was clearly a lot more complex than I had initially anticipated. So I returned to the drawing board, not feeling defeated, but optimistically empowered. This DRM wasn’t going to fall very easily. I simply didn’t have the man-power or insight for the usual divide-and-conquer approach (nobody knows how DVD Jon does it - he’s a glitch in the matrix). If I was ever to succeed then I’d need to work smarter, not harder. So that’s exactly what I did, but not before taking a day off.

Posted in RCE | 2 Comments »

How I cracked the iTunes 7 DRM, Pt I

Of the many programs I’ve taken the time to probe and dissect, none has instilled me with such a love-hate sensation as iTunes. My favoured media player by some distance, it is beautiful, easy to use, cleanly written, reliable, and all the rest. But with the iTunes (Music) Store came iDRM, as DVD Jon famously termed it. Apple make it pretty clear that they don’t like DRM any more than the users do, but that their hands are tied, and I respect that. Why then do they insist on doing such a bloody good job of making it very difficult to crack? Everybody knows that it will be broken sooner or later, so why go to all the effort - and it is a lot of effort - to choose ‘later’?

After months of sitting quietly while Apple’s DRM remained unbroken, with my previous encounters with iTunes encryption in mind (maybe I’ll write about them some day) I felt compelled, maybe even prepared, to take matters into my own hands. This was the birth of DisaRM, my home-grown iDRM-removal tool.

Why have you never heard of it? Well, call me a selfish coward but I didn’t want the attention or bother of being responsible for maintaining such a keenly sought taboo. And why didn’t I release the source code? Partly because my method was so awfully hacky, as you’ll see, that most programmers would run a mile. As it happened, QTFairUse6 was released mere days after I produced a working prototype (and well before DisaRM was ready for human consumption) so the onus was lifted.

For the sake of education, and self-indulgence, I’ll take a few posts to describe the story of DisaRM, gory details included.

Posted in RCE | 2 Comments »

Vaughn Of The Dead Pt II: Meet Vaughn

There’s something uncomfortable about setting up a machine to be as insecure as possible, but that’s what I’ve been doing today. Not being the sort to have sacrificial computers lying around, I settled for a virtual machine. So after a quick and easy installation of the VMare Workstation trial, I got straight to setting up Vaughn, my computer-within-a-computer.

The oldest non-biblical version of Windows I have is XP Pro SP1. While it isn’t that old, it’s still vulnerable to the RPC exploit responsible for the 2003 Blaster Worm epidemic, and is still one of the most popular avenues for the black-hat hacker. So after installing the OS, automatic updates were turned off and the bridged network connection was added to my router’s demilitarised zone, to make sure that Vaughn was fully exposed to the internet. XP SP1 didn’t distribute with a firewall, so that’s not a problem. Some essential pieces of software were installed including my full RCE toolkit and the excellent Wireshark packet analyser. Even though no outbound connections are made on the VM’s part, simply being on an active LAN is enough to invite some network traffic, so I had to set up a filter to remove the unrelated packets picked up by Wireshark. So as to prevent Vaughn participating in anything he shouldn’t, I installed an upstream-bandwith throttler and configured the connection to filter any known DoS traffic.

So now we wait, for as long as it takes. Maybe forever. Or at least until my VMware trial expires.

Posted in RCE | 5 Comments »