Ring3 Circus
December 5th, 2007, 16:45
So I had the motivation ("http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-i/"); 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 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.
http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-ii/
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 ("http://www.ring3circus.com/wp-content/uploads/atom-editor.exe")). 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:http://www.ring3circus.com/wp-content/uploads/udta_atoms.thumbnail.png ("http://www.ring3circus.com/wp-content/uploads/udta_atoms.png")The AAC stream is encrypted for DRMed files, using a proprietary variant of the Rijndael cipher ("http://en.wikipedia.org/wiki/Rijndael"). 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 ("http://www.ring3circus.com/wp-content/uploads/udta_atoms.png") 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.
http://www.ring3circus.com/rce/how-i-cracked-the-itunes-7-drm-pt-ii/