as reported on The Register Jon Lech Johansen added an extension to the VideoLAN mediaplayer which allows to circumvent apples drm protections and make it possible to play protected *.m4p files on linux for example, which wasnt possible before
first reports say that apple seems to use XOR for encryption
Full Version: Apple's iTunes DRM cracked
XOR? I hope that's a joke...
This guy must have millions to spend on lawyers...
QUOTE(Tripwire @ Jan 6 2004, 05:41 PM)
XOR? I hope that's a joke...
Having had a little bit better look at it, it does look a bit more complex. Can't tell what it is exactly...
Menno
Sweet. Love this thing. Bring da DRM on and someone'll crack them all.
AFAIK only latest nightly builds feature the DRM circumvention and not the 0.7 release version (dubbed "bond" btw 
)
I gather from the Register article that one needs a key file to enable playback of iTunes' DRM protected content. Since the key file is derived from your computer hard- and software and apparently not protected by strong encryption, it is now possible to create such a key file and thus "free" the content of its protection.
)I gather from the Register article that one needs a key file to enable playback of iTunes' DRM protected content. Since the key file is derived from your computer hard- and software and apparently not protected by strong encryption, it is now possible to create such a key file and thus "free" the content of its protection.
QUOTE(Tripwire @ Jan 6 2004, 08:41 AM)
XOR? I hope that's a joke...
Why create an elaborate DRM scheme when it will inevitably be cracked? As long as Apple can say it uses some form of encryption, the music companies will be satisfied.
When do we get a foobar/winamp plugin?
If you can obtain a playback license, use QTFairUse, and then rewrap the AAC into an MP4 and use it wherever you wish.
If you can't obtain a playback license, why are you bothering trying to unprotect iTunes 128kbps protected AAC content when you could use hundreds of "other" sources to get most of the same tunes in an unprotected format and using transparent encoding settings when you look hard enough?
If you can't obtain a playback license, why are you bothering trying to unprotect iTunes 128kbps protected AAC content when you could use hundreds of "other" sources to get most of the same tunes in an unprotected format and using transparent encoding settings when you look hard enough?
QUOTE(negritot @ Jan 6 2004, 03:28 PM)
QUOTE(Tripwire @ Jan 6 2004, 08:41 AM)
XOR? I hope that's a joke...
Why create an elaborate DRM scheme when it will inevitably be cracked? As long as Apple can say it uses some form of encryption, the music companies will be satisfied.
Egos! Big Fat Egos. People sit back thinking that there DRM's are infallible, and it turns out to be easier to crack it, than secure it.
Geez!
QUOTE(Tripwire @ Jan 6 2004, 05:41 PM)
XOR? I hope that's a joke...
Many people know how weak XOR is (worst-case is: with a constant key=1 it's the weakest possible encryption without directly revealing plaintext bits).
But few people know how strong XOR can be when properly used. In fact, it is a perfect method: when used with a one-time pad, it can *not* be broken (even with infinite computing power and time). It will take less ages to crack AES than to crack a one-time pad.
It is this duality that is quite confusing.
(Btw.. for the record, they didn't use XOR). Unless I'm terribly mistaken, the encryption scheme wasn't even broken. It's the key generation that was exposed
I know this is a bit late, but I just wanted to add this to the thread so that everyone has a better understanding of iTunes and the M4P's encryption.
Here's how it works:
In order to buy tunes from iTMS, you have to get an account with Apple and get an "AppleID" which is basically just an email address for the username of the account. This account gets a "user key" assigned to it that is unique to the account.
When you buy a song, a few things happen..
a) the song gets encrypted using your user key
b) it gets stuck into an M4P wrapper which, among info about the song, contains the username for your account
When you try to play a song, your copy of iTunes has to authorize itself. Authorization works like this:
a) iTunes reads the username from the song
b) assuming you haven't authorized for that account already, iTunes contacts home base and asks you for your password
c) iTunes downloads a copy of the user key from home base and stores it locally
d) however, the local keyring is also encrypted, using computer specific information like some registry keys, etc, etc.
So, when you play the song, iTunes grabs the computer specific info, uses this to build the "system key" which will decrypt the local keyring. That local keyring contains the user keys for every account that this particular computer is authorized for. Using the user key for that song, it can decrypt the song, produce straight AAC, and play the thing.
Jon's hack works because he figured out how to derive the system key from the computer specific information. Using the system key, he can decrypt iTunes keyring file. Then he grabs the now decrypted user keys, writes them off to disk in another file, and then Linux or Windows or whatever can play the songs without having to mess about. It simply grabs the user key from its new plain text keyring and can then decrypt/play the file.
The important part of all this is that he worked out how to derive the system key. That was the whole of the protection involved, really. Security through obscurity. Given the fact that iTunes can play the song without being connected to the network, once iTunes is authorized, everything required had to be on the machine somewhere. It was just figuring out what computer specific bits iTunes used to encrypt the keyring that was the real trick here.
It's also useful to understand how the iPod can play these files. The answer is simply that when you transfer the M4P's to the iPod using iTunes, iTunes decrypts the keyring using the system key, reencrypts the keyring using a system key derived from iPod specific information (such as the iPod's serial number), and copies the new keyring to the iPod. Now the iPod can do the same process, essentially.
The new RealPlayer can supposedly play M4P's too. If they have Apple's blessing, then it can either contact Apple home base to get the relevant user keys or it can decrypt iTunes's local keyring to get them. Either way would have the same effect, really.
All you need to decrypt an M4P is the user key. Now that the system key method is out in the open, direct conversion from M4P's to M4A's is possible. All the code you really need is right there in Jon's new code.
However, looking at Jon's code, it seems that there may be a legality issue. This code is very strange. It is highly confusing, to say the least, and either Jon has the oddest programming style *ever*, or he simply found the relevant portion of iTunes with a disassembler and converted the machine language directly to C, with a bit of tuning in the process. The big giant blocks of hexadecimal numbers tend to make this programmer think the latter of the two is more likely the case. If he did, in fact, disassemble and convert iTunes code into C, then he may be guilty of copyright infringement. Not that it really matters, now that the method is known, it'll be duplicated and revamped a bit, and eventually you'll see a M4P2M4A.exe program that does nothing but convert protected files to unprotected ones. It's pretty easy to do, really. I'm surprised it doesn't exist already, although the code is very hard to understand exactly WTF is going on in some parts.
Sticking this into the VideoLAN code was a pretty smart move on Jon's part though. It's easier to argue that he was trying to go for interoperability with Linux that way, instead of simply writing a converter, which probably would have been simpler. Given the fact that it needs registry keys and a whole lot of other Windows specific crud to derive the system key, this was the only real way to do it. Get the user key, save it somewhere where the Linux copy of VideoLAN could read and use it. Good planning. I guess he learned something from the CSS debacle.
Edit: Note that this isn't a total crack for it, exactly. You still need the user key to decrypt the thing, and it gets this user key from where iTunes stores it. This means that you still cannot decrypt files that your copy of iTunes is not authorized to play. But, if you were authorized to play them, you could convert them to straight AAC and thus not need to be authorized anymore.
Here's how it works:
In order to buy tunes from iTMS, you have to get an account with Apple and get an "AppleID" which is basically just an email address for the username of the account. This account gets a "user key" assigned to it that is unique to the account.
When you buy a song, a few things happen..
a) the song gets encrypted using your user key
b) it gets stuck into an M4P wrapper which, among info about the song, contains the username for your account
When you try to play a song, your copy of iTunes has to authorize itself. Authorization works like this:
a) iTunes reads the username from the song
b) assuming you haven't authorized for that account already, iTunes contacts home base and asks you for your password
c) iTunes downloads a copy of the user key from home base and stores it locally
d) however, the local keyring is also encrypted, using computer specific information like some registry keys, etc, etc.
So, when you play the song, iTunes grabs the computer specific info, uses this to build the "system key" which will decrypt the local keyring. That local keyring contains the user keys for every account that this particular computer is authorized for. Using the user key for that song, it can decrypt the song, produce straight AAC, and play the thing.
Jon's hack works because he figured out how to derive the system key from the computer specific information. Using the system key, he can decrypt iTunes keyring file. Then he grabs the now decrypted user keys, writes them off to disk in another file, and then Linux or Windows or whatever can play the songs without having to mess about. It simply grabs the user key from its new plain text keyring and can then decrypt/play the file.
The important part of all this is that he worked out how to derive the system key. That was the whole of the protection involved, really. Security through obscurity. Given the fact that iTunes can play the song without being connected to the network, once iTunes is authorized, everything required had to be on the machine somewhere. It was just figuring out what computer specific bits iTunes used to encrypt the keyring that was the real trick here.
It's also useful to understand how the iPod can play these files. The answer is simply that when you transfer the M4P's to the iPod using iTunes, iTunes decrypts the keyring using the system key, reencrypts the keyring using a system key derived from iPod specific information (such as the iPod's serial number), and copies the new keyring to the iPod. Now the iPod can do the same process, essentially.
The new RealPlayer can supposedly play M4P's too. If they have Apple's blessing, then it can either contact Apple home base to get the relevant user keys or it can decrypt iTunes's local keyring to get them. Either way would have the same effect, really.
All you need to decrypt an M4P is the user key. Now that the system key method is out in the open, direct conversion from M4P's to M4A's is possible. All the code you really need is right there in Jon's new code.
However, looking at Jon's code, it seems that there may be a legality issue. This code is very strange. It is highly confusing, to say the least, and either Jon has the oddest programming style *ever*, or he simply found the relevant portion of iTunes with a disassembler and converted the machine language directly to C, with a bit of tuning in the process. The big giant blocks of hexadecimal numbers tend to make this programmer think the latter of the two is more likely the case. If he did, in fact, disassemble and convert iTunes code into C, then he may be guilty of copyright infringement. Not that it really matters, now that the method is known, it'll be duplicated and revamped a bit, and eventually you'll see a M4P2M4A.exe program that does nothing but convert protected files to unprotected ones. It's pretty easy to do, really. I'm surprised it doesn't exist already, although the code is very hard to understand exactly WTF is going on in some parts.
Sticking this into the VideoLAN code was a pretty smart move on Jon's part though. It's easier to argue that he was trying to go for interoperability with Linux that way, instead of simply writing a converter, which probably would have been simpler. Given the fact that it needs registry keys and a whole lot of other Windows specific crud to derive the system key, this was the only real way to do it. Get the user key, save it somewhere where the Linux copy of VideoLAN could read and use it. Good planning. I guess he learned something from the CSS debacle.
Edit: Note that this isn't a total crack for it, exactly. You still need the user key to decrypt the thing, and it gets this user key from where iTunes stores it. This means that you still cannot decrypt files that your copy of iTunes is not authorized to play. But, if you were authorized to play them, you could convert them to straight AAC and thus not need to be authorized anymore.
Good article, thanks.
Is the real weakness the iPod? ie by encrypting it with a standard key, the user key can be figured out by comparing the two .m4p files. Not that it matters iTunes will not write to the iPod unless you are authorised.
Is the real weakness the iPod? ie by encrypting it with a standard key, the user key can be figured out by comparing the two .m4p files. Not that it matters iTunes will not write to the iPod unless you are authorised.
Yes, very good summary
Just one thing: the big hexadecimal blocks are called "S-boxes" and are an important part of many encryption algorithms.
It's a table of constants, used to efficiently move things around during stages of the encryption. Often there's nothing magic about these constants, but sometimes they're optimized for, I'd say, "maximum mess"
Just one thing: the big hexadecimal blocks are called "S-boxes" and are an important part of many encryption algorithms.
It's a table of constants, used to efficiently move things around during stages of the encryption. Often there's nothing magic about these constants, but sometimes they're optimized for, I'd say, "maximum mess"
QUOTE(spoon @ Jan 25 2004, 03:08 AM)
Is the real weakness the iPod? ie by encrypting it with a standard key, the user key can be figured out by comparing the two .m4p files. Not that it matters iTunes will not write to the iPod unless you are authorised.
No, you misunderstood. It's not the music file that gets reencrypted, it's the keyring.
iTunes keeps a keyring, which is basically an encrypted version of the user keys. This keyring is encrypted using the system key, which is generated from stuff that is more or less unique to the computer.
When the M4P transfers to the iPod, the M4P doesn't change in the slightest. It's bit for bit identical to the song on the hard drive. What does change is the system key. iTunes takes the keyring, decrypts it, re-encrypts it using a system key made from iPod specific information, and then writes the new keyring to the iPod. That way the iPod can decrypt its keyring, get the user key from that, and decrypt the M4P.
Well, that's what I get for not searching around enough.
[edit]Posting direct link here is not rule #9 compliant[/edit] has a command line program on there that will convert M4P's into MP4's.
Protected into unprotected, in other words. You need to be authorized to play the protected files in order to do it, but there you go. Bam.
[edit]Posting direct link here is not rule #9 compliant[/edit] has a command line program on there that will convert M4P's into MP4's.
Protected into unprotected, in other words. You need to be authorized to play the protected files in order to do it, but there you go. Bam.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.