SDK Spoofing


Our SDK Signature prevents a sort of cellular performance fraud called SDK spoofing (also referred to as traffic spoofing or replay attacks). SDK spoofing is the invention of legitimate-looking installs on actual devices with no existence of any real installs.

Fraud evaluation

SDK spoofing is harder to find than fake installs made by emulation or install tanks. The installs seems to be valid; they can account for as many as 80 percent of the installs on any particular campaign.
Fraudsters collect actual device data using their own programs or leveraging any program they could acquire control over; this may occur via favorite programs which aren't in any way harmful (by way of instance, a battery saver or flashlight application). SDK spoofing turned into a substantial issue for cellular advertisers in 2017, as fraud strategies of the sort are becoming more complex and have moved out of readily viewed efforts indicating a very low comprehension of URL structures into a more complicated use of device-based parameters.

How can this exploit occur?

Fraudsters use a true device with no user really installing a program so as to create installs which appear real (since they are actual) and hence have a advertiser's budget. The apparatus used in this strategy are real and so active and distribute. Fraudsters try to commit This Kind of fraud:

  • Break open the SSL encryption involving the communicating of a monitoring SDK and its own backend servers by doing a 'man-in-the-middle assault'.
  • Generate a run test installs to your program they would like to defraud.
  • Learn which URL calls signify certain actions within the program.
  • Research that portions of those URLs are static and which are lively.
  • Test their installation and experimentation with the dynamic pieces.
  • Once one install is successfully monitored, the fraudsters will have figured out a URL installation which permits them to make installs from thin air.
  • Repeat indefinitely.

How can Offerseven combat this type of exploit?

Rather than short-term hotfixes, we chose to make a signature ribbon to signal SDK communication bundles. This technique makes sure that replay attacks don't work. We introduced a fresh, dynamic parameter to the URL that cannot be stolen or guessed and is only ever used once. To be able to accomplish a reasonably stable hash along with an equally sensible user experience for our customers, we opted for an extra shared secret, which is generated from the dashboard for every program the customer would like to secure. Marketers have the chance to renew keys and use different types for different variant releases of the program. This lets them deprecate signature variations as time passes, making certain attribution is based on the maximum safety standard for the newest releases and the elderly releases may be taken out from attribution fully.

How can this work?

The newest SDK signature is produced by combining an program's key - many fields which are unique to the program itself and are incorporated in the SDK - along with multiple different areas hashed and delivered together with the install petition. Our backend supports the traffic arriving out of your SDK through the touch, and when there's's a game we'll take the install.

Drop us a line to get on board!

Response message