The Adjust Mobile Measurement Glossary
Our SDK Signature prevents a form of mobile performance fraud known as SDK spoofing (also called traffic spoofing or replay attacks). SDK spoofing is the creation of legitimate-looking installs with data of real devices without the presence of any actual installs.
- 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.
- 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).
- SDK spoofing became a significant problem for mobile advertisers in 2017, as fraud schemes of this type have become more sophisticated and have moved from easily spotted attempts indicating a low understanding of URL structures to a more sophisticated use of device-based parameters.
How does this exploit happen?
Fraudsters utilize a real device without the device’s user actually installing an app in order to create installs that look real (because they are real) and thereby consume an advertiser’s budget. The devices used in this scheme are real and therefore active and spread out. To commit this type of fraud, fraudsters must:
- Break open the SSL encryption between the communication of a tracking SDK and its backend servers by performing a ‘man-in-the-middle attack’.
- Generate a series of test installs for the app they want to defraud.
- Learn which URL calls represent specific actions within the app.
- Research which parts of the URLs are static and which are dynamic.
- 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.
- Repeat indefinitely.
How does Adjust combat this kind of exploit?
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 the older releases can be removed from attribution fully.
How does this work?
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.