un moyen de découvrir les appareils Android sur votre réseau ?

Question

Je veux être en mesure de découvrir les appareils Android sur mon réseau et, éventuellement, de récupérer des informations sur ces appareils. C'est très facile avec les appareils Apple, car ils utilisent les services Bonjour. Cependant, je n'arrive pas à trouver de service similaire sur Android.

Cela doit fonctionner sans modifier l'appareil Android, installer un service ou ouvrir un port. Il est censé fonctionner avec des appareils Android classiques de la même manière que Bonjour vous aide à trouver des appareils Apple classiques. Il suffirait de pouvoir vérifier que l'appareil fonctionne sous Android.

---

Réponse choisie : Bien que ce ne soit pas la réponse la mieux notée (pour l'instant), jetez un coup d'œil à la réponse de Luis. Comme il le mentionne, vous pouvez utiliser une recherche DNS (en utilisant votre serveur DNS local) pour découvrir les appareils Android. J'ai constaté que cette méthode a un taux de réussite de 100%, car Android force les appareils à utiliser un nom d'hôte de Android- _ ____ . Il est apparemment difficile de changer cela sur le téléphone, même s'il est enraciné. Je pense donc que cette méthode est assez précise. Merci, Luis !

Example:
$ nslookup 192.168.1.104 192.168.1.1
Server:     192.168.1.1
Address:    192.168.1.1#53

104.1.168.192.in-addr.arpa  name = android-711c129e251f14cf.\001.

---

Code échantillon : Si vous vouliez implémenter ceci en Java (par exemple, pour l'exécuter sur Android), vous ne pouvez pas facilement utiliser getHostName() car il utilise les serveurs DNS externes. Vous voulez utiliser le serveur DNS local de votre routeur, par exemple. Luis mentionne ci-dessous que vous pourriez modifier les serveurs DNS de la connexion Wifi, mais cela pourrait éventuellement casser d'autres choses. A la place, j'ai trouvé la méthode dnsjava s'avère extrêmement utile pour envoyer des requêtes DNS ciblées. Voici un exemple de code utilisant la bibliothèque :

        String ipAddress = "104.1.168.192";
        String dnsblDomain = "in-addr.arpa";
        Record[] records;
        Lookup lookup = new Lookup(ipAddress + "." + dnsblDomain, Type.PTR);
        SimpleResolver resolver = new SimpleResolver();
        resolver.setAddress(InetAddress.getByName("192.168.1.1"));
        lookup.setResolver(resolver);
        records = lookup.run();

        if(lookup.getResult() == Lookup.SUCCESSFUL) {
              for (int i = 0; i < records.length; i++) {
                if(records[i] instanceof PTRRecord) {
                  PTRRecord ptr = (PTRRecord) records[i];
                  System.out.println("DNS Record: " + records[0].rdataToString());
                }
              }
        } else {
            System.out.println("Failed lookup");
        }

    } catch(Exception e) { 
        System.out.println("Exception: " + e);
    }

Cela me donne le résultat :

DNS Record: android-711c129e251f14cf.\001.

Bingo.

Answer 1

Il existe une approche très simple qui m'a donné des résultats positifs dans quelques appareils différents.

Lorsqu'un périphérique se connecte à votre routeur, il reçoit une adresse IP (c'est-à-dire DHCP) et enregistre un nom dans le DNS. Le nom qui est enregistré semble toujours être de la forme android_nnnnnnnn .

Bien sûr, vous pouvez nommer n'importe quel ordinateur avec la même approche et tromper la vérification, ce qui entraîne des faux positifs ...

De plus, je ne peux pas garantir que tous les fournisseurs de périphériques suivent la même approche, mais j'ai constaté que cela fonctionnait correctement sur quelques périphériques de différentes marques (y compris différents niveaux de SDK) que j'ai testés.

--EDITED--

Comment s'y prendre

Cela dépend de l'endroit où vous allez exécuter le code pour découvrir les appareils Android. En supposant que vous exécutez le code dans un appareil Android :

1. Découvrez d'abord les dispositifs répondant à ping dans votre réseau. Vous pouvez utiliser le code dans ma réponse à ce post : execComd() pour lancer une commande ping.

2. Obtenez le nom des appareils qui répondent à l'aide du code :

   InetAddress inetAddress = InetAddress.getByName(string_with_ip_addr) ;

   String name = inetAddress.getCanonicalHostName() ;

--EDIT 2--

Preuve de concept

