How do exam bots use screen-sharing to leak live test content?

The broadcast model of cheating

The classic image of exam cheating is a lone student with a hidden phone. The industrial version is a broadcast: one test-taker shares their screen to a solver, who works through the questions in real time while feeding answers back through a hidden earpiece or a second device. The screen share is the uplink. Everything downstream, the solving, the distribution, the answer relay, depends on that live feed.

Bots automate the harvesting side. Screen-capture bots join shared sessions, record the question stream, and feed it into question-bank databases that the operation sells or reuses. A single shared screen during a high-stakes exam can yield dozens of fresh questions, complete with the exact wording and answer options. The test-taker thinks they are getting help on one exam. They are actually supplying the raw material for hundreds of future cheating attempts.

How the sharing evades detection

The evasion exploits the gap between the exam environment and the device. In a lockdown browser, screen sharing can be detected and blocked. But many exams run in standard browsers on personal devices, where the test-taker can run screen-sharing software alongside the exam with nothing in the exam environment the wiser. The proctor sees a compliant test-taker. The device is doing something else entirely.

More sophisticated setups use hardware: a second machine capturing the screen via HDMI, or a phone filming the monitor from an angle the webcam cannot see. These leave no software trace on the test device at all. Detection then depends on behavioral signals, answer patterns that suggest outside help, or the webcam catching something it should not. Each layer of indirection makes the technical detection harder and the behavioral detection more important.

Detecting the stream

Platform-side detection starts with the environment. Lockdown browsers that enumerate running processes, monitor display capture APIs, and flag virtual display drivers close most of the software-based sharing paths. Network analysis adds another layer: screen-sharing protocols have recognizable traffic patterns, and an exam session with an unexplained concurrent upload stream is worth a closer look.

The behavioral layer catches what the technical layer misses. Solvers working from a shared screen produce distinctive answer patterns: correct answers arriving with unnatural speed on hard questions, response times that correlate with question difficulty in reverse, and answer changes that cluster after long pauses. No single signal proves sharing, but the combination, fast correct answers plus an active upload stream plus a second device on the network, is dispositive.

Designing exams that resist leaks

The strongest defense is making leaked content perishable. Large question banks where each test-taker sees a different subset mean a shared screen reveals only a fraction of the bank. Algorithmic question variants, same concept with different numbers or scenarios, mean the harvested questions do not match what the next test-taker sees. Time pressure calibrated so that consulting outside help costs more time than it saves makes the shared screen useless even when it works.

This is defense in depth applied to assessment. Technical controls raise the cost of sharing. Behavioral analysis catches the sharing that happens anyway. Exam design ensures that even successful sharing yields little value. Testing programs that rely on any single layer, usually the proctoring software, discover its limits at the worst possible moment. The programs that survive the cheating arms race are the ones where the exam itself is the hardest part to beat.