[fdv]

Not sure how it happened, but this thread ended up being
"How to open a CMD prompt with TrustedInstaller permissions"
Scroll to page 2, post 29, to see.

Here below is my original message about taking the registry "back" from TrustedInstaller (there is a batch file below to do that, too).

---------------------ORIG MSG---------------------
This is a question about SetACL syntax but since it applies to TrustedInstaller I thought that the Win 7 forum will get greater exposure.
It's also a mini-how to that will help a lot of you who loathe TrustedInstaller.

Below you will find three commands that when executed in order, will strip a given key of TrustedInstaller.
In order, number one makes Administrators the owner, number two assigns and propagates permissions for Administrators on the key and children, number three revokes TI permissions on the key.
Here's the problem I have: I want to be able to:
1. cascade ownership right down through the entire registry from the root HKCR, HKCU etc etc etc keys
2. strip TI permissions from everything in the entire registry from the root HKCR, HKCU etc etc etc right down to every endpoint key

I know there is a -rec yes option to recurse. Won't help scrub the entire registry though.

setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn setowner -ownr "n:S-1-5-32-544;s:y"

setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn ace -ace "n:S-1-5-32-544;p:full;s:y;i:so,sc;m:set;w:dacl"

setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn ace -ace "n:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464;p:full;s:y;i:so,sc;m:revoke;w:dacl"

for {CLSID VALUE} put something like {a86ca2f1-af74-4a74-980b-e185d4ca01b0}

Any ideas?

Edit: I always edit my posts, and this one is no different.

You must do this with an elevated command prompt.

Also, FYI for everyone, the following files have the TI SID in them:
bcdboot.exe
bfsvc.exe
COMPONENTS
setupapi.dll
winlogon.exe
winsetup.dll
wpd_ci.dll

If you really wanted to render TI powerless you could load them up in a hex editor and change one digit of the SID or change it to admins(S-1-5-32-544) and pad out the rest of the string with 90 (noop). I haven't tried this yet.

This post has been edited by dencorso: 23 May 2012 - 10:26 PM

[jaclaz]

fdv, on 15 March 2012 - 10:56 PM, said:

Any ideas?

Just a random one.
Is there any reason why one can't make a small batch and let it go through all the Registry, "HKCR\CLSID\{CLSID VALUE}", "HKCU\CLSID\{CLSID VALUE}" etc.?
It will probably take some time but should be usable, or there is some catch that I am completely overlooking?

Another random one, would Regacl:
http://www.gbordier....tools/index.htm
work and behave more like what you want to do?

REGACL v1.3, Copyright Guillaume Bordier 1999, guillaume.bordier@iname.com
Modify registry permissions (local and remote)
usage : regacl <Key> [/{G|R|S} {user|group}:{R|W|F}] [..]
[/RECURSIVE] [/REPLACE]
/G=Grant /S=Set /R=Revoke
R=Read  W=Write F=Full Control
Key     =[\\ComputerName\]<Hive>\<RegKey>
Hive:   remote  : HKEY_LOCAL_MACHINE (HKLM) or HKEY_USERS (HKU)
        local   : remote + HKEY_CLASSES_ROOT (HKCR) or HKEY_CURRENT_USER (HKCU)
Warning : Grant is additive, Set is not (better use /S).
/RECURSIVE apply permissions to subkeys
/REPLACE replace existing permissions
/INHERIT make the setting inheritable to future sub-keys

jaclaz

This post has been edited by jaclaz: 16 March 2012 - 02:52 AM

[fdv]

Hey, man!

In answer to the first question, it'd be totally possible to export the registry's CLSID list, open it in notepad++, clean it up, and make a small batch file to go through every value. We want to find a way to not have to do that though.

As for the second program, I'm not too sure it's any different but will look

[jaclaz]

fdv, on 16 March 2012 - 06:08 AM, said:

to export the registry's CLSID list, open it in notepad++, clean it up, and make a small batch file to go through every value. We want to find a way to not have to do that though.

What I don't understand is the "export the registry's CLSID list" and "clean it up".

As an example, but I need more details to understand if something more is needed, if you run:

reg query HKCR\CLSID\

You already have a list of the CLSID's in HKCR\CLSID\, is not that enough?
A (absolutely "fake") code example:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=1,2,3 delims=\" %%A IN ('REG.EXE query HKCR\CLSID\') DO (
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn setowner -ownr "n:S-1-5-32-544;s:y"
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn ace -ace "n:S-1-5-32-544;p:full;s:y;i:so,sc;m:set;w:dacl"
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn ace -ace "n:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464;p:full;s:y;i:so,sc;m:revoke;w:dacl"
)

