Debugger & analysis detection
Recognizes when debugging or reverse-engineering tools are attached to the exam process.
A browser built to keep an exam honest.
WriteATest locks a candidate's machine into an isolated exam environment, continuously verifies the integrity of the session, and reports everything to a server that never trusts the client's word for whether it's clean.
telemetry · session 7f3a…
- consentCandidate accepted monitoring noticeok
- desktopMoved to isolated exam desktopok
- debuggerNo debugger attached to exam processclear
- memoryCode pages checked against signed baselinematch
- handlesExternal process opened a handle to the examflagged
- verdictComputed on the server, not the clientreview
Illustrative session — see the demo console for the full view.
Who it's for
Built where a clean machine can't be assumed
WriteATest KIOSK is designed for organizations issuing exams whose results carry real consequences.
Certification & licensing bodies
Professional and technical certifications where a compromised result affects who gets hired, licensed, or credentialed.
Higher education
Remote and in-lab coursework, qualifying exams, and admissions assessments run outside a proctor's direct line of sight.
Corporate assessment & hiring
Technical screens and internal certifications that feed directly into a hiring or promotion decision.
Training & credentialing providers
Course providers issuing a credential at the end of a program, where the final exam is the only checkpoint that matters.
How it works
What happens when a candidate presses start
Every session moves through the same stages, host to server, before a single answer is submitted.
01
Consent & bootstrap
The candidate sees a plain-language consent screen naming what's monitored during the session before anything starts.
02
Environment lockdown
The session moves to an isolated exam environment. The regular desktop, background apps, and common escape shortcuts are unavailable for the duration of the exam.
03
Sandboxed session
The exam runs inside a contained browser session. Ending it, timing out, or a proctor stopping it cleans up everything that ran alongside it.
04
Continuous verification
Signal about the state of the machine streams to the server for the whole session — the server makes the call on whether something looks wrong, never the candidate's own device.
Security
The anti-tamper engine
A layered set of detectors runs continuously in the background of every session, reporting signal to the server for an authoritative call — never a self-graded pass/fail.
Memory integrity verification
Confirms the application's code in memory matches what was originally shipped — checked independently on the server, never taken on the client's word.
Transient tamper detection
Designed to catch tampering that's undone before a routine check would otherwise notice it.
Code injection defense
Watches for code introduced into the exam process's memory at runtime, from outside the normal application flow.
Unauthorized software detection
Identifies untrusted libraries and applications loading into or interacting with the exam session, and flags anything unrecognized for review.
Process & access monitoring
Flags other processes on the machine attempting to inspect or reach into the exam session while it's running.
Under the hood
Where the verdict actually gets computed
For the engineers evaluating this rather than buying it: the exam machine only ever reports. It never decides.
exam client
WatGuard + Browser
Runs on the candidate's machine.
Reports raw signal onlyraw signal
telemetry server
Independent verification
Checks every signal against the signed baseline.
The client never grades its own examverdict
console
Your ops team
Proctors and reviewers.
Sees the verdict, live
Lockdown
An exam desktop, not a locked-down browser tab
WriteATest doesn't rely on window-focus tricks alone. It moves the candidate to a separate, isolated desktop environment for the duration of the exam — no regular shell, no taskbar, no background apps — with common escape routes unavailable at the system level rather than the application level.
A minimal exam taskbar keeps session status visible and gives the candidate exactly one way out: an authorized Exit Exam control.
- Task switchingblocked
- Start menublocked
- Forced app closureblocked
- Screen captureblocked
Exit Exam — the one authorized way out
Principles
Why institutions choose WriteATest
A few deliberate design decisions shape how the product behaves — and why they matter for exam integrity.
01
The server makes the call, not the client
Every check reports raw signal upstream. A compromised machine never grades its own exam — the verdict is computed server-side, out of the candidate's reach.
02
A full desktop, not a locked tab
Lockdown happens at the OS level in an isolated desktop session — not by disabling shortcuts inside a browser tab that a second window or a second monitor can route around.
03
Built to catch what resets itself
Some tampering is undone before a routine scan would notice it. The detection layer is built to keep watching, not to check in on a schedule.
04
Wraps your exam platform, doesn't replace it
WriteATest locks down the environment around the exam. Your existing exam content, question bank, and grading pipeline stay exactly as they are.
Compare
How this compares to a typical lockdown browser
Most browser-based exam lockdown tools share a common architecture. WriteATest departs from it in a few specific, load-bearing ways.
| Capability | Typical lockdown browser | ✳︎ WriteATest KIOSK |
|---|---|---|
| Integrity verdict | Self-reported by the exam client | Computed independently on the server |
| Session environment | A browser tab or fullscreen window with JS-based restrictions | A separate, isolated desktop session at the OS level |
| Detection cadence | Periodic checks on a timer | Continuous background monitoring for the whole session |
| Tampering that self-reverts | Often missed between scheduled checks | Purpose-built detection layer designed to catch it |
| Debugger & injection defense | Basic devtools/window checks | Layered anti-debug, memory integrity, and code injection detectors |
| External process access | Not typically inspected | Cross-process handles evaluated server-side, not self-reported |
| Second monitor / second device | A common blind spot for tab-based lockdown | Mitigated by full desktop lockdown at the OS level |
| Telemetry console | Usually vendor-hosted only | Self-hostable on infrastructure your team controls |
"Typical lockdown browser" describes common patterns across mainstream browser-based exam-lockdown tools as a category, not any single named product.
FAQ
Frequently asked questions
What security and testing teams usually ask before a pilot.
What does WriteATest actually run on?
The exam client is a Windows application built to run on the same exam-center or proctored-lab workstations institutions already deploy — no browser plugin to install or keep updated.
Does it replace our existing exam platform?
No. WriteATest wraps the session your exam platform already delivers. It locks down the environment and streams integrity telemetry; your exam content, question bank, and grading stay on your existing system.
What happens when tampering is detected mid-exam?
The detection lands on the telemetry console in real time. What happens next — flag for review, end the session, or let a proctor decide — is a policy your team sets, not a decision the client makes on its own.
Can we self-host the telemetry console?
Yes. The console is a separate service from the exam client, so it can run on infrastructure your team controls instead of a shared environment.
What data leaves the candidate's machine?
Integrity signal — process, memory, and environment state relevant to detecting tampering — not exam content or candidate answers, which stay inside your exam platform's own data path.