The Two-Second Ad Auction You Never See · NowSecure Labs

What happens when you open the app.

A mobile "ad auction" is exactly what it sounds like. Every blank ad slot in a free app<br>is sold in real time to the buyer willing to pay the most. The auction finishes in a few<br>hundred milliseconds. To bid intelligently, each ad company wants signals about the<br>device and the user, and the app sends those signals along with the request, where every<br>bidder sees them whether they win or lose. AppLovin runs one of the largest such auction<br>networks on mobile, under the brand name MAX.

Concretely: you open a free game. Before the first frame draws, the phone sends a tiny<br>encrypted request to a server called<br>ms4.applovin.com. That request asks AppLovin<br>to run the auction for the slot on your screen. AppLovin doesn't run it alone. The<br>documented behavior is that AppLovin passes parts of the request along to roughly<br>seventeen other ad companies, each of which gets a chance to bid. Whoever bids the most<br>wins the right to show you one banner, one interstitial, or one rewarded video. A few<br>hundred milliseconds later, an ad appears.

Partner list per Buchodi's analysis. The hand-off from AppLovin to each partner happens<br>inside AppLovin's servers, so we can confirm the shape of the auction message from our<br>measurements but we don't independently confirm which app's data reaches which partner.

The auction message is encrypted, so in principle nobody outside AppLovin and its partner<br>graph can read what each app actually shipped about the device or the user. That's the<br>part that just changed.

What the researcher figured out.

In May 2026, a security researcher writing under the name Buchodi<br>published an analysis showing that AppLovin's encryption keys are derived inside the SDK<br>from a string the app itself ships in plaintext: a value called the "SDK key" that sits in<br>Info.plist on iOS and AndroidManifest.xml on Android. Anyone who<br>downloads the app can read those bundles, rebuild the keys, and decrypt the request<br>bodies. Inside, the researcher found device identifiers, app metadata, consent signals,<br>the SDK version, the user's locale and timezone, and other device-fingerprinting fields.

The most quietly important finding in Buchodi's write-up is what happens when a user<br>opts out of App Tracking Transparency (ATT) on iOS. Apple's<br>opt-out zeros out the advertising identifier and the per-vendor identifier (Apple's<br>idfv) inside the auction body. Those are exactly the two fields Apple<br>designed the prompt around. Every other signal in the body is still populated and<br>still sent : the device model and OS build, the app build, the language and<br>region, screen dimensions, network type, the consent strings, the SDK configuration.<br>Enough to fingerprint a device across apps even without the IDFA, and enough to ship to<br>each of the seventeen demand-partner companies in the fan-out.

We're not republishing the research. The reverse-engineering belongs to Buchodi and it's<br>on their blog. We wanted to know something different: how many real, shipping mobile<br>apps emit this kind of message?

This is downstream research. The technical credit for breaking the<br>cipher is Buchodi's. The original write-up is at buchodi.com. Read it first if you want the protocol details. We're just counting.

What an auction message looks like.

Every request shares the same shape. Three short metadata fields, followed by an<br>encrypted body, all colon-separated:

decoded mediation envelope (after URL-decoding the p= query value)

version<br>protocol ID (40 hex)<br>SDK key suffix (54 chars)<br>encrypted body

2version

8a23…e8a3aprotocol ID

9o-B…-TSDK key suffix &middot; 54 chars

&middot;&middot;&middot;&middot;&middot;&middot;&middot;&middot;&middot;ciphertext (opaque)

We can see that shape. We don't decrypt the contents<br>on our test devices yet. That requires the app's SDK key, which we<br>did not use in this measurement just yet. Our claim is thus: if<br>a mobile app emits a request that matches this structure, that's a<br>strong signal it's using the version of the AppLovin protocol the<br>researcher just unwrapped.

Buchodi did decrypt it, and reported what's inside. The fields below come from their<br>write-up, not from our measurements. The point of listing them is to show that the<br>decrypted body is not abstract: it's a specific, surprisingly long fingerprint that goes<br>out on every auction.

What's inside the encrypted body<br>source: Buchodi

Identifiers

idfa zeroed if ATT deniedApple's cross-app advertising identifier.

idfv always sentApple's per-vendor identifier. Persists even after opt-out.

api_did "BADDID" sentinel if ATT deniedAppLovin's own server-issued device ID.

Hardware & OS

revisionHardware model code (e.g. iPhone14,3).

osOS patch version (e.g. 18.6.2).

tmTotal RAM in bytes.

ndx × ndyNative pixel screen dimensions, plus safe-area insets.

bt_ms_2Boot time in epoch milliseconds. A fingerprint anchor that survives app reinstalls.

System settings & state

kbInstalled...