gucci-on-fleek
commented
1 year ago Hmm, that's a new one. Might be easy for me to patch, might not. Unfortunately, I don't have any Windows 11 computers right now. I'll try and set up a VM, but it might be a while before I get around to it.
You might just be able to hook the EnumProcesses, function, but I seem to recall that the Browser tries pretty hard to prevent you from hooking that function through some GetProcAddress trickery. EnumProcesses is exported by kernel32.dll (and also psapi.dll, but I don't think that the Browser uses that one) so it's not like we can easily bypass the whole library.
I see a few options forward here:
- If
EnumProcessesisn't protected, then we can just hook it like we do withGetSystemMetrics. My recollections suggests that this is probably not the case. - Killing
vmcomputeagent.exekills the VM pretty abruptly if I remember correctly, so any solution that requires killing or relaunching the program is completely out of the question. But we should be able to delete or rename the file while the process is still running, which may trick the Browser. - We could always hook
GetProcAddress. We'd need it to return a valid function pointer somewhere inkernel32.dll, but there might be an inert enough function with a close enough function signature that this might work. Returning an error forGetProcAddressmight also work, but I kind of doubt it. - Binary patch the
LockdownBrowser.exefile. This is a bit of a pain since the Browser is fairly decent at making sure that it hasn't been modified. Not insurmountable, but kind of a pain. - Have a program launch the Browser, suspend the process, patch out the detection code in memory, then resume the process. Again based off of this article, it looks like the Browser only verifies that its executable file is intact, not its memory. This is kind of a pain, but looks like a decent option forward.
- Binary patch
kernel32.dll. This option is fairly insane, but since we're in an ephemeral VM, it is actually doable. I haven't checked how the Browser enforces the DLL load paths, but we may even be able to just drop a modifedkernel32.dllin the same folder as the Browser which would actually be relatively straightforward. - The really crazy option is of course to make a custom kernel module/driver. This is complicated by the fact that kernel development is hard, driver signature enforcement, and the fact that the Windows Sandbox doesn't let you load kernel modules. Not a very good option.
If it's just (1) or (2), then there's a chance (but no guarantee) that I'll have time to fix it in the next month or so. If it's any of the other options, then I have no idea when (or if) I'll have enough free time to patch this. You're best bet here is to submit a PR, which I would be completely willing to review and merge.
Boane
When building and trying to open Sandbox-with-Microphone-Camera.wsb, LockDown browser does not automatically install. After manually installing LockDown browser in the Sandbox and launching with
.\withdll.exe /d:GetSystemMetrics-Hook.dll "C:\Program Files (x86)\Respondus\LockDown Browser\LockDownBrowser.exe"results in a "You must close the following program before starting LockDown Browser: vmcomputeagent.exe" error.I am currently using Windows 11 Pro 22H2 and LockDownBrowser v2.1.0.02.