~bohwaz/blog/

Avec de vrais morceaux de 2.0 !

Music for masses!

Allofmp3.com released a brand-new feature: free downloading of 128kbps MP3 songs, but files are encrypted and only playable in Music for masses Windows player, which is able to display ads (but there is no ads for now). I done some searching work to find how they encrypt files and using DRM.

Files differences

I downloaded a file in their .mp3x free format and bought the same in mp3 128kbps. There is only a 32 bytes size difference between files, but files are completely differents. So this is not just a header modification, seems that file is completely encrypted.

Sniffing client

So i launched the client and sniffed packets with wireshark. First it sends a GET request in HTTP when logging: 

GET http://212.5.165.110:8080/drm/interface.html?r=695307100&action=login
  &username=<strong>Mj8hJCgj</strong>&password=<strong>******</strong>&base=PPISIYFUCTEKYKDLKOQWEYAELQIOIMET HTTP/1.1

Note that for security reasons I removed my encrypted password. You can notice that both username and password are encrypted, but I don't know how (DSA?). The r argument is static, it don't change at each connection, but base changes at each new connection. Let's see what the server answers: 

Connection: close
Content-Type: text/html
Content-Length: 664
Server: DRM Player Interface Server 0.1

<?xml version="1.0" encoding="windows-1251"?>
<data>
  <drmplayer version="51" minvalidversion="51">http://files.allofmp3.com/files/musicformasses-setup.exe</drmplayer>
  <session id="<strong>1561401155</strong>">HEwBQHvGdEPjX1O0E1BPtbqYnAD6mYjxgZvFFw7FibrObIVRN/PbFBzBhiSFf6lbn2HaJ13aSvPjTn4mSboUHA==</session>
  <coverurl>http://www.alltunes.com/image.php?rnd=%RANDOM%&amp;gid=%GROUPID%&amp;aid=%ALBUMID%&amp;pic=5</coverurl>
  <orderurl>http://music.allofmp3.com/onlineenc/order-drm.shtml?r=%RANDOM%&amp;session=%SESSION%&amp;cid=%CONTENT%</orderurl>
  <balance>2.85470438774421</balance>
  <deskey>3tbDmPWCBbIG3ipiXkXKEZJcYr8HIfRwDPycnC6lNadjfy99JzEiBhwgCg==</deskey>
</data>

OK their protocol seems easy, but powerful. Just XML, encryption, and keys mechanism. No need to have some weird blobs like Window Media Player or ITunes. So in details: the server sends back a session id, and in <session> tag some encrypted keys, some kind of template to get cover url and an url to order album in better quality. It also contains my balance value (go get some round function ;) ), the last required valid version to access the service and a url to download it (for upgrading clients), and also a <deskey>.

Now let's see when the player loads a .mp3x file: 

GET http://212.5.165.110:8080/drm/interface.html?r=309666303&action=getfiledrmkey
   &DrmKeyID=<strong>1339079983</strong>&SessionID=<strong>1561401155</strong>&ContentID=<strong>1271061</strong> HTTP/1.1

DrmKeyID and ContentID don't change, and SessionID is the one sent when authentication is done. No idea where the player finds the KeyID and ContentID, there are for sure in the .mp3x file but it has to decrypt a part of it, because it isn't in plain ascii in the file. And then the server answers: 

Connection: close
Content-Type: text/html
Content-Length: 187
Server: DRM Player Interface Server 0.1

<?xml version="1.0" encoding="windows-1251"?>
<data>
  <key>i7ZTtbnDYVaCJPeeafXb7RfgeKCwbUTedmWJWdBOGq8oe315PT4aFg8zaw==</key>
  <content groupid="3327" albumid="3" songid="1"/>
</data>

So it gives a key (probably an encrypted one) to decrypt the file, and also a group id, album id and a song id. And that's all. 2 requests, 2 answers. This is the most basic and probably the most efficient DRM system. Everything is based on the obfuscation because we don't know the encryption key for all encrypted datas in http exhange between client and server. But after someone will disassemble the player code and find the key, the only protection is to change the key periodically.

