Resolve Issues with Windows Resource Protection using the WRPMitigation Shim


Every now and again, I bump up against a setup application (it’s almost always a setup application) that tries to drop older versions of protected operating system files. It’s fairly easy to mitigate, but I thought I would go through some of the mechanics, and some of the places where the mitigation can break down.

Let’s take a walk down memory lane…

Windows ME logo horiz

Introduced in Windows 2000 and brought over to Windows ME … I’ll pause for everyone to recover from the shivers in your spine … we offered a feature called System File Protection. This feature is designed to protect the integrity of the operating system. This feature had a couple of issues, which I talk about here: http://blogs.msdn.com/cjacks/archive/2007/04/20/windows-resource-protection-wrp-and-activex-control-installation-on-windows-vista.aspx.

So now, things are better, except of course the applications that break, which is why we didn’t just modify the ACLs in the first place. So, one by one, we just start applying our WRP shims to applications that need it, and this got us back where we needed to be for application compatibility. We automatically apply this shim if we detect that you are a setup. We apply this shim to regsvr32.exe. We throw it everyplace that we think we’re going to catch people trying to write to protected operating system files.

So, how does it work?

Well, first we always try to run the original API. If that fails, then we check to see if you are a WRP protected file. We do that for performance – if what you are trying to do already works, we don’t need to fix you, nor do we need to run code to determine if we ought to fix you. We just let you go on doing your thing.

But if the operation didn’t work, then we’ll check to see if the file is WRP protected. If so, then we’ll pretend that things worked.

How do we pretend?

Well, if you’re trying to delete, we can just return success. Move? Success. Change attributes? Success.

But what if you’re trying to write?

In that case, we don’t get very far by returning success, because we need to return a handle that is valid or the application could AV. So, we just create a temp file, and return a handle to this temp file.

Right now, I’m running an application attempting to update kernel32.dll, and I find this in %temp%: WRP112.tmp.

That’s where I’ll be writing when I write. My application continues to work, and we resolve the issue.

But let’s back up a minute – what happens if I am trying to drop my file in a non-standard location and register it from there? Here, we can run into issues. Clearly, the application is intentionally trying to circumvent protection mechanisms. They drop the dll somewhere other than the location of the protected dll (which succeeds) and then call regsvr32.dll. (Some people think they’re really tricky – I once saw an app drop some version of shell32.dll from Windows 2000, but they called it shell32.ico, then called regsvr32 on it.)

Our check to see if it’s a protected operating system file says “no” because it isn’t owned by Trusted Installer, and we don’t fix it up.

With people trying to be tricky like this, I usually end up modifying the package to remove this drop. But I suppose I could CorrectFilePaths to hit my protected location…

