QTFairUse?

[MacRumors]

A Register.co.uk article reports that the author of DeCSS has written a small command line Windows utility (QTFairUse) which "will dump the output of a QuickTime stream to a file". The Quicktime stream in question are AAC files and The Register article implies that it is able to circumvent Apple's DRM.

According to the QTFairUse README:


Usage:

Open and play a MPEG4 AAC file in QuickTime Player. The raw AAC data will be written to Desktop/QTFairUse.aac


The application clearly piggybacks off of Apple's Quicktime player and patches the "quicktimempeg4.qtx" file of Windows' Quicktime. It then outputs this "raw AAC data" to a file while the original AAC file plays under Quicktime. The proposed theory is that the application intercepts the Decrypted AAC files from Quicktime after authorization has taken place, and saves out the resultant decrypted (de-DRM'd) AAC data. (Note: the user of this software must be authorized to play the protected song).

Based on limited testing from one user with Quicktime 6.4 under Windows... the application does create ".aac" files when Protected AAC and Unprotected AAC files are played through Quicktime. These output files, however, are unplayable in their raw form. The reason for this is that these files represents the true "raw" AAC data that is passed through to Quicktime to play. All header information has been removed. To create playable files, a further packaging of the files is required to add the appropriate MPEG headers. As a result, testing of the files is limited, but we suspect the application likely does work as suggested -- stripping DRM from your protected AAC files (though is of limited use in its current form).



In any case, this is the first public attempt at breaking Apple's Digital Rights Management format. The potential for abuse and concern for an application such as this is greater than simple "stream rippers" in that this would introduce lossless ("perfect") copies of protected files

 

[Freg3000]

Just to clarify, is this "hack" only available on Windows machines? Or can I try it on my Mac? If it is, then I might test it out.

 

[arn]

Originally posted by Freg3000
Just to clarify, is this "hack" only available on Windows machines? Or can I try it on my Mac? If it is, then I might test it out.

It's for Windows.

arn

 

[LimeLite]

I really think people should not try to hack the DRM, because if they do, the record companies will be pissed and Apple will have to make a more strict DRM to appease them, thus ruining it for the rest of us.

 

[trog]

I don't see the point.

I'm sorry, I'm not testing out the utility, I don't own anything that runs windows.

Just to stick my nose in though (delete my post if its worthless, Arn), I don't see the point. There are a ton of ways to strip the DRM already that don't requre stream ripping. Virtually any application that can convert audio formats and has access to the Quicktime engine can strip the DRM by converting it to AIFF, WAV, mp3, etc.

The important thing is that in every case you are required to have permission (from iTunes) to PLAY the song to convert it, rip it, etc. This utility would be no different because, as it states, it would "dump the output of a Quicktime stream".

So. If this works, why is it important, it isn't doing anything novel?

And if it doesn't work, what does that prove, that Apple's DRM is tough to crack?

What am I missing here that is interesting?

 

[arn]

Re: I don't see the point.

Originally posted by trog
Virtually any application that can convert audio formats and has access to the Quicktime engine can strip the DRM by converting it to AIFF, WAV, mp3, etc.
.......
What am I missing here that is interesting?

DRM AAC -> AIFF -> ACC is lossy and uninteresting. You can burn your CD and rerip it. There. no more DRM, but you lose some quality.

DRM AAC -> AAC - if it simply decrypts then it is NOT lossy. And is interesting.

arn

 

[trog]

Re: Re: I don't see the point.

Ahh I see, thanks. So the question then is whether the utility has to "re-compress" the file to AAC or not. All stream-rippers would essentially go AAC»AIFF»AAC and lose quality. Yup, I see why this would be interesting.

My guess is it wouldn't (yes, I'm jumping to conclusions, sorry), because from reading about Apple's DRM there isn't anything encoded into the song per se, there is only a lock on whether the song will play...

Hope someone can try this and see. Would there be a way to tell if the song has been re-encoded? Looking at the waveforms perhaps?

 

[baddog]

Well i don't run Windows, but looking at the code (barely 200 lines), it's obvious that it's not doing much. It's just a patch that's modifying the binary, and I'm guessing that at some point _after_ QT has decrypted the song, it's making it run some alternate code to make QT spit the song to a file rather than to the sound device (just guessing, but I'm probably right). This new code is definitely not complex enough (100 bytes!!) to do anything intricate like encode AAC or decrypt M4P.

