Non, ce n'est pas possible. Relis le post plus haut.
Le protocole entre le serveur associé à l'appli et celui des serveurs PI est fixé (par Google), il ne peut pas changer sans casser la totalité des applications utilisant PI (ou alors très lentement, genre sur plusieurs années).
Donc la seule chose qui pourrait changer c'est le protocole entre DroidGuard et le serveur PI de Google (qui n'est pas documenté). Mais ça voudrait dire faire une version du code serveur PI par (削除) client (削除ここまで) VM générée (ce qui est impossible, vu qu'il y a des milliards de clients, tu ne peux pas avoir des milliards d'instances différentes d'un logiciel sur des serveurs).
Donc il y a forcément un protocole commun entre les VM et le serveur. Si protocole commun il y a, alors un LLM qui rev eng n'importe laquelle des VM va pouvoir se faire passer pour ce client là.
Quand au nonce, il faut bien comprendre que la VM n'a pas d'accès au réseau (ce serait trop facile à proxifier évidemment, vu qu'il est possible de le faire au niveau noyau avec un eBPF ou un tcpdump tout bête). Elle communique avec un service commun (des play services) qui lui communique avec le serveur. Le "nonce", c'est le token, il est forcément publique (du moins entre Google et l'application). Le token est signé (avec du code de crypto standard, voire ton TEE, on s'en fout) par Droidguard, la sécurité n'est pas là, il est trop facile d'intercepter la signature et de la modifier/forger. Ce qui est difficile c'est ce que la VM Droidguard génère elle même (la charge) avant la signature et qui valide ton téléphone. C'est ça qu'une LLM doit simuler: générer une charge validable par les serveurs PI. Et le contenu de la charge peut changer d'une VM à l'autre, mais vu la limitation sur les serveur PI exposée plus haut, il ne peut pas y avoir des milliards de format de charges différents, il en suffit d'un.
Enfin la VM n'est pas "petite" non plus (vu la taille pour l'obfuscation et l’interpréteur de leur pseudo code stack), donc impossible d'envoyer une VM pour chaque requête PI (encore une fois, un milliard d'Android * quelques Mo = trop de données).
[^] # 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é à 2 (+1/-0).
Non, ce n'est pas possible. Relis le post plus haut.
Le protocole entre le serveur associé à l'appli et celui des serveurs PI est fixé (par Google), il ne peut pas changer sans casser la totalité des applications utilisant PI (ou alors très lentement, genre sur plusieurs années).
Donc la seule chose qui pourrait changer c'est le protocole entre DroidGuard et le serveur PI de Google (qui n'est pas documenté). Mais ça voudrait dire faire une version du code serveur PI par
(削除) client (削除ここまで)VM générée (ce qui est impossible, vu qu'il y a des milliards de clients, tu ne peux pas avoir des milliards d'instances différentes d'un logiciel sur des serveurs).Donc il y a forcément un protocole commun entre les VM et le serveur. Si protocole commun il y a, alors un LLM qui rev eng n'importe laquelle des VM va pouvoir se faire passer pour ce client là.
Quand au nonce, il faut bien comprendre que la VM n'a pas d'accès au réseau (ce serait trop facile à proxifier évidemment, vu qu'il est possible de le faire au niveau noyau avec un eBPF ou un tcpdump tout bête). Elle communique avec un service commun (des play services) qui lui communique avec le serveur. Le "nonce", c'est le token, il est forcément publique (du moins entre Google et l'application). Le token est signé (avec du code de crypto standard, voire ton TEE, on s'en fout) par Droidguard, la sécurité n'est pas là, il est trop facile d'intercepter la signature et de la modifier/forger. Ce qui est difficile c'est ce que la VM Droidguard génère elle même (la charge) avant la signature et qui valide ton téléphone. C'est ça qu'une LLM doit simuler: générer une charge validable par les serveurs PI. Et le contenu de la charge peut changer d'une VM à l'autre, mais vu la limitation sur les serveur PI exposée plus haut, il ne peut pas y avoir des milliards de format de charges différents, il en suffit d'un.
Enfin la VM n'est pas "petite" non plus (vu la taille pour l'obfuscation et l’interpréteur de leur pseudo code stack), donc impossible d'envoyer une VM pour chaque requête PI (encore une fois, un milliard d'Android * quelques Mo = trop de données).