Solved Cannot repair member file [l:12{6}]"mf.dll" of Microsoft-Windows-MediaFoundation

[tom982]

Here you go

https://dl.dropbox.com/u/16537616/imageres.dll

 

[Cytherian]

Hi Tom, when you say RTM disc, do you mean an original install disc of Vista? That would be correct, as I installed from a set of discs that I own. So, it would appear to be a valid file, but maybe there was a newer one that SFC is expecting based on the hash code it has? Is there some way to do a look-up somewhere of what version the hash code resolves to?

EDIT: Just saw your post (we hit submit within the same minute). That is the file I have on my hard drive. I did a direct bit comparison and they are the same. So, SFC is somehow expecting a different one then. Maybe what happened was after I modified it, other updates must have tried to replace it, but then the system copied over my modified one that I'd replaced in the stores. Then I wouldn't have ever seen it. Does that sound plausible?

 

[Cytherian]

I think I may have figured out why SFC is complaining. When I went to the imageres.dll file in the System32 folder and checked properties, I clicked on the Previous Versions tab. It showed a shadow copy of a slightly different size. Same program version though (6.0.6000.16386). Instead of being 15.0 MB (15,821,312 bytes), it shows as 14.4 MB (15,181,824 bytes). That's the one I'd modified. I wonder if SFC is checking this file as a reference...

 

[tom982]

Hi Tom, when you say RTM disc, do you mean an original install disc of Vista? That would be correct, as I installed from a set of discs that I own. So, it would appear to be a valid file, but maybe there was a newer one that SFC is expecting based on the hash code it has? Is there some way to do a look-up somewhere of what version the hash code resolves to?

EDIT: Just saw your post (we hit submit within the same minute). That is the file I have on my hard drive. I did a direct bit comparison and they are the same. So, SFC is somehow expecting a different one then. Maybe what happened was after I modified it, other updates must have tried to replace it, but then the system copied over my modified one that I'd replaced in the stores. Then I wouldn't have ever seen it. Does that sound plausible?

Yeah, it's from the original disc. You'd be able to find that exact file on a SP1/2 disc as well because as far as I can tell, it's never been updated since Vista was released. I'm not surprised though, there's not many things that can be exploited with a bunch of icons! Your theory would sound plausible if the file had been updated

Right, I think I've got to the bottom of this. Basically, you've replaced the wrong files and SFC doesn't like you for it. This file has never been updated, so an update isn't to blame here.

Here are the hashes taken from install.wim, of the locations that SystemLook found on your computer:

C:\Windows\System32\imageres.dll
Your file: 111C47816F39A91EAAA18DA0A54E8E63
My file: EDC41901878A99EA11765F5536CCAE67

C:\Windows\SysWOW64\imageres.dll
Your file: 111C47816F39A91EAAA18DA0A54E8E63
My file: 111C47816F39A91EAAA18DA0A54E8E63

C:\Windows\winsxs\amd64_microsoft-windows-imageres_31bf3856ad364e35_6.0.6000.16386_none_36a57cbab3586699\imageres.dll
Your file: 111C47816F39A91EAAA18DA0A54E8E63
My file: EDC41901878A99EA11765F5536CCAE67

C:\Windows\winsxs\x86_microsoft-windows-imageres_31bf3856ad364e35_6.0.6000.16386_none_da86e136fafaf563\imageres.dll
Your file: 111C47816F39A91EAAA18DA0A54E8E63
My file: 111C47816F39A91EAAA18DA0A54E8E63

It looks like that when you came to restore the files, you used the x86 file for every replacement - which is why SFC is kicking up a fuss. The ones in red need replacing with the one that I put in my Dropbox for you a few posts back

I think I may have figured out why SFC is complaining. When I went to the imageres.dll file in the System32 folder and checked properties, I clicked on the Previous Versions tab. It showed a shadow copy of a slightly different size. Same program version though (6.0.6000.16386). Instead of being 15.0 MB (15,821,312 bytes), it shows as 14.4 MB (15,181,824 bytes). That's the one I'd modified. I wonder if SFC is checking this file as a reference...

