Ring3 Circus
December 5th, 2007, 16:45
After last time’s failure ("http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-ii/"), 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.
http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-iii/
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.
http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-iii/