La méthode ci-dessous est juste une preuve de concept pour ce que j'ai écrit ci-dessus.

J'utilise isReachable() pour générer la requête ICMP, dont il est dit dans de nombreux articles qu'elle ne fonctionne qu'avec les appareils rootés, ce qui est le cas de l'appareil utilisé pour la tester. Cependant, je n'ai pas donné de permissions Root à l'application qui exécute ce code, donc je crois qu'elle ne pouvait pas activer le bit SIUD, ce qui est la raison pour laquelle certains prétendent que cette méthode échoue. Je voudrais le faire ici du point de vue de quelqu'un qui le teste sur un appareil non rooté.

Pour appeler, utilisez :

ArrayList<String> hosts = scanSubNet("192.168.1.");

Il revient dans hosts une liste de noms de périphériques répondant à la requête ping.

private ArrayList<String> scanSubNet(String subnet){
    ArrayList<String> hosts = new ArrayList<String>();

    InetAddress inetAddress = null;
    for(int i=1; i<10; i++){
        Log.d(TAG, "Trying: " + subnet + String.valueOf(i));
        try {
            inetAddress = InetAddress.getByName(subnet + String.valueOf(i));
            if(inetAddress.isReachable(1000)){
                hosts.add(inetAddress.getHostName());
                Log.d(TAG, inetAddress.getHostName());
            }
        } catch (UnknownHostException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    return hosts;
}

Regards.

Answer 2

Android ne sera pas aussi facile qu'iOS. Il n'existe pas d'équivalent de Bonjour.

Android 4.0, Ice Cream Sandwich, présenté Wi-Fi Direct Le réseau Peer to Peer. Au début, j'espérais qu'il pourrait être analysé comme vous le pensez, mais il aide les appareils Android à communiquer sans point d'accès, ils ne sont donc pas vraiment "sur votre réseau". De plus, ICS ne fonctionne que sur une fraction des appareils Android.

Plutôt qu'une approche de netscan active, vous vous retrouvez avec une approche de surveillance passive. Si votre réseau est sécurisé, renifler le paquet crypté est possible, mais peu pratique. Vous devrez

• mettez votre interface réseau dans mode moniteur
• capturer le poignée de main à 4 voies
• le décrypter en utilisant la clé pré-partagée du réseau.
• cela vous donnera la clé dont vous avez besoin pour décrypter le trafic

Si vous voulez voir ça en action, Wireshark soutient Décryptage WPA .

Une fois que vous êtes en mesure de visualiser le trafic Wi-Fi, vous remarquerez que les appareils Android ont tendance à communiquer avec certains serveurs Google et leurs connexions HTTP ont Les chaînes de l'agent utilisateur qui peuvent être identifiées . C'est la base d'une solution passive viable.

Tenable Network Security proposent des produits qui semblent adopter ce type d'approche.

Une autre idée

@Michelle Cannon a mentionné Meshlium Xtreme de Libelium, dont l'approche ne vous permettra pas d'atteindre tous les objectifs (pas sans de bonnes tables d'adresses MAC à jour). Mais elle pourrait permettre d'atteindre un objectif moins important. Vous le pouvez :

• Détecter tous les dispositifs sans fil
• Éliminer les appareils Apple utilisant l'identifiant unique d'organisation (OUI) du MAC.
• Dites qu'il s'agit d'un appareil mobile en surveillant l'intensité du signal pour déterminer s'il est en mouvement (les appareils mobiles ont tendance à apparaître et à disparaître).
• Vous pouvez utiliser le MAC OUI comme indice, c'est Android.
• Vous pouvez peut-être utiliser le MAC OUI comme indice qu'il ne s'agit pas d'Android (mais d'un ordinateur portable ou d'une carte sans fil, etc.)

Cela peut fonctionner si vous voulez détecter les appareils qui sont probablement Android.

Empreinte digitale DHCP

@Michelle Cannon a suggéré le DHCP fingerprinting. Je n'étais pas sûr au début, mais je dois le remercier d'avoir suggéré ce qui semble être la meilleure solution pour une analyse passive simple. En guise d'avertissement, j'aimerais expliquer pourquoi je suis arrivé en retard à la fête.

Il y a des choses que nous savons, des choses que nous ne savons pas, et des choses que nous pensons savoir mais qui sont fausses.

À bien des égards, c'est une bonne chose qu'Android utilise le noyau Linux. Mais ce n'est pas une bonne chose si vous voulez découvrir les appareils Android sur votre réseau. La pile TCP/IP d'Android est celle de Linux et les appareils Android ressembleront donc à des appareils Linux, du moins c'est ce que je pensais au début. Mais ensuite j'ai réalisé que Linux a beaucoup de paramètres de configuration de la construction, de sorte qu'il pourrait y avoir quelque chose de distinctif sur Android lorsqu'il est vu sur un réseau, mais quoi ?

Le fingerprinting DHCP utilise les options DHCP exactes demandées par le dispositif, plus le timing. Pour que cela fonctionne, il faut généralement disposer d'une base de données d'empreintes digitales à jour. Au début, ça ressemblait à fingerbank était très fier d'obtenir ces données, mais j'ai ensuite remarqué que leurs fichiers n'avaient pas été mis à jour depuis presque un an. Avec tous les différents types d'appareils Android, je ne pense pas qu'il soit pratique de conserver des empreintes digitales mises à jour pour un seul projet.

Mais ensuite j'ai regardé les signatures DHCP pour Android et j'ai remarqué ceci :

Android 1.0:     dhcpvendorcode=dhcpcd 4.0.0-beta9
Android 1.5-2.1: dhcpvendorcode=dhcpcd 4.0.1
Android 2.2:     dhcpvendorcode=dhcpcd 4.0.15
Android 3.0:     dhcpvendorcode=dhcpcd-5.2.10 

Linux utilise normalement dhclient comme client DHCP, mais Android utilise dhcpcd. Android a une forte préférence pour l'utilisation de logiciels sous licence BSD lorsque cela est possible et dhcpcd utilise une licence BSD. Il semblerait que dhcpvendorcode puisse être utilisé comme un indicateur fort qu'un appareil mobile fonctionne sous Android.

Surveillance du DHCP

Un client utilise le DHCP pour obtenir une adresse IP lorsqu'il se joint à un réseau, il commence donc sans adresse IP. Il contourne ce problème en utilisant les diffusions UDP pour l'échange initial. Sur le Wi-Fi, même avec WPA, le trafic de diffusion n'est pas crypté. Il suffit donc d'écouter le port UDP 67 pour le trafic client-serveur et 68 pour l'inverse. Vous n'avez même pas besoin de mettre votre interface réseau en mode promiscuous. Vous pouvez facilement surveiller ce trafic en utilisant un analyseur de protocole comme Wireshark.

J'ai préféré écrire du code pour surveiller le trafic et j'ai décidé d'utiliser Python. J'ai choisi pydhcplib pour gérer les détails du DHCP. Mon expérience avec cette bibliothèque n'a pas été sans heurts. J'ai dû télécharger et placer manuellement les fichiers de support IN.py et TYPES.py. Et leur conversion de paquets en chaînes de caractères laissait le dhcpvendorcode vide. Il a analysé les paquets DHCP correctement, alors j'ai simplement écrit mon propre code d'impression.

Voici un code qui surveille le trafic DHCP du client au serveur :

#!/usr/bin/python
from pydhcplib.dhcp_packet import *
from pydhcplib.dhcp_network import *
from pydhcplib.dhcp_constants import *

netopt = {
    'client_listen_port':"68",
    'server_listen_port':"67",
    'listen_address':"0.0.0.0"
}

class Server(DhcpServer):
    def __init__(self, options):
        DhcpServer.__init__(
            self,options["listen_address"],
            options["client_listen_port"],
            options["server_listen_port"])

    def PrintOptions(self, packet, options=['vendor_class', 'host_name', 'chaddr']):

        # uncomment next line to print full details
        # print packet.str()

        for option in options:
            # chaddr is not really and option, it's in the fixed header
            if option == 'chaddr':
                begin = DhcpFields[option][0]
                end = begin+6
                opdata = packet.packet_data[begin:end]
                hex = ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']
                print option+':', ':'.join([(hex[i/16]+hex[i%16]) for i in opdata])
            else:
                opdata = packet.options_data.get(option)
                if opdata:
                    print option+':', ''.join([chr(i) for i in opdata if i != 0])
        print

    def HandleDhcpDiscover(self, packet):
        print "DHCP DISCOVER"
        self.PrintOptions(packet)
    def HandleDhcpRequest(self, packet):
        print "DHCP REQUEST"
        self.PrintOptions(packet)

    ##  def HandleDhcpDecline(self, packet):
    ##      self.PrintOptions(packet)
    ##  def HandleDhcpRelease(self, packet):
    ##      self.PrintOptions(packet)
    ##  def HandleDhcpInform(self, packet):
    ##      self.PrintOptions(packet)

server = Server(netopt)

while True :
    server.GetNextDhcpPacket()

Ce code est basé sur l'exemple du serveur de pydhcplib car il écoute les demandes des clients, comme un serveur.

Lorsque ma tablette Nexus 7 Android 4.2 se connecte, cette information intéressante est capturée (expurgée) :

DHCP REQUEST
vendor_class: dhcpcd-5.5.6
host_name: android-5c1b97cdffffffff
chaddr: 10:bf:48:ff:ff:ff

DHCP DISCOVER
vendor_class: dhcpcd-5.5.6
host_name: android-5c1b97cdffffffff
chaddr: 10:bf:48:ff:ff:ff

Le nom d'hôte semble avoir un format fixe et est facilement analysé. Si vous avez besoin de l'adresse IP, vous pouvez surveiller le trafic entre le serveur et le client. Remarque : seul l'échange initial, lorsqu'un nouveau client se présente sans adresse IP, est diffusé. Les futures extensions de bail, etc., ne sont pas diffusées.

Recherche inversée de DNS

@Luis a posté une excellente solution qui démontre que le plus simple est le mieux. Même après avoir vu que le client DHCP d'Android définissait le nom d'hôte à Android-5c1b97cdffffffff, je n'ai pas pensé à demander au routeur sa liste de noms en utilisant des recherches DNS inversées. Le routeur ajoute le nom d'hôte à son serveur DNS afin que vous puissiez toujours accéder à l'appareil si son adresse IP change.

Le nom d'hôte est censé rester listé dans le DNS pendant la durée du bail DHCP. Vous pouvez vérifier si le périphérique est toujours présent en pinging il.

L'inconvénient de dépendre du nom de l'hôte est qu'il est possible de le modifier. Il est facile pour le fabricant de l'appareil ou l'opérateur de changer le host_name (bien qu'après avoir cherché, je n'ai pas pu trouver de preuve qu'ils l'aient fait). Il existe Apps pour changer de nom d'hôte mais ils ont besoin de Root, donc c'est, tout au plus, un cas limite.

Enfin, il y a une ouverture Android Issue 6111 : Permettre la spécification d'un nom d'hôte qui compte actuellement 629 étoiles. Il ne serait pas surprenant de voir le nom d'hôte configurable dans les paramètres d'Android à un moment donné dans le futur, peut-être bientôt. Donc, si vous commencez à dépendre du nom d'hôte pour identifier les appareils Android, sachez qu'il pourrait vous être retiré.

Si vous effectuez un suivi en direct, un autre problème potentiel de la recherche inverse de DNS est que vous devez décider de la fréquence de l'analyse. (Bien sûr, ce n'est pas un problème si vous ne prenez qu'un seul instantané). Un balayage fréquent consomme des ressources réseau, un balayage peu fréquent vous laisse avec des données périmées. Voici comment l'ajout de la surveillance DHCP peut vous aider :

• Au démarrage, utiliser le Reverse DNS Lookup pour trouver les appareils.
• Ping des périphériques pour voir s'ils sont toujours actifs
• Surveillez le trafic DHCP pour détecter instantanément les nouveaux appareils.
• De temps en temps, relancez le DNS Lookup pour trouver des dispositifs que vous auriez pu manquer.
• Si vous avez besoin de remarquer le départ de périphériques, faites un ping aux périphériques à la résolution temporelle désirée.

Bien qu'il ne soit pas facile (ni précis à 100 %), il existe plusieurs techniques qui le permettent. possible pour découvrir les appareils Android sur votre réseau.

Answer 3

AFAIK, le système Android ne fournit aucune zeroconf sur sa pile intégrée d'applications et de services système. Pour activer la découverte automatique sur l'appareil connecté au réseau local, vous devez soit installer une application zeroconf tierce, soit développer votre propre application/service et l'installer sur l'appareil, en choisissant parmi les options de l'API :

• JmDNS (pour le protocole bonjour d'Apple)
• Accrochage (pour le protocole UPnP de Microsoft)
• API NSD Android (introduit depuis Android 4.1)

Je ne comprends pas très bien vos besoins. Si vous voulez quelque chose de similaire (c'est-à-dire la découverte et la connexion automatiques) sur les appareils Android classiques, vous pouvez probablement utiliser les éléments suivants Wi-Fi direct qui est maintenant disponible sur certains appareils ultérieurs fonctionnant sous Android 4.0. Toutefois, elle exige que les deux appareils prennent en charge Wi-Fi Direct et ne créent qu'une connexion P2P ad hoc avec le Wi-Fi désactivé, un peu comme une connexion Bluetooth avec une plus grande portée :

Pour la prise en charge de l'API Wi-Fi Direct, consultez le guide officiel. Connecter des appareils sans fil .

Answer 4

Je regarde ça et je pense

http://www.libelium.com/smartphones_iphone_android_detection

Prêtez une attention particulière à ce qui suit

Les utilisateurs doivent-ils avoir installé une application spécifique ou interagir d'une manière ou d'une autre pour être détectés ?

Non, le scan est effectué en silence, Meshlium détecte simplement les "trames de balises" émises par les radios Wifi et Bluetooth intégrées aux Smartphones. Les utilisateurs doivent simplement avoir au moins une des deux interfaces sans fil activée.

Il y a longtemps, j'utilisais une application appelée stumbler sur mon mac pour trouver des réseaux wifi, je pense que c'est similaire.

Autres idées

Si j'ai besoin de déterminer les téléphones Android sur un réseau local, comment puis-je le faire ? En l'absence d'un service DNS en cours d'exécution, je n'ai que deux possibilités

Le SSID s'il est diffusé - ne peut rien me dire L'adresse IP - Android vous permet d'avoir beaucoup de contrôle sur le nommage des hôtes, donc je suppose que vous pouvez définir une plage d'adresses IP spécifiques pour vos appareils Android. -Pas très utile.

Si le bluetooth est activé, je diffuse une signature SDPP de périphérique bluetooth que je peux utiliser pour déduire le type de périphérique.

Si j'exploitais un service prenant en charge Android et que je voulais découvrir des appareils Android spécifiques sur mon réseau, je pourrais simplement enregistrer les adresses MAC de ces appareils et les surveiller sur le réseau.

En dehors de cela, vous devez exécuter soit un bonjour (dns-sd) ou upnpp dameon sur le périphérique.

Answer 5

Réponse actualisée

Désolé, je n'ai pas bien compris la question initiale. Seul votre commentaire m'a fait comprendre clairement que vous ne voulez pas avoir à installer tout ce qui est sur les appareils cibles mais vous voulez juste un moyen de découvrir des téléphones aléatoires dans votre réseau.

Je ne suis pas sûr que cela soit vraiment possible de la manière dont vous le souhaitez. Sans un service de découverte de réseau fonctionnant sur Android, vous ne trouverez pas le périphérique en premier lieu. Bien sûr, vous pouvez utiliser certains protocoles réseau de bas niveau, mais cela ne vous donnerait qu'un indicateur qu'il y a quelque chose, mais pas ce que c'est (un appareil Android, un PC ou autre).

L'approche la plus prometteuse serait de vérifier les applications préinstallées qui ont une fonctionnalité réseau quelconque. Par exemple, les appareils Samsung ont Kies Air (si l'utilisateur l'active), Motorola utilise UPnP pour son serveur multimédia et HTC a aussi sa propre application, si je me souviens bien. Cependant, il n'y a pas d'application qui soit installée sur tous les appareils Android de tous les vendeurs et opérateurs. Vous ne pouvez donc pas vous fier uniquement à l'une d'entre elles, mais vous devrez vérifier plusieurs services différents en utilisant leurs protocoles et comportements spécifiques afin d'obtenir des informations supplémentaires sur l'appareil. Et, bien sûr, l'utilisateur devra activer la fonctionnalité pour que vous puissiez l'utiliser.

Ancienne réponse

Une alternative supplémentaire à la liste de yorkw est AllJoyn par Qualcomm. Il s'agit d'un cadre de découverte et de communication peer-to-peer open source et multiplateforme que j'ai moi-même déjà utilisé par le passé.

Bien que Qualcomm soit un grand sponsor d'AllJoyn, cela ne signifie pas que vous ayez besoin d'un chipset Qualcomm dans votre définition. En fait, AllJoyn fonctionne sur n'importe quel chipset, y compris Intel et nVidia. Il n'est pas nécessaire d'enraciner les téléphones ou de modifier le cadre d'Android. Il fonctionne tout simplement en utilisant le Wi-Fi et/ou le Bluetooth comme méthodes d'appairage.