The size inconsistency is probably from the custom file being cached by VSS, but I doubt SFC would check this, I think it sticks to VSS.



On a completely unrelated note, in the process of doing this I managed to make Windows Explorer lock up and I tried to kill it using Task Manager. Didn't work, so I used task manager to launch command prompt and tried a taskkill command. Didn't work either. I then thought I'd see what the system account thought of it so I used psexec -i -s -d cmd.exe to elevate me to launch a command prompt with system privileges (higher than the hidden admin). It launched perfectly, and killed the process, but when I tried to launch it again, just by doing the command explorer.exe, it completely froze and after a few minutes, said it was configuring my theme settings and personalising desktop settings etc. I was then put into a really strange environment where I was logged into the System account:

All of my Desktop files and shortcuts had disappeared, but when they were there when I clicked on Desktop in Windows Explorer.

It was so strange and I'm still not entirely sure how I managed to actually log into the System account!

Tom

 

[Cytherian]

Hey Tom, thanks so much for the info and... I definitely get it now. I'm a little embarrassed that I didn't see it before. I made the "brash" assumption that since my laptop is running an Intel processor, the AMD files would be ignored. So rather than bothering to make two updates, one for Intel and the other for AMD, I just copied the Intel version of imageres.dll everywhere the file existed. It is after all the same size. Well, I guess Microsoft wants to be prepared for all contingencies, even though one cannot install an AMD chip on this laptop motherboard.

Anyway, getting on to the repair... You indicate the version for AMD as the one that needs to be in C:\Windows\System32\imageres.dll. But my CPU is Intel. Shouldn't it be the x86 version? What's even more strange to me is that the file size is identical. Is it possible that the code is exactly the same, but the hash code for the file is different? What program could I use to see the exact differences between these two files?


VERY weird about the system account login! I guess when you killed Explorer and then launched it explicitly as System, Windows decided to convert your full session to System. Very odd. When you logged off and then logged back in again, did everything restore back to normal for your primary user account? Also... I noticed you have a Windows 8 program start icon, but your specs say Windows 7. Were you actually running Windows 8, or some desktop add-on for Windows 7?

 

[tom982]

Hi Gary,

No worries I'm glad we got to the bottom of it, I was so confused by the two valid MD5 hashes for each version of imageres.dll until it clicked that you're using x64 Vista.

The AMD64 in any filename in WinSxS doesn't mean that the file is specific to AMD chips. When x64 processors were first introduced, they were made by AMD and hence, they got named accordingly in Windows. Any file for AMD64 means that it's just for an x64 chip - it will happily be loaded on a thread of an Intel or AMD processor, assuming they're x64. I don't know why they're still named this way, but it would be a very big thing to change in Windows and isn't really worth the money from MS's point of view.

I just learnt about hashes/digests in my Maths Cryptography lecture a few hours ago actually, so this should test how much I was paying attention! A hash function is considered one to one, where an input of bits (binary digits) is processed and mapped to an output. We don't cover MD5 in this semester, so I can't go into any details, but it is designed to be one to one. This isn't truly the case, as it has been proven that MD5 is susceptible to attacks where two files can generate the same hash. This is bad news because it means a digital signature can be transferred from one file to another - something which shouldn't be possible, if the function was one to one. It isn't possible for one file to have two different hashes. Although it works in the reverse direction, inputting something to the MD5 function is one to one. They're definitely different files

I don't have any tools that will disassemble an x64 .dll so I can show you the assembly, but .NET reflector might do it? I don't know though, it's just a guess.

Yeah, it's strange isn't it? Fortunately, everything was fine after I logged out, then logged into my admin account. I modified explorer.exe to make it look like Windows 8. I also use this theme:

Windows 8 RTM Theme for Windows 7 by ~mare-m on deviantART

Hardly surprisingly, the system account didn't load my custom theme, so only the patched icon showed This is what it should look like:

 

[Cytherian]

