How Video Streams Are Spoofed in KYC: The Architecture of Attacks via Emulators, Virtual Cameras, and Video Stream Injection

Video Stream Injection in Biometrics

Biometric face verification is built on simple logic: the device camera captures the user, the SDK processes the frames, and the server decides whether the subject is genuine. A video injection attack breaks this chain — instead of a real image from the physical camera, the system receives pre-prepared or synthesized video and processes it as though a live person were in front of the lens.

The fundamental difference from presentation attacks (a photo on a screen, a silicone mask, a video played in front of the camera) is that the physical sensor is not involved at all. The data is spoofed in software: at the operating system level, inside the application, or during network transmission. Classic liveness detection mechanisms, designed to analyze optical artifacts — moiré patterns from a screen, glare, lack of depth — are ineffective here. The injected stream looks «clean»: it carries no traces of a physical medium, because the digital image never left the digital environment.

The scale of the threat is growing rapidly. According to industry reports for 2024–2025, the number of attacks using virtual cameras has increased by orders of magnitude, and face-swap injections have tripled compared with 2023. In October 2024, the European Committee for Standardization (CEN) approved the technical specification CEN/TS 18099:2024, which for the first time defined a framework for evaluating systems that detect injection attacks on biometric data. Building on that document, work on the international standard ISO/IEC 25456 began in early 2025. The FIDO Alliance has included Injection Attack Detection (IAD) requirements in its certification program for biometric components. Video stream injection has ceased to be a theoretical threat and has become the primary attack vector against remote biometric verification.

To build a defense, you need to know precisely where and how the data is spoofed. What follows is a breakdown of each injection point: from hooking camera calls inside a mobile application to spoofing packets on the way to the server.

Injection Points from Camera to Server

The path of biometric data from the physical sensor to the server-side verification module involves several links, each of which is potentially vulnerable. The chain looks like this: hardware camera sensor → driver/HAL (Hardware Abstraction Layer) → the operating system’s camera API (Camera2 on Android, AVFoundation on iOS) → the biometric application’s SDK → data transmission channel → server-side processing.

At each transition, an attacker can inject spoofed data. The methods differ in complexity, required privileges, and the degree of control over the device:

• Application level. Hooking Camera API calls within the application process — through dynamic instrumentation (Frida, Xposed) or modification of the APK/IPA. Requires root/jailbreak or running on an emulator. The attacker substitutes the frame buffer before the biometric SDK begins processing.
• Operating system level. Installing a virtual camera that registers with the OS as a physical device. On desktop, this is done with off-the-shelf tools (OBS Virtual Camera, the v4l2loopback module on Linux). On mobile platforms, it is done through Android emulators (Genymotion, BlueStacks) or on rooted devices, where the camera driver can be replaced.

• Network transport level. Interception and spoofing of data between the client and the server. With a proper implementation of TLS and certificate pinning, this vector becomes significantly harder. On a compromised device, certificate pinning is bypassed with the same instrumentation tools, after which the traffic becomes available for modification through a MITM proxy.

A biometric system cannot trust data from the device unless the integrity of the entire chain has been verified — from the hardware sensor to the moment the data reaches the server. Modern protection approaches combine runtime environment checks on the device, cryptographic binding of the stream to the physical camera, and server-side validation of data consistency.

Spoofing by Hooking Camera Calls in the Application

The most common injection vector on mobile devices is hooking Camera API calls directly within the application process. The mechanics of the attack rely on dynamic instrumentation tools: Frida, the Xposed Framework, and their analogs, which make it possible to attach to a running process and change the behavior of any function on the fly.

A typical scenario on Android: the application calls the Camera2 API to obtain a preview from the camera, a Frida script hooks the call to the method responsible for retrieving the frame buffer, and it replaces the buffer’s contents with data from a pre-prepared video file. The application and its embedded biometric SDK receive frames that look like a live capture but are actually read from local storage. The camera interface, meanwhile, may display correctly on the screen.

Carrying out such an attack usually requires root access — it is needed to launch the Frida server and inject into the target application’s process. There is also a root-free scenario: repackaging the APK with an embedded Frida Gadget. The attacker decompiles the application, injects the Frida library, re-signs the APK, and installs the modified version. This approach does not require root, but it assumes the application does not verify the integrity of its own code and signature.