Comments (19)

  1. Mark Sowul says:

    "Well, if you’re trying to delete, we can just return success. Move? Success."

    What could the developers of these apps possibly be thinking such that they concluded it was a perfectly good idea to go around moving and deleting system files?  I’m surprised that, even after all these years of reading The Old New Thing, I still have the ability to be amazed by things like this.

  2. Mark Sowul says:

    (Of course, the other shenanigans about registering the wrong files from other operating systems and such, I’m jaded on that and it didn’t faze me at all : )

  3. ABC says:

    Please could you tell me what is the exact difference between the

    "Trusted Installer" and "Administrator"

  4. cjacks says:

    TrustedInstaller is a service. Administrator is a user account. Administrators is a group.

  5. ABC says:

    Hi,

    Most of the cases, I saw when we are trying to install an application on Vista machines. It is getting failed because it is writing something into one of the Windows Protected File.

    So for this kind applications we can apply the "WRPMitigatiion shim", right?…But even after applying this shim also I am getting the same error. It seems shim is not working……do we need to do any other extra things in the parameter field while applying the shim ( here you are saying we have to apply the shim to regsvr32.exe….what it is?)….

    pls tell me how to apply this kind of fixes to applications.?

  6. cjacks says:

    WRPMitigation does not require any command line parameters. If it’s not fixing it, it’s probably not related to Windows Resource Protection.

  7. ABC says:

    Hi,

    Because of this WRP issues, applications are not getting installed in Vista.

    After applying the WRPMitigation shim, I am able to install the application. But just I want to know the logic how it is working after applying the shims.

    Whether this shim is really giving permissions to those WRP folders/files/Registries and allowing to modify/delete these files? or it is redirecting these files to some other file locations which is not related to WRP files?….

    ABC

  8. cjacks says:

    Nope – we don’t give you permission to write there. We actually just create a temp file and return a handle to the temp file. So, the app still writes, but that writing doesn’t affect the protected file at all. We in fact can’t let you write there – the ACLs only allow the Windows Module Installer service to write there, and your app isn’t that service so it won’t have access. :-)

  9. ABC says:

    Thanks Chrish,

    ok, I agree it. But whenever the same WRP file is required during the launching or during the functionality of app.This temp file will not be available, then how it will work?

    Actually Whenever we install any app, the required files/registries gets installed in our machine. So whenever our appl. is trying to write something into this WRP locations, it is failed and after applying shims it is creating one temp file and returing success value. But the moment instllation is completed this temp file will not be available right?…So during functionality time, how it will work?…

    and one more doubt is, even if the admin also not able to write or app. not able to write into this WRP locations. Then what is the need of sitting these files in our machine?

    please clarify me on this.

  10. cjacks says:

    You won’t use the old file – you’ll use the new one. If we let you use the old file, then we’d be putting Windows into an unknown and untested state. That’s why we implemented WRP – to keep that from happening. We just trick the installer into thinking it dropped all the files it wants to drop. The temp file just goes away when we’re done tricking it.

  11. ABC says:

    k….ya, I had confusion earlier, now it’s clear.

    So all WRP files/registries are located at  one particular place or it can be anywhere in our system.?

    can we see these files/registries directly or will it be in hidden mode?.

    if we can see it, how can we identify it’s WRP file/reg.( other than checking the properties of folder permissions)

  12. ABC says:

    k….ya, I had confusion earlier, now it’s clear.

    So all WRP files/registries are located at  one particular place or it can be anywhere in our system.?

    can we see these files/registries directly or will it be in hidden mode?.

    if we can see it, how can we identify it’s WRP file/reg.( other than checking the properties of folder permissions)

  13. cjacks says:

    WRP protected files can be anywhere, although files tend to be mostly in the Windows directory. You can see them directly – most aren’t hidden. You could check the ACLs – or, if you’re writing code, you could use the SfcIsFileProtected / SfcIsKeyProtected APIs.

  14. ABC says:

    Hi Chris,

    I want complete folder structure differences in XP & Vista.

    ex: in XP: userprofile is C:documents & settings

    but in Vista it is replaced with "C:users"

    can I get this material from any sites,do u have it/

  15. cjacks says:

    Come on, ABC, you’re not even trying any more. Your first stop should be a search engine, not me. I can’t do all of your research for you.

    http://msdn.microsoft.com/en-us/library/bb756982.aspx

  16. ABC says:

    Hi Chris,

    Apologies for putting this kind silly questions.

    actually I tried in google search….But I did not get complete folder structure diffe. I know  only few……But I just wanted to know all the differences made in vista.

    it’s not like, I am not trying. As you know in depth of the Vista and I am really eager to learn all in one stretch. That’s the reason behind it, nothing else.

    once again apologies from my side..But really thanks for your patience reply.

  17. ABC says:

    Hi Chris,

    I had installed one application through SAT tool and it had listed WRP issues in the log file of SAT. But the application could installed fine without any issues.

    I was wondered, though it was having WRP issues,how it could installed fine?

    Just I would like to know why it did not stop the installation of app?

    After finding the log files I had sent it to the Client saying it had compatible issues of installation but it could installed fine. Since it did not break the installation I said to them we can ignore this issues?

    But he was not happy with my answer, means he is expecting somewhat more descriptions how can we ignore it?

    please can you guide me how can I convience my client showing strong evidence.?

    help me in this regard. Thanks in advance.

    -ABC

  18. cjacks says:

    The WRPMitigation shim is automatically applied when we detect that you are a legacy setup application. So, the installers that have the problem we’re already fixing up for you.

    So, even though it’s technically "wrong" it doesn’t affect you since we’ve already fixed it. Most people leave these alone, but if they’re repackaging then it’s obviously a good idea to make it right.