Log in

View Full Version : MP3 Dumping.


Innocent
September 21st, 2004, 15:24
I hope someone can help me with this. I was wondering if there was a way to dump an mp3 file from memory? Does a software player store the file somewhere in memory? (or at least part of it because it has to buffer)

I am wondering because I am working on elicense DRM.

dELTA
September 21st, 2004, 17:01
Most players only buffer a small part of the file in a circular buffer, but some of them have options regarding the size of this buffer, which could make it possible to make it buffer the entire file I guess. Otherwise you could always hook the buffering function and make it dump data progressively too I guess.

But on the other hand, is there really any DRM system that's stupid enough to only put an encryption envelope around the whole file, and then decrypt pure sound data in memory? The ones I've seen have been much more "intertwined" than that...

Innocent
September 21st, 2004, 18:14
Quote:
But on the other hand, is there really any DRM system that's stupid enough to only put an encryption envelope around the whole file, and then decrypt pure sound data in memory? The ones I've seen have been much more "intertwined" than that...


Actually, I think there is. It is called eLicense. Getting an elicense DRM'd file unpacked is as easy as any program that is packed with elicense. While on the subject... wouldn't there be a way to capture the data somehow as it gets sent to the player anyway? (in the case of other DRM protections like M$ DRM) I mean, the player needs to be passed unencrypted data so can't we find where it is passed to the player and progressively dump it?



The only workaround I can see would be to have a player that "reads" encrypted files. In this case the player would have it's own encryption system. Here is an example:

Say M$ created a new file format. Call it .wme for windows media encrypted (file). Only windows media player can play it. This system would consist of 2 layers of encryption:

1. Take an existing mp3 file and encrypt it in the new .wme standard. The file is now encrypted in a scheme that only windows media player can handle.

Suppose the original mp3 had the data: 10D3D092BD34AA99

Now that it is in .wme it looks like: 2659274501374855

Have the .wme extension trigger the wme reading mode:

Now when playing the file media player sees: 2659274501374855 but recognizes that it is really 10D3D092BD34AA99 and plays that. I suppose this could be done through simple substitution. i.e. the player sees 26h (the first byte of the example string) and knows that it really means 10h by using a substitution table. The key to this is that the "real" bytes are never passed in a buffer so someone can dump it.

Expanding on this: now that you have a working substitution table why not have say, 256 different ones and include which one you want media player to use for this file. (the one that the file is encoded for)

2. Now that you have working .wme files, add the DRM layer. A person buys and downloads the .wme, receives the license key, and can now play the file.
The DRM layer is decrypted on the fly and media player never puts the original bytes of the file in memory.


Call me crazy or whatever. I don't know if all this would work or not; it was just my crazy tangent to your post dELTA.

dELTA
September 21st, 2004, 19:01
Your description/idea is a simplified description of what I was referring to, yes.

And yes, the unencrypted sound data can always theoretically be captured. The depth of the decryption code inside the decorder loop will determine how tedious it will be.

And you could of course always create a fake sound driver and capture the raw digital output from the player too, but in that case you would have to re-encode the sound data if you wanted it in the original compressed format, which might lead to slight degradation of quality, i.e. this method is not completely clean unless the original sound data source is using non-destructive compression.

Silver
September 22nd, 2004, 07:14
I was going to point out exactly what you said at the end of your post, Delta. As long as it's possible for people to write drivers (video, audio and whatever else), DRM protection is only as difficult as it is to re-encode the data to something. It's the same principle as the WinAMP diskwriter plugin...

Innocent
September 22nd, 2004, 15:10
Quote:
As long as it's possible for people to write drivers (video, audio and whatever else)


Yes but what about people that don't know how to write drivers like me Since the protection I am working on just has the raw data in a buffer how can I progressively dump it? Hopefully there is a not to complex way of doing this...

dELTA
September 22nd, 2004, 15:37
Yes, as I said above in my first post in this thread, simply hook the function that fills the buffer. Should be trivial once you have pinpointed the correct function/location.