On iOS, similar attacks are possible on jailbroken devices. Tools such as Frida or Substrate make it possible to hook AVFoundation calls, replacing CMSampleBuffer buffers with a synthetic video stream. In September 2025, the industry documented a specialized tool for performing video injections on modified devices running iOS 15 and later, designed to bypass verification procedures.

Spoofing via a Virtual Camera and Modification of the Media Stack

A virtual camera is a software component that registers with the operating system as a full-fledged video capture device. Any application requesting camera access sees the virtual device in the list of sources and can use it on equal footing with a physical sensor. This mechanism is widely used in legitimate scenarios — streaming, video conferencing, working with external cameras — but it also creates a channel for injection.

On desktop platforms the attack is trivial. OBS Studio (with its Virtual Camera feature) or specialized applications create a virtual device with a single click. On Linux this is done with the v4l2loopback kernel module, which creates a virtual video node in the file system at /dev/video*. A prepared video — recorded in advance or generated in real time — is broadcast through the virtual camera. When a KYC provider’s web application running in the browser requests camera access, the user selects the virtual device, and the system receives a synthetic stream and processes it as genuine.

This vector is often combined with real-time face swap. The chain: the physical camera captures the attacker’s face → face-swap software (DeepFaceLive and similar) overlays the target face on the fly → the result is fed through the virtual camera into the verification application. Generative models already operate with a latency of under 50 ms at 720p resolution — enough for most KYC procedures. Liveness detection tools oriented toward the optical artifacts of presentation attacks do not detect the spoof, since the stream contains no physical traces of a screen or mask.

On mobile platforms the situation is more complex, but not blocked. Android emulators (Genymotion, BlueStacks, Nox, and others) make it possible to feed an arbitrary video file into the virtualized camera — a standard feature intended for development and testing. If the KYC application does not recognize that it is running in an emulator environment, the virtualized camera is used for injection. On a physical device with root access, a virtual camera is implemented by replacing the HAL module or redirecting the stream at the driver level.

For web applications running through a browser, the virtual camera remains one of the primary vectors. The browser’s WebRTC and MediaDevices APIs do not distinguish between physical and virtual devices by default. Some protection is provided by metadata analysis: virtual cameras may differ in their characteristics — the absence of information about the hardware sensor’s resolution, an atypical device name, specific behavioral patterns when capture parameters change. These signals are not enough for reliable blocking: experienced attackers modify the metadata to imitate real hardware.

Real-Time Injection of Synthetic Video

The mechanisms of spoofing described above determine how injected data enters the system. No less critical is the question of what exactly is fed into the stream — and here generative technologies radically increase the effectiveness of attacks.

Synthetic video for injection falls into three categories.

Category	Description
Replay of a previously recorded video (replay)	Replay of a previously recorded video (replay). The attacker uses video captured during a previous legitimate verification session, or a prepared recording of the target’s face. The approach is simple to implement but vulnerable to challenge-response: if the system asks the user to turn their head in a random direction or say a random phrase, a canned recording will not pass the check.
Real-time face swap	The attacker sits in front of the camera while a generative model replaces their face with the target’s. This method counters challenge-response: the attacker follows the system’s instructions (turning the head, smiling, blinking), and the model transfers the movements onto the target face in real time. Modern tools operate with a latency imperceptible to the human eye. The quality of the swap depends on the training set: the more photographs of the target face are available, the more accurate the result.
Fully synthetic faces belonging to no real person	Generative adversarial networks (GANs) and diffusion models create photorealistic images of people who do not exist. In the KYC context, such faces are used to create synthetic identities: a forged document with a synthetic photo + injected video with the same face. Because the «person» never existed, a check against anti-fraud databases turns up nothing — the history is clean because it was fabricated from scratch.

The availability of the tools poses a particular danger. Open-source software for face swapping capable of running in real time is publicly available. To run it, a consumer-grade graphics card with CUDA support is enough. Specialized tools for injection attacks are distributed in closed communities, but the barrier to entry is falling: ready-made scripts, step-by-step instructions, pretrained models. According to the World Economic Forum (Cybercrime Atlas report, January 2026), over the next 12–15 months the availability barrier for these tools will continue to fall while the quality of synthesized content will rise.

For verification systems, this means that analyzing only the pixel content of frames is no longer enough. Effective protection requires verifying the source of the data (whether it came from a physical camera), not just its content (whether the face looks real). This is precisely the principle behind the concept of Injection Attack Detection — a security layer separate from liveness detection that works with stream metadata, device characteristics, and runtime environment integrity.

