Lockdown now closes windows sandbox

[mayed505]

Lockdown now closes windows sandbox

[gucci-on-fleek]

Well I'm honestly surprised that this has worked for 2 years now without any patches. I'll look into it though and see if it's easy to fix

[mayed505]

Same here. quite surprised they never picked that out.

I wouldn't be surprised if the hard-coded a function sees if there's a folder named "Runtime_directory" on desktop

[mayed505]

After looking into this, lockdown created a newer update as a security patch.

This could be them using the "wsb-detect" library or something similar to such as detecting the Username of the Windows Sandbox such as "WDAGUtilityUserAccount" or most likely trying to see if there's a running process called "CExecSvc.exe".

I will be digging around and seeing if I can figure out something here.

[mayed505]

I figured it out, it's detecting to see if there's a service running called:
-> Service Host: Network Service -> "Remote Desktop Services" and killing that process that closes down the sandbox.

[mayed505]

update: I was able to hide the processes for RDP however, whenever I disable or stop VmComputeAgent.exe is closing down Windows Sandbox which makes me think the lockdown browser tries to end process "VmComputeAgent.exe" or in short, Hyper-V Guest Compute (System32 File).

Any idea how we would be able to hide it from the process list?

Edit: It's called Hyper-V Guest Compute Service from the Taskmager / Process List

[gucci-on-fleek]

To get the process list, the Lockdown Browser is using the EnumProcesses Win32 function. Now, you'd think that we'd be able to hook this just like we hooked GetSystemMetrics:

lockdown-browser/src/GetSystemMetrics-Hook.cpp

Lines 9 to 21 in af9bfd4

	static int(WINAPI *Original_GetSystemMetrics)(int nIndex) = GetSystemMetrics; // Save the original function
	int WINAPI Hooked_GetSystemMetrics(int nIndex)
	{
	if (nIndex == SM_REMOTESESSION)
	{
	return 0; // Make it look like this is a local session
	}
	else
	{
	return Original_GetSystemMetrics(nIndex); // Don't override the other SystemMetrics requests
	}
	}

but that doesn't actually work. If we run the Lockdown Browser in a quasi-debugger, we can see that the calls to GetSystemMetrics look something like:

GetSystemMetrics(0) -> 600
GetSystemMetrics(1) -> 360
GetSystemMetrics(2000) -> 0
[etc.]

Now, the calls to EnumProcesses are a lot more interesting:

LoadLibraryW(PSAPI) -> 74e80000
GetProcAddress(74e80000,EnumProcesses) -> 74e813c0
[nothing]

Instead of actually calling the function named EnumProcesses, it looks up the function's address in psapi.dll, then calls the address. This is almost certainly made to deter any function hooks, making this a little trickier to work around.

I'll keep investigating though, although I can't promise anything.

[mayed505]

So with that newer update instead of going through EnumProcesses it is now looking up the function's address via psapi.dll?

I originally spent hours working out which process it was detecting, the only thing it made sense to me was when ending a specific process I've said above which yielded the same result (closing Windows Sandbox) so I figured it was that.

The reason was whenever you launch Lockdown Browser and for example, it detects the anydesk_service.exe instance, it would ask you to close it. However, with this new update only specifies this:

I can provide you with the newer update if you don't have it available though D:

[mayed505]

I can confirm the newer patch works now.

Appreciate it. 👍

[gucci-on-fleek]

I can confirm the newer patch works now.

Glad to hear.

So with that newer update instead of going through EnumProcesses it is now looking up the function's address via psapi.dll?

It still uses EnumProcesesses, but it's loading it in a funny way.

The "proper" way to use EnumProcesesses would be something roughly like:

(my C is terrible, so this is very rough and mostly incorrect)

#include <windows.h>
#include <psapi.h>

void main() {
    DWORD lpidProcess [1024];
    DWORD lpcbNeeded;

    EnumProcesses(lpidProcess, sizeof(lpidProcess), &lpcbNeeded);

    return lpidProcess;
}

but the Browser is doing something more like:

#include <windows.h>

void main() {
    BOOL (WINAPI *_EnumProcesses)(DWORD *lpidProcess, DWORD cb, LPDWORD lpcbNeeded);
    DWORD lpidProcess [1024];
    DWORD lpcbNeeded;

    _EnumProcesses = GetProcAddress(LoadLibraryW("PSAPI"), "EnumProcesses")

    _EnumProcesses(lpidProcess, sizeof(lpidProcess), &lpcbNeeded);

    return lpidProcess;
}

