Si vous avez un téléphone rooté, optez pour nethogs (pour le contrôle en direct) ou iptables (pour obtenir des statistiques) outils en ligne de commande. L'utilisation d'un VPN ou d'applications Android basées sur les statistiques est la seule solution possible sans root. Ou consultez cette réponse pour un logcat / dumpsys solution basée sur la technologie.
Tout d'abord, le suivi de l'UID ou du PID d'un flux réseau n'est pas simple car ces paramètres ne sont pas liés au réseau mais au système d'exploitation. Propositions y projets abandonnés existent.
Android attribue un UID unique à chaque application installée, tout comme chaque utilisateur humain sous Linux possède un UID. Nous pouvons donc capturer les paquets envoyés par un UID spécifique sur les interfaces réseau pour suivre son utilisation.
TCPDUMP :
Maintenant, comment pouvons-nous capturer le trafic réseau ? La plupart des renifleurs de réseau utilisent libpcap famille de bibliothèques indépendantes du système à cette fin. Elle prend en charge Filtre à paquets BSD (BPF) pour le filtrage des paquets dans le noyau. Certains utilitaires populaires qui utilisent libpcap inclure tcpdump , nmap , tshark/wireshark , dumpcap , nethogs etc. Application Android Utilitaires de réseau et d'autres font également appel à tcpdump .
Toutefois, l'information sur l'UID n'est pas propagée par le biais de l'interface utilisateur. AF_PACKET / PF_PACKET canal qui pcap utilise à Couche 2 de l'OSI . Ce que nous pouvons faire ici, c'est utiliser les sockets réseau (combinaison d'IP et de port) créés et utilisés par une application. netstat -tup ou ss -tup affichera tous les sockets réseau avec des connexions actives/établies. Les deux outils sont disponibles sur Android (ou vous pouvez obtenir un binaire statique), ss est le plus récent. Socket vs. UID Les informations peuvent également être lues directement à partir de /proc/net/{tcp,udp} . Application Android Netstat Plus fonctionne sur le même principe. Cela fournira l'adresse locale (socket) utilisée par un processus.
Une fois que nous savons quels sockets sont utilisés par une application (UID), tcpdump -i wlan0 src <IP> and port <PORT> va vider tout le trafic issu de ce processus.
De même, une prise à distance (si elle n'est pas connectée par plusieurs applications) peut également être utilisée pour filtrer les résultats.
LIMITES :
Toutefois, cette approche pose quelques problèmes :
- Les applications Android lancent généralement plusieurs processus à la fois, en parallèle, c'est-à-dire plusieurs PIDs travaillant sous le même UID . Nous devons donc capturer le trafic de tous les processus.
- Les applications continuent à créer et à supprimer des sockets. Garder la trace de des prises de courant qui changent continuellement est presque impossible, surtout lorsqu'un grand nombre d'applications accèdent simultanément au réseau.
- Il existe - bien que rarement - une possibilité que les les sockets sont partagés par plusieurs processus sur les systèmes d'exploitation de type UNIX. Les sockets partagés distants tels que UDP/53, utilisés pour la résolution DNS, ne peuvent pas être suivis par un seul processus. Cela affaiblit encore plus l'approche.
NetHogs traverse procfs et s'adapte aux limitations susmentionnées (bien que cela ne soit pas toujours très réussi) :
![]()
IPTABLES :
Les inconvénients d'un outil de couche 2 décrits ci-dessus peuvent être atténués par les moyens suivants iptables LOG ou NFLOG . Couche 2 se situe juste au-dessus de la couche physique, c'est-à-dire que c'est la dernière chose que les paquets rencontrent avant de quitter le dispositif. C'est pourquoi, se situant au niveau de la couche liaison de données et travaillant à un niveau inférieur de la pile réseau, le BPF est une sorte de mécanisme de filtrage de paquets sans état, par rapport aux mécanismes suivants netfilter / iptables qui travaille à l'OSI Couche 3 (plus proche des programmes en espace utilisateur). Ainsi, iptables peut également obtenir des informations de la pile TCP/IP ( Couche 4 ). Il filtre les paquets sur la base des UID de leurs créateurs en utilisant le module owner que interagit avec les sockets pour trouver la propriété des paquets.
iptables écrit dans le journal du noyau qui peut être lu en utilisant dmesg ou logcat . L'UID d'une application peut être obtenu à l'aide d'une application ou lu à partir de l'application. /data/system/packages.list ou pm list packages -U .
# iptables -I OUTPUT -m owner --uid-owner <UID> -j LOG --log-level 7 --log-prefix 'SNIFFER: ' --log-uid
# dmesg -w | grep SNIFFER
La sortie peut être enregistrée dans un fichier et formatée à l'aide d'outils tels que grep , awk , printf etc. Journal du réseau - bien que très obsolète - fonctionne de manière similaire. AFWall+ est un pare-feu basé sur iptables qui peut enregistrer / notifier l'activité réseau d'une application lorsque celle-ci est bloquée.
Le seul inconvénient de cette approche est qu'elle ne peut pas être utilisée pour renifler le trafic d'un seul processus lorsqu'il y a plusieurs processus fonctionnant avec le même UID . iptables ne peut pas capturer les paquets basés sur les PIDs. Ils ont décidé à ne pas utiliser iptables avec des processus car le processus est démarré avant d'être bloqué/reniflé, et le programme pourrait facilement créer un processus enfant avec un nouveau PID qui ne serait pas bloqué/reniflé. De plus, les PIDs sont créés et détruits aussi rapidement que les sockets. Il y a donc toujours une possibilité de fuite de trafic.
QTAGUID :
owner ne fonctionnera pas pour trafic entrant ou transféré car les paquets IP ne portent aucune information de propriété. Pour mesurer l'utilisation du réseau entrant/sortant par application, Android a patché le noyau pour y inclure qtaguid module. Nous pouvons lire les statistiques de /proc/net/xt_qtaguid/stats . Avec quelques scripts shell, obtenez l'utilisation des données en direct depuis le redémarrage :
![]()
Cependant sur Android 9+, qtaguid est en train de a remplacé をもって étendu BPF (qui est également prévu pour remplacer netfilter dans le noyau Linux). Relié : Quel processus est responsable de la capture de l'utilisation des données ?
IPTABLES + TCPDUMP :
Une autre solution consiste à placer le trafic sortant d'une application dans un fichier de type NFLOG et plus tard captures tcpdump les paquets de ce groupe :
# iptables -I OUTPUT -m owner --uid-owner 1000 -j NFLOG --nflog-group 30
# tcpdump -i nflog:30
Cela permet de s'assurer que nous nous rapprochons de la couche physique lorsque nous reniflons le trafic sortant. Mais cela peut toujours donner faux positifs Par exemple, si des paquets sont abandonnés ou perdus dans les tables de routage. C'est pourquoi renifleurs travaillent au niveau de la couche 2 de l'OSI. Ou encore mieux, vous pouvez observer depuis l'extérieur, par exemple en utilisant un serveur proxy / VPN, un PC connecté ou un routeur. Mais cela ne permettra pas de capturer le trafic sur la base de chaque UID/PID.
AUTRES OPTIONS :
- Utilisez des outils de diagnostic comme
strace pour suivre syscalls lié à l'activité réseau d'un processus. force_bind y tracedump fonctionnent également sur le même principe. Le noyau de Linux sous-système d'audit peut être utilisé pour la même chose.
- Utilice Classification du réseau cgroup をもって
iptables NETFILTER_XT_MATCH_CGROUP pour renifler le trafic de certains processus.
- Utilice
Network Namespaces pour isoler les processus et lire l'utilisation des données sur la base de chaque interface. nstrace fonctionne sur le même principe.
- Si l'intention est entièrement de bloquer le trafic provenant de certains processus,
SELinux y seccomp peut être utilisé pour restreindre la capacité des processus à créer des sockets en définissant des règles d'accès restreintes. policies et en supprimant syscalls respectivement.
La plupart de ces options ne sont pas directement viables pour Android et nécessitent des configurations avancées.
Les API d'Android (OPTIONS NON-Root) :
Certaines applications comme NetGuard utiliser VpnService API d'Android pour bloquer le trafic à la couche 3 (interface TUN). L'application peut "notifier quand une application accède à l'internet" . Capture et suivi par application ( 1 , 2 ) est possible en utilisant l'API VPN comme Android utilise UIDs y SOcket_MARKs ( 1 , 2 ) pour contrôler le trafic dans le réseau Politique de routage ( RPDB ), juste avant de quitter le dispositif.
Certaines applications comme NetLive utiliser NetworkStatsManager mais il est en retard sur l'utilisation en temps réel et "ne se met pas à jour assez rapidement" c'est "destiné à fournir des données historiques" .
NOTE : Je n'ai aucune affiliation avec les applications référencées.
RELATION :