Spoofing During Transmission of Video Data to the Server

The final link in the injection chain is the channel between the client device and the server side of the verification system. Whereas the previous methods spoofed the input data before the SDK finished processing it, here the attacker modifies the already-formed data packet on its way to the server.

The classic variant is interception of HTTPS traffic through a MITM proxy (Burp Suite, mitmproxy, Charles Proxy). Under normal conditions, certificate pinning in the mobile application prevents the attack: the SDK accepts responses only from a server with a specific certificate and rejects fake ones. On a compromised device (root/jailbreak), certificate pinning is bypassed through Frida — a script hooks the certificate check and always returns «trusted». After that, all of the application’s traffic is available to the attacker in plaintext.

Having gained access to the decrypted traffic, the attacker analyzes the structure of the API requests to the verification server. Biometric data is usually transmitted as JPEG/PNG images or encoded video streams embedded in JSON/multipart requests. The attacker replaces the content — inserting a pre-prepared image or video in place of what was actually captured — and sends the modified request to the server. If the server side does not reconcile the request’s metadata (session parameters, device tokens, timestamps) against what it expects, the spoof goes unnoticed.

A more advanced approach is a complete bypass of the mobile SDK. The attacker reverse-engineers the server system’s API, reproduces the necessary endpoints, and sends requests directly, without the client application. All client-side checks (liveness, runtime environment verification, device binding) become useless — the attacker crafts the requests manually and fills in every required field with the values the server expects to see.

Protection at this level is built comprehensively. On the transport side — certificate pinning resistant to interception (a multi-level implementation, binding to the leaf certificate rather than the CA). On the data side — cryptographic signing of frames on the device using a key bound to the hardware security module (TEE / Secure Enclave). If every frame is signed with a key that cannot be extracted without compromising the hardware element, content spoofing at the transport level becomes detectable. On the server side — validation of timestamps, checking the correlation between the declared device parameters and the characteristics of the received stream, and detecting anomalies in the frame sequence.

Emulators and Virtual Devices in KYC

An Android emulator is a program that reproduces the behavior of a mobile device on an ordinary computer: the operating system, applications, sensors, camera. In the KYC context, an emulator becomes an environment with full control over all the data the application considers «real». Unlike a physical smartphone, where access to hardware components is limited, an emulator makes it possible to spoof every signal — from the camera’s video stream to device identifiers and GPS coordinates. Emulators combine the capabilities of video injection, environment spoofing, and masquerading as a legitimate device.

How an Android Emulator Spoofs the Camera and Video Stream

The attacker’s key task when passing KYC is to make the application accept synthetic video instead of a real capture from the camera. On a physical device this requires root, API hooking, or the installation of a virtual camera. In an emulator the task is easier: the camera is virtual from the outset.

Emulators — BlueStacks, Nox, MEmu, LDPlayer, Genymotion, the Android Studio Emulator — make it possible, through configuration files or settings, to specify the video source for the front and rear cameras. The source can be a file on disk, the host system’s webcam, or a stream from OBS Virtual Camera, ManyCam, and similar tools. When the KYC application calls the Camera2 API to capture an image, it receives frames from the spoofed source and has no standard means of distinguishing it from a physical sensor.

In practice the attack looks like this: a real-time deepfake generation program is launched on the host computer, and its output is routed through a virtual camera into the emulator. The application inside the emulator «sees» a face that responds to liveness-check commands — head turns, a smile, blinking. The physical camera is not involved: the entire video stream is synthetic.

How an Emulator Spoofs Device Signals That Affect Risk

Spoofing the camera is only part of the task. Anti-fraud systems in KYC evaluate not only biometrics but also the device context: model, identifiers, location, behavioral patterns. An emulator makes it possible to falsify all of these parameters.

Device identification. The Build.MODEL, Build.MANUFACTURER, Build.HARDWARE, and Build.FINGERPRINT properties in an emulator contain, by default, characteristic values such as «sdk_gphone», «generic», or «ranchu». Most popular emulators (LDPlayer, Bliss OS, Waydroid, and others) make it possible to overwrite these values by editing build.prop or through profile managers — the emulator presents itself as a specific model (Samsung Galaxy S23, Pixel 7) with plausible values for all fields.

