The Respondus LockDown Browser is an application designed to “lock down” a system for the duration of an exam. It claims to display a full screen browser that cannot be minimized, prevents task switching, stops “over 400 screen capture, messaging, screen-sharing and network monitoring applications” from running, blocks external links to avoid compromising the “locked testing environment”, and so forth. The application is intended to (1) stop students from accessing external material while taking the exam, (2) stop students from recording the examination quesitons, and (3) stop students from communicating with others – all in an effort to stop cheating.
I learned about this application over the weekend when an online exam for a class I am taking this semester required its use. I was quite annoyed to learn it did not have a linux client and relied on Internet Explorer. Using linux as my primary OS, I naturally loaded it into a VMWare copy of Windows XP only to discover it refuses to run in a virtual machine. Not wanting to go all the way to campus to take the exam, I fired up IDAPro and decided to take a look at the VM detection mechanisms – needless to say I was unimpressed.
First I searched for the error message I received when I tried running LockDown in VMWare. I found it here, showing its address as 0x49BE08. I note this for later.
Wondering about the detection mechanism I next search for strings containing VMWare. If you notice these strings are all located near each other in the data section which made me suspect an array of device information the LockDown browser was searching for. These are located near 0x4988F8.
Here at 0x49BE08 we find the error string. Using IDAPro we can examine what areas of the program references this location.
The error string we are interested in is only referenced one time by a subroutine at 0x40AC25. We navigate to this area to analyze it further.
Here is the beginning of the referencing subroutine. We scan down the instructions looking for where it jump to the kill.
Here at 0x40AEEB the address for the error string is pushed onto the stack before calling to another subroutine. Without analyzing too deeply we can guess the call generates the error before exiting. Let’s look up a little to see how we get to this section of code.
Here at 0x40AEBD and 0x40AECB we find two Jump on Not Zero (jnz or opcode 75) instructions which jump to the section of code that generates our error. We can assume, therefore, the subroutines and tests performed prior to these determine if (on zero) a VM is not present or (on non-zero) if a VM is present. Take note of 0x40AEDB, this instruction jumps over the kill section to what looks like another test. Let’s clean up the labels a little before we plan our attack.
So now we have what seems to be two tests looking for virtualization, an exit if VM found section, and a PostVMTest section testing for other things. We saw earlier what looked like VMWare device names in what seemed to be an array, this indicates LockDown may be using the detection mechanism of relying on known names of VM devices. There are more complicated detection methods out there, see all the research on detecting Blue Pill for details on that, but all indications are none of these more advanced techniques are used in LockDown.
Next I switch to OllyDbg to edit the jump statements. There are a lot of possible ways to defeat the virtualization detection, mangling the device info strings might work for example, but I instead chose a more elegant solution. Instead of stopping the detection, I alter the jnz addresses to be the next test thats jumped to by the last jz instruction. The jnz will now jump to 0x40AF1C instead of 0x40AEDB. The virtualization is detected, but the error/exit section is never reached.
This video is recorded in VMWare. It shows me opening the LockDown browser and getting the error message, then editing the executable, resaving it, and launching the modified version. The modified browser launches and brings me to UNO’s blackboard login page ready to take my exam. Half an hour of poking around and changing 2 bytes of data saved me a trip to campus and exposed the LockDown browser as a joke. Once in a virtual environment everything they claimed to prevent is null and void.
What’s the moral of the story? First, if you don’t provide a linux version, and you refuse to work in a virtual machine someone is going to break your flimsy protections to make it work. Second, don’t post this on your website:
“Hacker Tested, Market Approved – Hundreds of universities and schools around the world use Respondus LockDown Browser. It seems that at least one person (or team) at each institution makes it a quest to “break out” or beat the system. Some of the best minds have taken our software to task over the years, and we’ve addressed each issue that’s been raised. (Yes, you have our blessing…go ahead and see if you can break it.)” http://www.respondus.com/update/2009-1-b.shtml
I give this product a resounding FAIL.