With this demonstration you can see that absolutely no DRM system will secure, beause by its theory, it can't. DRMs must use obfuscation and their only one protection is to hide the crypting key and the protocol used. This is no security, this is just gaining some hours before someone cracks the key and the protocol. And this is just a question of days before someone cracks the Music4Masses key, as protocol is in plain text.

Note that AllofMP3.com is actually the greatest music download website. It allow you to buy for low prices (from 1 to 3 dollars by album), for the format of your choice (from MP3, Vorbis, FLAC, AAC, Wave, MPC, etc. at any bitrate), without any DRM. Their "music for masses" program is here to seduce new people to listen freely to medium quality music, and after making them paying the album to download it to your MP3 walkman (or iPod). Great idea imho. Give it a try.

Oh and as you can notice, there is absolutely no spyware in this software.

PS: You can follow MusicForMasses development on AOM Developers blog.

Write a comment
(optional)
(optional)
(mandatory)
            __       _                  
  ___ _ __ /_/  __ _| |_ _   _ _ __ ___ 
 / __| '__/ _ \/ _` | __| | | | '__/ _ \
| (__| | |  __/ (_| | |_| |_| | | |  __/
 \___|_|  \___|\__,_|\__|\__,_|_|  \___|
(mandatory)

URLs will create links automatically.
Allowed HTML tags: <blockquote> <cite> <pre> <code> <var> <strong> <em> <del> <ins> <kbd> <samp> <abbr>

une personne

Seeing as Visa and Mastercard just stopped Allofmp3's main revenue stream, I doubt that allofmp3 is trying to get more people to buy their music, however, I did hear (here in the US) that they are switching to an ad-based system. Could that be the reason for their free music?

Guillermito

I did the same research. Inside the music4masses exe, there is a Rinjdael (AES) symetric encryption algo (and before some fucker sends the lawyers again, you don't have to disassemble the binary to see that : the specific S-table data is very visible by anyone). So I guess one of these two keys sent by the server ("key" or "deskey") is a base64 encoded AES key (the final "==" is typical of base64), unique for each account. If this is the case, then it's over : just decrypt all the mp3x with any AES implementation and your own key that you sniffed.

Also, the fmod.dll they use is the native un-modified one. So you could alternatively patch this dll to hook the decoded mp3 stream before it is played.

I don't think they will change the key periodically, as then you would have to download again all the .mp3x.

A pity I don't have more time in my hands.

Also, I never heard of this MusicForMe tool (1st comment). Any link ?

Guillermito

Thanks. Yes, it works perfectly for me. I guess the author uses the strategy I talked about above, a fmod.dll patch. It's probably the most evident way to go, less work needed. You don't even have to play the file because I think Music4Masses decrypts the files in the playlist in memory right away, before playing them, to get the mp3 tags. At least the new 0.53 version does that. But if I remember, their first version 0.51 didn't do that, that's maybe why it doesn't work for you. You have to update to the 0.53. Nice piece of reversing, Mr anonymous author. Now, instead of trying to do the same, I will do some downloading instead :)

une personne

I figured the first part out, reread the Readme a few times. Anyway, now I'm getting a "Network Error" on connecting to the server. Is anyone else getting that?

Steve

I'm having the same problem ...

Everytime I try to login now MusicForMasses shows a message: "Network error occurred. Please try again later".

It seems that AllOfMp3 pulled the emergency brake to save their precious bandwidth ;o)

Guillermito

It still works nicely today. Although yesterday around 8 PM (US East Coast time) allofmp3 went into a "we are doing some work" mode, you couldn't order music for some time, and I also got a network error when using Music4Masses.

Josh

Since YouSendIt links die really really fast, I re-upped MusicForMe on Rapidshare. Still working great here!

Man, I'd like to know who the developer was though.

Guillermito

Josh : Maybe it's better for the developper to stay anonymous. Remember Microsoft filed a formal complain last month against the guy who posted a tool to break (or go around) the WMV 10 DRM (news.yahoo.com/s/pcworld/... ).

That's probably why almost nobody knows yet about Music4Me, and I still cannot find any reference about it except here. This kind of tool, once known, would immediately make Slashdot front page, and generate a lot of interest in the geek world. Just check on Google News the last stories about Visa and MasterCard not allowing anymore allofmp3 to use their credit cards. Or the Microsoft DRM breaking tool stories. It's big.

I would bet that a huge amount of people would love to know about Music4Me. Allofmp3 has milllions of users. The author has to be careful. I've been through a copyright violation infringement trial in France, for reversing some software, and it's not fun, lasts for years, and costs a lot of money.

BohwaZ

Yes Guillermito is right and I'm asking myself if I will let the download links here. Don't want to have any prob. This post was just to show how DRM works in theory by analysing a simple example. Maybe it's not a good idea to keep links to MusicForMe here...

Josh

That's true...

Though I would like to have some way of keeping up with the program if this isn't going to be it, as you're right.. it's not mentioned ANYWHERE online. Which is kinda cool. :)

Guillermito

On the above blog, in the comments : "Anyhow, if you guys wouldn't mind, could you use [...] instead? It has both the MusicForMasses installers (0.53, the only version that works with MusicForMe) as well as MusicForMe. Plus, its above 1MB so it'd help out my premium point gathering. Josh."

One more proof that people are fuckers who would sell their mother to get some financial advantage. Nice move, asshole. I hope the author of this tool won't suffer because of your "point gathering" whoring.

It's on Digg. Tomorrow it will be everywhere.

Bob

When Music4Masses makes the login request, the username and password are encrypted against the "base" via a simple XOR. Every byte from the base is XOR'd with a byte from the username and password. Base is randomly generated and 32 bytes long. It's always all uppercase letters.

The base is also used to encrypt the "deskey", although I do not know the encryption method yet. The encryption method is a block cipher, I just don't know which.

The deskey is used to decrypt AT LEAST the 32- extra bytes on the MP3X file. The 32-bytes are at the end of the file (always).

Those 32 bytes, I believe, lead to the contentid and drmkeyid. The contentid and drmkeyid are unique to an MP3X file.

The final key that these scripts return is encrypted with the base as well, but again I do not know what block cipher is used. Also, the base may be added to something else when encrypting these things. But I do know for sure the base is used.

NOTE! The deskey and final key are returned encoded with base64. That's pretty obvious, just base64 decode to get the real key. Then the only problem is figuring out how to decrypt them using the base.

The final key is used to decrypt the MP3 data out of the MP3X. However I do not know if it is the only key used. The deskey, although it is used to decrypt those last 32 bytes, may be used in conjunction with the final key. I do not know yet.

I'm glad someone noticed Music4Masses used AES. I've been reading my way through cipher material on Wikipedia and it's a real pain. Still it'll awhile to figure out exactly what's going on here. Are the deskey and key encrypted with AES? The BASE could indeed be used as a 256-bit key, but I haven't taken the time to find a good AES implementation to test this theory.

I've discovered all this information by playing around with the web interface scripts. Watch how deskey and key are affect when you change the base. It's not a simple XOR, and not a stream cipher, so more likely than not it's some sort of block cipher. Which? I don't know.

Not enough info? You can modify the MP3X all you want, excluding the last 32 bytes. You can remove data, add data, 0 out data, whatever. Using a hacked FMOD (my own) you can see the results of whatever data you choose. I tried setting the entire file (minus 32 bytes) to 0. The result was quite interesting. The first 32 bytes or so was random, and then there was a repeating sequence of 32 bytes. This went on for 4096 bytes (including that random first 32 bytes) and then repeated the whole thing (random 32 bytes, repeating 32 bytes). I could be wrong on the exact length of the repeating and random sections, but it did indeed repeat everything after 4096 bytes.

I am not experienced with encryption algorithms, though, so I can't say what this is characteristic of. I can say it's not a stream cipher, and as someone pointed out it is likely AES. However I looked and noticed that the S-table in M4M is different from the one included in the implementation I got off WikiPedia. At least it looked that way. I really don't have enough cipher experience to say more on that subject.

That's about all I've come up with so far. I haven't played with the 32-byte footer much. Perhaps I should modify it byte by byte seeing how it breaks/changes the interface.html calls. Although my time is probably better spent trying to figure out how deskey and key are encrypted. Once I've got that I'll at least have the key used to decrypt the MP3.

If this ever gets hacked (I hope I can do it myself. It's very educational doing this sort of thing, since I've never done it before.) it'll be interesting to create a new player. M4M is rather buggy right now and I doubt it'll get any better soon. If someone (me!) hacks the whole encryption scheme from head to toe it'll be a breeze to write up a new, better player (which includes a decode to mp3 feature, of course ;) ).

Note on FMOD hacking: I made my own fmod.dll hack. M4M gives FMOD the MP3 data, not the PCM data. Which means you get the original, unencrypted MP3 data, ready for dumping to a file. My hack does this in the Stream_Open function. Just be sure you record the custom file operation functions, since M4M sets them. And check what the open file function returns. If it returns NULL, do not try to read (crash).

The problem with the fmod.dll hack is that you don't have the original filename. M4M might be passing a struct along as the file pointer for the custom file functions. If that struct contains the filename then you could easily grab it, but I haven't taken the time to check just yet.

Problem/Feature: M4M decrypts all the files in the playlist, even when not playing. This is so it can get file info. What this means is that you just have to sit back and wait for it to decrypt every file automatically. The hacked fmod will dump each MP3. This is nice, although not as nice as a hacked decryption program would be. The problem is that M4M won't always decrypt the files in order. So not only do you not know the original names, but you don't even have any order to the output. This means you have to manually rename every file, trying to figure out what it was original called by checking filesizes.

Well, I hope that helped someone! I'll keep pecking away at M4M myself, for fun and education. If anyone wants my hacked FMOD source code I will happily provide it. I may even try to check that struct theory in later tonight.

~Bob

Bob

Hey guys! I'm back. Same Bob who made the comment above (read it ;) ).

I did some digging and figured out a way to get the ORIGINAL FILENAME for an fmod.dll hack. I didn't develop MusicForMe; this is based off my own code.

This is really simple. Just two steps:

1) Download:

rapidshare.com/files/5883...

2) Extract to your MusicForMasses folder (overwrite fmod.dll)

