joakim

No I seriously doubt that.

If you want ReFS support in Windows 8 CP; http://reboot.pro/15466/#entry152971

After a little look inside bootmgr (and boot.sdi) it seems like the issue is with the way the wim format is mounting and how the filesystem driver (ntfs) sees the mounted volume. So bootmgr does its job, and the wim is mounted, and winload and the kernel is then executed all fine. However the crash (or freeze) happens when the kernel is loading drivers (have not debugged yet). So I'm not sure what needs to be changed. I managed to reassemble a modified bootmgr version 6.2.8250, so at least something useful came out of it.

I think the impersonation is complete, but because of the session separation it is not possible to interact with the process. That was the reason for using tcp/ip for the communication. what is that you can't do, except interacting with a GUI? The process in my solution originates from a remote thread inside the TI process, and for that reason it should be identical in terms of privs and rights. The other solution is different in that the created and duplicated token has its session id modified, which means you can interact with it directly (including GUI's I presume).

On my windows api journey, I discovered this neat little tool that achieves kind of the same thing, just very differently (and less complicated); http://developex.com/custom-software/devxexec.html It is based on token duplication and not remote threads as I described.

I have been informed that the newest Windows 8 (6.2.8250) does not work with my minimal boot.sdi. It is likely something in bootmgr that has changed, so one of the files needs to be changed. Will start by looking in bootmgr. Other stuff I should look at while inside it?

I forgot to explain properly that the reason why session separation is not blocking our shell, is because the process itself (the cmd window that we type the commands in) is not running inside session0. It is the other part of the network connection that is session0, and obviously is "invisible". We therefore communicate of TCP/IP into our session0 TI-privileged server. For that reson no GUI can be launched during such a session, and we are limited to command line utilities (but who cares..). It would thus not surprise me if MS added some memory protection to the TrustedInstaller service at some time in the future.

I quickly compiled a lame server communicating over tcp/ip and accepting commands over port 6666. All good and well as the commands sent by the client was in fact executed if valid. Ie, the server was started by having Session0Cmd injecting it into the TrustedInstaller.exe process. But it was probably the lamest server/client application created this century.. I then realized what the best solution actually is. Grab a copy of good old netcat and inject it with Session0Cmd. Then use netcat and connect it to your localhost. And guess what. A running and interactive cmd.exe in sessionX that has all the privileges you could ever dream of. You don't get more privs than that! So the commands I used; Session0Cmd 2003 "nc -l -p 6789 -d -e cmd" Now netcat is running as a daemon and serving cmd.exe for you on port 6789. To connect to it and obtain the actual TI-privileged cmd, open a cmd window and use this command; nc localhost 6789 Good luck hacking your system Hope you know what you're doing.

Never mind. I am fairly sure the right way to go is by duplicating the token of the TrustedInstaller and expand on that as already described. For instance spot the difference in output from cacls; c:\windows\winsxs NT SERVICE\TrustedInstaller:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)R NT AUTHORITY\SYSTEM:(OI)(CI)R BUILTIN\Users:(OI)(CI)R c:\windows\system32\config NT SERVICE\TrustedInstaller:(CI)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F CREATOR OWNER:(OI)(CI)(IO)F

Are you sure this tool is able to replicate the privs of the trustedinstaller? Can someone verify in Windows 7?

If you want to use an "alternative/non-standard" driver without using TESTSIGNING, then you for sure need to look into patch guard (unless you just want to remove the TESTSIGNING watermark..). Some people apparently managed to fix patch guard some time ago, but that method no longer works. Bypassing patch guard is not an easy task.

The "NT AUTHORITY\SYSTEM" account is by itself not enough to modify stuff inside the WRP protected areas. For instance the winsxs folder (and sub folders) are blocked, and if you run cmd.exe as just "NT AUTHORITY\SYSTEM", then you get access denied. You need more, ie similar to what the token of the trustedinstaller has. That's why I showed the command with session0cmd and how it can give you the right privileges. For some unknown reason, it seems not possible to just switch into an interactive session with anything running with trustedinstaller privs (something you easily can if just "NT AUTHORITY\SYSTEM" is granted and nothing more). But despite not being totally inetractive with session0cmd, at least we can issue commands/start other programs from there.. But still, it would be interesting to create something inetractive as can possibly be done with ipc accross sessions.

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.

What exactly are you trying to patch/fix here? The thread title implies the digital signature, for which certain components will check against during boot. WRP is not dependant on the digital signature, but rather file-hash focused. Patchguard is a driver-only protection, and does not bother with anything else..

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/files/file/171-payload-execution-tools/ or my mediafire account