Unique identifiers. The IMEI, Android ID, SIM card serial number, and MAC address are bound to hardware components on a real device. In an emulator, the IMEI is by default filled with zeros or absent. Using Xposed modules, patches to system libraries, or «anti-detect» utilities, these values are generated to look valid: the IMEI format conforms to the standard, the MAC address belongs to the vendor specified in Build.MANUFACTURER, and the Android ID is unique for each instance.

Geolocation and network parameters. An emulator makes it possible to set arbitrary GPS coordinates. If the coordinates are synchronized with the IP address (by binding to a SOCKS5 proxy or a VPN with an exit point in the required region) and with the time zone, detection based on geo-anomalies becomes difficult.

Sensors. The accelerometer, gyroscope, and magnetometer on a real device generate the micro-vibrations characteristic of a live user. An emulator either provides no sensor data at all or returns static values. The absence of sensor «noise» is one of the strong indirect indicators of a virtual environment used by advanced anti-fraud systems.

GPU and performance. Rendering in an emulator is performed by translating OpenGL ES → the host machine’s OpenGL/Vulkan. GPU identification strings (gl_renderer, gl_vendor) often contain mentions of «SwiftShader», «ANGLE», «VirtualBox», or specific desktop graphics cards (NVIDIA GeForce, AMD Radeon), which is impossible on a mobile device. Advanced masking tools spoof these values too, but fully imitating the behavior of a mobile GPU remains a difficult task.

How Emulator and Virtualization Detection Is Bypassed

KYC solution developers implement runtime environment checks to block execution in an emulator. Attackers systematically find ways around them. Understanding the specific bypass methods is necessary to build resilient protection.

Masking build properties and the file system. The simplest checks look for values characteristic of emulators in the system properties or for the presence of specific files (/dev/qemu_pipe, /system/lib/libc_malloc_debug_qemu.so, init.goldfish.rc). The bypass comes down to editing build.prop through root access and deleting or renaming the marker files. Many emulators do this «out of the box» in enhanced-compatibility mode.

Spoofing hardware characteristics. Detection based on GPU strings, processor architecture (x86 instead of ARM), or the absence of sensors requires deeper masking. To translate ARM instructions on an x86 host, binary translation is used (libhoudini, libndk_translation), which makes it possible to run ARM applications but leaves traces in /proc/cpuinfo and in performance characteristics. Some anti-detect solutions hook the system calls that read /proc/cpuinfo and substitute ARM-compatible values.

Bypassing the Play Integrity API. The Google Play Integrity API (which replaced the SafetyNet Attestation API, finally shut down in early 2025) returns verdicts on device integrity. The MEETS_BASIC_INTEGRITY verdict confirms that the application is not running in an emulator, MEETS_DEVICE_INTEGRITY confirms that the device is certified and unmodified, and MEETS_STRONG_INTEGRITY confirms that current security updates are installed. As of May 2025, Google moved all verdict levels to hardware-backed security signals, which significantly complicated forgery on emulators.

Full isolation of instances. Advanced «anti-detect» managers for emulators create isolated instances, each with a unique set of identifiers, a device profile, a bound proxy server, and synchronized geolocation. From the KYC system’s point of view, each instance looks like a separate physical device from a specific region. A single operator manages dozens of «devices» from a desktop — this makes it possible to scale fraudulent operations.

What this means for defense. No single check — neither analysis of build properties, nor the Play Integrity API, nor detection of file markers — provides reliable emulator detection. A resilient approach requires correlating many signals: mismatches between the declared model and the real GPU behavior, anomalies in sensor data, statistical deviations in camera characteristics, atypical frame-processing timings. The more parameters are analyzed on the server side, the higher the cost and complexity of the bypass for the attacker, even if each individual signal can be faked.

Runtime Environment Bypass on Mobile Devices

Video stream injection and camera spoofing are only part of the arsenal. For these techniques to work in a mobile application, the attacker must first gain control over the environment in which the biometric SDK runs. Stock Android and iOS isolate applications from one another, restrict access to system resources, and monitor code integrity. It is precisely these mechanisms that prevent spoofing the video stream, hooking SDK calls, or disabling liveness checks — and it is precisely why bypassing the runtime environment becomes the first step in virtually any advanced attack on biometric verification.