You're done. Anything played in M4M will now get decoded to:

original-filename.mp3

So if you play

02-paranoid_android_128_lame_cbr_ex.mp3x

you'll see the following file in a few seconds (same folder)

02-paranoid_android_128_lame_cbr_ex.mp3

It always puts the file in the same folder as the one you played. It will NOT overwrite existing files, so if for some reason you end up with a corrupted MP3 just delete it and restart M4M.

That zip includes:

fmod.dll -- My own. Redirects most calls to fmod_original.dll, intercepts Stream_Open.

fmod_original.dll -- The original, necessary to make sure M4M functions like normal. Dynamically loaded by fmod.dll

fmod_hack.h -- Header file ripped off fmod.h

main.cpp -- fmod.dll's code. All hand coded, and not very clean, sorry. But I let you have it anyway. Would be odd of me to hide information when I'm trying to unlock information ...

That is all! I hope you guys find this helpful, I know I will! I'll keep working at breaking the interface scripts and encryption itself, but until I, or someone else, does this should suffice, yes?

NOTE: I only tested my lastest improvement a little, and made a quick change before uploading, so please report any issues and I'll try to address them. I have a few checks that should prevent crashes when weird data gets sent to my code, but ya never know!

Rock on.

Guillermito

Nice work Bob. My guess is that the AES is not a modified version. Modifying an extremely well tested and analysed algorithm such as AES would be foolish and unpredictable. Modifying the S-Tables could lead to a large set of weak keys, for example.

