What is SDK Spoofing?

SDK spoofing is the creation of legitimate-looking installs with data of real devices without the presence of any actual installs. Fraudsters utilize a real device to create installs that look real to consume an advertiser’s budget. It is also known as traffic spoofing and replay attacks.

To commit this type of fraud, fraudsters break open the SSL encryption between the communication of a tracking SDK and its backend servers by performing a ‘man-in-the-middle attack’. Then the fraudster will generate a series of test installs for the app they want to defraud.

After learning which URL calls represent specific actions within the app, they will research which parts of the URLs are static and which are dynamic. They can then test their setup and experiment with the dynamic parts. Once a single install is successfully tracked, the fraudsters will have figured out a URL setup that allows them to create installs out of thin air. This can then be repeated indefinitely.

1. SDK spoofing is harder to detect than fake installs generated by emulation or install farms. The installs appears to be legitimate; they may account for up to 80% of your installs on any given campaign.

2. Fraudsters collect real device data by using their own apps or leveraging any app they can gain control over; this can happen via popular apps that are not at all dangerous (for example, a battery saver or flashlight tool.)

3. SDK spoofing became a significant problem for mobile advertisers in 2017, as fraud schemes of this type have become more sophisticated and move from easily spotted attempts to a more sophisticated use of device-based parameters.

Instead of short term hotfixes, we decided to create a signature hash to sign SDK communication packages. This method ensures that replay attacks do not work. We introduced a new, dynamic parameter to the URL which cannot be guessed or stolen and is only ever used once. In order to achieve a reasonably secure hash and an equally reasonable user experience for our clients, we opted for an additional shared secret, which will be generated in the dashboard for each app the client wants to secure. Marketers also have the opportunity to renew secrets and use different ones for different version releases of their app. This allows them to deprecate signature versions over time, making sure that attribution is based on the highest security standard for the newest releases and older releases can be removed from attribution fully.

To learn more about Adjust’s SDK Signature, take a look at our documentation.

The new SDK signature is made by combining an app’s secret - several fields that are unique to the app itself and are integrated into the SDK - with multiple other fields hashed and sent with the install request. Our backend verifies the traffic coming from the SDK through the signature, and if there’s a match we will accept the install.