This research is concluded. I set out to understand how Respondus LockDown Browser 2.1.5.01 classifies its environment, records internal detection state, and divides responsibility between user-mode components and its Windows kernel driver.
The result is an evidence-graded technical record rather than a finished exploit. This is independent research, unaffiliated with Respondus. The public repository contains my notes and findings, does not include the analyzed binaries, and does not provide a working examination-security bypass. A YouTube breakdown of the research is planned.
The Research Target
The analyzed build was made up of three main components:
LockDownBrowser.exe, the primary user-mode application.LockDownBrowser.dll, a supporting library with UI, input, and hook-related behavior.LockDownService215.sys, a Windows filesystem minifilter driver.
The initial question sounded narrow: how does this version detect a virtual machine? The evidence quickly showed that there was no single VM check to find. Environment classification was distributed across hardware identity, Windows device inventory, BIOS and registry values, process and module paths, sessions, runtime artifacts, and kernel-visible activity.
How I Investigated It
I combined static and dynamic analysis instead of trusting one decompiler view or one runtime observation.
- Ghidra for x86-64 PE analysis, cross-references, data structures, and reconstructed control flow.
- Frida for early runtime instrumentation and string-table tracing.
- Windows API analysis across SetupAPI, COM, the Registry, PSAPI, ToolHelp, Services, WTS, and Filter Manager.
- Manual reconstruction of state writers, serializers, comparison helpers, and protected dispatcher paths.
- External observation when instrumentation began changing the target's behavior.
I labeled findings as confirmed only when they were supported by static structure, runtime data, API use, tracing, or reconstructed control flow. Anything that did not reach that bar remains explicitly open in the research log.
What I Mapped
The clearest result was a much better model of the environment-classification pipeline.
I recovered a 26-entry device-prefix collection covering indicators associated with Parallels, VMware, VirtualBox, QEMU, Xen, VirtIO, AWS, and Wine. I also mapped related checks against device descriptions, friendly names, BIOS values, system-manufacturer data, CPU identity, and COM device names.
Three non-zero internal rldbvm states emerged from the analysis:
rldbvm=1is associated with broader hardware and platform classification.rldbvm=2is written by username, process or module path, and periodically refreshed runtime-artifact paths.rldbvm=3represents an expected-device consistency failure involving display-like hardware and a PCI Express root.
A separate rldbdetect mechanism records broader hack or tamper conditions. One useful architectural finding was that a runtime artifact collection can contribute to both VM classification and general detection state, so those systems are related rather than perfectly isolated.
User Mode, Kernel Mode, and Telemetry
The kernel component is not just a passive service. LockDownService215.sys registers as a filesystem minifilter and imports callbacks for process creation, thread creation, and image loading. The analyzed components also expose the capability for user-mode and kernel-mode communication.
At the same time, I was careful not to turn capability into a claim about policy. I found direct readers that serialize VM state into telemetry or status data, but I did not confirm the final consumer that turns every classification into an enforcement decision. That distinction is one of the most important outcomes of the project: finding a detection flag is not the same as proving what the application ultimately does with it.
The Protected Control Flow
Some of the hardest regions used deliberate control-flow protection that made ordinary function boundaries unreliable. The techniques I confirmed included:
- Overlapping instruction streams.
RETgadgets embedded inside other instruction bytes.- Synthetic return stacks.
- Opaque arithmetic predicates.
- Computed dispatch and small arithmetic gadget chains.
Manually following those chains established how the protection worked, but eventually produced less information about the application's behavior than tracing state, policy, and operating-system effects. That changed the direction of the research rather than invalidating it.
Where Dynamic Analysis Stopped Helping
Direct Frida spawning interfered with startup and authentication. Attaching after a normal launch also caused the instrumented processes to terminate shortly after hooks were installed.
I documented that instrumentation-sensitive behavior and did not attempt to defeat it. From there, I leaned more heavily on static reconstruction, previously recovered runtime data, external observation, and non-invasive tracing.
Why I Concluded the Research
The project reached a natural point of diminishing returns. The high-level architecture, major VM-state writers, device and registry indicators, shared detection state, kernel capabilities, and obfuscation strategy were documented. The remaining questions would require substantially more time in protected dispatcher chains and an unmapped user/kernel protocol.
Those open questions are preserved instead of being papered over:
- The exact semantic label for every internal VM category.
- The remaining protected selectors and artifact record types.
- The complete policy transition from classification to enforcement.
- The driver's IOCTL and minifilter communication protocol.
- The exact purpose of several recovered process and accessibility tables.
Stopping here was part of doing the research honestly. The repository distinguishes what I observed, what I reconstructed, and what I still could not prove.
Published Notes and Upcoming Video
The complete evidence log, address-level notes, confirmed-versus-open matrix, and credits are available in the public research repository. Research by arcticdev00 on an earlier version provided a valuable starting point for this investigation.
I will turn the work into a YouTube video that explains the investigation at a more approachable level. Until that is published, the repository is the canonical technical record.