Lockdown browsers rely on a combination of process monitoring, system-level hook injections, display architecture checks, and network traffic control to enforce test integrity. Below is an analysis of the primary methods attempted to bypass these security measures and the technical reasons why they succeed or fail.

1. Virtual Machines (VMware, VirtualBox, Hyper-V)

• How It Works: Running the lockdown browser inside a guest Virtual Machine allows the user to run unmonitored host OS applications (e.g., browsers, AI tools) alongside or behind the VM window.
• Why It Fails (Most Common Outcome): Modern proctoring software checks system parameters at launch to detect hypervisors:
  
  • MAC Address Filtering: Checks for OUI prefixes associated with virtual network adapters (e.g., 00:05:69 for VMware, 08:00:27 for VirtualBox).
  • Device & Registry Artifacts: Scans the registry/system devices for strings like "VBOX", "VMware", or "QEMU".
  • CPU Instructions: Executes the CPUID instruction; bit 31 of register ECX explicitly flags whether the OS is running under a hypervisor.
• Why It Sometimes Works: Advanced users employ hardened/stealthed hypervisors (e.g., custom-compiled KVM/QEMU with spoofed CPU flags, modified ACPI tables, and patched DMI data). By hiding hypervisor signatures, the lockdown browser operates under the assumption that it is running on bare-metal hardware.

2. Secondary Devices & Hardware Video Splitters

• How It Works: Using hardware outside the computer—such as a secondary phone, a physical HDMI splitter passing the display signal to a second monitor, or inline capture cards.
• Why It Fails:
  
  • Webcam/AI Monitoring: Lockdown software bundled with AI monitoring (e.g., Respondus Monitor, Proctorio) flags head movements, gaze tracking, off-screen eye shifts, and secondary faces.
  • EDID / Display Enumeration: On the local OS level, lockdown browsers query display APIs (like Windows EnumDisplayMonitors or macOS CGGetActiveDisplayList). Unapproved dual-monitor setups or active HDMI splitters altering display topology are flagged or blocked immediately.
• Why It Sometimes Works: Purely hardware-level passive splitters or video capture devices placed after the GPU output cannot be detected by software alone, provided the student maintains strict eye contact with the primary screen to avoid triggering webcam flagging.

3. Process Injection, Task Managers, & System Hooks

• How It Works: Attempting to kill the lockdown browser process, modify its memory, or switch focus to background apps via hotkeys (e.g., Alt+Tab, Cmd+Tab, Ctrl+Alt+Del).
• Why It Fails:
  
  • Low-Level Keyboard Hooks: Lockdown software registers global low-level keyboard hooks (or macOS Event Taps) that intercept key combinations before the OS processes them.
  • Process Guarding: Lockdown applications routinely scan running processes and terminate forbidden executables (e.g., Discord, TeamViewer, Zoom). On Windows, some use kernel-mode drivers to prevent process termination via Task Manager.
• Why It Sometimes Works:
  
  • Rogue Background Scripts: Custom scripts running with elevated (administrator/root) privileges that kill the lockdown browser's monitoring sub-routines without closing the main parent window.
  • Zero-Day OS Vulnerabilities: System-level exploits that allow execution outside the restricted desktop shell.

4. Custom DNS & Proxy / Network Manipulation

• How It Works: Routing network traffic through a local proxy (e.g., Burp Suite, Charles Proxy) or modifying DNS records to inspect, block, or manipulate outbound telemetry sent to proctoring servers.
• Why It Fails:
  
  • SSL/TLS Pinning: Modern lockdown applications embed hardcoded cryptographic certificates (certificate pinning). If a proxy attempts a Man-in-the-Middle (MitM) inspection by re-signing SSL traffic with a custom root CA, the application rejects the handshake and terminates the session.
  • Heartbeat Ping Protocols: Software continuously sends encrypted heartbeats to server infrastructure. Blocking or altering telemetry packets results in an immediate exam lockout due to "loss of connection."
• Why It Sometimes Works: If the application relies on standard system trust stores without strict TLS pinning, local interception techniques may occasionally succeed in intercepting unencrypted data payloads.

5. Dual-Booting / External OS Encapsulation

• How It Works: Booting from a secondary OS or using external hardware controllers (e.g., Raspberry Pi-based KVM over IP) to control input/output dynamically.
• Why Works Best (Hardware-Level Overrides): Software-based lockdown browsers are limited by the boundaries of the operating system they run on. If a user routes physical keyboard and mouse inputs through an external hardware micro-controller (KVM device) while mirroring video to an external display, the software records valid system inputs and displays normal performance, rendering pure software detection ineffective without webcam/facial monitoring.