evlncrn8
September 22nd, 2004, 16:01
alternatively be lazy, get a male to male din cable, connect speaker out to line in on the soundcard, start an mp3 recording program (tons of em on download.com or shareware places), tell the 'drm' player to play the encrypted file.. job done.. no need to reverse anything, except your lazy ass into a chair.. heh

Innocent
September 22nd, 2004, 17:43
Well, I found where the file is being buffered. I am certainly not on dELTA's level so I don't really know how to proceed Man, also I am having trouble writing my first keygen. I have reversed a serial algo and I know exactly what I want to do but I don't know how to code a dialog box app.

dELTA
September 22nd, 2004, 18:34
Hehe, for the keygen: Use Delphi, it rules (yes, there actually is no real reason to be anal about it and do everything in pure assembler, all things have their place ).

For the mp3 dumper: Read up on coding hooks. Then hook the buffering code right after it has copied the data to the buffer. In your hook code, simply dump this new data from the buffer to a file with a couple of simple API calls.

And remember, programming skills are very important both for the understanding of code and the manipulation of it, so if you want to be able to do any cool stuff at all, take my advice and spend some time becoming a decent programmer first, believe me, you won't regret it.

Keep up the good work anyway!

Silver
September 23rd, 2004, 06:09
ew, he just recommended Delphi.... Someone get that guy a doctor.

Real men use C/C++, and if you want to be truly elite, use MFC or WTL too

Fake51
September 23rd, 2004, 07:36
Quote:
[Originally Posted by Silver]
Real men use C/C++, and if you want to be truly elite, use MFC or WTL too


Real men eat coffee for breakfast, then hexcode their resources into their binaries while bitching about it and m$ for ages, only to end up copypasting their ripped algos into some ageold asm-source they had lying around.

Just thought I'd make my obligatory "once every third month"-remark.
Fake

dELTA
September 23rd, 2004, 09:51
Quote:
ew, he just recommended Delphi.... Someone get that guy a doctor. Real men use C/C++,
I assume this would be the same "real men" who sit and try to get their MFC crap working (after already having given up after three weeks of attempts getting the GUI to work in pure MASM, hoping that noone would notice what a sissy they were to switch to Visual Studio in the first place) while the smart guys already got the program (and the next eight projects) done and went to lunch?

I like C/C++ better than Object Pascal in most aspects too, but since noone seems to have put together an equally beautiful and efficient tool as Delphi based on C/C++, I'm sticking to Delphi until someone does. It has the perfect balance between simplicity and power, and also access to all the low-level power you can get in any other language/development platform, as soon as you need it.

Silver
September 23rd, 2004, 10:20
Ouch, handbags at the ready, ladies . For my part, I'm a die hard MFC coder. IMO MFC is excellent if you take the time to learn the concepts and quirks up front.

Delta, have you tried Borland's VCL? I know some C++ coders that swear by it. Never used it for win32 myself, but when I tried Kylix C++ under SuSE I thought it was pretty good...

disavowed
September 23rd, 2004, 10:28
why not just use total recorder (http://www.highcriteria.com/productfr_tr.htm ("http://www.highcriteria.com/productfr_tr.htm"))? it records the data that gets sent to your sound card.

dELTA
September 23rd, 2004, 10:37
Silver:
Yes, the VCL is actually shared between Delphi and C++ Builder (and even originally derived from Delphi, since it came first), which is an even bigger testimony to how similar the two languages really are, much more so than most prestige blind C++ coders would like to admit anyway. I like C++ Builder too, but for some reason they still added some stuff that made it a bit more inconvenient to use than Delphi in several aspects, which is why I still stuck with Delphi when C++ Builder was released. But I agree, C++ Builder is a very good product indeed. And finally, no matter how much "time you have taken to learn the concepts and quirks of MFC", I bet that you can't beat an equally trained Delphi coder in speed and efficiency (of development that is) for equal results on 95% of all projects. *slowly putting down handbag*

disavowed:
Yes, TotalRecorder use the driver technique mentioned earlier, and they were actually the first ones to use it in a commercial product as far as I know. But as also mentioned above, you have to reencode the data in this case, which is not completely "clean".