[WouterL]

Hi,

I've managed to decrypt the map.dat file for the custom emoticons in VB.
The result is a tag like this:

<msnobj Creator="xxx@xxx.xxx" Size="5684" Type="2" Location="TFRDD.dat" Friendly="AAA=" SHA1D="Poxkp25S0dmfLOtkM4U2krbFoT4=" SHA1C="uF4G/233aTsNxaTuPJbIKPNRxkE="/>

Decrypting TFRDD.dat also works fine. In this file there is a tag for each custom emoticon like this one:

(webc) webcam <msnobj Creator="xxx@xxx.xxx" Size="258" Type="2" Location="TFR51.dat" Friendly="AAA=" SHA1D="o0YBBk9i6bxFd4WK4awWnnZsdqQ=" SHA1C="Frw1WNunppuDunQ+DvR/Xj8bak0="/>

But when I try to encrypt map.dat again it goes wrong. The byte size is equal to the original file (612 bytes in my case, shouldn't be much smaller or bigger by other MSN users).
The contents is not the same as the original, but that is normal because each time you encrypt the same file it is different (Decrypting my encrypted file again results in the same contents as the original). When I put the encrypted map.dat in the CustomEmoticons directory MSN will fail to open it. The custom emoticon screen in MSN stays empty.

Has anyone succeeded in encrypting the map.dat file again? Or does anyone know what is going wrong?

Other question:
Listcache.dat is also decryptable. But when I view the results it looks like crap. Some parts are viseble. Like all the email addresses in my contact list. But for the rest it looks like binary stuff to me... Does anyone has an idea what kind of file this could be?

Wouter

[Daniel]

In about october last year i made a display picture and custom emoticon manager, and i came across the same problems too. my conclusion is that, messenger checks the hashes, if they do not match those in the ones it read from the file earlier, it just resets the file to what its got in memory (seen that error "Your display pictures cannot be used, please create new ones"?), so basicly, the dat files are just storage, its not a realtime thing, I THINK the only way around this would be to modifiy it when messenger isnt running, it wouldnt know what hit it.

As for the list cache, its in some format, im not sure what, the first few bytes are the same as a word document, would probably just need to see what librarys/function messenger accesses when reading it.

[WouterL]

I think it's indeed a realtime thing like the listcache.dat file. But in my case I don't get the error "Your display pictures cannot be used, please create new ones". The manage emoticons screen in MSN stays empty without saying anything when I restart MSN. When I put the old map.dat back it works fine again and my emoticons are back. I also tried to use all possible methods for the 4 CryptProtectData function flags but without luck!
And I've just tested it to encrypt the temp file listed in the map.dat file at the same time as the map.dat file but that also wouldn't work.

In MS docs I found that the CryptUnProtectData function only works when you have the same privileges as the encryptor. That is true in my case. I have only one account here: Administrator.
MS doesn't say anything about the the function cannot decrypt when it is encrypted in an other application. So that can't be the cause of the problem.

There must be a way to get it working properly... To bad that I can't find any documentation on this subject on the internet. I'll try to find the solution. And when I have it I'll post it here with the source..

Wouter

[Daniel]

WouterL, on Feb 10 2004, 02:07 PM, said:

I think it's indeed a realtime thing like the listcache.dat file.

The list cache isnt realtime... its only updated when you sign out..

But anyway, you might be having another problem, like the couple of extra bytes at the start of the file, ive forgotten what the story is, but the file should be something like

03 04 ENCRYPTED DATA....

The 2 or 3 bytes at the start of the file might be some version info, im not sure...

[WouterL]

The first 2 bytes (03 04) are indeed version info or something. I decrypt the data without them. And all goes well. When you try to decrypt with these 2 bytes it goes wrong. When I encrypt the file again I put these 2 bytes in front so that the size of my encrypted file is equal to the one msn encrypted (612 bytes as mentioned in my first post). These 2 bytes are also used for the listcache.dat file and your MSN .NET password in the registry.

I've just tested the realtime issue... When I encrypt the files all goes well and the emoticons are still there. After I restarted MSN the emoticons are gone. So MSN keeps them in memory the entire time it is loaded. Map.dat is a caching file like listcache.dat. But I am sure that the contents of map.dat is not on the server like listcache.dat. Because if I use MSN on an other computer I have no custom emoticons. And if you remove map.dat the emoticons are gone for ever...

[Snakerboy]

Map.dat is kept locally, i assume because if users had large display pictures it would cost time money and bandwith tranfering them over.

Could it have somthing to do with the time the files are created? could Messenger be checking when it was unloaded and when the files were changed? Just a thought.

[WouterL]

I also thought about the time stamp possibility...
As said in my first post. The file looks different each time I encrypt it so there could be some kind of time stamp or whatever, or another possibility:
The CryptProtectData function uses keys for encryption. These keys are stored in the registry. Maybee MSN knows the key the file was encrypted with.
And if it is encrypted with another key it won't work. But there is no possibility to get the key used with the CryptProtectData function.

So maybe MSN saves it in the registry or something. But I can't verify that.
I haven't discovered a registry key that could contain such information.
Maybe someone else has?

[PsychoMark]

I'm stuck on the same issue now. I first tried recalculating all SHA1 hashes, updating the sizes, etc. All turned out to be working perfectly (comparing the hashes produced by MSN versus mine), so I was thinking about the encryption too. A test which does nothing but decrypt the map.dat then immediately re-encrypt it fails. I do the skipping of the first 2 bytes, and writing them back afterwards. Also used the correct email address for the encryption. In fact, if I run my decryption function again on the file generated by me, it decrypts it just fine and I can see the <msnobj> again :blink:

CryptProtectData generates a key based on the user's credentials, so if that's the function used by Messenger (gonna try to find out with a bit of reverse engineering) then it should work just fine. Even checked to see if they included a description in the encryption, which according to my findings they didn't.

The next thought that came to mind was Messenger keeps another hash somewhere, perhaps in the registry. Testing showed that wasn't the case. The test was simple: first I backed up my UserTile folder, then added a new display picture. This would cause map.dat and the index file to change. I then placed the backup back, overwriting the map.dat. Messenger showed the old list just fine, which indicates to me the only problem here is the way the file is encrypted...


So far no solution either :(

[WouterL]

Decrypting my own encrypted map.dat file again works also fine here... For msgplus users: You can customize the emoticons when you press ( in a message window. While msn can't read my map.dat msgplus can??? I've tried to contact patchou with the question of how he decrypts the files, but until now he did not answer :(

I still think it has something to do with the flags of the CryptProtectData function.
There are more flags then Microsoft describes on MSDN. Check this sample to see more flags http://www.mvps.org/...o/protect.shtml

[PsychoMark]

Looked at the code in the link you gave, tried CRYPTPROTECT_CRED_SYNC, got very excited and thought we had cracked this, but I was wrong :(. The reason: CryptProtectData with that flag does return True, but the data is empty... my file-writing code after that checked the length, therefore skipped overwriting the map file...

If Patchou decrypts the files using the same method we do it's easy enough to get the PNGs. That's not the issue in this whole thing, the problem is that Messenger (and only Messenger it seems) fails after reencrypting them... very strange...

[PsychoMark]

Managed to build a proxy for crypt32.dll and have Messenger load it. It's a bit of a pain to find out which exports are needed, but I managed to get 3 calls trapped so far (which appear to be the encryption for the auto-login password) before it crashed. Those calls (to both ProtectData and UnprotectData) all show a flags value of 0...

More research is to come...