README.md

   1 ## WindowsD - Fixing broken windows
   2
   3 *Aka drivers won't load, processes are unkillable, registry can't be edited...*
   4
   5 WinD is a 3rd party "jailbreak" so administrators can remove some
   6 mal-features introduced in modern windows versions. Currently, it can disable:
   7
   8 * Driver signing, including WHQL-only locked systems (secureboot tablets).
   9 * Protected processes (used for DRM, "WinTcb").
  10 * Read-only, "invulnerable" registry keys some software and even windows itself employs
  11
  12 WinD works similiarly to [other tools](https://github.com/hfiref0x/DSEFix) which disable DSE, but is
  13 designed to be more user friendly and support for more OS/hardware combinations.
  14
  15 It is also designed to be "transparent", that is anything probing for
  16 "integrity" - typically DRM - will still see the system as locked down,
  17 even if drivers and processes are accessible to system administrator.
  18
  19 The idea is more or less 'run once and forget'.
  20
  21 Only accounts with SeLoadDriverPrivilege (admin) can use it.
  22
  23 ### Supported windows versions
  24
  25 Almost all builds of Windows 7, 8.1 and 10, 32bit and 64bit on Intel CPUs were tested.
  26 You need to use specific WinD32/64 .exe according to bit-ness of your system.
  27
  28 XP64, Vista and server editions *may* work, but you're on your own.
  29
  30 ### Usage
  31
  32 Download Wind32/64 according to bit edition of windows and simply click the
  33 exe. An installation wizard should start guiding through installation (it
  34 should be enough to answer y to everything). After that, your system should
  35 be unlocked and software with unsigned drivers should start working
  36 normally again.
  37
  38 ### Advanced usage
  39
  40 If you don't want to install on-boot loader, but only load particular
  41 service/driver while bypassing DSE, type:
  42
  43 ```
  44 > wind64 /l yourdriver.sys
  45 ```
  46 \- or -
  47 ```
  48 > wind64 /l DriverServiceName
  49 ```
  50
  51 But if you want your system to ignore signatures as a whole (ie load installed
  52 drivers at boot), use:
  53
  54 ```
  55 > wind64 /i
  56 ```
  57
  58 Which will install it as a service permanently. It is recommended you create
  59 a system restore point beforehand, in the event something will not go as planned.
  60
  61 In case you want to uninstall the service (and re-lock your system), use:
  62
  63 ```
  64 > wind64 /u
  65 ```
  66
  67 ### Process protection
  68
  69 Windows has a concept of "protected process" - one which cannot be tampered
  70 with. Of course this is only a fiat restriction, and we can disable it with:
  71
  72 ```
  73 > wind64 /d 1234
  74 ```
  75
  76 Where 1234 is PID of the process you want to unprotect. Once unprotected,
  77 a debugger can be attached, hooks can be injected etc. This command is
  78 useful only on Win7 and early win8/10 - later versions use patchguard to
  79 watch for changes of protection flags.
  80
  81 Meaning you have to employ same trick as we do for loading drivers - reset
  82 protection, do your stuff, restore protection - and do it quick. This can
  83 be done only via the C API.
  84
  85 Another route is elevate your own process to WinTcb level (which should not
  86 register it with PG), at which point it should be possible to fiddle with
  87 other WinTcb process. For that, you need to get familiar with internal
  88 encodings of PS_PROTECTION structure. More in-depth description can be
  89 found at Alex's blog:
  90
  91 * [Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1](http://www.alex-ionescu.com/?p=97)
  92 * [Protected Processes Part 2: Exploit/Jailbreak Mitigations, Unkillable Processes and Protected Services](http://ww.alex-ionescu.com/?p=116)
  93 * [Protected Processes Part 3: Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)](http://www.alex-ionescu.com/?p=146)
  94
  95 ### Registry
  96
  97 Windows contains 3 mechanisms to make dealing with registry especially painful:
  98
  99 1. "Hard R/O lock", an undocumented, but publicly exported system call, `NtLockRegistryKey()`. This will
 100    make given key read-only, until next reboot. Worse still, there does not need to be even a process or driver
 101    holding onto the key.
 102 2. "Soft Lock", `NtNotifyChangeKey()`. For this one, there has to be something holding on the open key handle and
 103    listening to notifications about changes to key value. The listener is either a thread, or kernel-resident
 104    driver. They'll usually silently replace the key back to value they want. No errors are reported, but the key
 105    cannot be edited.
 106 3. Global hooks. These can be installed only by kernel drivers, and hook directly to registry operation calls.
 107    These are not per-key. Originally designed for AV software, but malware has use for it too.
 108
 109 Note that all methods work at run time, they are not permanent permission within the registry.
 110 "Protection" like this, unlike permissions, works only within the currently running session.
 111
 112 WindowsD allows you to override and control all of these methods.
 113
 114 #### Method 1
 115 Parameters `/RD` and `/RE`:
 116
 117 ```
 118 > wind64 /RE \Registry\Machine\SYSTEM\CurrentControlSet\Control\Services
 119 ```
 120 Will very sternly disallow writing to this subtree - no new services can be installed. There does
 121 not exist permission to disable this setting (except via `/RD` command), and almost nothing can
 122 override it - not even internal kernel APIs.
 123
 124 `/RD` and `/RE` can be issued on any key.
 125
 126 #### Method 2
 127 Parameters `/ND` and `/NE`
 128 ```
 129 > wind64 /ND \Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\Windows
 130 ```
 131 Will disable notifications on this subtree (which contains frequently hijacked autorun, `AppInit_DLLs`).
 132 Now you can edit it back to value you want, without something mysterious forcing it back. Finally, you
 133 can even protect it with `/RE`.
 134
 135 Note that `/NE` can be issued only on key with notifications previously disabled via `/ND`
 136
 137 All registry paths are NT, not the usualy Win32 ones:
 138
 139 * `\HKLM\` becomes `\Registry\Machine\`
 140 * `\HKCU\` becomes `\Registry\User\`
 141
 142 #### Method 3
 143
 144 Uses parameters `/CD` and `/CE`. There is no registry path to specify (that is specific
 145 to the driver which registered the callback), so we can simply disable and re-enable again all
 146 hooks present.
 147
 148 ### Bugs / BSODs
 149
 150 The tool depends on many undocumented windows internals, as such, may break
 151 every windows update. Usually, it will simply refuse to load and you'll see
 152 all restrictions in effect again. There is a small chance it will render system
 153 unbootable too, so before installing via `wind /i`, USE the system restore.
 154
 155 If you boot your system in safe mode, the driver will refuse to load as well,
 156 and then you can simply uninstall the service via `/U` or manually:
 157
 158 ```
 159 > sc delete WinD64inject
 160 ```
 161
 162 If you get a BSOD, open an issue with exact version of windows and build number,
 163 and attach the following files from your system: `CI.DLL`, `NTOSKRNL.EXE`
 164
 165 ### API
 166
 167 There is header-only C API - `wind.h` Usage goes like:
 168
 169 * `handle = wind_open()` - open the control device, NULL handle on error
 170 * `wind_ioctl(handle,command,buffer,buflen)` - send command(s)
 171 * `wind_close(handle)` - close the control device
 172
 173 `command` can be:
 174
 175 `WIND_IOCTL_INSMOD` - load driver, bypassing DSE. Service entry must already
 176 exist for the driver. Buffer is UTF16 service registry path, length is size of
 177 buffer in bytes, including terminating zeros.
 178
 179 `WIND_IOCTL_PROT` - set/unset process protection. buffer points to `wind_prot_t`
 180 typed buffer.
 181
 182 * `buf->pid` - set to pid you want to change protection flags for.
 183 * `buf->prot` - contents of this struct are copied to process protection flags,
 184   but original protection flags of process will be returned back in the same
 185   buffer - ie contents will be swapped.
 186
 187 To unprotect a process, just clear all its flags - bzero(&buf->prot).
 188
 189 You can re-protect a process after you're done with it, simply by calling the
 190 ioctl again with same buffer (it holds the original flags) and the `buf->prot`
 191 will be swapped again.
 192
 193 `WIND_IOCTL_REGNON/OFF, WIND_IOCTL_REGLOCKON/OFF`
 194
 195 These take string with registry key as paramater, and can turn locking and notifications on/off.
 196
 197 ### Internals
 198
 199 Just like DSEfix and things similiar to it, we simply load a signed driver,
 200 exploit vulnerability in it to gain access to kernel, and override the
 201 policy with whatever we want. There are some differences too:
 202
 203 * Custom signed driver exploit is used, [technical details here](http://kat.lua.cz/posts/Some_fun_with_vintage_bugs_and_driver_signing_enforcement/#more)
 204 * 32bit support (Win8+ secureboot).
 205 * Can coexist with vmware/vbox as the exploit is not based on those (and hence
 206   does not need CPU with VT support either).
 207 * The vulnerable driver is WHQL signed, so it works even on systems restricted
 208   to WHQL via secureboot env.
 209 * We automate `reset ci_Options` -> `load unsigned` -> `ci_Options restore`
 210   PatchGuard dance by hooking services.exe to use our NtLoadDriver wrapper DLL.
 211
 212 ### Building and debugging
 213 You need MSYS2 for building - https://msys2.github.io/
 214
 215 Once you get that, drop into mingw-w64 shell and:
 216
 217 ```
 218 MINGW64 ~$ pacman -S mingw-w64-i686-gcc mingw-w64-x86_64-gcc
 219 MINGW64 ~$ git clone https://github.com/katlogic/WindowsD
 220 MINGW64 ~$ cd WindowsD && make
 221 ```
 222
 223 To build wind32.exe, just launch the "mingw-w64 win32" shell, and:
 224
 225 ```
 226 MINGW32 ~$ cd WindowsD && make clean && make
 227 ```
 228
 229 Cross compiling (on linux, or mingw32 from mingw64) is possible, but you'll have to tweak Makefile on your own.
 230
 231 Finally, to get debug version:
 232
 233 ```
 234 MINGW64 ~/WindowsD$ make DEBUG=1
 235 ```
 236
 237 And you'll see both the userspace exe, dlls and kernel driver tracing heavily into DbgView.