A source shows up in your dashboard looking like the best partner you have ever run. It is delivering installs, and behind each one a full funnel: sign-ups, tutorial completions, add-to-carts, even purchases, all at a cost per action that makes every other channel look slow. You lean into it, and you move budget toward it.
Then the part that should follow never arrives. The in-app revenue tied to those purchases never lands, the users behind the installs never open a second session, and the cohort that looked so healthy on day one flattens to nothing by day three.
The reason is that there were never any people. A fraudster studied the signals your app’s measurement software development kit (SDK) sends when a real person installs the app and triggers events, learned how to reproduce those signals, and then fired thousands of them from a server with no phone and no user anywhere in the loop.
This is SDK spoofing, and it is one of the harder forms of mobile ad fraud to catch because the fake traffic is designed to look exactly like the real thing, all the way down to the protocol.
Contents
Key takeaways
- SDK spoofing fakes installs and in-app events by copying the messages a measurement SDK sends to its server and sending them at scale. There is no real phone and no real user behind any of them.
- This sets it apart from click fraud. A click injection scheme steals credit for a real person’s install; SDK spoofing makes up the whole event, so no real person is ever there.
- Faking events pays more than faking installs alone. Once advertisers started paying per action, fraudsters began faking whole event chains to look like real users and earn the higher payout.
- Encryption hides the data in transit, but it does not prove who sent it. The real defense is signing each request, backed by a closed-source SDK that makes the protocol hard to copy.
What SDK Spoofing Is
Adjust defines SDK spoofing as a form of mobile ad fraud in which attackers forge the communication between an app’s SDK and its backend servers, generating install and engagement signals that look authentic without any real user activity behind them.
It is sometimes called traffic spoofing or a replay attack, because the core move is to capture the shape of a legitimate signal and send it again, over and over, with the values changed.
The trick lives in one specific place: the conversation between the measurement SDK inside an app and the mobile measurement partner (MMP) that records what happened. Every time someone installs an app or fires an event inside it, the SDK sends a small, structured message to the MMP saying so. SDK spoofing is the craft of writing those messages by hand, convincingly enough that the MMP records them as real. AppsFlyer, which also calls it SDK hacking, describes the same outcome from the other end: an advertiser ends up paying for tens or even hundreds of thousands of installs that never actually occurred.
What makes it stand apart from the rest of the fraud family is how little it needs. There is no phone farm to maintain, no emulator fleet to keep ahead of detection, no real person to recruit. Once the attacker has a working message, a single server can produce fraudulent installs all day, which is part of why the technique scales so cheaply and stays profitable.
How the Attack Gets Built
The work happens before any fake traffic is sent, in a quiet reconnaissance phase. Following the breakdown, Adjust lays out how it runs in three stages.
1. The attacker breaks open the secure channel
The SDK talks to its servers over an encrypted connection, so the attacker sits in the middle of their own test device and the MMP, a setup known as a man-in-the-middle (MITM) approach, and watches the traffic go by.
2. Reverse engineer the calls
By generating a handful of real installs and events on that test device, they learn which network request corresponds to an install, which one corresponds to a purchase, which fields stay the same every time, and which fields are dynamic and have to be filled in correctly for the call to be accepted.
3. Once they understand the recipe, they automate it
They generate large volumes of fake installs and post-install events with no user touching anything, and because the calls carry plausible device data, often harvested from real but compromised apps, they slide past the basic checks and get attributed as genuine.
There is a second route to the same place, and it matters because it explains why the problem is stubborn.
As AppsFlyer has argued, much of the public discussion frames SDK spoofing as a network attack, but the data can also be tampered with before it ever reaches the network.
Using runtime instrumentation tools, an attacker can hook into the app while it is running and change the values the SDK is about to send, then let the SDK package and sign and transmit them normally. The message leaves the device looking perfectly legitimate because, as far as the SDK is concerned, it is.
SDK Spoofing
How an SDK Spoofing Attack Is Assembled
Stage 01
Intercept
A man-in-the-middle setup on the attacker’s own test device watches the encrypted SDK traffic.
Stage 02
Reverse Engineer
They learn which calls mean an install or a purchase, and which fields are static versus dynamic.
Stage 03
Replay at Scale
One server fires thousands of fabricated calls, with no real device or user behind any of them.
Stage 04
Attributed as Real
The measurement partner records the fake signals as genuine installs and events.
Alternate path: on-device runtime tampering
Instead of replaying calls from a server, the attacker changes the values inside the app while it runs, then lets the SDK sign and send them. The traffic leaves the device looking perfectly valid.
No real phone or user exists past the attacker’s test device. Everything downstream is fabricated.
Why Fake In-App Events Are Worth More Than Fake Installs
Spoofing did not start by faking purchases. It started by faking installs because, for a long time, installs were what advertisers paid for.
As measurement matured and buyers got tired of paying for installs that never turned into anything, the money moved to cost-per-action deals, where a source earns its fee only when a user registers, subscribes, reaches a level, or buys. That shift was good for advertisers, and it changed the economics of fraud at the same time.
If a source is paid per install, a fabricated install is the whole prize. If a source is paid per purchase, a fabricated install earns nothing on its own, so the fraudster has to fabricate the purchase too.
That is the reason spoofed traffic so often arrives with a believable sequence of in-app events attached. A bare install with no activity behind it is suspicious and cheap. An install followed by a sign-up, a tutorial completion, and a first purchase looks like a high-value user and pays like one. The fraudster builds the funnel because the funnel is where the budget is.
This is also what makes spoofed in-app events more corrosive than spoofed installs alone.
The deeper damage is to your optimization. When fabricated purchase events flow into your reporting, the source that produced them looks like your strongest driver of revenue, so your bidding and your budget allocation tilt toward it, and the better the fake funnel, the more real money it pulls in.
How It Compares to Other Install Fraud
SDK spoofing is one of several schemes that end with credit assigned to a source that did not earn it, and they are easy to blur together.
The clean way to separate them is to ask two questions: is there a real device involved, and is there a real person? SDK spoofing is the only one where the answer to both is no.
| Fraud type | What gets faked | Real device? | Real user? | Telltale trait |
|---|---|---|---|---|
| SDK spoofing | Installs and in-app events, forged at the protocol level | No | No | Signals are server-generated; no device or user exists behind them |
| Click injection | The attribution credit for an install | Yes | Yes | Android-specific; a fake click fired in the seconds during an install |
| Click spam / flooding | Large volumes of clicks ahead of an organic install | Mixed | Sometimes, a real organic user is poached | Long, scattered click-to-install times |
| Device emulation | Installs and activity on virtual devices | Emulated | No | Emulator signatures and tell-tale behavioral patterns |
| Fake installs | Installs from devices or bots | Real or emulated | No genuine intent | Often mixed with real traffic to stay hidden |
The line that matters most for detection is the one between SDK spoofing and click injection, because the two demand opposite instincts. Click injection rides on top of real installs by real people who genuinely wanted the app, so those users engage and retain normally and you cannot catch the fraud by looking at their behavior. SDK spoofing is the reverse. There is no user, so there is no behavior to find, and the absence of behavior is exactly the thing that gives it away. Chasing retention is the wrong move against injection and the right one against spoofing.
SDK Spoofing
Real Install vs Spoofed Signal
✓ Real person
Someone genuinely wants the app.
× No one
There is no user at all.
✓ Real device
A genuine phone installs the app.
× No device
No phone performs the install.
✓ App fires it
The real SDK sends the signal.
Forged
The calls are recreated by hand.
✓ Authentic
One signal from a real session.
Fabricated
Fake signals sent at scale.
✓ Recorded right
Credit goes to the real source.
Recorded as real
The fake passes as a conversion.
The real chain is missing its first links: no person, no device. The fraud begins at the fabricated signal.
The Signals That Expose It
Because spoofed traffic is engineered to look ordinary on the surface, the tells are rarely in any single record. They show up in patterns and in the gap between what a source claims and what reality later confirms.
Technical signals
The first family of signals is technical, and AppsFlyer points straight at it: SDK version anomalies. A spoofing operation reproduces whatever SDK version it captured during reconnaissance, which is often not the version your live app actually ships.
So, installs arriving from an SDK version you never released, or a sudden spike in installs tied to one specific version that does not line up with your own release schedule, is a strong sign that something is generating traffic outside your real app.
Your MMP can usually surface this directly, and asking your attribution provider for a fraud exposure report is a reasonable first step when a source looks too good.
Reality gap
The second family is the reality gap, and it is the one that an advertiser can watch without any special tooling.
Spoofed events have no human behind them, so they never turn into the things only humans produce: the purchase events do not reconcile against the actual revenue in your payment system, the reported subscriptions never renew or show up in your billing, and the cohorts that looked busy in their first session flatten out because there is no one left to come back. None of these is proof by itself, since real campaigns have weak cohorts too, but a source whose reported value consistently fails to materialize as money or retention is telling you something the install count is not.
SDK Spoofing
The Reality Gap: Reported vs Confirmed
A confident top line and a collapsed bottom line. The wider the gap, the stronger the reason to investigate the source.
Why Encryption Alone Does Not Stop It
It is tempting to assume that an encrypted connection settles the matter, and this is where a lot of intuition goes wrong.
Adjust’s own documentation on SDK Signature is blunt about it: when an SDK sends data, it is encrypted with Transport Layer Security (TLS), the standard protocol that protects web traffic, but while TLS stops a bad actor from reading your data in transit, it does nothing to stop them from sending fraudulent install or event data to your endpoint in the first place.
Encryption proves the message was not tampered with on the wire. It does not prove the message came from a real instance of your app.
The runtime path from earlier makes the gap even clearer. If an attacker alters the data inside the app before the SDK packages it, the SDK encrypts and transmits the altered values through a perfectly valid secure connection, and the network-level protections that were supposed to guarantee authenticity are looking at traffic that is, by their own standards, completely clean.
Protection that only defends the channel is defending the wrong thing. A spoofing defense has to verify that the sender is a genuine instance of the app, and the encryption on that channel is not built to do that.
How Measurement Partners and Platforms Defend Against It
Since the problem is authenticity rather than secrecy, the defense has to prove that each signal came from a real, untampered instance of the app.
The mechanism the industry has settled on is cryptographic request signing. Each call the SDK sends is signed using a combination of app-specific secrets, dynamic parameters, and device and session data, which produces a hash that the receiving server can check.
Requests that arrive unsigned or carrying an invalid signature are rejected before they ever count, and on Android, the app’s signing-certificate fingerprint can be allowlisted, so traffic that does not match it is treated as suspicious. A spoofing server cannot reproduce that signature because it cannot predict or reuse the secret the real app holds.
Purchase events can be checked in a second way, more specific than the signature. A genuine in-app purchase produces a receipt issued by the App Store or Google Play, so the reported purchase can be confirmed against the store before its revenue is counted.
This receipt check validates the transaction with the store in real time and marks each purchase as genuine or not, so a spoofed purchase event with no real transaction behind it does not pass as real revenue. It only covers purchase-type events, but those are the ones tied most directly to payouts.
Signing works best when the SDK itself is hard to take apart, which is the case for a closed-source SDK. An open codebase makes the protocol transparent to everyone, including the attacker reverse engineering it, so the cryptographic logic is right there to study.
Keeping the SDK’s internals closed does not make reverse engineering impossible, since any software can be picked apart given enough effort, but it raises the cost and the time required, which is often enough to push an opportunist toward an easier target. Around both of these sit behavioral and anomaly detection at the MMP, which is where the SDK version spikes and other pattern breaks get caught.
The supply side has a role too. Networks and anti-fraud platforms that sit in the path between a traffic source and the advertiser can apply their own validation, flagging suspicious install and event patterns so they are filtered out rather than passed downstream as clean conversions.
No single layer is a wall on its own. Request signing rejects the forged calls it can prove are forged, anomaly detection catches the patterns signing alone would miss, and advertiser-side review of whether reported value turns into real money closes the part no automated filter can see for you. Each layer covers a different blind spot, which is why defense against spoofing is layered rather than absolute.
What Advertisers Can Do
SDK spoofing is convincing because it is built to be, copied from the real protocol and stripped of the one thing it cannot reproduce, an actual person using the app. That absence is also the opening.
The defense that holds is the combination of an MMP that signs and validates every request, a closed-source SDK that makes the protocol expensive to copy, and your own habit of checking whether a source’s reported value ever becomes real revenue and real retention.
Treat install and event counts as claims your own data still has to confirm, and route your attribution through a partner that rejects what it cannot verify. For every source that looks too good, one question cuts through the reported numbers: where are the people behind them.
FAQ
Is SDK spoofing the same as a bot or a fake install?
It is a more advanced relative. Fake installs are a broad category for any fraudulently generated install, and many of those use real or emulated devices that leave behavioral fingerprints. SDK spoofing skips the device entirely and forges the SDK’s server communication directly, which is what makes it harder to spot than a typical bot install.
Does it affect iOS or only Android?
The technique targets the SDK-to-server communication rather than anything platform-specific, so the basic method is not exclusive to one operating system. Some related defenses, such as Android signing-certificate fingerprinting, are platform-specific, but the core risk of forged or replayed signals applies wherever an SDK reports installs and events.
Why can’t an encrypted connection stop it?
Encryption keeps the data private and unaltered while it travels, but it does not verify that the sender is a genuine copy of your app. A fraudster can send fabricated data over a perfectly valid encrypted connection, or alter the data on the device before the SDK encrypts it. Stopping that requires signing each request so the server can reject anything it cannot verify, which encryption alone does not do.
How do I tell if a source in my own account is spoofed?
Look past the install and event counts to see whether the value shows up where it should. Check for installs reported from SDK versions you never shipped or version spikes that do not match your release schedule, and compare reported purchases and subscriptions against the revenue and renewals that actually hit your billing. A source that keeps reporting strong activity which never reconciles to money or retention is the pattern to investigate, and your MMP’s fraud reporting will usually flag the SDK-version anomalies directly.