Jump to content

How to overwrite .dll file in system32?


shorterxp

Recommended Posts

Dear forum

As sole user and administrator, I am unable to overwrite a particular .dll in system32 on a Windows 7 PC but I get "you do not have perimissions to perform ths action".
It 'isn't use' at the time of copy.
Is this specifically because sys32 and its contents are protected by WFP?
On windows XP (with SFC dsiabled) its possible to overwrite the same dll in question, in same folder.

Is it Impossible on standard Win 7 Install? Is there a workaround?

Edited by shorterxp
Link to comment
Share on other sites


1 hour ago, shorterxp said:

Is there a workaround?

There may be.

You can probably do it using Trusted Installer credentials or by direct disk writing (IF the new file is the same size as the old one).

Example of Trusted Installer approachI:

Direct disk writing approach (again only valid if the new file is the same size of the old or - maybe - also if it is smaller), consists in finding out the extents the file is in (if needed make it contiguous) and then attempt dd-ing the new file on that same location, you can use mygrafmenter or extents here:

http://reboot.pro/topic/18570-extents/

to get LBA extents data then use dd for windows or similar (dsfi of the DSFOK toolset ) to try if the write "goes through".[1]

jaclaz

 

[1] if I were you, and IF the new file is same size or smaller, I would personally rather use direct disk writing before booting using grub4dos blocklist and dd commands.

 

Edited by jaclaz
Link to comment
Share on other sites

IIRC TrustedInstaller is a security context and not actually a user. If you really need to make the file change with the OS booted, you can try to run a CMD as SYSTEM (Local System) and see if that grants you a high enough priveledge to make the file change. Here is a tool from NirSoft that should give you the ability to run something as system (among others):

https://www.nirsoft.net/utils/advanced_run.html

Even so with a CMD as system, file attributes may prevent a file change. If the file is not in use, you can Move it out of that folder, and then move the replacement file into that folder. This way, there is no over-write. You may have to use attrib on the file to get it out of there.

If you can do this work outside of the OS, such as from DOS or Linux, you won't have to be worrying about ACLs. If you do the work from inside WinPE, you may run into the same problems as with the OS.

Link to comment
Share on other sites

20 hours ago, jumper said:

Can someone explain how the previous two links are relevant? TIA
 

They are other tools similar to the RunasTI by joakim I linked to earlier, the topic contains also some background/why/how the approach works:

 

jaclaz

Link to comment
Share on other sites

On 2/11/2020 at 5:08 PM, jumper said:

Thank you two for the detailed explanations.  My Win9x background has me ill-prepared for such NT service and security concepts.

Well, that is a pet peeve of mine, Trusted Installer is not as much a security concept as a limiting of freedom :w00t: :ph34r:

In the good ol'times of NT and 2000 "pro's" (which implied network, shared pc's etc, AND often an IT supervision) had a all in all "sound" security/access implementation, and the "normal users" (your home PC and laptop, probably never connected to a network) had a simplified model with 9x/Me,

With XP, it was forced down the throat of common users a whole load of access/permisisions and what not that simply made no sense.

With the (stupid) Vista and later there were not that many (or good) improvements (in the sense of actual increase in security in practice), as each and every (stupid) additional roadblock has been - before or later - worked around, the only effects were to make the life of users (and in some cases of developers a little more miserable).

 

On 2/14/2020 at 12:20 AM, shorterxp said:

Thanks for the solutions. I got it to work in the end.

And if you would tell us which among the various proposed solutions/workarounds you used successffully that would maybe be useful to someone else with the same or similar issue.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Yes, that is one of my pet general forum use dislikes: when somebody asks a question, gets help and then later posts some variation on:-

 

Thanks for the solutions. I got it to work in the end.

without actually explaining exactly how they resolved the problem.

So many times you look for answer to a particular question online and find a thread in some long dead or now barely used forum which is about just what you wanted to know and the thread is abruptly ended by a post like that. Frustrating and a wee bit selfish. 

Link to comment
Share on other sites

On 2/10/2020 at 8:00 PM, abbodi1406 said:

TrustedInstaller is a service, and it own all OS components (files)

the posted two tools provide a way to execute a program as System account with TrustedInstaller token = grant full permissions

another tool to use would also be PowerRun which allows running an app as SYSTEM user/account.

Link to comment
Share on other sites

14 hours ago, vinifera said:

aint it easier to just boot via any PE cd and do quick change ?

It doesn't hurt to try. The problem with a WinPE is that it will acknowledge ACLs on files and folders, especially where the folders match protected ones and accounts or security contexts that also exist in the WinPE. It is because WinPE will still have the underlying security components that the full Windows OS does. So as a result, some files may still be locked or not even visible to a WinPE just as it would be in the full OS. That is why the best method (for outside of the OS work) is to use an OS that supports NTFS but does not have those security components.

Otherwise, whether you are in a WinPE or in the full OS, you would need to use some tool such as the ones above to run under a different security context or account. It could still be done manually by changing the ACLs, change the file, and then set the ACLs back but it is quite tedious.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...