A rather simple question, but I need help from experienced Visual C programmers here.

I have an app which I am reversing. It imports the MFC71U.dll library, but the file it imports is located in the executable's folder, it does not use the generic one present in *systemroot*\windows\system32.

That is fine and dandy: Now I compared the two versions of the mfc71u.dll library: different size, different date, BUT THE SAME VERSION NUMBER.

I ran the two files through the diffing suite:

The superficial analysis BDS level 1 analysis finds "no" differences,
but it is obvious that the file has been heavily modified in a more in depth analysis.

Questions: Is it usual for M$ to produce new versions of the MFC libraries without changing the version number?

Or was this file doctored by the software authors for what ever reason?

As a side, I cannot get IDA to recognize and name the exports of this modified MFC71U file even after FLIRT

a superficial glance at the output of bds says that the sizes are same and
md5 are same

but you say
different size

so it is conflicting information

well sizes could be same but matching md5 too

is md5 susceptible to such easy matchabilty ??



the information looks conflicting

Yes. What you've got is potentially an MFC app that was configured to use static linking.

Well, I swear I saw different sizes when I looked at what windows told me in the folder look, before I did the diffing, the 2003 version was 0.94 Mb and the new version was 1.23 Mb. But the diffing suite finds the same size.


But the same MD5???????

If you look further into the BDS 2 level the files HAVE changed. (while preserving the MD5???)

I cannot make heads and tails of this whole story.

Well, MD5 collisions are quite trivial to make...

http://www.cits.rub.de/MD5Collisions/

I myself am the proud owner of two little files that contain different content but the same MD5 hash, and you can all make your own in a little under an hour now

edit: I just checked out some more MD5 collision finders, and have now generated several more collisions taking only a few seconds each

Cool, it was a while since we had a good post in the crypto forum, why don't you submit a tip about these fast md5 collision finders there LLXX?

OK. I see.

Now my question is: Was this just a routine generation of MFC71U.dll variant, perhaps configured for static linking as Silver suggest, why would anyone go through the extra work of faking the version number and adjusting the MD5 of the new, updated file??

Is it necessary for the installer to recognize the library? or Is there something hidden in that library. . .


Add on: I look around in my computer and found several instances of MFC71U.dll. They fall into 2 categories: the "original" dated in March 2003, and the modified dated at some variable time later.

So perhaps M$ did release the new library, but once again, why bother adjusting the MD5?

yeah it seems every one installs thier own copies of mfc71u.dll in thier respective folders

i googled a bit to find some information

it seems the original one dated march 2003 is geniune one there doesnt seem to be any other versions

File: There are 11 versions of mfc71u.dll in our database
File Version Name: MFCDLL Shared Library - Retail Version
File Version String: 7.10.3077.0
File Version Company: Microsoft Corporation
Product Version String: 7.10.3077.0
Product Version Number: 7.10.3077.0
Product Version Name: MUSICMATCH Jukebox 1.X

File Hash: 7B93C623333F121DC9E689CCB1B7A733
File HashType: MD5
File Size: 1,023.00 KB (1,047,552 Bytes)
File Modified Time: 3/19/2003 1:12:12 AM
Date Added: 1/26/2007 2:20:04 PM


http://www.programchecker.com/file/8133.aspx

but i noticed a update that relates to mfc

Microsoft Security Bulletin MS07-012
Vulnerability in Microsoft MFC Could Allow Remote Code Execution (924667)
Published: February 13, 2007 | Updated: April 26, 2007

may be your different dll is hotpatched and md5 collided by coincidence

http://support.microsoft.com/kb/933339/ describes version not updated problem

LOL.

Even though its known how to create two files with the same md5 there is no way to create a file so it has a specific md5. And the chance that it's coincidence is smaller than the chance of winning three lotteries on the same day.

I thought of doing that, but that was before I found out there were new faster collision generators available. Will do.

I just searched my hard drive and found only one mfc71u.dll, and it has the same 7b93c6... MD5 as noted above. Here's some SHA hashes of mine:

SHA1: 68b25cb19dee136d4f31809bc61bf2adca0cb41c
SHA256: 0c58f682e1b3af064963dd616e80609006e9317f2fcb0f3a51ed32fef13b1081
SHA512: 03474624f566fae1e21f369882a2f164ba2990c01e45399b48e4708fe3dc7d228fa05f678a57658b28f62cb57d237e76e641 66381628e09cc768f5a0b9194ef3

It's probabalistic, so there's no guarantee it can't happen. More unlikely events have occurred...and now that MD5 collisions are nearly trivial to generate, making a file with a specific hash (preimage attack) is probably not far off. There is a lot of cryptographic research that we don't know about