For KYC systems, this means that protection cannot be limited to checking the «vitality» of the face. If the runtime environment is compromised, the results of any client-side checks can be forged before they are even sent to the server.

Root and Jailbreak as a Precondition for Injection and Instrumentation

On devices with factory settings, the operating system rigidly restricts what applications can do. An Android application runs in an isolated «sandbox» with its own UID and cannot read the memory of other processes, replace system libraries, or modify files outside its own directory. iOS imposes even stricter limits: code signing is mandatory for any executable file, and the Secure Enclave Processor isolates the handling of biometric data at the hardware level.

For attacks on biometrics, root and jailbreak create three critical capabilities: dynamic instrumentation (attaching to a running process to hook any SDK functions), access to the camera and video subsystem at a level unavailable to ordinary applications (replacing the camera driver or redirecting the video stream), and the ability to disable the application’s built-in integrity checks, including root detection and SSL pinning.

The toolkit for rooting is developing rapidly. On Android, Magisk dominates with the Zygisk module, which injects code into the Zygote process — the parent process of all Android applications. Masking modules (Shamiko, Zygisk Assistant, and similar) hide root privileges from specific applications: the su and Magisk files become invisible, and system properties return «clean» values. In parallel, KernelSU and APatch are developing, which operate at the kernel level and leave even fewer traces in user space. As of early 2026, detailed public instructions exist for passing even strict integrity checks (Strong Integrity) on rooted devices — including spoofing hardware attestation through leaked certificates.

On iOS the situation is more constrained: there are no public jailbreaks for current versions (iOS 18+), and Apple is systematically strengthening the protection of the kernel and the SEP. For earlier versions (iOS 15–17), a specialized deepfake injection tool for jailbroken devices was publicly documented in September 2025. The tool connects to a compromised iPhone through a remote server (Remote Presentation Transfer Mechanism) and injects synthetic video into the application’s video stream, bypassing the physical camera.

For KYC systems, the fact that root access exists does not automatically mean fraud, but it radically expands the attack surface. The policy for responding to detected root or jailbreak is a business decision that depends on the risk level of the specific scenario.

Dynamic Instrumentation and Hooking Biometric SDK Functions

Having gained privileged access to the device, an attacker can attach to a running application and modify its behavior without changing the source code. This technique — dynamic instrumentation — is implemented with Frida, Xposed/LSPosed (on Android), and similar tools on iOS.

How Frida works: a server process (frida-server) is launched on the device with root privileges and gains access to the target application’s memory. Through a control script (usually in JavaScript), the attacker specifies functions to hook and defines new behavior — substituting return values, changing arguments, or fully bypassing a call.

In a biometric KYC application, instrumentation makes it possible to attack several critical points.

Category	Description
Liveness check functions	The SDK calls an internal method that returns the result of the «vitality» check (pass/fail and a confidence level). By hooking the call, the script forces the SDK to always return a positive result, regardless of the actual input video.
OS-level biometric authentication	On Android, the BiometricPrompt API returns the onAuthenticationSucceeded callback when a fingerprint or face check succeeds. A universal script is available on Frida CodeShare that hooks all overloads of the authenticate() method and forcibly invokes the successful-authentication callback with a spoofed AuthenticationResult. The script works on all Android versions up to API 34, provided the application does not bind authentication to a cryptographic object (CryptoObject) stored in the hardware key store.
Interception of data transfer between the SDK and the server	Instrumentation makes it possible to modify JSON responses, scores, session metadata, and any other data formed on the client before transmission. If the server side accepts the result of a client-side check without independent validation, spoofing a single field may be enough to pass verification.

Xposed/LSPosed operate differently: instead of attaching to a process from the outside, they embed modules directly into the Android Runtime (ART) through the Zygisk mechanism. This makes it possible to hook Java methods even before the application begins its own checks. This approach is harder to detect, because the instrumentation happens at an early stage of process loading.

Countering Frida on the SDK side usually comes down to several techniques: detecting frida-server by open ports or process names, checking the libraries loaded into the process, monitoring ptrace system calls, tracking anomalous patterns in memory. Attackers adapt their tools: modified Frida builds change process names and signatures, bypass standard detection methods, and dynamically adapt to new checks. This creates a constant race in which neither side has an absolute advantage.

The architectural takeaway: any checks performed only on the client can be hooked and forged. Client-side checks raise the cost of an attack and cut off unskilled adversaries, but the final decision about passing verification must be formed on the server, taking into account signals that are hard to falsify through instrumentation.