Ah.... another presumption I made. It has not been my week. I immediately thought AMD meant the brand of processor. X86 would be 32 bit, not 64 bit then... So, I'll be sure to put the right one in place. I'm still a little miffed as to why the files are the same size.

Is the Math/Cryptography class just something you're taking independently, or is it part of a degree program? I imagine it must be quite fascinating. I had no idea that MD5 could be compromised like that. Amazing the level of deviousness that people can go to.

Thanks for the link on the W8 theme. Doesn't it feel rather 2D though? I've kind of grown to like Vista's theme.

 

[tom982]

It's a perfectly reasonable assumption to make. I read into it a little more and it turns out that the naming structure is due to AMD developing the x64 processor faster than intel, who's proposal was x86-64. But as much as I moan about the file name, it isn't going to do much! lol.

Yeah, x86 is 32 bit It's named strangely because Intel's first 32 bit chips were named with a suffix of 86 (e.g. 8086), so they just denoted the other characters with an x.

I ran both files through HxD (a file hex viewer) to compare what the contents are - although I can't see what the code is, you can see a representation of the file structure:

https://dl.dropbox.com/u/16537616/x86.zip

It's quite a big file! The originals are 81MB each, the compression managed to squeeze them down to 60MB total though. As you can see, they're definitely different.

I'm currently in my first year of my Maths degree - Cryptography is a topic we cover in the unit Number Theory and Cryptography. Some of the things in there are completely mindblowing, but it's really interesting. I think MD5 is considered a broken algorithm now, and I'm surprised they haven't started replacing it yet to be honest. I take it you heard of Flame a few months ago. Have you seen this article?

Crypto breakthrough shows Flame was designed by world-class scientists | Ars Technica

One of the topics we cover in Cryptography is the Birthday Paradox which states that if you have a group of 23 people, there is a 50% chance that two of them will have the same birthday. It sounds ridiculous when you first hear it, but the statistics behind it are sound:

Birthday problem - Wikipedia, the free encyclopedia

"99% probability is reached with just 57 people" - well I didn't know that one!

You might notice that stage 3 in the diagram of the Flame article is the "birthday bits" - this is a cryptographic attack which uses the birthday paradox to reduce the total number of hashes that you need to try before you get a match. As I briefly covered in my previous post, people are trying to get two files with the same MD5 to cause havoc - the birthday paradox applies to this as you're trying to get two of the same thing, but in this case it's hashes rather than birthdays. I don't understand how collision or meet in the middle attacks work (the Wikipedia page is so confusing! Plus we don't cover it this semester) so I can't explain the last few steps, but it's certainly really clever.

I had a phase of trying loads of themes and I never particularly liked any of them, so I settled with this one as it matches my wallpaper:

It'll be a pain to change this one though, I had to replace so many files to complete the transformation!

Tom

 

[Cytherian]

Hey Tom, interesting findings there on the imageres.dll differences. I guess it was just luck that both versions ended up as the same file size. Well, I applied the replacements in the correct positions and SFC gave me a 100% cleared check. Very nice to know everything is settled.

Yes, I'd read upon Flame when the news broke about it. It's alarming to think that the code is now out in the open. All of that hard exclusive work done by top people is now in the hands of malicious software pirates who will not only learn from it, but probably find ways to exploit it further. This may end up being somewhat akin to just handing fully comprehensive nuclear weapons technology papers to Iran. I just hope that anti-malware scientists can come up with a defense against it.

Nice winter scene there, very serene.


Incidentally, now that I got my system integrity back to 100%, I then elected to try the WinAero "Startup Sound Changer" program. It does work, but it only goes so far as to change \Windows\System32\imageres.dll. It did not do anything else, which means that the change will not persist.

I've now written a tutorial on this subject, found HERE.

 

[tom982]

Yeah, the images will make up most of the file size and they're the same in both the x86 and x64 versions of the file. It'll just be a bit of text here and there that's different Great job with the SFC! Good to hear everything is sorted.