So instead of calling the function by name, it looks up the function's address directly from psapi.dll then calls that. If there aren't any hooks installed, these should both have the same result; however, the hooks modify the program so that the name EnumProcesses resolves to the injected dll and not the system one.

The browser has used this weird workaround on EnumProcesses for a few years now (I think), so this project has never hooked that. What has changed in the most recent update is that VmComputeAgent.exe has been added to the list of "forbidden" programs.

[mayed505]

Thanks for the explanation, I’m still learning C as I’ve been more into other web projects such as Node.JS, PHP , backend network administration, etc so this is all new to me.

If they ever stumbled upon this and magically did a new patch fixing this up, I believe the only workaround in the future is to prevent a new automatic update to be installed and run it on legacy instead. I believe it’s kind of possible by tricking it into believing it installed the newer update or just simply blocking the update checker overall. 👍🏻

[mgiedz]

I can confirm the newer patch works now.

Glad to hear.

So with that newer update instead of going through EnumProcesses it is now looking up the function's address via psapi.dll?

It still uses EnumProcesesses, but it's loading it in a funny way.

The "proper" way to use EnumProcesesses would be something roughly like:

(my C is terrible, so this is very rough and mostly incorrect)

#include <windows.h>
#include <psapi.h>

void main() {
    DWORD lpidProcess [1024];
    DWORD lpcbNeeded;

    EnumProcesses(lpidProcess, sizeof(lpidProcess), &lpcbNeeded);

    return lpidProcess;
}

but the Browser is doing something more like:

#include <windows.h>

void main() {
    BOOL (WINAPI *_EnumProcesses)(DWORD *lpidProcess, DWORD cb, LPDWORD lpcbNeeded);
    DWORD lpidProcess [1024];
    DWORD lpcbNeeded;

    _EnumProcesses = GetProcAddress(LoadLibraryW("PSAPI"), "EnumProcesses")

    _EnumProcesses(lpidProcess, sizeof(lpidProcess), &lpcbNeeded);

    return lpidProcess;
}

So instead of calling the function by name, it looks up the function's address directly from psapi.dll then calls that. If there aren't any hooks installed, these should both have the same result; however, the hooks modify the program so that the name EnumProcesses resolves to the injected dll and not the system one.

The browser has used this weird workaround on EnumProcesses for a few years now (I think), so this project has never hooked that. What has changed in the most recent update is that VmComputeAgent.exe has been added to the list of "forbidden" programs.

Not to be that guy but maybe for the sake of us students you could remove the comment that hands them the answer to patching this? 🙏

[mayed505]

Not to be that guy but maybe for the sake of us students you could remove the comment that hands them the answer to patching this? 🙏

I mean, they could see the commit and know what we've done exactly. Even if they decide to patch it, there can be always a bypass no matter what. Lockdown isn't some sort of kernel application.

[gucci-on-fleek]

@mgiedz

Not to be that guy but maybe for the sake of us students you could remove the comment that hands them the answer to patching this? 🙏

Wouldn't do any good since

1. They clearly already know how to block functions from being hooked, since they are already doing so for EnumProcesses

2. The actual code itself clearly shows which functions I'm hooking
   

   lockdown-browser/src/GetSystemMetrics-Hook.cpp

   Lines 9 to 22 in c284f12

   	static int(WINAPI *Original_GetSystemMetrics)(int nIndex) = GetSystemMetrics; // Save the original function
   	int WINAPI Hooked_GetSystemMetrics(int nIndex)
   	{
   	if (nIndex == SM_REMOTESESSION)
   	{
   	return 0; // Make it look like this is a local session
   	}
   	else
   	{
   	return Original_GetSystemMetrics(nIndex); // Don't override the other SystemMetrics requests
   	}
   	}

   I mean, look at the filename!

3. Those code snippets are my reconstructed version of the code in the Lockdown Browser. The people from Respondus don't need that since they already have the actual code for the Lockdown Browser!

4. The point of this tool is to show school administrators that the Lockdown Browser is trivial to bypass so that they stop forcing what is essentially spyware onto their students. The point is not for students to use this on actual exams for the purpose of cheating, since that would just make administrators think that the solution is more spying. (I'm not stupid though — I know what people are actually using this tool for)

---

I mean, they could see the commit and know what we've done exactly. Even if they decide to patch it, there can be always a bypass no matter what. Lockdown isn't some sort of kernel application.

Yep, unless I make this project closed-source, then it's trivial for Respondus to patch any of these issues. Of course, the point of this project is to avoid running sketchy closed-source software on your computer, so this project kinda needs to be open source.