Putting Innovatrics to the Test: An Adversarial Evaluation of Biometric Liveness Controlslive

Citadelo deployed its engineering team for an intensive 16 days pure black-box penetration test targeting the Innovatrics Identity Verification (IDV) Toolkit to simulate a real-world adversary and attempt to bypass its facial biometric liveness controls. This article describes the reverse-engineering, runtime instrumentation, and data-injection steps we executed to challenge the system.

Introduction: The Criticality of Independent Biometric Verification

In an era where a single AI-generated deepfake can deceive an enterprise out of $25 million, the boundary between physical reality and synthetic fabrication has dissolved. This threat vector is no longer just an abstract problem for risk boards, it has triggered a global regulatory reckoning. With the European Union's AI Act reaching its critical enforcement milestones, strict transparency requirements and rigorous cybersecurity requirements now legally obligate organisations to actively verify that their digital perimeters can distinguish a genuine human from a synthetic artifact.

In this area, remote enrolment and online authentication have gone from being useful tools to being a big deal. Biometric verification systems are the ultimate gatekeepers for modern zero-trust architectures. They take over from older authentication methods like passwords, PINs and static security questions. 

But the enemy has also adapted, by focusing on the face. The fact that generative AI, open-source automated video injection scripts and highly stable runtime manipulation frameworks are now freely available has made it much easier for people to carry out advanced presentation attacks.

Facial biometrics are the last line of defence against identity fraud, so if these mechanisms are hacked, attackers can create unauthorised accounts, get around anti-money laundering (AML) controls and hack into the main financial systems. This means that companies can't rely on certificates from vendors or approvals that are based on a single point in time. They have to prove that their tools work by testing them in real-world situations.

This case study documents a black-box security assessment performed against the Innovatrics Identity Verification (IDV) Toolkit. One of the leading solutions for reliable and high-assurance digital identity verification engines. During a time period of 16 days we analyzed the solution's internal mechanics, reverse engineered its low-level workflows, attempted to bypass native security measures, performed digital injection attacks and evaluated the results. Despite this effort, the platform's multi-layered security architecture successfully kept its integrity, preventing any bypass of the biometric perimeter.

"During a major customer engagement, we were required to provide independent proof that our identity verification solution is resilient against injection attacks. We selected Citadelo for their expertise, reputation, and ability to meet the customer's demanding timeline. Their rigorous assessment provided valuable independent validation and reinforced confidence in the robustness of our technology." Viktor Bielko - IDV Toolkit Product Manager, Innovatrics.

Why Black Box? The Adversarial Mirror

Evaluating a software development kit (SDK) via a strict black-box methodology is essential because it mirrors the exact operational constraints, limitations, and strategies of a real-world adversary. In this engagement, we were granted zero insider privileges, we received no internal source code, no architectural blueprints, and no proprietary debugging instructions. The entire assessment relied exclusively on publicly available developer documentation, standard production client application binaries, and exposed public API endpoints.

When evaluating software under these conditions, the team must abandon some assumptions regarding how code should ideally execute, relying instead on empirical observation of how the application behaves in practice. A truly secure biometric SDK must remain robust regardless of the environment in which it is distributed, proving resilient even when an attacker enjoys total control over the host operating system. This design philosophy honors Kerckhoffs’s principle by actively avoiding "security by obscurity". 

By executing the assessment without prior inside knowledge, testers could accurately determine whether the application's runtime defenses, obfuscation schemes, and transport layer security schemes were genuinely capable of resisting focused, state-of-the-art reverse engineering and automated exploitation.

Target Scope and Testing Methodology

Our technical assessment focused primarily on the Innovatrics Android Face Lite Library and its end-to-end interactions with the Digital Identity Service (DIS). While testers briefly evaluated the corresponding iOS implementation, we designated the Android ecosystem as our primary target for analysis due to its open architectural nature, which permits more granular interaction with low-level binaries and system calls.

The engagement was structured into three progressive technical phases:

• Phase 1: Static Analysis & Decompilation - This phase involved reconstructing high-level bytecode structures, extracting hardcoded variable constants, mapping internal class hierarchies, and isolating native third-party library dependencies for structural evaluation.
• Phase 2: Dynamic Instrumentation & Hooking - Here, testers focused on injecting custom scripts into the active runtime environment using instrumentation tools. This allowed us to intercept active execution paths, trace logic branch decisions, inspect cryptographic buffers, and patch volatile memory structures in real time.
• Phase 3: Automated Digital & Transport Layer Attacks - The final phase escalated to orchestrating network traffic manipulation, intercepting state-tokens, and simulating advanced digital injection vectors, such as virtual camera frame spoofing, to feed manipulated data directly into the system.