Patching the Application to Disable Checks

Dynamic instrumentation requires root access and works «in the moment» — when the application restarts, the hooks must be set up again. Patching is a different approach: the attacker modifies the application build itself, disabling protective mechanisms at the code level, and installs the modified version.

The typical process: the APK file is decompiled with apktool, which extracts the resources and the intermediate code representation (smali — a readable form of Dalvik bytecode). The attacker analyzes the decompiled code, looking for characteristic markers: the strings «isRooted», «checkIntegrity», «emulatorDetected», calls to signature-verification methods, references to the Play Integrity API. Having found a check method, it is enough to change a single instruction — replacing the return value from «true» (root detected) to «false». The application is rebuilt, signed with a new key, and installed on the device.

For iOS the process is more complex because of mandatory code signing, but on a jailbroken device or using developer certificates, an analogous approach is possible: disassembling the binary file, modifying ARM instructions, re-signing, and installing.

In practice, patching makes it possible to disable several layers of protection at once: root and jailbreak detection, the application’s integrity check (comparing the APK hash against a reference), SSL pinning (which opens the possibility of intercepting traffic), and any client-side checks — from emulator detection to validation of video stream metadata.

On Android there are modules (CorePatch for LSPosed and similar) that disable the system’s APK signature verification, making it possible to install modified applications over the originals. This simplifies the attack: data and the session are preserved without reinstallation.

Obfuscation and native code slow down an attack but do not make it impossible. A skilled researcher with enough time can analyze any client-side code. Patching is countered by a combination of measures: obfuscation raises the barrier to entry, runtime checks detect modification during operation, and server-side validation renders the result of client-side patching meaningless.

Bypassing the Trusted Execution Environment and Hardware Restrictions

A Trusted Execution Environment (TEE) is an isolated hardware area of the processor, protected from the main operating system. On Android, keys created in the TEE through the Android Keystore cannot be extracted even with root access: cryptographic operations are performed inside the protected module, and only the result is returned to the outside. On devices supporting StrongBox (a dedicated secure element available since Android 9), the level of isolation is even higher — keys are stored in a separate physical chip resistant to hardware attacks.

On iOS, the Secure Enclave Processor (SEP) performs an analogous function. Face ID and Touch ID biometric data is processed exclusively inside the SEP, and the application receives only a cryptographically confirmed fact of successful or unsuccessful authentication. Beginning with the A12 chips (2018), Apple substantially strengthened the SEP’s hardware protection, which makes extracting or emulating it an extremely resource-intensive task.

Hardware key attestation (Key Attestation) allows the server to remotely verify that a cryptographic key was indeed created inside the TEE or StrongBox on an uninfected device with a locked bootloader. The server sends a random challenge, the device generates a key pair in the hardware store and returns a certificate chain whose root is signed by a key embedded by the manufacturer (on Android — the Google Attestation Root Key). The certificate contains metadata: the security level (TEE or StrongBox), the bootloader status (locked or unlocked), and the security patch version.

Attackers try to bypass this protection too. The main vector is leaks of attestation keys from device manufacturers. If the private key of a certain model is compromised, an attacker can generate valid attestation chains on an arbitrary device. Google maintains a Certificate Revocation List, but time passes between a leak and its revocation. As of early 2026, publicly available modules exist (TrickyStore and similar) that make it possible to substitute «someone else’s» attestation certificates on a rooted device, bypassing the bootloader status check.

A second approach is software emulation of the TEE. Projects such as TEESimulator create virtual keys in a software environment and intercept requests to the hardware store through Binder IPC, substituting the responses of a software simulator. The real hardware store is not used, but the application and the server receive valid-looking responses. The effectiveness of the attack depends on how carefully the server side verifies the certificate chain and reconciles it against a current list of revoked keys.

A third vector is bypassing the TEE-bound logic at the application level. Even if a key is stored in a hardware module, the biometric SDK may use the cryptographic result incorrectly. If the application calls BiometricPrompt.authenticate() without a CryptoObject, authentication comes down to the OS checking the fact that a «finger was applied / face was recognized» — a fact that is easy to fake through Frida. Binding to a CryptoObject with a key for which the setUserAuthenticationRequired(true) flag is set forces the system to perform the cryptographic operation only after a real user authentication inside the TEE. This substantially complicates instrumentation: the result of a hardware module’s cryptographic operation cannot be substituted by means of software hooking — the key never leaves the protected area.