This would only work on one specific version of QT and Apple can easily release a new version with slightly more obfuscated code to make it much harder to repeat the exploit.

Still, it's great to know that when Apple stops supporting .m4p in 10 years (no seriously), leaving us with no where to play them, that I can go back an buy a 10-year old winpc for 5$ and decrypt my iTMS music

 

[zaphon]

Based on the source code, it appears it's two items.

1. QTFairUse.exe
2. November.DLL

QTFairUse.exe patches up QuickTimeMPEG4.qtx to call November.DLL, and November.DLL just purely dumps a blob of memory to disk (to the file Desktop\QTFairUse.aac to be exact)

So my guess is the following.

Quicktime opens an encrypted (DRM'd) aac file and un-encrypts it into ram. This patch causes it to than call November.DLL to write this un-encrypted version out to disk. Than it plays as normal.

That's my $0.02 review of it.

Now if I had a windows box, I'd try it out. But the best I could do is Virtual PC, and well screw that.

 

[arn]

yep... sounds likely that it just dumps post-decrypted, pre-decoded AAC.

someone's testing it... we'll see how it works.

arn

 

[Nermal]

I don't have any protected AACs to try it with, but I find the "build" file interesting. The first line is "#!/bin/sh" which tells a Unix system to use the "sh" shell. But if it's a Windows app, why does it have this Unix command?

Edit: I just looked at MinGW, and see that it's a small GNU implementation on Windows. That explains the line.

 

[Exponent]

Trog:

Just to stick my nose in though (delete my post if its worthless, Arn), I don't see the point. There are a ton of ways to strip the DRM already that don't requre stream ripping. Virtually any application that can convert audio formats and has access to the Quicktime engine can strip the DRM by converting it to AIFF, WAV, mp3, etc.

Sorry Trog, this isn't true. I'm writing code that uses QuickTime translation RIGHT NOW (as in I have had Project Builder and now XCode open and running 24/7 the past 3 months), and I can attest that the QuickTime engine available to developers can NOT read the music data of DRM files.

You can go use WireTap if you want a post-decoded & decompressed stream. But you can't read the file and get the individual samples, nor call a translator that does this.

(Of course, I could be wrong. I wish I was wrong, as I'm currently locked out of DRM-AAC files. If it wasn't for the legal headaches, I'd be inclined to snag this source - I have a legit use for decoding these files.)

 

[arn]

Originally posted by Exponent
Sorry Trog, this isn't true. I'm writing code that uses QuickTime translation RIGHT NOW (as in I have had Project Builder and now XCode open and running 24/7 the past 3 months), and I can attest that the QuickTime engine available to developers can NOT read the music data of DRM files.

Toast 5.0 could do it.

It could load protected AACs and save them out as AIFF

arn

 

[iMeowbot]

Originally posted by zaphon
Quicktime opens an encrypted (DRM'd) aac file and un-encrypts it into ram.

Yep, that's the flaw that's being exploited. That hole might have been usefully avoided if the decryption and decoding were more tightly integrated, but that would complicate code maintenance and introduce performance headaches (extra buffering could instead have been added after the AAC->PCM step, but that could add latency and would take lots more memory).

I'm sure that this development was anticipated, as suggested by the earlier ConfirMedia/Verance mumblings.

[Edit: should probably explain the implications of that. The watermarking would enable Apple or the labels to identify the source of cracked iTMS files. If the watermarking is done on Apple's servers, this might work out for them. If it's instead implemented on the client side in QT or iTunes in the playback or burning engines, chances are good that yet another small patch could be used to remove it.]

 

[Exponent]

Toast 5.0 could do it.

It could load protected AACs and save them out as AIFF

I suspect it could do it by internally making the OS think there's a CD drive, as writing out to a CD is something within the allowances of FairPlay.

Or they could be pulling a "WireTap" like-trick and creating a virtual sound output device and capturing the post-decode, post decompress stream.

Or as large and important developers, they have access to APIs that small fries like me don't have. Or they just know the right people in Apple to talk to.

All I know is that when code written for the QuickTime Sound Converter engine reports back an error when handed a DRM file. If anyone knows the way to read these, please let me know!

 

[mj_1903]

Apple could quite easily do a simple encryption in RAM using XOR and a unique key which would make it 20x harder to simple do a dump, but I suspect they already are doing something like that.

XOR by the way uses almost no CPU to decrypt.

Good news on the dud file arn.

 

[mj_1903]

Originally posted by Exponent
Trog:

Sorry Trog, this isn't true. I'm writing code that uses QuickTime translation RIGHT NOW (as in I have had Project Builder and now XCode open and running 24/7 the past 3 months), and I can attest that the QuickTime engine available to developers can NOT read the music data of DRM files.

NSMovieView can happily play DRM files and subclassing it could provide a means of recording the data into AIFF or even back into AAC.

Edit: Well, if you really wanted to get complicated you could use the obj-c runtime to get the data out before and after encryption, although I never would want to.

 

[arn]

Testing Results

Ok, based on limited testing from one user (one configuration)

Protected AAC -> aac (unplayable)
Unprotected AAC -> aac (unplayable)

HOWEVER... this actually makes sense.

The app presumably pulls data as a stream while Quicktime plays it. Quicktime never "plays" the MPEG Header... so these files are headerless. It's truly the raw AAC data.

If someone packaged these files up, I suspect they will work.

arn

 

[dangil]

aac files unreadable ? NOT !

this program outputs raw AAC data..

this means it's not wraped in a mp4 container

m4a files are aac data wrapped on mpeg-4 files.. like divx is wrapped in .avi files, or Vorbis files are wrapped in Ogg files...

to use this aac dump, use programs like MPEG4UI to mux the aac into a mp4 container

you should copy a m4a file's track ID so itunes and quicktime can understand and decode it properly...

do some research on mp4 and you will find out ...

 

[arn]

Re: aac files unreadable ? NOT !

Originally posted by dangil
this program outputs raw AAC data..

this means it's not wraped in a mp4 container

Yep, this is correct...

Unprotected AAC => aac, plus headers works.

Can't test it on an Protected AAC => aac w/ headers because we don't know how to actually generate the proper headers. (The person in the working example above simply copied the headers from the previous unprotected AAC)

arn

 

[Sol]

Thieves

Some people go so far out of their way to steal music. Apple should use a watermark technique to be able to track down the people who purchased the original protected AAC files that will go floating around the Net because of applications like this.

 

[sparkleytone]

Reasons why this might not matter.

As much as this could potentially be a blow to the iTMS, there are a few things that may make it meaningless.

I have a hard time believing that people are going to be anywhere near as willing to pirate songs that they have already bought legally thru the iTMS. Music downloaded by people from the online store is a much more personal purchase than a CD at Best Buy that someone may have bought for one or two songs. I don't think people will be as willing to share freely the music that they picked out and bought online.

I also believe that a big part of the mp3 piracy problem stems from people on the inside. People in the industry are ripping and sharing CDs they never had to pay for, such as promotional prerelease albums. This is a HUGE problem for the record industry. This is a nonfactor with the iTMS.

The bottom line here is that someone has to buy the song before it can be cracked. This is not the case in the CD-ripping scene.

Thoughts?

 

[SeaFox]

Okay, I was gonna download the gnu parts and try it. But I just relaized I downloaded the release candidate version of MSYS instead of the current stable release, and I noticed that Mingw is fourteen megs. So I don't care anymore.

But anyway, anyone who did download the DRM cracker, did you notice this in the list of software?

FreeMe - decrypt MS DRM restricted content

Why the heck are we making such a big deal about the iTunes crack if there's a M$ DRM crack, all the other services use WMA so it would be a lot more damning to develop a crack for it.

 

[greenstork]

Well this was bound to happen sooner or later. I'm sure the RIAA is keeping a close eye on this one. Currently, it seems difficult enough to not worry the record industry but as soon as someone automates this process, watch out.

The good news is that Apple seems to have established sufficient clout in the industry. You just don't cripple the Time Magazine invention of the year.

As long as the process of stripping the DRM remains this tricky, I don't think Windows users will see many changes. I would imagine though, if things get easier, that Apple will circle the wagons (i.e. rewrite QT code, watermark songs, etc.)

 

[ZildjianKX]

I hate digital rights management... now that this hack is out, I might actually buy some music so I won't have to deal with the hassle. Now if they would up the bit rate, I'd be a happy customer.

The moral of the story... any human made protection can be broken...