Debugging

CryptDisk is debugged using WinDbg between two VMware VM's, VisualStudio and WinDbg are running in VS17c and the target is running CryptDisk in the Win10-1703 VM. (\\Green\Volumes\Win10-1703)

Driver signing is not required IF kernel debug is enabled in the target VM. (See ).

1. Configure the target
   1. Boot the target VM
   2. Launch a DOS console as admin
   3. Run bcdedit /dbgsettings
   4. Copy the information temporarily.
   5. Make sure the hostip is the address of the VM running WinDbg.
      To update: bcdedit /dbgsettings net hostip:192.168.0.100 port:49999
2. Start WinDbg
   There should be an existing workspace for CryptDisk.
   File > Kernel Debug...
   NET > Port Number:49999
   The key needs to be copied from the target using the command bcdedit /dbgsettings
3. Boot the target VM.
   The target should be given at least 2GB, 4GB is plenty.
4. Deploy the CryptDisk binaries to the target.
   There is a deploy.bat script:
   copy /y Out\Winx64Debug\CryptDisk.exe \\Win10-1703\Test\CryptDisk copy /y Out\Winx64Debug\CryptDriver2.sys \\Win10-1703\Test\CryptDisk copy /y Out\Winx64Debug\CryptIFS.sys \\Win10-1703\Test\CryptDisk This copies the binaries from the debug build.
5. Run CryptDisk.exe
   The debug build does not automatically load the driver, giving me a chance to poke around before it is loaded.