On the other hand, your experiment by setting a whole mp3x to 0 is arguing against this. A normal strong symetric cypher does not spit out repeated sequences, even if the input is all 0's.

That's strange.

I need to read again your comment, with my tools in front of me. Many interesting things in what you said, but it's 4 AM here :)

Btw, to check the presence of AES S-Tables in a binary, you have the FindCrypt plugin if you have IDA Pro (hexblog.com/2006/01/findc... or for free, PeID with the Kanal plugin (peid.has.it/).

moi

The biggest german IT news site (Heise) just posted an article which confirms that the protection of MusicForMasses is cracked.

I think AllOfMP3 tries to fix this hole as soon as possible...

for

I'm having a problem with the Music4Masses player I can't load any songs? When trying to add a song, I browse to where I downloaded the mp3x but the folder is empty as if none of that file type exists in the folder (which it does, checkded and double checked to make sure I wasn't being retarded). Any commnets/help would be apprcieated.

Thanks

BohwaZ

Since MusicForMe could be found easily on the web now, I removed any link to it on those comments. Sorry guys but don't want to see the RIAA folks sueing me. I kept the Bob Link because he's showing the source code and his explaination is really interesting. In future just do links to your weblogs or websites please, but no direct link to files, thanks.

Tass

Hi

I'm quite interested in this all, as AllOfMP3 have recently stopped accepting payments. I'd like to use MusicForMasses, possibly even MusicForMe, but when I got to AllOfMP3, I still only see options to BUY songs. How do I get these free, encrypted MP3s?

Thanks,

snoopy

no, because:

old Build:

GET h.ttp://212.5.165.110:8080/drm/interface.html?r=695307100&action=

login&username=Mj8hJCgj&password=******&base=PPISIYFUCTEKYKDLKOQW

EYAELQIOIMET HTTP/1.1

Build 0.64:

GET h.ttp://download.allofmp3.com:8080/drm/interface.html?r=309666303&

action=exchangekeys&key=.........................== HTTP/1.1

and then:

GET h.ttp://download.allofmp3.com:8080/drm/interface.html?r=695307100&

action=login&username=******/&password=***==&SessionID=*** HTTP/1.1

n0b0dy

Mjello fellow reversers.

Figured I'd share what I've got so far..

The new version uses RSA for exchanging data back and forth.

The first GET provides the server with a public keypair, generated by the client. The format of 'key' is: base64encode(N + "#" + E);

In response the server sends a chunk of data encrypted with the public key back.

The encrypted chunk is split into an array of blocks which looks like:

struct EncryptedBlock {

WORD dwDecryptedLength;

WORD dwEncryptedLength;

BYTE dbEncryptedData[1]; // the array is dwEncryptedLength bytes long.

};

Once decrypted the chunk contains keys for encrypting the username and password, the sessionid and some other stuff.

In the next GET the server is given the username and password.

Each are taken in plaintext, encrypted using Rijndael (AES) with the keys from the previous response and converted to base64.

That's as far as I've gotten, for now.

I imagine most of what follows are variations of the above.

SKiD

These are the dll's the prog is using...

Executable modules

Base Size Entry Name File version Path

00330000 00009000 00331782 Normaliz 6.0.5441.0 (winm C:\WINDOWS\system32\Normaliz.dll

00400000 0043B000 00696A90 MusicFor C:\Programme\MusicForMasses2\MusicForMasses.exe

10000000 0000E000 10007B4B StylerHe 1, 3, 1, 1 C:\Programme\Styler\StylerHelper.dll

20000000 002D9000 xpsp2res 5.1.2600.2180 (x C:\WINDOWS\system32\xpsp2res.dll

5B0F0000 00038000 5B0F1626 uxtheme 6.00.2900.2180 ( C:\WINDOWS\system32\uxtheme.dll

5D450000 0009A000 5D4534BA COMCTL32 5.82 (xpsp.06082 C:\WINDOWS\system32\COMCTL32.dll

5DCA0000 00045000 5DCA132D iertutil 7.00.5730.11 (wi C:\WINDOWS\system32\iertutil.dll

61DC0000 0000E000 MFC42LOC 6.00.8665.0 C:\WINDOWS\system32\MFC42LOC.DLL

62E10000 00009000 62E12EAD LPK 5.1.2600.2180 (x C:\WINDOWS\system32\LPK.DLL

63000000 00014000 63002A70 SynTPFcs 7.6.5 21Aug03 C:\WINDOWS\system32\SynTPFcs.dll

66500000 0000A000 665016B9 wbsys 4, 0, 0, 0 C:\WINDOWS\system32\wbsys.dll

66600000 00017000 66604761 wbhelp 4.01 C:\test\wbhelp.dll

66710000 00059000 66747A51 hnetcfg 5.1.2600.2180 (x C:\WINDOWS\system32\hnetcfg.dll

719B0000 00040000 719B14CD mswsock 5.1.2600.2180 (x C:\WINDOWS\system32\mswsock.dll

719F0000 00008000 719F142E wshtcpip 5.1.2600.2180 (x C:\WINDOWS\System32\wshtcpip.dll

71A00000 00008000 71A01642 WS2HELP 5.1.2600.2180 (x C:\WINDOWS\system32\WS2HELP.dll

71A10000 00017000 71A11273 WS2_32 5.1.2600.2180 (x C:\WINDOWS\system32\WS2_32.dll

72C80000 00008000 72C82575 msacm32 5.1.2600.0 (xpcl C:\WINDOWS\system32\msacm32.drv

72C90000 00009000 72C943CD wdmaud 5.1.2600.2180 (x C:\WINDOWS\system32\wdmaud.drv

73D30000 000FE000 73D373C8 MFC42 6.02.4131.0 C:\WINDOWS\system32\MFC42.DLL

73E40000 00004000 73E41021 KsUser 5.3.2600.2180 (x C:\WINDOWS\system32\KsUser.dll

73E70000 0005C000 73E71788 DSOUND 5.3.2600.2180 (x C:\WINDOWS\system32\DSOUND.dll

746A0000 0004B000 746A13A5 MSCTF 5.1.2600.2180 (x C:\WINDOWS\system32\MSCTF.dll

75250000 0002E000 75269FCC msctfime 5.1.2600.2180 (x C:\WINDOWS\system32\msctfime.ime

75790000 0006B000 757CAEB6 USP10 1.0420.2600.2180 C:\WINDOWS\system32\USP10.dll

76330000 0001D000 763312C0 IMM32 5.1.2600.2180 (x C:\WINDOWS\system32\IMM32.dll

76350000 0004A000 76351AB8 comdlg32 6.00.2900.2180 ( C:\WINDOWS\system32\comdlg32.dll

76AF0000 0002E000 76AF2B69 WINMM 5.1.2600.2180 (x C:\WINDOWS\system32\WINMM.dll

76BF0000 0002E000 76BF1529 WINTRUST 5.131.2600.2180 C:\WINDOWS\system32\WINTRUST.dll

76C50000 00028000 76C5126D IMAGEHLP 5.1.2600.2180 (x C:\WINDOWS\system32\IMAGEHLP.dll

76EE0000 00027000 76EEAD1F DNSAPI 5.1.2600.2938 (x C:\WINDOWS\system32\DNSAPI.dll

76F80000 00006000 76F8142F rasadhlp 5.1.2600.2938 (x C:\WINDOWS\system32asadhlp.dll

770F0000 0008C000 770F1558 OLEAUT32 5.1.2600.2180 C:\WINDOWS\system32\OLEAUT32.DLL

771B0000 000CE000 771B1678 WININET 7.00.5730.11 (wi C:\WINDOWS\system32\WININET.dll

773A0000 00103000 773A4246 comctl_1 6.0 (xpsp.060825 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll

774B0000 0013D000 774CD0A1 ole32 5.1.2600.2726 (x C:\WINDOWS\system32\ole32.dll

77A50000 00095000 77A51642 CRYPT32 5.131.2600.2180 C:\WINDOWS\system32\CRYPT32.dll

77AF0000 00012000 77AF3399 MSASN1 5.1.2600.2180 (x C:\WINDOWS\system32\MSASN1.dll

77BA0000 00007000 77BA33BD midimap 5.1.2600.2180 (x C:\WINDOWS\system32\midimap.dll

77BB0000 00015000 77BB1292 MSACM3_1 5.1.2600.2180 (x C:\WINDOWS\system32\MSACM32.dll

77BD0000 00008000 77BD1135 VERSION 5.1.2600.2180 (x C:\WINDOWS\system32\VERSION.dll

77BE0000 00058000 77BEF2A1 msvcrt 7.0.2600.2180 (x C:\WINDOWS\system32\msvcrt.dll

77D10000 00090000 77D1F538 USER32 5.1.2600.2622 (x C:\WINDOWS\system32\USER32.dll

77DA0000 000AA000 77DA70D4 ADVAPI32 5.1.2600.2180 (x C:\WINDOWS\system32\ADVAPI32.dll

77E50000 00091000 77E56284 RPCRT4 5.1.2600.2180 (x C:\WINDOWS\system32\RPCRT4.dll

77EF0000 00047000 77EF65BA GDI32 5.1.2600.2818 (x C:\WINDOWS\system32\GDI32.dll

77F60000 00076000 77F651FB SHLWAPI 6.00.2900.2995 ( C:\WINDOWS\system32\SHLWAPI.dll

78130000 0009B000 78132329 MSVCR80 8.00.50727.163 C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb\MSVCR80.dll

7C800000 00106000 7C80B5AE kernel32 5.1.2600.2945 (x C:\WINDOWS\system32\kernel32.dll

7C910000 000B7000 7C923156 ntdll 5.1.2600.2180 (x C:\WINDOWS\system32
tdll.dll

7C9D0000 0081F000 7C9F7366 SHELL32 6.00.2900.2951 ( C:\WINDOWS\system32\SHELL32.dll

BlueBaron

@ eGG I've written a proxy program that worked perfectly but then the whole server response encryption thing happened.

@ n0b0dy My proxy program would be able to decrypt and reformat the XML response into the 0.53 alpha format before returning it to the player if I knew how the whole decryption worked. Your post #33 helps but I'm just still not there.

I've got MP3x files skipping like crazy while trying to play with the 0.64 alpla player. It worked so much better with the fmod.dll, now it looks like the prog is using DirectSound. I think the winner will be the one who hooks the correct dsound/winmm api first to dump the stream buffer to a file. I'm not a great C++ programmer so if anyone wants to take the madCodeHook www.madshi.net/madCodeHoo... for a spin I bet you'll have better luck than me.

n0b0dy

Well, it's gonna be a cat and mouse game either way.

I was actually quite supprised to find their executable completely naked, would have thought using some super leeto exe cryptor was a no brainer.

Anyway, if a DirectSound hack shows up, they start checking for hooks..

If a decrypter shows up, they change the protocol..

Im betting that a decrypter is less likely to show up any time soon, so that's where I'm putting my money :)

Anonymous

I'm assuming that the mp3x files are unique for everyone, right?

Just for comparison, though: The End from MCR's Black Parade:

Size 1808250 bytes

CRC32: 721C637F

n0b0dy

How the private/public keys are generated isn't important unless you're trying to break the system from the outside, ie. for a proxy.

But, P and Q are generated from a pool of random data collected using rand() unseeded, so the whole scheme is fully deterministic if you know the initial state of rand().

Anyway, generating your own keyset and sending off the public key works fine.

JustinCase

P and Q are passed as a hex string right? PPP...PP#QQQQ. Do you now the key length for the public RSA key? (I believe they're using 512 bits but I'm not sure)

n0b0dy

P and Q (and D) are kept private.. N is around 320 bits.

N and E are passed as base16 numbers in big-endian as follows: N..N#E..E encoded in base64.

The server uses the public keys to encrypt blocks of the http body in the responses, ie. <encrypted message>=<message>^E mod N.

They're encrypted in blocks because <message> cannot be larger than N.

I'd suggest visiting www.rsasecurity.com for more information on RSA.

some1

I'm calculating the RSA-keys with 180 bit primes. The server always replys a 1104 byte chunk. The chunk ist splitted as mentioned above. Mostly the blocks have a content like:

dwDecryptedLength = 32; (sometimes 31)

dwEncryptedLength = 48; (sometimes 44)

dbEncryptedData[1]...

Does anybody know how to decrypt 48 bytes into 32 bytes? Does anybody know, whether the decrypted data contains any plain text to verify the decryption procedure succeded?

some noob

as most of us know the musicForMe for musicForMasses 0.5x did work right, M4M need the key to decrypt and to get that it connects to allOfMp3s site couldnt you just log the key you get form the newest M4M and then make a crack that makes the old M4M 0.5x load a local file that contains the key just edit the xml you got from the new m4m and change it to

<drmplayer version="51" minvalidversion="51">

then storage it at your disk and make you old version 0.5x load that instead?

i belive most crackers around could do omthing like that right?

that way you could still dump your encrypted mp3x to real mp3 right?