Pour faire très simple, le principe de validation se fait avec 4 entités:
1. Ton device, l'appli qui nécessite la certif PI (A)
2. Un serveur lié à l'appli qui fait la demande de certification (B)
3. Un serveur qui communique via internet avec B, géré par Google (C)
4. DroidGuard (sur ton téléphone) qui dialogue avec (C) et (A) : (D)
La séquence:
1. Lors d'une certif PI, ton appli (A) demande au PlayService de valider ton système. Celui télécharge une VM et la lance via (D).
2. La VM est "obfuscated", mais grosso modo, c'est un spyware qui va scruter ton téléphone en mode root/système pour y détecter toute modification non googlesque.
3. Ton appli (A) va communiquer avec (B) qui va lui donner un token opaque qu'elle va passer à (D)
4. DroidGuard va signer ce token avec la clé publique de Google en y ajoutant toutes les infos issues du spyware (pas très RGPD tout ça, mais passons) et l'envoyer à (C).
5. Le serveur de ton appli (B) va communiquer avec (C) pour lui soumettre le token à vérifier
6. Le serveur PI (C) va s'assurer que le token fourni par (D) est bien signé (donc validation HW validée) et correspond à celui fourni par (B). Il va dire à (B) "Ok c'est bon".
7. (B) va renvoyer un "Go go go" à ton appli (A) pour qu'elle continue de t'afficher des pubs, sinon, c'est la page rouge "erreur VTFF"
Donc toute cette architecture a plusieurs failles:
1. Tu peux MITM le serveur (B) de ton appli. Mais s'il est pas trop débile, tant qu'il n'a pas vu la demande de certif PI, il peut te jeter. Par contre, une fois la demande PI faite, si tu maintiens la session en vie via un MITM, tu peux continuer ad vitam æternam à utiliser l'appli, même sur un autre téléphone. C'est une des fonctions de MicroG d'ailleurs: d'utiliser un téléphone ancien qui passe PI comme proxy DroidGuard.
2. Tu peux pas MITM le serveur (C) car c'est sur internet
3. Tu peux truander DroidGuard avec ton propre "DroidDeguard" qui répond comme l'original mais fait ce qu'il veut. C'est le maillon faible de la chaîne, d'où la technique de sécurité par l'obscurité ici, avec les VM polymorphe de Google. Une fois une VM décodée pour comprendre le protocole utilisé pour dialoguer avec (C), c'est game over. Le protocole a peu de chance de changer, vu le nombre de device en circulation et la lenteur pour certain de se mettre à jour. Si un LLM peut rev. eng. le protocole en un jour, de toute façon, c'est impossible pour Google de mettre à jour ses serveurs prod à cette vitesse.
4. Tu peux hacker l'application (A) pour qu'elle ne fasse pas la demande PI. Mais comme la logique/sécurité du système est très probablement dans (B), tu n'iras pas loin de toute façon, si (B) voit des requêtes sur quelque chose qui est censé arriver après la certif PI, il va te jeter.
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . En réponse à la dépêche La certification du matériel appliquée aux ordiphones: la sécurité comme prétexte pour constituer un oligopole ?. Évalué à 4 (+3/-0). Dernière modification le 08 juillet 2026 à 10:58.
Regarde mon post juste au dessus.
Pour faire très simple, le principe de validation se fait avec 4 entités:
1. Ton device, l'appli qui nécessite la certif PI (A)
2. Un serveur lié à l'appli qui fait la demande de certification (B)
3. Un serveur qui communique via internet avec B, géré par Google (C)
4. DroidGuard (sur ton téléphone) qui dialogue avec (C) et (A) : (D)
La séquence:
1. Lors d'une certif PI, ton appli (A) demande au PlayService de valider ton système. Celui télécharge une VM et la lance via (D).
2. La VM est "obfuscated", mais grosso modo, c'est un spyware qui va scruter ton téléphone en mode root/système pour y détecter toute modification non googlesque.
3. Ton appli (A) va communiquer avec (B) qui va lui donner un token opaque qu'elle va passer à (D)
4. DroidGuard va signer ce token avec la clé publique de Google en y ajoutant toutes les infos issues du spyware (pas très RGPD tout ça, mais passons) et l'envoyer à (C).
5. Le serveur de ton appli (B) va communiquer avec (C) pour lui soumettre le token à vérifier
6. Le serveur PI (C) va s'assurer que le token fourni par (D) est bien signé (donc validation HW validée) et correspond à celui fourni par (B). Il va dire à (B) "Ok c'est bon".
7. (B) va renvoyer un "Go go go" à ton appli (A) pour qu'elle continue de t'afficher des pubs, sinon, c'est la page rouge "erreur VTFF"
Donc toute cette architecture a plusieurs failles:
1. Tu peux MITM le serveur (B) de ton appli. Mais s'il est pas trop débile, tant qu'il n'a pas vu la demande de certif PI, il peut te jeter. Par contre, une fois la demande PI faite, si tu maintiens la session en vie via un MITM, tu peux continuer ad vitam æternam à utiliser l'appli, même sur un autre téléphone. C'est une des fonctions de MicroG d'ailleurs: d'utiliser un téléphone ancien qui passe PI comme proxy DroidGuard.
2. Tu peux pas MITM le serveur (C) car c'est sur internet
3. Tu peux truander DroidGuard avec ton propre "DroidDeguard" qui répond comme l'original mais fait ce qu'il veut. C'est le maillon faible de la chaîne, d'où la technique de sécurité par l'obscurité ici, avec les VM polymorphe de Google. Une fois une VM décodée pour comprendre le protocole utilisé pour dialoguer avec (C), c'est game over. Le protocole a peu de chance de changer, vu le nombre de device en circulation et la lenteur pour certain de se mettre à jour. Si un LLM peut rev. eng. le protocole en un jour, de toute façon, c'est impossible pour Google de mettre à jour ses serveurs prod à cette vitesse.
4. Tu peux hacker l'application (A) pour qu'elle ne fasse pas la demande PI. Mais comme la logique/sécurité du système est très probablement dans (B), tu n'iras pas loin de toute façon, si (B) voit des requêtes sur quelque chose qui est censé arriver après la certif PI, il va te jeter.