How to Detect and Block Attacks on the Video Stream in Biometrics

Execution Integrity Verification in the Mobile SDK

The first line is verifying that the biometric SDK runs in a normal environment: on an unmodified device, inside a genuine application, without outside interference.

On Android, this task is handled by the Play Integrity API. When called, the API returns a Google-signed token with three key verdicts: appIntegrity confirms that the application’s binary file is recognized by Google Play and has not been modified; deviceIntegrity indicates whether the application is running on a certified device or in an emulated environment; appAccessRiskVerdict signals the presence of active applications capable of capturing the screen or controlling the device through accessibility services. As of library version 1.5.0 (August 2025), recovery dialogs appeared — GET_INTEGRITY and GET_STRONG_INTEGRITY — which prompt the user to fix the problem rather than simply blocking access.

On iOS, an analogous role is played by App Attest from the DeviceCheck framework. On first launch, the SDK generates a cryptographic key bound to the specific application instance and device. Apple signs the attestation of this key, and the server can subsequently verify the authenticity of every request through an assertion mechanism. Forging the attestation without physical access to the Secure Enclave is practically impossible.

An additional level is local integrity checks in the SDK’s native code: computing the hash of the executable file at launch and comparing it with a reference, verifying the APK or IPA signature, and checking whether the code was loaded from a non-standard source. These checks do not replace platform attestation, but they raise the cost of an attack: the adversary has to bypass several independent mechanisms simultaneously.

Protecting the Biometric SDK from Modification and Debugging Tools

Even if the runtime environment has passed attestation, the risk of dynamic instrumentation remains — hooking SDK functions in the process’s memory. Frida or Xposed make it possible to substitute the return values of functions without changing the file on disk, which means that checking the hash of the binary file will not detect such interference.

The countermeasures are built along several lines. The first is detecting debuggers and injection tools. The SDK checks whether a debugger is attached to the process (through ptrace on Android or sysctl on iOS), scans the list of loaded libraries for characteristic artifacts (for example, frida-agent), and analyzes open ports and named pipes typical of dynamic-analysis tools. Detecting Frida may include searching for specific strings in the process’s address space and checking the integrity of symbol tables.

The second is code obfuscation. Renaming classes and methods, encrypting string constants, control flow flattening, and inserting bogus branches turn static analysis into a laborious task. Critical functions — token generation, video data encryption, integrity verification — are moved into the native layer (C/C++), where reverse engineering requires substantially more effort than in Java or Kotlin bytecode.

The third is white-box cryptography to protect keys and secrets. Unlike standard encryption, a white-box implementation embeds the key directly into the algorithm so that extracting it from the binary file without full cryptanalysis is impossible. This approach is used in highly secure SDKs to generate JWT tokens and sign requests to the server: even having gained access to the binary code, an attacker cannot reproduce a valid token outside the original application.

Emulator Detection and the Response Policy in KYC

An emulator is one of the most accessible attack tools: it makes it possible to spoof the camera, geolocation, device identifiers, and sensor parameters within a single controlled environment. Detecting emulation relies on a combination of hardware and behavioral traits that a virtualized environment cannot fully reproduce.

Typical indicators on Android: characteristic values of Build.FINGERPRINT, Build.MODEL, Build.HARDWARE (goldfish, ranchu, generic), the presence of QEMU files and drivers (/dev/qemu_pipe, /dev/goldfish_pipe), the absence of real sensors or their static readings, anomalously stable battery values, atypical OpenGL renderer parameters. The Play Integrity API, in the deviceIntegrity field, directly indicates a virtualized environment — provided the check is performed on the server and the attacker has not intercepted the response.

On iOS, the risk of emulation is lower: Apple does not provide a full-fledged emulator with access to the camera and cryptographic subsystems for arbitrary code. Attacks on iOS are more often built on jailbreaking a real device. The SDK must verify that the App Attest key was generated on a physical Secure Enclave — an indirect confirmation of running on real hardware.

Detection is half the task. No less significant is the response policy. A hard prohibition (immediate session blocking) minimizes fraud risk but increases the likelihood of false positives — for legitimate users with non-standard firmware or corporate Android builds. A softer variant is continuing the session with an elevated risk level, additional checks (enhanced liveness, a request for additional documents), and passing a signal to the anti-fraud layer.

