What is SDK spoofing?

How it differs from other fraud

Most fraud involves some real activity — a real device, a real install, a stolen attribution. SDK spoofing skips all of it.

The fraudster reverse-engineers the communication between a measurement SDK and its server, then sends those requests directly. No app is installed, no device is involved, and no user exists. The measurement platform records installs and events because it received exactly the messages an install would produce.

It is the purest form of the fraud: manufacturing the evidence rather than manufacturing the activity.

Why it was effective

Downstream quality checks are useless against it. A spoofer can fabricate any post-install event sequence they like, including one that looks like excellent retention and healthy engagement, because they are writing the story rather than being observed.

Cost is also negligible. There are no devices to farm and no real installs to generate — just requests, which can be produced at enormous volume from very little infrastructure.

How it is defeated

Cryptographic signing. Modern measurement SDKs sign their traffic with keys that are provisioned and rotated, so a request that is not signed correctly is rejected regardless of how plausible its contents look.

That moves the attack from reverse-engineering a protocol — a one-off effort with a long payoff — to extracting live keys, which is much harder and has to be repeated as keys rotate.

The practical requirement for advertisers is unglamorous: keep measurement SDKs current. Spoofing defences live in the SDK, and an outdated version is running last year's protections against this year's attacks.

• Keep SDK versions current, which is the single most effective control.
• Verify signing is enabled rather than assuming it is on by default.
• Watch for sources with perfect metrics, since fabricated behaviour tends to lack the messiness of real users.
• Hold out. Fabricated installs produce no lift — see incrementality.