Injection attacks bypass your camera entirely — feeding synthetic video directly into your verification pipeline. Here's the first definitive guide to detecting and stopping them.

Most identity verification providers focus their security on what appears in front of the camera. Is it a real face or a printed photo? Is the person live or a screen replay? These are the right questions — for presentation attacks. But they are the wrong questions for injection attacks, because injection attacks never present anything to the camera at all.

An injection attack intercepts the video pipeline between the camera and the verification system, replacing genuine camera frames with synthetic ones. The verification application believes it is processing a live camera feed. It is processing a deepfake. Every downstream check — liveness detection, face matching, document capture — operates on fabricated data and cannot be trusted.

This is the attack vector that liveness detection was never designed to catch. And it is the vector that sophisticated fraudsters and AI fraud agents are increasingly exploiting, precisely because they know the industry's primary defense does not address it.

How Injection Attacks Work

Method 1: Virtual Camera Software

Virtual camera applications — OBS Virtual Camera, ManyCam, Snap Camera, and similar tools — create a software-defined camera device that appears to operating systems and applications as a physical camera. The application presents a video source (a pre-recorded deepfake, an AI-generated face, or a real-time face-swap output) through the virtual camera. When the verification application requests camera access, the OS offers the virtual camera alongside any physical cameras. If the user selects the virtual camera (or if the system is configured to default to it), the verification session processes the synthetic feed.

Detection approach: Device enumeration and camera attestation. The verification system identifies all available camera devices, checks whether each is a physical hardware device or a software-defined virtual camera, and blocks sessions originating from virtual cameras. On mobile devices, the verification SDK can validate the camera's hardware attestation through platform APIs (Android's SafetyNet/Play Integrity, Apple's DeviceCheck).

Method 2: Modified Application Binaries

More sophisticated attackers modify the verification application itself — patching the binary to replace the camera capture function with a function that reads from a file or stream. The application appears to function normally, but the camera module is compromised at the code level.

On mobile devices, this typically involves jailbreaking (iOS) or rooting (Android) the device, then modifying the verification SDK or the application binary. On web applications, browser extensions or developer tools can intercept the getUserMedia API that provides camera access, replacing the genuine camera stream with a synthetic one.

Detection approach: Application integrity verification. On mobile, the SDK should perform runtime integrity checks — detecting jailbreak/root status, verifying the application binary against a known-good hash, and checking for hooking frameworks (Frida, Xposed, Substrate) that enable function interception. On web, the system should detect browser extensions that intercept media APIs and verify that the getUserMedia response originates from a hardware device.

Method 3: API Interception

For verification systems that expose APIs for frame submission, an attacker can bypass the client application entirely — sending crafted frames directly to the API endpoint. The attacker captures the API call structure from a legitimate session, then replays it with deepfake frames substituted for genuine camera frames.

Detection approach: Session binding and frame provenance. Each verification session should be cryptographically bound to a specific device and time window. Frames should include device-signed metadata that cannot be replicated outside the genuine client application. Challenge-response mechanisms — where the server sends an unpredictable challenge that must be reflected in the next frame (e.g., a specific light pattern displayed on screen that the camera must capture) — make pre-recorded frame submission impossible.

Method 4: Emulated Devices

Android emulators (BlueStacks, Genymotion, Android Studio Emulator) can run verification applications with fully synthetic camera feeds. The emulator presents itself as a genuine Android device with a camera, but the "camera" is a software-defined input that can be fed any video source.

Detection approach: Emulator detection through hardware analysis. The verification SDK examines device characteristics that emulators cannot perfectly replicate — specific hardware identifiers, sensor data (accelerometer, gyroscope, magnetometer), battery information, build properties, and kernel-level indicators. A genuine device has consistent, specific hardware signatures. An emulated device has generic or inconsistent signatures that can be fingerprinted.

Suggested read: Technology — How deepidv's Verification Engine Works

Why Liveness Detection Cannot Catch Injection Attacks

The fundamental limitation of liveness detection against injection attacks is that liveness evaluates the content of the video — the face, its movements, its texture — not the source of the video. A deepfake injected through a virtual camera or modified app delivers content that is indistinguishable from a genuine face to liveness algorithms, because it was designed specifically to produce that result.

Active liveness (asking the user to perform an action) fails because the injected video can perform the action. A deepfake face can blink on command, turn to the side, and follow an on-screen target — because the face-swap is running in real time, mapped to the attacker's actual movements. The deepfake performs the liveness challenge perfectly because the attacker behind it is a real person performing the actions.

Passive liveness (evaluating frame characteristics) fails because the injected frames have been processed to match the characteristics of genuine camera output. Texture analysis, depth estimation, and reflection detection all evaluate properties of the image that a sufficiently sophisticated deepfake can replicate.

Injection detection must operate at the platform level — evaluating the integrity of the capture pipeline before the content reaches the biometric engine. It is a separate, prerequisite layer, not a component of liveness detection.

Building the Detection Architecture

Mobile SDK (iOS and Android)

The mobile SDK is the strongest injection defense because it controls the capture environment. Key detection capabilities include device attestation via platform APIs, camera hardware validation (blocking virtual cameras at the OS level), runtime integrity checking (jailbreak/root detection, hooking framework detection), application binary validation (hash verification against known-good builds), environmental analysis (emulator detection, screen recording detection, developer mode detection), and frame provenance signing (each captured frame is cryptographically signed with device-specific keys).

Web Browser

Web-based verification has a larger attack surface because the browser provides less hardware-level control. Detection capabilities include WebRTC device enumeration (identifying virtual vs physical cameras), browser extension detection (flagging extensions that intercept media APIs), getUserMedia source validation, browser fingerprinting (detecting headless browsers and automated environments), and challenge-response frame validation.

API Layer

Even with strong client-side detection, the API must independently validate frame provenance. Server-side detection includes session token validation (confirming frames originate from a bound session), frame timing analysis (are frames arriving at the expected rate and timing for a genuine camera?), metadata consistency checking (do frame metadata attributes match the claimed device?), and statistical analysis of frame sequences (genuine cameras produce frames with specific inter-frame variation patterns that synthetic sources cannot perfectly replicate).

Injection Attack Detection FAQ

What is an injection attack in identity verification?

An attack that bypasses the physical camera by feeding synthetic video directly into the verification pipeline — using virtual cameras, modified apps, API interception, or emulated devices. The verification system believes it is processing a live camera feed when it is processing fabricated video.

Can liveness detection stop injection attacks?

No. Liveness detection evaluates the content of the video (the face), not the source. An injected deepfake performs liveness challenges perfectly because the attacker behind it is a real person whose movements are mapped onto the synthetic face.

How does deepidv detect injection attacks?

Through device attestation, camera hardware validation, application integrity checking, emulator detection, and frame provenance signing — all operating before a single frame reaches the biometric engine.

What is frame provenance signing?

A technique where each captured frame is cryptographically signed with device-specific keys. The server verifies the signature before processing the frame. Frames without valid signatures — or with signatures from unauthorized devices — are rejected.

Is injection attack detection mandatory for compliance?

Not explicitly yet. But FinCEN's effectiveness-based AML standard, MiCA's "reliable and independent" verification requirement, and Japan's FIEA securities-grade KYC all implicitly require detection that catches the threats actually being used against verification systems. If injection attacks are the primary threat vector and your system does not detect them, your verification is not "effective" or "reliable."

Book a demo to see injection-proof verification running on your integration.