Reverse Engineering and Runtime Instrumentation Analysis

When an app runs on an end-user's phone, an attacker technically controls the device. They will try to read the app's internal code (decompilation) or monitor its behavior while it runs (dynamic instrumentation). Application developers defend against this by packing their security logic into complex compiled files and deploying internal alarms that shut the app down if debugging tools are detected. While these techniques can be bypassed, doing so requires manual, low-level modifications.

Analysis of Attack Vectors and Execution Results

Over the course of our 16-day assessment, our team systematically progressed through the attack pipeline. This involved inspecting the network communication, deobfuscating the decompiled code, reverse engineering native libraries, understanding the inner workflow of face capture, bypassing security barriers and establishing runtime visibility to execute digital injection attacks.

Virtual Camera Simulation via LSPosed Hooking

Our first attack vector sought to completely replace the user's live physical camera feed with a pre-recorded video presentation attack. To execute this without holding a physical phone up to a screen, we deployed an application operating as a system module. This module hooks high-level Java APIs, specifically the Android Camera2 API, forcing the OS to yield video frames from an arbitrary file source rather than the physical image sensor.

• Result: Unsuccessful

While the high-level video data was substituted within the Java layer, stream was successfully replaced with our pre-recorded file, the Innovatrics validation engine immediately detected the anomaly, rejected the capture sample, and flagged the session as  tampered. 

"Man-in-the-App" Cryptographic Boundary Interception

We moved to an internal data-swap attack. The objective was more sophisticated: we allowed a legitimate camera session to capture valid hardware metadata, thereby ensuring the SDK captured authentic hardware sensor telemetry, but intended to intercept and swap out the underlying biometric image frames inside the memory buffer immediately prior to encryption and transmission.

• Result: Unsuccessful

Real-Time Frame Injection

Our final adversarial approach targeted the core image initialization constructor inside the SDK’s native execution tree. Rather than swapping network packets or overriding OS camera APIs, the objective was to stream sequential, high-resolution adversarial frames directly into the image processing pipeline prior to internal serialization.

• Result: Unsuccessful

What does this mean?

The resilience demonstrated by the IDV Toolkit highlights several critical requirements for modern security architectures operating in highly regulated domains like banking, fintech, and insurance:

1. De-coupling Client Trust: 

This evaluation proves that client-side security controls (such as code obfuscation, root detection, and anti-tamper alarms) are valuable hurdles that delay adversaries, but they cannot represent an organization's final line of defense. Given enough time and focus, an attacker can bypass client-side code blocks using runtime instrumentation.

The true baseline of biometric security depends entirely on server-side validation mechanisms. The system remains secure even when the client-side application running on a compromised smartphone is controlled by an attacker.

2. Continuous Lifecycle Auditing: 

Security verification is never a one-time checklist event executed at project launch. As open-source reverse-engineering tools mature and generative AI tools lower the cost of creating highly realistic deepfakes, attack methodologies will continue to evolve. Organizations must integrate adversarial biometric penetration testing into their continuous development and risk assessment lifecycles rather than treating it as a legacy compliance requirement.

3. Hardware-Anchored Telemetry: 

Modern identity verification solutions must look far beyond basic pixel data. Solutions that merely evaluate whether an image "looks real" are highly vulnerable to digital injection attacks. By integrating low-level hardware checks, the entry barrier for attackers is raised significantly, neutralizing standard software-driven virtual cameras and emulators.

Conclusion

“The black-box assessment of the Innovatrics Identity Verification Toolkit demonstrated that the platform features a highly resilient, defense-in-depth architecture. While our team successfully bypassed initial anti-instrumentation routines and achieved client-side memory control on the host Android device, our subsequent digital injection attacks completely failed to subvert the system's robust liveness checks.” Oliver, an ethical hacker at Citadelo.

The combination of strict native-layer code isolation, hardware-anchored data correlation, and server-side validation models ensures the solution provides elite protection for enterprise digital ecosystems.

Black-box penetration testing remains one of the most effective ways to validate how a security solution performs under realistic attack conditions. By approaching the target without privileged knowledge, it provides an objective assessment of whether an external attacker could compromise the system using publicly available information and techniques.

Depending on an organization's security objectives, this approach can also be complemented by a white-box assessment. While black-box testing focuses on real-world attack simulation, white-box testing enables a deeper review of the application's internal design, implementation, and source code. Both methodologies have distinct strengths, and selecting the right approach ultimately depends on the specific risks, compliance requirements, and assurance level an organization aims to achieve.

Whether you want to validate your security from an attacker's perspective through a realistic black-box assessment or gain additional insight with a white-box review, our team can help you choose the approach that best fits your security objectives.