Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
shorterxp

How to overwrite .dll file in system32?

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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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
  • Like 1

Share this post


Link to post
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. 

  • Like 1
  • Upvote 3

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Share this post


Link to post
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
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...