6. Load the driver
   Driver > Load
   This should immediately hit a hardcoded breakpoint in DriverEntry()
   NTSTATUS DriverEntry(DRIVER_OBJECT *pDriver, UNICODE_STRING *RegPath) { NTSTATUS Status= STATUS_SUCCESS; CfgLoad(); RtlStringCbCopyA(DbgPrefix,sizeof(DbgPrefix),"CryptDisk"); //NOTE: By default, only error messages are printed by Windows. DbgPrintEx(PRINT_ID,PRINT_LEVEL,"CryptDriver has arrived!\r\n"); DbgPrintEx(PRINT_ID,PRINT_LEVEL,"CryptDriver version %s %s\r\n",gVerID.BuildStr,gVerID.Builder); DbgPrintEx(PRINT_ID,PRINT_LEVEL,"DriverEntry=%llX pDriver=%llX\r\n",DriverEntry,pDriver); //if(KD_DEBUGGER_ENABLED && !KD_DEBUGGER_NOT_PRESENT && gDbgBreak) if(gDbgBreak) DbgBreakPoint(); pDriver->DriverUnload= DriverNtUnload; DriverEntry2(pDriver); return(STATUS_SUCCESS); }

I knew this would be a problem eventually...
S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk>dir \\win10-1703\Test The system cannot contact a domain controller to service the authentication request. Please try again later. I recently moved, leaving my domain controller (Hush) behind, and have been relying on cached domain credentials. This works for local stuff (UAC and system updates) but any real network access between different machines must be authenticated by the domain controller (or referring to Hush for the name lookup) -- which is nowhere to be found.

This presents a big problem, since the solution requires either

1. Bringing Hush back onto the network. This involves hoping Hush still exists and can be shipped to me.
2. Building a new domain controller.

#1 is the easiest but takes time, and Hush was never very good at its job due to being woefully short on RAM.

#2 is the right solution. But this is a huge, invasive interruption with a high risk of data loss as any data and files tied to the old domain will become inaccessible when the machines are migrated to the new domain. If I embark on this path, I need to be extremely diligent about copying all my files, data, and configurations to external storage that will remain accessible from the new domain account(s).

It is always something...

WORKAROUND:
I can defer this issue by replacing the machine name with its IP address. This works because Win10-1703 is sharing its directories to EVERYONE.
S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk>dir \\192.168.0.217\Test Volume in drive \\192.168.0.217\Test has no label. Volume Serial Number is E4E6-32BD Directory of \\192.168.0.217\Test 01/10/2019 07:36 PM <DIR> . 01/10/2019 07:36 PM <DIR> .. 12/18/2018 04:47 PM <DIR> CryptDisk 04/06/2018 06:40 PM <DIR> Eps13 08/28/2018 01:42 PM <DIR> mnt 07/26/2018 04:07 PM <DIR> nurl 05/14/2018 12:18 PM <DIR> Out 05/18/2018 12:19 PM <DIR> symchk 01/28/2018 01:30 PM <DIR> VS17 01/10/2019 07:43 PM <DIR> winfsp 01/10/2019 07:36 PM <DIR> WinFSPX 0 File(s) 0 bytes 11 Dir(s) 23,225,282,560 bytes free

Target Configuration

1. Boot the target VM.
   There may be a long delay while the target waits for a response from the WinDbg host.
2. Get the current configuration using bcdedit (running as administrator on the target): C:\>bcdedit /dbgsettings key 3t9cfwij47bf3...ardfcumlhdi6 debugtype NET hostip 192.168.0.208 port 49999 dhcp No The operation completed successfully.
   hostip should be the address of the VM running WinDbg (VS17c). This can be updated using
   bcdedit /dbgsettings net hostip:192.168.0.7 port:49999
3. Configure the host and launch WinDbg
4. Reboot the target
   The target should connect to WinDbg quickly, indicated by text appearing in the WinDbg console:
   Using NET for debugging Opened WinSock 2.0 Waiting to reconnect... Connected to target 192.168.0.217 on port 49999 on local IP 192.168.0.7. You can get the target MAC address by running .kdtargetmac command. Connected to Windows 10 15063 x64 target at (Thu Dec 12 11:33:40.467 2019 (UTC - 7:00)), ptr64 TRUE Kernel Debugger connection established. There may be disturbing and mysterious delays during the target boot. I believe these may be due to symbol lookups, but I was never able to get rid of them.

Host Configuration

1. Launch WinDbg
2. Set the symbol path
   C:\VS\Symbols;srv*
   I specify only local paths. Having WinDbg try to fetch symbols from the Microsoft server introduces random and lengthy delays, especially when I am using a limited (or non-existant) internet link.
   
3. Set the source path
   S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Driver2\DeviceDisk;S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Driver2;S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\WinKM;S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Driver2\DeviceIFS
   
4. Determine the host IP address using ipconfig.
5. Start a kernel debug session
   File > Kernel debug...
6. Select NET
   Port number: 49999
   Enter the key from the target's bcdedit output: 3t9cfwij47bf3...ardfcumlhdi6
7. Click OK
8. WinDbg will wait from an incoming debug session from the target.

Debugging CryptDisk.exe

Debugging a user-mode process is actually a bit trickier than debugging the driver.

WinDbg needs to break in user-mode to set user-mode breakpoints. It is not able to set breakpoints in CryptDisk.exe from the breakpoint in CryptDriver.sys!DriverEntry.

WinDbg can launch a new process:
.create

WinDbg can attach to an existing process:
.attach processID
Get the processID from .tlist

Using Visual Studio (See ):
Set Project Properties > Debugging > Debugger to launch: to Remote Windows Debugger. Launch Remote Debugger on the target.

I had problems connecting, with VS reporting "connection terminated." This means there was no firewall or network problems (that triggers a different error message) and the remote debugger on the target was rejecting the connection due to failed authentication. I eventually realized this because the Microsoft Domain situation had changed and Win10Target was no longer part of the domain, and was unable to authenticate the user account Visual Studio was presenting. I changed the connection type to "no authentication" and was able to connect. Since correcting the domain situation is a daunting oddysey and there is ZERO chance of some hacker invading my local network, running without authentication is perfectly fine by me. Microsoft, on the other hand, thinks this is a very bad idea and changes the settings back to "with authentication" every time it starts.

Windows Defender SmartScreen

Updating CryptDisk is easy, just overwrite the binaries with the new versions. (I typically just copy them to C:\Bin)

I may see a warning when I try to run the new version:

I'm not sure which version of Windows introduced this, I first started seeing it in Dec 2019. It is yet another attempt by Microsoft to pretend it is providing security when it is actually not. It is pointless to tell me that an app is running when I just explicitly launched it, without telling me anything about what the app is doing. The natural reaction will always be to click "Run anyway", allowing Microsoft to then disavow any responsibility for what the program is then allowed to do.

Real security would be to allow me to know what system services the app is tying to use and then be able to allow or disallow those actions before they happen -- not just an all-or-nothing uninformed choice at install time.

Anyway, just click "Run anyway" and the new version of CryptDisk.exe will be registered as an allowed app.

See also:

• StackOverflow: How to avoid the “Windows Defender SmartScreen prevented an unrecognized app from starting warning”