What is SDK spoofing?
Definition: What is SDK spoofing?
SDK spoofing, also known as traffic spoofing or replay attacks, occurs when attackers generate install and engagement signals that appear authentic by replicating real device data and SDK server calls. Instead of driving real users, fraudsters fabricate high volumes of “installs” and in-app events to siphon advertising spend.
Unlike simpler fraud tactics, SDK spoofing operates at the protocol level, making it significantly harder to detect. The signals look indistinguishable from legitimate traffic unless advanced validation methods are in place.
)
How SDK spoofing works
SDK spoofing exploits the communication layer between an app and its measurement or attribution provider. Fraudsters typically follow a multi-step process:
- Breaking secure communication
Attackers intercept and analyze the encrypted communication between an app’s SDK and backend servers. This is often done using a man-in-the-middle (MITM) approach to observe how install and event data is transmitted. - Reverse engineering SDK calls
Once they understand the structure of network requests, fraudsters identify:
- Which URLs correspond to installs and in-app events
- Which parameters remain static
- Which parameters are dynamic and required for validation
- Simulating installs and events
After successfully replicating a legitimate install signal, fraudsters can automate the process. They generate large volumes of fake installs and post-install events without any actual user interaction. Because these requests include real device data (often harvested from compromised or controlled apps), they pass basic validation checks and are attributed as genuine.
Why SDK spoofing is effective
SDK spoofing stands out as one of the most advanced forms of mobile ad fraud for several reasons.
- It mimics real user behavior: Unlike bot traffic or emulated installs, spoofed activity uses real device data, making it appear credible. This includes device IDs, OS versions, and other signals typically used in attribution.
- It scales easily: Once fraudsters identify a working request structure, they can replicate it indefinitely. This allows them to generate massive volumes of fake installs at minimal cost.
- It bypasses traditional detection: Basic fraud prevention systems often rely on identifying anomalies in device behavior or traffic patterns. SDK spoofing avoids these signals entirely by operating within expected parameters. In some cases, spoofed installs can account for a significant share of campaign activity, making them difficult to distinguish without specialized protections.
SDK spoofing vs. other fraud types
While SDK spoofing is often grouped with other types of mobile ad fraud, it differs in execution and sophistication.
)
Click spam: Click spam (also known as click flooding) involves generating large volumes of fake clicks in the hope of being credited for organic installs. Unlike SDK spoofing, it does not fabricate installs directly—it manipulates attribution by overwhelming the system with fraudulent clicks.
Click injection: Click injection occurs when fraudsters detect when an app is being installed on a device and inject a last-second click just before the install is registered. This hijacks attribution from legitimate sources. SDK spoofing, by contrast, fabricates the entire install event from scratch.
Device emulation: Device emulation uses virtual devices to simulate installs and app activity. These environments can often be detected through behavioral patterns or emulator signatures. SDK spoofing bypasses this entirely by forging server-side communication without simulating a device.
Fake installs:Fake installs is a broad category encompassing any fraudulent install generation. SDK spoofing is a more sophisticated subset, distinguished by its ability to replicate SDK-level signals rather than surface-level activity.
Key risks for mobile app marketers
SDK spoofing directly impacts campaign performance, budget efficiency, data reliability, and decision-making by introducing fraudulent signals that appear legitimate. Advertisers end up paying for installs and in-app events that never actually occurred, draining budgets without acquiring real users. At the same time, these fabricated installs distort attribution data, making it significantly harder to evaluate campaign effectiveness or optimize channels with confidence.
Because spoofed traffic often looks high-performing on the surface, marketers may unintentionally allocate more spend toward fraudulent sources, compounding the problem. Over the long term, this erosion of data integrity leads to flawed insights, ultimately impacting core strategies such as user acquisition planning, budget allocation, and lifetime value modeling.
How Adjust prevents SDK spoofing
SDK spoofing cannot be fully addressed with reactive detection. Instead, it demands proactive validation at the source of data transmission. A prevention-first approach ensures that fraud is stopped before it impacts data, attribution remains accurate, marketing decisions are based on real user behavior, meaning datasets can be relied on.
Adjust combats SDK spoofing through SDK signature, an anti-spoofing solution against external attack vectors, validating every install and event at the moment it is sent. The SDK Signature library is designed to be easy to integrate and to work seamlessly with the Adjust SDK without the need for any extra code.
Each SDK request is signed using a unique combination of app-specific secrets, dynamic parameters, and device- and session-level data. This creates a secure hash that cannot be predicted, reused, or forged.
For app marketers and developers, the key takeaway is clear: accurate attribution requires secure attribution. Without robust validation mechanisms, even the most advanced campaigns are vulnerable.
Learn more about Adjust’s Fraud Prevention Suite or request a demo today to see first-hand how we can grow (and secure) your app business.
Never miss a resource. Subscribe to our newsletter.
Keep reading
)