How to overwrite .dll file in system32?

[shorterxp]

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 February 7, 2020 by shorterxp

[jaclaz]

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 February 7, 2020 by jaclaz

[abbodi1406]

https://github.com/mspaintmsi/superUser

https://m2team.github.io/NSudo/

[jumper]

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

[Tripredacus]

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.

[abbodi1406]

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

[jaclaz]

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

[jumper]

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

[shorterxp]

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

[jaclaz]

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  

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 February 15, 2020 by jaclaz

[WalksInSilence]

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. 

[erpdude8]

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.

[vinifera]

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

[Tripredacus]

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.

[ibay770]

This worked well for me. However it is annoying that we need these methods as opposed to booting with TI privileges by default like audit mode does.