From d9c58f0a50239b27867385c991d8c81ee7a5431a Mon Sep 17 00:00:00 2001 From: katlogic Date: Mon, 1 Aug 2016 15:51:43 +0200 Subject: [PATCH] Create README.md --- README.md | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..f4fb536 --- /dev/null +++ b/README.md @@ -0,0 +1,126 @@ +## WindowsD - Fixing broken windows (DSE and WinTcb protection levels) + +WinD is a 3rd party "jailberak" so administrators can remove some +mal-features introduced in modern versions windows. Currently, it can disable: + +* Driver signing, including WHQL-only locked systems (secureboot tablets). +* Protected processes (used for DRM, "WinTcb"). + +WinD works similiarly to other tools [1] [2] which disable DSE, but is +designed to be more user friendly - that is, be mostly transparent and +simply unlock the system, with no need for user to further intervene manually. + +It is also designed to be "transparent", that is anything probing for +"integrity" - typically DRM - will still see the system as locked down, +even if drivers and processes are accessible to system administrator. + +Only accounts with SeLoadDriverPrivilege (admin) can use it. + +### Supported windows versions + +Windows 7, 8, 8.1 and 10, 32bit and 64bit on Intel CPUs. +You need to use specific WinD32/64 .exe according to bit-ness of your system. + +Vista and server editions *may* work, but are untested. + +### Usage + +Download Wind32/64 according to bit edition of windows and simply click the +exe. An installation wizard should start guiding through installation (it +should be enough to answer y to everything). After that, your system should +be unlocked and software with unsigned drivers should start working +normally again. + +### Advanced usage + +If you don't want to install on-boot loader, but only load particular +service/driver while bypassing DSE, type: + +``` +> wind64 /l yourdriver.sys +``` +\- or - +``` +> wind64 /l DriverServiceName +``` + +But if you want your system to ignore signatures as a whole (ie load installed +drivers at boot), use: + +``` +> wind64 /i +``` + +Which will install it as a service permanently. It is recommended you create +a system restore point beforehand, in the event something will not go as planned. + +In case you want to uninstall the service (and re-lock your system), use: + +``` +> wind64 /u +``` + +### Process protection + +Windows has a concept of "protected process" - one which cannot be tampered +with. Of course this is only a fiat restriction, and we can disable it with: + +``` +> wind64 /d 1234 +``` + +Where 1234 is PID of the process you want to unprotect. Once unprotected, +a debugger can be attached, hooks can be injected etc. Re-protection is not +supported from command line at this time, you have to use C API for that. + +### Bugs + +The tool depends on many undocumented windows internals, as such, may break +every windows update. Usually, it will simply refuse to load and you'll see +all restrictions in effect again. There is a small chance it will render system +unbootable too, so before installing via `wind /i`, USE the system restore. + +If you get a BSOD, open an issue with exact version of windows and build number. + +### API + +There is header-only C API - `wind.h` Usage goes like: + +* `handle = wind_open()` - open the control device, NULL handle on error +* `wind_ioctl(handle,command,buffer,buflen)` - send command(s) +* `wind_close(handle)` - close the control device + +`command` can be one of: + +`WIND_IOCTL_INSMOD` - load driver, bypassing DSE. Service entry must already +exist for the driver. Buffer is UTF16 service registry path, length is size of +buffer in bytes, including terminating zeros. + +`WIND_IOCTL_PROT` - set/unset process protection. buffer points to `wind_prot_t` +typed buffer. + +`buf->pid` - set to pid you want to change protection flags for. +`buf->prot` - contents of this struct are copied to process protection flags, +but original protection flags of process will be returned back in the same +buffer - ie contents will be swapped. + +You can re-protect a process after you're done with it, simply by calling the +ioctl again with same buffer (it holds the original flags) and the `buf->prot` +will be swapped again. + +### Internals + +Just like DSEfix and things similiar to it, we simply load a signed driver, +exploit vulnerability in it to gain access to kernel, and override the +policy with whatever we want. There are some differences too: + +* Custom signed driver 0day is used. +* 32bit support (Win8+ secureboot). +* It can actually coexist with vbox, does not depend on VT support in CPU + and it even triggers if the driver is already present as we try to load it + under different name. +* The vulnerable driver is WHQL signed, so it works even on systems restricted + to WHQL via secureboot env. +* We automate `reset ci_Options` -> `load unsigned` -> `ci_Options restore` + PatchGuard dance by hooking services.exe to use our NtLoadDriver wrapper DLL. +