They are different problems because they look at different things. Camera injection detection asks whether the frames reached your app from the phone’s physical camera or were fed in by a virtual camera, a hook or an emulator. Liveness asks whether a real person was in front of the lens. Deepfake detection asks whether the face itself was synthesised or swapped. Identity verification then matches that face to a document. A remote onboarding flow needs each answer from the layer that can give it. This article covers Android and iOS apps; each platform has its own capture risks.
Definitions
Three kinds of attack reach a selfie or document step, and they differ in where the deception happens: before the lens, at the lens, or in the content itself.
Capture-path manipulation
- The real camera is bypassed
- Frames come from a file, a hook or an emulator
- The content can be flawless because it was chosen in advance
- Only the app can see the route the frames took
Presentation and generated content
- The real camera is used, or its route is trusted
- The lens sees a photo, a screen, a mask or a synthetic face
- The deception is in what the frames show
- Content analysis in the identity layer judges it
Capture-path manipulation
The attacker never points a camera at anything. They replace the source: a virtual camera that presents a video file as the front camera, a hooking framework that swaps frames inside the app’s process, an emulator that feeds prepared footage, or a modified copy of the app with its capture module removed. The pixels may be flawless, because they were chosen in advance.
Presentation attacks and liveness
Here the real camera is used, but it sees a printed photo, a phone screen replaying a video, or a mask. Liveness checks look for depth, texture, motion or response to a prompt to tell a present person from an artefact.
Generated content
Deepfake detection analyses the image or video for signs of synthesis, face swapping or reenactment. It can run on frames from any source, which is its strength and its weakness: it judges content without knowing how that content arrived.
A deepfake delivered through an injected stream never has to fool the lens. It only has to fool the model that judges the frames.
Who owns which layer
A remote onboarding flow passes frames through several components. Each can answer one question well and none can answer all of them.
Camera
Produces frames, or is bypassed by an injected source.
Mobile app
Checks the capture path while the camera is open and attaches the result.
Identity service
Judges liveness, synthetic content and the match with the document.
Your backend
Combines every result with device and account history and decides.
| Question | Where it is answered | Evidence it uses | What it cannot see |
|---|---|---|---|
| Did the frames come from the physical camera? | Mobile app, at capture | Camera source, process integrity, device state | Whether the face is real or matches a document |
| Is a live person present? | Identity verification service | Motion, depth, texture, challenge response | Whether the stream was injected upstream |
| Is the face synthetic or swapped? | Identity verification service or a specialist model | Visual artefacts in frames | How the frames reached the app |
| Does the face match the document? | Identity verification service | Document data and face comparison | Capture path and device state |
| Should this onboarding proceed? | Your backend | All of the above, plus device and account history | Nothing it is not sent |
The app is the only component that sits next to the camera, so it is the only place that can vouch for the capture path. Your backend is the only component that sees every result together, so the final decision belongs there, not in the app and not in any single service.
Testing each layer on its own terms
A single test run that mixes every attack hides which layer did the work. Keep the evaluations separate, and write down the pass condition before the first test.
| Test | Attack presented | Layer under test | Pass condition |
|---|---|---|---|
| Injection | Prepared footage through a virtual camera, a hook in the capture code or an emulator | Mobile app | The session is flagged, whatever the footage shows |
| Presentation | Printed photos, screens and masks in front of a real camera on genuine devices | Liveness | The attempt is rejected |
| Synthetic content | Generated or swapped faces through a genuine camera path | Content analysis | The face is flagged, independent of the capture result |
| Matching | Genuine people with mismatched documents | Verification | The pairing is rejected |
| Regression | The genuine-user journey on supported devices | Every layer | Genuine users complete onboarding |
Record results per layer and per platform. A strong liveness score tells you nothing about injection resistance, and the reverse.
- Agree which team owns each layer and each pass condition.
- Run injection tests on Android and on iOS, and record them separately.
- Repeat presentation and synthetic tests after each identity service update.
- Repeat the genuine-user journey after each app release.
- Confirm that the capture-integrity result reaches the backend with the media.
How Otukan protects the capture path
Otukan protects the part only the app can protect. While the camera is open, it detects frames that do not come from the physical camera, virtual camera sources, instrumentation attached to camera and image-processing code, and emulators feeding prepared video. Frames captured while hooks are present can be marked untrusted or discarded, and root indicators on Android and jailbreak indicators on iOS add context to the result. It confirms that the app’s code and signing identity match your release, so a copy with a replaced capture module stands out. The capture-integrity result travels with the media to your backend, where you set the response per flow, including routing to manual review. Checks are built separately for Android and iOS and cover Flutter and React Native apps, and Otukan runs joint positive, negative and regression tests with your team and identity provider. Protection fits your existing build and release pipeline, and your signing keys stay with your team.
The product control is covered on mobile camera injection detection, and the wider onboarding and payment fraud controls on mobile fraud prevention.