εxodus n’exécute plus les applications durant 80 secondes pour les raisons suivantes :

• l’absence d’interactions humaines ne permet pas un minimum de pertinence (création de compte, login, navigation dans l’application, …)
  


• l’exécution dans un simulateur biaise totalement l’analyse puisque certains traqueurs se taisent lorsqu’ils sont exécutés sur simulateur
  


• Exodus Privacy ne dispose ni des moyens techniques ni des moyens humains pour maintenir et généraliser ce type d’analyse
  
  
  
  En bref, εxodus ne fait plus d’analyse d’activités réseau.

Effectivement, la décompilation fait partie des méthodes permettant de déterminer si un traqueur est inactif. La décompilation n’est pas une solution légale pour Exodus Privacy. L’autre solution permettant de constater l’activité d’un traqueur est d’analyser les communications réseau entre une applications et des serveurs distants, c’est l’un des objectifs du projet https://piranhalysis.github.io/.



Il est important de noter que certaines applications embarquent certains traqueurs qui seront activés ou non en fonction de campagnes marketing. Ainsi, aujourd’hui un traqueur peut être inactif et être activé demain.

La réinitialisation de l’identifiant publicitaire (advertising id  sous Android, idfa sous iOS) est bien souvent contourné par les trackers publicitaires de la façon suivante. La première fois qu’un tracker est lancé sur un mobile (lors du premier lancement d’une application qui le contient), ce tracker va générer un identifiant unique (impossible à modifier sans faire un reset d’usine) stocker sur le mobile. Ensuite, le tracker va envoyer systématiquement au serveur auquel il est associé : l’identifiant publicitaire + l’identifiant généré.

Ainsi, Facebook par exemple, connaît la liste de tous les identifiants publicitaires d’un mobile ainsi que les dates auxquelles l’identifiant publicitaire a été changé.

Sur le PiRogue, il est tout à fait possible d’utiliser Wireshark en plus de MITMproxy. Ce duo permet d’avoir l’intégralité du trafic réseau + le trafic HTTPS en clair (lorsque c’est techniquement possible). Il est également possible de décoder, à la volée les messages protobuf. C’est que fait, entre autre, ce plugin MITMproxy : GitHub



Et typiquement, le HotSpoot fait exactement ce que tu expliques : garder les IP de destinations + résolution DNS. Le projet est rapidement présenté ici :https://esther.codes/hotspoot-a-privacy-pot/



Enfin, tout dépend de l’objectif. Ici, l’objectif premier est d’analyser les messages envoyés par des applications Android.

1Mo dans l’IoT c’est énorme ! Dans l’IoT, la RAM fait quelques centaines de ko et la flash (là où on stocke le programme + les données) fait quelques Mo.

Bon nombre d’objets connectés ne font aucune vérification de certificat pour des raisons de coût. En effet, embarquer les certificats racines représente un gros volume de données et donc un espace mémoire plus grand et donc un équipement plus coûteux.