jaclaz

[fdv]

Oh! Sure, that will work too. I was thinking of piping it to a txt file but your bit here works better and is pretty creative!
In truth I didn't spend much time on the idea though, because I really want to cover items 1 and 2 in my post, essentially "fix" the child objects.

What I think I would have to do is use the 'reset children' command and then re-assign, with inheritance, permissions for System, Admin, and User. That's the problem with the reset children command, it seems to erase other non-owner permissions which is obviously a bit of a problem. Hoping for a better way.

[jaclaz]

fdv, on 16 March 2012 - 09:48 AM, said:

What I think I would have to do is use the 'reset children' command and then re-assign, with inheritance, permissions for System, Admin, and User. That's the problem with the reset children command, it seems to erase other non-owner permissions which is obviously a bit of a problem. Hoping for a better way.

I still cannot understand fully what you need/want to do.
Generally speaking, since you are talking of Windows 7, Powershell has seemingly a few powerful methods to deal with ACL, but my knowledge on them ends right here.

http://waynestorey.c...ve-recursively/

This may be something like it:
http://blogs.technet...ger-part-1.aspx
http://blogs.technet...ger-part-2.aspx

jaclaz

This post has been edited by jaclaz: 16 March 2012 - 10:49 AM

[GrofLuigi]

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