In practice, KYC systems often apply a cascading scheme: a low threshold — logging and flagging the session; a medium one — additional challenge requests and manual verification; a high one (a coincidence of several emulation indicators with signs of video stream spoofing) — rejection of the session. The thresholds are tuned to the specific business profile and the acceptable level of friction for users.

Binding the Video Stream to the Physical Camera and Session Parameters

Whereas a liveness check analyzes the content of the frames, binding the video stream to its source answers a different question: were these frames really obtained from the device’s physical camera in the current session?

Virtual camera detection is the first element of control. A study published in December 2025 on arXiv describes a machine-learning approach trained on the metadata of more than 30,000 real sessions. The model analyzes the camera’s behavioral patterns: the latency when changing resolution (a physical camera interacts with a hardware controller and responds more slowly than software emulation), the nature of implicit modifications to settings, and the limits on the available resolutions and frame rates. These traits are robust even when the camera name is obfuscated — virtual cameras (OBS Virtual Camera, ManyCam, custom v4l2loopback devices) reproduce the metadata but cannot fully imitate physical behavior.

For mobile SDKs, an additional factor is binding to the specific hardware camera identifier through the Camera2 API on Android or AVCaptureDevice on iOS. The SDK records the camera identifier, its characteristics (focal length, sensor size, supported FPS ranges), and checks with each frame that the source has not changed. An attempt to substitute a virtual device leads to a mismatch of parameters.

The second element is cryptographic binding of the video data to the session. The SDK generates a unique nonce for each verification session and embeds it in the data stream: signing a group of frames with a key bound to the attested application instance, or including session metadata (timestamp, nonce, device ID) in an encrypted container sent to the server together with the video. This makes reuse of a previously recorded stream (replay) pointless — the server side will reject data with an invalid or expired nonce.

Encrypting the transmission channel from the SDK to the server (TLS with certificate pinning) closes the man-in-the-middle vector: intercepting and spoofing the stream at the network level requires compromising the certificate pinning inside the application, which brings the attacker back to the need to bypass RASP protection.

Server-Side Checks of Video Data Consistency and Correlation of Anti-Fraud Signals

Server-side verification of video data consistency begins with validating the cryptographic artifacts: the stream’s signature must correspond to the key of the attested application instance; the nonce must match the one issued by the server for the current session; and the frame timestamps must fall within a reasonable interval. A deviation in any parameter is grounds for raising the risk score or rejecting the session.

The next level is analysis of the video content. Server-side models evaluate the naturalness of the video: consistency of lighting between frames, the presence of facial micro-movements (involuntary eye saccades, micro-expressions, variations in pose), and the absence of generative-model artifacts (anomalies at the boundaries of the face, unnatural reflections in the pupils, texture breaks when the head turns). These checks complement client-side liveness: even if the attacker bypassed the check on the device, the server-side model analyzes the same frames independently.

The greatest value comes from correlating disparate signals. The anti-fraud layer combines data from several sources: the result of device attestation, detection of an emulator and root/jailbreak, the result of binding to the physical camera, the liveness and deepfake-detection assessment, device metadata (model, OS, language, time zone, IP address), and behavioral signals (the speed of moving through the stages, the pattern of interaction with the interface). A coincidence of several weak signals is sometimes more informative than one strong one: a session with suspiciously fast passage of a liveness challenge, from a device with an atypical ratio of model to OS version, with a data-center IP address — each factor on its own does not prove fraud, but their combination sharply raises the probability of an attack.

Cross-session analysis adds another dimension. The server can detect that the same device, IP address, or biometric template appears in several sessions over a short period — which is characteristic of high-volume fraud. Linking such signals across sessions, and even across different customers (with proper anonymization of the data), makes it possible to detect organized schemes that are invisible within a single isolated check.

Building a multi-layered defense is a task at the intersection of mobile development, cryptography, ML, and anti-fraud analytics. At the design stage, the threat model and acceptable risk thresholds are defined; at the pilot stage, each layer of protection is tested against real attack scenarios while measuring the impact on the conversion of legitimate users. Companies specializing in biometric verification provide ready-made SDKs with integrated environment checks, camera binding, and server-side analytics — this lets the customer obtain comprehensive protection without having to build every layer independently.