Application security feature

Voice and audio injection detection

Otukan checks that voice captured in your app comes from the device microphone, flagging virtual audio inputs, hooked capture and emulators before verification.

  • Android
  • iOS
  • Flutter
  • React Native
Injected voice audio is met at the microphone path boundary before it reaches the appInjected voice audioMicrophone pathYour app
  • Source before content

    Before anyone asks whether a voice is genuine, Otukan asks where the audio came from: the device microphone, or something feeding it.

  • One link in the chain

    Otukan protects the capture path and hands the evidence to your voice verification or liveness service, which keeps its own role.

  • Real speakers pass

    Headsets, hearing aids and car audio are tested as normal routes, so genuine customers are not turned away for how they speak.

Audio injection routes Otukan checks

Select a route to see how Otukan spots it, what the app does and what your verification service receives.

Virtual microphone input

  1. Detect

    Otukan inspects the active audio input route and flags sources that are virtual or software-defined rather than a physical microphone.

  2. Respond

    The recording is not submitted, and the customer is asked to use the built-in microphone or a known headset.

  3. Report

    The input route classification travels with the capture to your verification service.

Hooked audio capture

  1. Detect

    Otukan detects instrumentation on the audio capture functions inside your app's process, where recorded speech can be swapped in.

  2. Respond

    The voice step stops and the session follows the policy for tampering.

  3. Report

    An instrumentation signal marks the capture as untrusted for your backend.

Emulated devices

  1. Detect

    Otukan recognises emulators and virtual devices, where a microphone can be simulated end to end.

  2. Respond

    Voice enrolment and voice login can be refused on emulated hardware, per your policy.

  3. Report

    Your backend receives an emulator signal with the request.

Tampered voice flow

  1. Detect

    Otukan checks that the app handling the recording is the release you signed, not a copy altered to upload prepared audio.

  2. Respond

    A modified copy is stopped at the voice step, per your policy.

  3. Report

    An integrity result accompanies every voice submission.

Capture integrity across onboarding

Voice is one capture path among several, and Otukan protects each of them in the same way.

  • Camera injection detection

    Applies the same source-first check to selfies and document images, flagging feeds that did not come from the device camera.

  • Emulator detection

    Separates physical phones from emulated ones, which are the easiest place to simulate a microphone or camera.

  • KYC fraud prevention

    Joins capture evidence to the identity journey, so your verification provider sees how each sample was produced.

  • Biometric flow protection

    Protects the app logic around biometric and voice checks, so a result cannot be forced or skipped on the device.

You choose the response

Set a response for each user flow. Start by observing, then tighten flow by flow as the signals prove themselves.

Observe

Signal sent to your backend

Rolling out a new policy and measuring real-world signals.

Warn

This device looks modified. Continue with care.

Conditions some genuine users create, such as developer settings.

Restrict

Payments are unavailable on this device.

Payments, stored data and account changes.

Terminate

Session closed for your security.

Clear tampering on a high-risk flow.

How it works

  1. Draw the capture path

    We trace the voice journey from microphone to your verification service and mark each point attackers can reach.

  2. Protect the app

    Otukan joins the pipeline you use today; release signing remains with your engineers.

  3. Check each recording

    Every voice capture carries the input route, process integrity and device status it was made under.

  4. Hand over evidence

    Your verification or liveness service receives the capture evidence and makes the identity decision.

  5. Test normal speakers

    Headsets, hearing aids, car systems and quiet voices are tested so real customers are accepted.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

A mobile security team should evaluate voice and audio injection detection by one question: does the product prove the audio came through the device microphone in an unmodified app? Otukan answers it at the capture point. It flags virtual and software-defined audio inputs, instrumentation on your app’s capture functions, emulated devices and altered copies of your app, then attaches that evidence to the recording. Your voice verification or liveness service still decides whether the speaker is live and who they are. Otukan closes the routes that bypass the microphone; judging the sound itself belongs to those services. Android and iOS checks are built separately.

Capture path

Where voice enters your app

Apps use voice for enrolment, voice login, call-back confirmation and spoken consent. In each case the journey is the same: microphone, operating system audio stack, your app’s capture code, upload, and a decision on your server or at your provider. An attacker who wants a cloned or recorded voice accepted does not need to fool the ear. It is enough to replace the audio somewhere along that path.