Flame is scarily clever, and as you said, it's not good that it's in the wild. But at least the analysts can begin to decompile it and see how it works. I'm just glad it was an attack on a country rather than something targeting you and me.

 

[Cytherian]

One more thing... I had made yet another presumption, but then had the wits about me to double-check. I've discovered that even if I replace the correct modified 64-bit file under Winsxs, SFC still complains about the file(s). It must be referencing the original imageres.dll file hash code from somewhere else. Kind of a bummer, but then, from a program functionality standpoint it won't be a problem. I'm guessing that one would have to figure out where the hash code is, calculate the new hash code, and then replace it. The trouble is, you would have to bother doing this anytime the file changed, even when reverting back to the original. Anyway... it has been quite the learning experience.

 

[NoelDP]

Windows Winsxs Hash codes are proprietary - and the generators are unpublished, so far as I'm aware.

 

[Cytherian]

^ That would make sense, to help foil any rogue software incursions.

 

[tom982]

Right, the hunt is on. I'm determined to find these hashes I thought a good starting point would be to run Procmon and see what SFC is doing. It got to 37% and I thought I'd export the procmon log for you guys to see - the export got to ~950MB! So I quit procmon and sfc. I learnt something new today though, SFC doesn't do any of the work. As far as I can tell, it just launches TrustedInstaller.exe and that did hundreds upon hundreds of registry queries.

 

[Cytherian]

Fascinating, Tom. So SFC hands it all off to the TrustedInstaller, eh? Very mysterious, how the TrustedInstaller makes so many registry queries before reporting back to SFC. I wonder if Microsoft made it so complex as part of a means to foil any 3rd party from being able to take advantage of the system and work around Microsoft methods/policies.

Incidentally, in examining a number of 3rd party custom theme applications that modify system files, they do not address SFC at all. They just assume the average user won't bother to run it. It leaves a little door crack to the possibility down the road where users mysteriously find their theme modifications "vanish", when Windows detects the discrepancy and corrects for it.

 

[NoelDP]

Nothing mysterious there - TrustedInstaller is the default owner of everything in the Winsxs folder, and reducing permsissionf or that will result in errors (some minor and fixable, some major and irremediable)

It's both a Windows service, and a Windows user - anything that gets in its way *should* get trampled over - but Windows is a little too polite to do that.
(not to mention the fact that Windows no longer has a supreme owner under 'normal' circumstances)

 

[Cytherian]

I see your point, Noel. I found it mysterious from the standpoint of all those numerous registry queries. You'd figure that enough data would be provided so that the queries involved would be only a few rather than many hundreds. Or, there would be a rudimentary query that might spawn a few additional ones to do specific data mining.

In any case, whatever the reasons, I have to say that the system integrity has definitely gotten better over the years. It'll be interesting to see if BSOD encounters are even further reduced in W8.

 

[NoelDP]

SFC/TrustedInstaller picks the 'files to test list' out of the registry - hence the large number of registry queries

 

[tom982]

Finally found where the hashes are stored! :D I have customised explorer.exe on my system and wanted to know what SFC thought of it, so I ran the command sfc /verifyfile=C:\Windows\explorer.exe and it returned this in my CBS log:

2013-01-28 14:41:23, Info                  CSI    00000008 CSI Store 2165296 (0x0000000000210a30) initialized
2013-01-28 14:41:24, Info                  CSI    00000009 [SR] Verifying 1 components
2013-01-28 14:41:24, Info                  CSI    0000000a [SR] Beginning Verify and Repair transaction
2013-01-28 14:41:28, Info                  CSI    0000000b Hashes for file member \??\C:\Windows\explorer.exe do not match actual file [l:24{12}]"explorer.exe" :
  Found: {l:32 b:B8A6NfUv2Em+7oP1tXiESuCnyvhLWQrkRNmwWTZ+Qsg=} Expected: {l:32 b:a+0aOpVqhZ70Qg/rJGbAQIAOrwHvUyFO+dq1Ou/xz/A=}