But partial dethroning is OK (I've succeded with Classes and everything works).

*Edit: and propagation rarely works not because they've set a new system of ACL (what I thought in the Vista era), but because of the way default permissions are set during install. I strongly suspect this is the reason for invention of WIM.

*Edit2: And the default liberal permissions for Creator/Owner (wildly exploited now) are not a "courtesy" of Microsoft, but a failsafe to prevent disasters.

GL

This post has been edited by GrofLuigi: 16 March 2012 - 11:07 AM

[jaclaz]

GrofLuigi, on 16 March 2012 - 10:59 AM, said:

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

Yes , but you also must remember how you CANNOT have an XP without Internet Explorer



jaclaz

[GrofLuigi]

jaclaz, on 16 March 2012 - 12:46 PM, said:

GrofLuigi, on 16 March 2012 - 10:59 AM, said:

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

Yes , but you also must remember how you CANNOT have an XP without Internet Explorer



jaclaz

Sorry, but I don't understand what you're aiming at. And I like to consider myself as having some sense of humor.

GL

[fdv]

He means that people used to think it was "impossible" to run Windows 98 without IE, then someone did it. Then it was "impossible " to run Windows 20o0 without IE, and someone did it. Then it was "impossible " to run Windows XP without IE, and someone did it.
In other words, there is some exception to any rule -- if you say TI should not be stripped of any rights, he is saying that it might be possible to rig a system having done exactly that.

What really troubles me is that no one has tried.

I mean, just loading a hex editor and replacing the TI SID with the admin SID S-1-5-32-544 and padding out the extra characters should have been tried at some point, and yet no one has done it! TI honestly does not look like an "octopus," it only has a certain number of connections to and within the OS. It isn't really "everywhere." And yes, it's in the MSI. But it remains to be seen what happens if another SID is substituted.

Edit, as usual. To explain further and give thoughts... The TI is actually a service, not a user. S-1-5-80 starts all service SIDs. As long as the service is running, will Windows be happy? If we replace it in terms of object ownership? Rip it out from every ACL? As long as the stupid exe runs as a service, maybe windows won't "know" and can be tricked. That's the nitty gritty of where jaclaz and I are going with this thought process.

This post has been edited by fdv: 16 March 2012 - 10:56 PM

[dencorso]

fdv, on 16 March 2012 - 10:33 PM, said:

What really troubles me is that no one has tried.

We don't really know that. Younger people prefer blogs (which then disappear in the night) and IM over forums, and don't really love documenting what they did to get the job done. So, it may have been done already but never documented anywhere.

But I think GrofLuigi has a point, too: but my take is it may not be necessary to dethrone TI, provided everybody in the Admin group has equally full rights... democratizing TI's rights surely is the kind of subversion that fits my tastes.

Then again, blowing WRP to smithereens can maybe be simpler to accomplish...

[jaclaz]

@Grofluigi
Though your advice seems sound and most probably valid , I think that you cannot really say until you have tried doing it, and possibly tried doing it again and again with some different settings.

As fdv pointed out, we were told for a few years how (examples):

• you cannot strip IE from a Windows OS
  
• you cannot boot a NT based OS from USB
  
• you cannot boot a NT OS from an image
  
• you cannot make a "portable" XP

but every time someone took the time to try doing it, if he/she insisted enough, and with the cooperation/ideas/support of a bunch of other peeps, the "said to be impossible" chore resulted after all possible.

This does not mean of course that everythng said to be impossible is possible, only that before confirming such impossibility, some "serious" attempts to do it should be made.

In these regards fdv has proven in the past to possess the abilities and patience (and ingenuity, and a lot of other qualities) that made possible to strip IE from 2K and XP:
http://www.vorck.com/windows/
so he is - as I see it - particularly "qualified" to do "strange, perverted and potentially dangerous things" on a "poor (almost) innocent little Windows OS" .


jaclaz

[GrofLuigi]

The problem isn't that TI has too much rights, but that we (Administrators) don't have enough. My thinking is, if Microsoft built it that way, and it isn't standing in my way, i'd rather leave it alone.

I have killed several windows installations, but sadly I didn't document my steps. Every time I was "nearly there" and it was like Windows was toying with me, knew what I was doing, let me approach the finish line and than dropped the hammer.

About WRP: I've disabled WRP with instructions from here and Windows ended nearly unusable - couldn't install updates or (maybe, I forgot) regular programs, and there were many other problems (some control panel items won't start). To add insult to injury, I couldn't add the files back to WinSXS, even from other OS. I wouldn't recommend this route yet.

What I think are promising courses of action:

- Adding TI "token" to yourself or Admin group. I don't know if that's even possible, but it would be way better than for example, running yourself as TI (as Den mentioned somewhere).
- Giving ourselves and TI full permissions to (almost) entire registry and filesystem tree. It would save us (at least me) tons of headaches and time when thinking about is it safe to "process" the desired item (take ownership etc.) . Some may say it's defetism, but I really have nothing against the guy. TI can be ADDED from GUI like this.
- I am wary of hex editing and would leave it to the king here.

GL

[dencorso]

You rock, GrofLuigi!
I had utterly forgotten all about natsumerio's work (of course I'm growing old, but it seems my memory is failing me, too, sometimes ). While I'm not even near jaclaz's class, in what regards remembering things and locating related info, I'm usually not that absent-minded. I see I must do some mnemonic gymnastics right away, to shake off the rust from my brain!!!

Of course natsumerio's approach is with a war-axe, not a scalpel, so things are bound to get nasty. But, then again, it sure is yet another starting point to consider, and interesting info in itself.

[joakim]

FYI: I tried my Session0Cmd on a 64-bit Windows 7 SP1, and was able to execute commands with privileges of TI like this;

Start the TrustedInstaller service and obtain the PID of the process. Then run with syntax like this:

session0cmd_x64 2004 "cmd /c echo HelloWorld > C:\Windows\winsxs\hardtodelete.txt"

That's a PoC, and the number 2004 equals the PID of TrustedInstaller.exe. Ie, the above command is run with the same privileges as what the PID it is injected into, have. At worst trustedinstaller process crash, for which you can restart the service. The tool requires admin privileges. Not sure if it's of any use though.

Download; http://reboot.pro/fi...xecution-tools/ or my mediafire account

This post has been edited by joakim: 19 March 2012 - 05:31 PM

[joakim]

I was thinking a little more about this TI stuff, and believe it is possible to make a workaround. Since we can easily duplicate the token of the TI process, all we need to do is start a process with this token and make it interact with us. But by design this is not easily possible, but I think it still is possible. I was thinking of having a "server" part running in session0 with this token, and communicate out by some means to current user in sessionX through IPC/named pipes and read the commands. ImpersonateLoggedOnUser will help us reach our user session. The ipc could be tricky to get going though. Not sure.

[dencorso]

Great idea!

[CoffeeFiend]

I was wondering why is this even necessary in the first place (running as TrustedInstaller). Wouldn't starting a process or service as NT AUTHORITY\SYSTEM be unlocked enough? I mean, that shouldn't be blocked from doing anything really and it's really simple to do:



Edit: unless you want to *disallow* TrustedInstaller from doing something, which could easily cause loads of problems.

[dencorso]

Do the same methods that worked on XP succeed in making you the System user (= NT AUTHORITY\SYSTEM)?

[CoffeeFiend]

psexec works for sure.

Then again, just like the "other thread" I have *no* idea what we're really after