The points attackers reach

Point on the pathManipulationOtukan check
Input deviceA virtual microphone or software audio source replaces the physical oneInput route classification
Operating systemA rooted or jailbroken device reroutes system audioDevice integrity status
App processCapture functions are hooked to return prepared audioInstrumentation detection
HardwareAn emulator simulates the whole deviceEmulator detection
App itselfA repackaged copy uploads a file instead of recordingRelease integrity check

Platform differences

Android exposes more detail about audio devices to apps, and its open audio stack gives virtual audio tools more room to operate. iOS tells an app less about routes, and it also leaves far fewer ways to replace audio on a device that is not jailbroken. Otukan uses each platform’s own signals and records which checks ran on which platform.

Control boundary

Four different questions

Voice fraud controls are often bundled together, which makes evaluation hard. Separate them:

  • Injection detection (Otukan): did the audio come through the microphone of an intact app on a physical device?
  • Content classification: does the audio sound synthetic or manipulated?
  • Liveness: is a live person speaking right now?
  • Identity proofing: is this the person the account belongs to?

A strong voice journey uses all four, and each is tested on its own.

What Otukan hands over

Each capture carries its input route, process integrity result, device status and app integrity result. Your provider receives the sample with that context, so a synthetic voice pushed through a virtual input fails before classification starts.

Evidence your provider can use

The capture evidence is designed to be read by a machine and a person. Your verification service can apply a simple rule, such as refusing any sample recorded through a virtual input, while your fraud analysts see the same record when they review a disputed enrolment. Because the evidence is produced for every capture, not only suspicious ones, you also learn which routes genuine customers use most.

For camera and document capture, see camera injection detection.

Customer impact

Test the real ways people speak

Genuine customers use wired and wireless headsets, hearing aids, car systems and speakerphone, sometimes with background noise and assistive settings enabled. Each is recorded in the test plan as a legitimate route, confirmed on physical devices and repeated through install, update, sign-in and the voice step itself.

Recovery routes

When a capture is refused, the customer needs a clear next step: switch to the built-in microphone, remove a virtual audio app, or complete verification another way, such as a document check or a branch visit. Otukan’s messages describe the problem in plain words without accusing the customer. A refused capture is also recorded, so your team can spot customers who meet repeated refusals and reach out to them.

Proportionate policy

Start in observe mode to see which input routes your real customers use. Then refuse only the routes that bypass the microphone, and keep the decision on voice content with your provider. Microphone access from outside your flows is covered on detecting unauthorised microphone access. Voice capture checks belong to Otukan’s mobile fraud prevention family.

Common questions

  • Is this the same as deepfake voice detection?

    No. Deepfake detection judges whether the sound of a voice is synthetic. Otukan checks whether the audio came through the device microphone into your genuine, unmodified app. The two answer different questions and work best together: a cloned voice played into a virtual input is flagged by Otukan before any content analysis is needed, and your classifier handles what remains.

  • Does Otukan replace voice liveness or speaker verification?

    No. Liveness decides whether a live person is speaking, and speaker verification decides who that person is. Both belong to your identity or voice provider. Otukan gives them a record of how the sample was captured, so their decision can take into account where the audio came from.

  • What about a recording played aloud next to the phone?

    Sound played into the real microphone arrives through a physical route, so the capture path looks normal. That case belongs to liveness and speaker checks, which analyse the audio itself. Otukan closes the routes that bypass the microphone completely, such as virtual inputs, hooked capture and emulators, which are the ones attackers can automate at scale.

  • Will customers with hearing aids or car kits be refused?

    They should not be, and the policy is tested for it. Bluetooth headsets, hearing aids and car audio are legitimate input routes. Otukan classifies them as physical routes and includes them in the test plan before any enforcement, alongside quiet voices, background noise and customers using accessibility settings.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Trust the voice your app hears

Tell us the platforms, the app framework and where voice is captured, such as onboarding, voice login or call-back confirmation. We do not ask for voice recordings, customer data, binaries or production credentials.

Or request a technical demo