There is some rather detailed information to be found regarding tweaks in the early boot phaze of Windows 7; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html which covers modification of many binaries, and might be useful..

Maybe something as simple as; "sc.exe delete servicename" would be good enough.

I also think it's though enough to create the animations themselves. Basically it is just 105 frames/bitmaps of size 200x200. Look in the section "The Animation" on the page; http://www.coderforlife.com/projects/win7boot/ there is listed a few recommended applications for. For more about the technical details (which I personally find easier) look here; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html

That is the way if you only want to adjust the size of the logfile. However, you cannot set it to lower than 2 Mb (because it's coded so), unless you are using a patched untfs.dll. If you run; chkdsk /f driveletter ,it will create a new logfile with default size of 256 Kb (as well as fixing other issues). If you run format.com to format a partition with NTFS with the patched untfs.dll in the same directory, then it will also default to 256 Kb for the logfile. Of course this is not something one would do on a multi GB partition. This is mostly for the sake of the fun in exploring the filesystem. In the patch posted above 200000h = 2097152 bytes = 2 Mb, while 40000h = 262144 bytes = 256 Kb. So adjust the values to whatever (but at least a multiple of 2 of 40000h). Joakim

I just realized how to create/modify tiny NTFS partitions with the standard tools like chkdsk.exe and format.com. Actually it must be the exact same thing that Mark did back in the 90's when he made the ntfs floppy thing. He said he used SoftIce back then, but it can also easily be done by simply patching untfs.dll. The whole point is to set the size of the $LogFile to something below the hardcoded minimum (2097152 bytes or 2 Mb), and thus significantly reduce the size of the metafiles/systemfiles. Now after some tests, it seems no coincidence that Mark ended up with a 256 Kb logfile. I believe it's a driver limitation.. So 256 Kb seems the smallest possible size that will be accepted by the nt file system driver. Smaller logfiles can be made (48 Kb) with correctly adjusted $MFT++ entries, but the actual header of the logfile (restart page) gets invalidated. 3 places need modification; At va 5b04cfc5; [b8 00 00 20 00] -> [b8 00 00 04 00] At va 5b04d324; [c7 00 00 00 20 00] -> [c7 00 00 00 04 00] At va 5b04d336; [bf 00 00 20 00] -> [bf 00 00 04 00] And if you also want to try it on a floppy then at va 5b0346fb; [74 08] -> [eb 08] But for already known reasons, the ntfs driver cannot open such a floppy, even though its correctly ntfs formatted.. This was done on the XP sp2 version of untfs.dll (5.1.2600.2180). Just make the mod and place it together with chkdsk/format in a separate directory. Now you can create NTFS partitions below 1 Mb in size (with limited usage though). Note: Some highly advanced tools like Paragon Hard Disk Manager do not even evaluate the validitiy of the actual $Logfile, so it will report a damaged NTFS partition (seen as RAW by Windows) to be 100% healthy... Joakim

OK so I just got home and able to verify the stuff. I was slightly wrong. For the record, pxeboot.0 is renamed pxeboot.n12 and it does not matter which version you use. I just modified the version from Windows 7 (6.1.7600.16385) and it worked just fine. However it was not a unicode string. It's an ascii string and there is just 1 such string (bootmgr.exe) inside it, so you cannot miss it. But before you can use with modified Boot\bcd paths you must deactivate some security concerning bootmgr.exe. Either put nointegritychecks on in your bcd store for the bootmgr entry, or make the hack directly on the binary by following the instruction somewhere near the end of the first post in this thread; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html Joakim

Actually I'm nowhere near a usable machine at the moment and unable to inspect the binaries in question. But I'm fairly sure I've done this in the past. Should be a unicode string if I'm not mistaken. Cannot remember exactly but maybe I used an older pxeboot.0 (Vista based). Assuming you are network booting your nt6.x WinPE. If not, go directly for bootmgr.

Ehh, sorry. I could not see the screenshot because of a firewall, when posting the first post. Ignore it.

Take your tijme reading this thread; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html If you don't care about the details, then go for the link to the AIO tool at bottom of the first post. It's a great app by a great coder by the way. The app and the details are discussed through out the whole thread, which is quite long..

It appears that you slightly misunderstood (if I understood you correctly) the concept of the thread. From my point of view it looks like you're trying to patch the wim file. What you want to do is probably (since you posted in this thread) integrate all images into the same wim, and patch the windows bootloader instead. That's the whole reason why I've prepared a severely hacked bootmgr to make this possibly. If you have several different wims and want to keep it like that, then you don't need to bother with any patching as it can all be configured in the bcd store by MS's own tool bcdedit.exe. Joakim