2013-01-28 14:41:28, Info                  CSI    0000000c [SR] Repairing corrupted file [ml:520{260},l:28{14}]"\??\C:\Windows"\[l:24{12}]"explorer.exe" from store
2013-01-28 14:41:28, Info                  CSI    0000000d Repair results created:
POQ 0 starts:
     0: Move File: Source = [l:192{96}]"\SystemRoot\WinSxS\Temp\PendingRenames\b3e77f8e65fdcd01030000002c533867._0000000000000000.cdf-ms", Destination = [l:104{52}]"\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"
    1: Move File: Source = [l:162{81}]"\SystemRoot\WinSxS\Temp\PendingRenames\6995818e65fdcd01040000002c533867.$$.cdf-ms", Destination = [l:74{37}]"\SystemRoot\WinSxS\FileMaps\$$.cdf-ms"
    2: Hard Link File: Source = [l:236{118}]"\SystemRoot\WinSxS\amd64_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17567_none_afa79dc39081d0ba\explorer.exe", Destination = [l:54{27}]"\??\C:\Windows\explorer.exe"

POQ 0 ends.
2013-01-28 14:41:28, Info                  CSI    0000000e [SR] Verify complete

Hash found: B8A6NfUv2Em+7oP1tXiESuCnyvhLWQrkRNmwWTZ+Qsg=
Hash expected: a+0aOpVqhZ70Qg/rJGbAQIAOrwHvUyFO+dq1Ou/xz/A=

So I was curious where it pulled this expected has from as I know the COMPONENTS hive pretty well now and I'm fairly sure it isn't in there. So I had a look at the manifest for explorer.exe. As far as I can tell, C:\Windows\explorer.exe isn't actually a file, it's a hardlink to a certain version in WinSxS. Looking at this in the CBS log:

\SystemRoot\WinSxS\amd64_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17567_none_afa79dc39081d0ba\explorer.exe

I've got the component name: amd64_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17567_none_afa79dc39081d0ba

So now to find its manifest! Here it is:

C:\Windows\winsxs\Manifests\amd64_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17567_none_afa79dc39081d0ba.manifest

This is what's inside:

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved.">
  <assemblyIdentity name="Microsoft-Windows-explorer" version="6.1.7601.17567" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
  <dependency discoverable="no" resourceType="Resources">
    <dependentAssembly>
      <assemblyIdentity name="Microsoft-Windows-explorer.Resources" version="6.1.7601.17567" processorArchitecture="amd64" language="*" buildType="release" publicKeyToken="31bf3856ad364e35" />
    </dependentAssembly>
  </dependency>
  <file name="explorer.exe" destinationPath="$(runtime.windows)\" sourceName="explorer.exe" sourcePath=".\" importPath="$(build.nttree)\">
    <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" />
    <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2">
      <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
        <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
      </dsig:Transforms>
      <dsig:DigestMethod xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
      <dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">[B][COLOR=#ff0000]a+0aOpVqhZ70Qg/rJGbAQIAOrwHvUyFO+dq1Ou[/COLOR]/xz/A=[/B]</dsig:DigestValue>
    </asmv2:hash>
  </file>
  <file name="explorer-ppdlic.xrm-ms" destinationPath="$(runtime.system32)\spp\tokens\ppdlic\" sourceName="explorer-ppdlic.xrm-ms" 

[I]And more junk...[/I]

Look familiar?

So in summary, SFC must query the COMPONENTS hive for the component name, then find the location and look up the hash then compare it to the file's hash.

Tom

 

[Cytherian]

Finally found where the hashes are stored!

[...]

So in summary, SFC must query the COMPONENTS hive for the component name, then find the location and look up the hash then compare it to the file's hash.

Great work, Tom! Fascinating to know about how "explorer.exe" isn't really what is executed but merely a pointer to the actual program that ends up being run. It makes sense that it works this way, so that Windows can conditionally control what versions are used for compatibility purposes.

Anyway... I'm guessing that the manifests aren't version controlled via WinSXS, so you could theoretically update the hash to match what changes you've forced. Do you know how the hash is initially calculated?