ε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.
Le
27/11/2018 à
13h
55
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 : GitHubEt 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.
Le
28/03/2018 à
14h
17
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.
Le
27/03/2018 à
19h
13
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.
6 commentaires
L’effet du RGPD sur les trackers des applications Android, selon Exodus Privacy
24/11/2018
Le 27/11/2018 à 14h 04
εxodus n’exécute plus les applications durant 80 secondes pour les raisons suivantes :
En bref, εxodus ne fait plus d’analyse d’activités réseau.
Le 27/11/2018 à 13h 55
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 CNIL s’attaque encore à la publicité mobile, cette fois avec Vectaury
09/11/2018
Le 10/11/2018 à 17h 47
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é.
Avec PiRogue, capturer le trafic HTTP(S) d’un smartphone devient plus simple
27/03/2018
Le 28/03/2018 à 15h 10
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 :
GitHubEt 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.
Le 28/03/2018 à 14h 17
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.
Le 27/03/2018 à 19h 13
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.