Piratage du chiffrement de la médiation AppLovin : l'empreinte numérique des appareils contourne l'ATT

Une analyse approfondie du protocole de médiation publicitaire d'AppLovin a mis en lumière un chiffrement personnalisé qui ne protège pas la vie privée des utilisateurs. Le chercheur a déchiffré plus de 5 000 véritables requêtes d'enchères capturées à partir d'utilisateurs consentants et a constaté que la charge utile chiffrée transmet suffisamment de données sur l'appareil pour identifier de manière unique un iPhone entre des applications de différents éditeurs — même lorsque l'utilisateur a refusé l'autorisation App Tracking Transparency (ATT).
Comment fonctionne le chiffrement
Chaque requête de médiation est un POST HTTPS vers ms4.applovin.com/1.0/mediate. À l'intérieur de la couche TLS, un second chiffrement encapsule la charge utile. Après décodage base64, le format filaire est composé de trois champs séparés par des deux-points + le texte chiffré :
2:8a2387b7dbed018e5e485792eac2b56833ce8a3a:T7NreIR729giTKR-thJPcKeT6JXevACogl57SIFzwKp-1BASwpBT6v:<binaire>
Champs :
- Tag de version (
2) - Identifiant de protocole de 40 caractères —
sha1(salt).hex() - Suffixe de 54 caractères de la clé SDK AppLovin de l'éditeur (stockée en clair dans
Info.plistouAndroidManifest.xml)
Le chiffrement utilise deux ingrédients : un sel constant de 32 octets intégré dans chaque binaire SDK (21 octets significatifs + 11 octets nuls, identique sur plusieurs applications et plateformes) et la clé SDK par éditeur. La clé dérivée est SHA-256(salt || sdk_key[:32]). Le flux de clé est généré en utilisant SplitMix64, un PRNG non cryptographique. Le compteur est System.currentTimeMillis() XORé avec les 8 premiers octets de la clé dérivée — ce qui divulgue l'heure horloge murale sur le fil avant le déchiffrement. Aucun MAC ou authentification n'est appliqué, ce qui signifie qu'un attaquant peut altérer le texte chiffré.
Ce qui est transmis
Le texte clair déchiffré est du JSON compressé en gzip avec environ 30 clés de premier niveau. Les plus critiques :
device_info— la charge utile d'empreinte d'AppLovin avec environ 50 champssignal_data[]— des jetons opaques de chaque SDK partenaire de demande
Un exemple d'une requête où ATT a été refusé (IDFA mis à zéro) :
Champ Valeur Description
revision iPhone14,3 Modèle matériel (iPhone 13 Pro Max)
os 18.6.2 Version du système d'exploitation
tm 5918212096 RAM totale (5,51 Go)
ndx / ndy 1284 × 2778 Pixels d'écran natifs
kb en-US,es-ES Claviers installés
font UICTContentSizeCategoryXXXL Taille du texte d'accessibilité
tz_offset -4 Fuseau horaire
volume 40 Volume audio système
mute_switch 1 Interrupteur physique de sourdine
bt_ms_2 1770745989000 Heure de démarrage de l'appareil (ms epoch)
dnt / idfa true / 00000… ATT refusé
idfv 81E958C3-…-51DE7CE11819 Identifiant du fournisseur (stable entre applications)
Des champs supplémentaires incluent les marges de zone sécurisée, la mémoire libre, le code opérateur, le code pays, la locale, l'orientation, la hauteur de la barre d'état, l'horloge monotone, les indicateurs de batterie et l'état de la connexion sécurisée. Cela équivaut à pratiquement toutes les propriétés système accessibles par un code tiers.
Exposition en aval
Un éditeur typique inclut environ 18 SDK de demande (Meta, Google, Mintegral, Vungle, ironSource, Unity, InMobi, BidMachine, Fyber, Moloco, TikTok, Pangle, Chartboost, Verve, MobileFuse, Bigo, Yandex, plus celui d'AppLovin). À chaque chargement de bannière (environ 30 secondes), le SDK AppLovin transmet la charge utile déchiffrée de l'appareil à chacun de ces réseaux en aval, permettant le suivi inter-applications des utilisateurs sans consentement ATT.
Implications
L'hypothèse selon laquelle ATT seul empêche une identification déterministe est fausse. L'empreinte de l'appareil via les champs divulgués fonctionne tout aussi bien. L'absence d'authentification dans la couche de chiffrement soulève également des préoccupations d'intégrité.
📖 Lire la source complète : HN AI Agents
👀 See Also

Google TIG signale la première exploitation zero-day générée par IA dans la nature
Le groupe Google Threat Intelligence a identifié un acteur malveillant utilisant une exploitation de zero-day présumée développée avec l'IA, marquant la première utilisation offensive observée de l'IA pour l'exploitation de vulnérabilités zero-day.

ClawCare : Garde du corps pour les agents de codage IA après une fuite de clé AWS
ClawCare est un outil Python qui analyse les commandes avant leur exécution dans les agents de codage IA comme Claude Code, bloquant les modèles risqués tels que les vidages massifs d'environnement et les shells inversés. Il a été créé après qu'un développeur a accidentellement divulgué une clé AWS via un agent.

Recherche : Les caractères Unicode invisibles peuvent détourner les agents LLM via l'accès aux outils
Une étude a testé si les LLM suivent des instructions cachées dans des caractères Unicode invisibles intégrés dans du texte normal, en utilisant deux schémas d'encodage sur cinq modèles et 8 308 sorties évaluées. Résultat clé : l'accès aux outils amplifie la conformité de moins de 17 % à 98-100 %, les modèles écrivant des scripts Python pour décoder les caractères cachés.

Sécurité OpenClaw : 13 étapes pratiques pour sécuriser votre agent IA
Un post Reddit détaille 13 mesures de sécurité pour les installations OpenClaw, notamment l'exécution sur une machine séparée, l'utilisation de Tailscale pour l'isolation réseau, le confinement des sous-agents dans Docker et la configuration de listes d'autorisation pour l'accès des utilisateurs.