Android ne va pas être aussi facile que iOS. Il n'existe pas de Bonjour équivalent.

Android 4.0, Sandwich à la crème glacée, introduit Wi-Fi Direct peer to Peer networking. Au début, j'espérais qu'il pourrait être scanné de la façon dont votre pensée, mais il aide les appareils Android communiquer sans un point d'accès, de sorte qu'ils ne sont pas vraiment "sur votre réseau". De plus, ICS ne fonctionne que sur une fraction des appareils Android.

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

• mettez votre interface réseau en mode moniteur
• capture the 4-way handshake
• déchiffrez-le en utilisant la clé pré-partagée du réseau
• ce vous donnera la clé dont vous avez besoin pour déchiffrer le trafic

Si vous voulez le voir en action, Wireshark prend en charge WPA décryptage .

une fois que vous êtes en mesure de voir le trafic Wi-Fi, vous remarquerez que les appareils Android ont tendance à communiquer avec certains serveurs Google et leurs connexions HTTP ont chaînes D'Agent utilisateur qui peuvent être identifiés . C'est la base pour un solution passive viable.

Tenable Network Security offrent 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'y arriver (pas sans de bonnes tables D'adresses MAC à jour). Mais cela pourrait faire partie de l'atteinte d'un objectif moindre. Vous pouvez:

• Detect tous les appareils sans fil
• Éliminer les appareils Apple à l'aide du MAC sur le plan Organisationnel Identifiant Unique (OUI)
• Dire c'est un appareil mobile, par le suivi de la force du signal pour déterminer son déplacement (et les appareils mobiles ont tendance à se montrer et de s'en aller)
• vous pouvez être en mesure d'utiliser le MAC OUI comme un indice C'est Android
• vous pouvez être en mesure D'utiliser le MAC OUI comme un indice ce n'est pas Android (mais un ordinateur portable ou sans fil carte, etc.).

cela peut être réalisable si vous êtes prêt à détecter les appareils qui sont probablement Android.

DHCP Fingerprinting

@Michelle Cannon suggère de relever les empreintes digitales du DHCP. Je n'étais pas sûr au début, mais je dois le remercier d'avoir suggéré ce qui semble être le meilleur pari pour un simple balayage passif. En guise de mise en garde, j'aimerais expliquer pourquoi j'étais en retard à la fête.

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

à bien des égards, il est bon que Android utilise le noyau Linux. Mais ce n'est pas bon si vous voulez découvrir des appareils Android sur votre réseau. La pile TCP/IP d'Android est la pile Linux pour les appareils Android ressemblera à des appareils Linux ou du moins je l'ai pensé au début. Mais ensuite J'ai réalisé que Linux a beaucoup de paramètres de configuration de construction pour qu'il puisse être quelque chose de distinctif sur Android lorsqu'il est vu sur un réseau, mais quoi?

DHCP fingerprinting utilise les options DHCP exactes demandées par le périphérique plus le timing. Pour que cela fonctionne, vous avez généralement besoin d'une base de données d'empreintes digitales à jour à comparer. Au début, il a semblé que fingerbank a été croqué en provenance de ces données, mais ensuite j'ai remarqué que leurs fichiers n'avaient pas été mis à jour depuis près d'un an. Avec tous les différents types D'appareils Android, Je ne pense pas il est pratique de conserver des empreintes digitales à jour pour un seul projet.

mais ensuite j'ai regardé les signatures DHCP réelles 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 le dhcpvendorcode pourrait être utilisé comme un indicateur fort qu'un mobile l'appareil est en cours d'exécution Android.

DHCP "suivi de l'1519400920"

un client utilise DHCP pour obtenir une adresse IP lorsqu'il rejoint un réseau, donc il démarre sans adresse IP. Il contourne ce problème en utilisant des émissions UDP pour l'échange initial. Sur Wi-Fi, même avec WPA, le trafic de diffusion n'est pas crypté. Vous pouvez donc simplement écouter sur le port UDP 67 pour le trafic client-serveur et 68 pour le trafic inverse. Vous n'avez même pas besoin de mettre votre interface réseau dans la promiscuité mode. 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 a décidé d'utiliser Python. J'ai sélectionné pydhcplib pour gérer les détails de DHCP. Mon expérience avec cette bibliothèque n'était pas lisse. J'avais besoin de télécharger et de placer manuellement IN.py et TYPES.py dossiers de soutien. Et leur conversion paquet en chaîne laissait le dhcpvendorcode vide. Il a analysé les paquets DHCP correctement, donc j'ai juste écrit propre code d'impression.

voici le 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 de serveur de pydhcplib parce qu'il écoute les requêtes des clients, comme un serveur.

Quand 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 déchiffré. Si vous avez besoin de la Adresse IP vous pouvez surveiller le trafic du serveur vers le client. Note: seul l'échange initial, lorsqu'un nouveau client apparaît pour la première fois sans adresse IP, est diffusé. Futures prolongations de baux, etc., ne sont pas diffusées.

Reverse DNS Lookup

@Luis a posté une excellente solution qui montre comment plus simple est mieux. Même après avoir vu que le client DHCP D'Android réglait host_name sur android-5c1b97cdffffff, je n'ai pas pensé à demander le routeur pour sa liste de noms utilisant des recherches DNS inversées. Le routeur ajoute le nom d'hôte à son serveur DNS de sorte que vous pouvez toujours accéder au périphérique si son adresse IP change.

le nom d'hôte est censé rester inscrit dans le DNS pendant la durée du bail DHCP. Vous pouvez vérifier si l'appareil est toujours présent "1519980920 de" ping 151970920".

un inconvénient à dépendre de host_name est qu'il y a des façons de changer cela. Il est facile pour le fabricant de l'appareil ou le porteur pour changer le nom de l'hôte (bien qu'après la recherche, j'ai été incapable de trouver des preuves qu'ils ont jamais). Il existe des applications pour changer le nom d'hôte , mais elles nécessitent root, ce qui est tout au plus un cas extrême.

enfin il y a un Ouvert Android question 6111: permettre un nom d'hôte à être spécifié qui a actuellement 629 étoiles. Il ne serait pas surprenant de voir host_name configurable dans les paramètres Android à un moment donné dans le futur, peut-être bientôt. Donc, si vous commencez host_name pour identifier les appareils Android, comprendre qu'il pourrait être tiré hors de sous vous.

si vous effectuez un suivi en direct, un autre problème potentiel avec la recherche DNS inversée est que vous devez décider à quelle fréquence scanner. (Bien sûr, ce n'est pas un problème si vous êtes juste de prendre un instantané.) Le balayage fréquent consomme des ressources réseau, Peu fréquent vous laisse avec des données périmées. Voici comment ajouter DHCP la surveillance peut aider:

• au démarrage, utilisez la recherche inverse DNS pour trouver des périphériques
• Ping périphériques pour voir si ils sont toujours actifs
• surveiller le trafic DHCP pour détecter instantanément de nouveaux appareils
• relancez occasionnellement la recherche DNS pour trouver des appareils que vous auriez pu manquer
• si vous avez besoin de remarquer la sortie des périphériques, ping des périphériques à la résolution de synchronisation désirée

bien que ce ne soit pas facile (ni précis à 100%), Il existe plusieurs techniques qui rendent possible de découvrir les appareils Android sur votre réseau.

autant que je sache, le système Android ne propose pas de zeroconf application/service sur le système intégré d'application/service de la pile. Pour activer la découverte automatique sur le périphérique réel attaché au réseau local, vous avez besoin soit installer une application zeroconf tierce partie ou développer votre propre application / service et l'installer sur le périphérique réel, certaines options API sont:

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

Je ne suis pas tout à fait clair au sujet de vos exigences, si vous voulez quelque chose de similaire (c.-à-d. auto découvrir et se connecter) sur les appareils Android vanilla, vous pouvez probablement utiliser Wi-Fi direct qui est maintenant disponible sur certains appareils plus tard exécutant Android 4.0, cependant, il nécessite à la fois les appareils prennent en charge Wi-Fi Direct et ne créent qu'une connexion P2P ad hoc avec Wi-Fi éteint, un peu comme une connexion bluetooth avec une plus longue portée:

pour le support Wi-Fi Direct API, consultez le guide officiel - Connecting Devices Wireless .

je suis en train de regarder ce une pensée

http://www.libelium.com/smartphones_iphone_android_detection

payer la note spéciale à cette

les utilisateurs doivent avoir une application spécifique installée ou d'interagir d'une certaine manière à être détecté?

non, le scan est effectué en silence, Meshlium ne détecte que les "cadres de balise" émis par les radios Wifi et Bluetooth intégrées dans le Smartphone. Les utilisateurs ont juste besoin d'avoir au moins une des deux interfaces sans fil activée.

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

autres idées

Eh bien si je dois déterminer les téléphones android sur un réseau local comment je le ferais. Absent d'un service dns en cours d'exécution Je n'ai que quelques possibilités

le SSID si son émission - ne peut rien me dire l'adresse ip-android vous permet d'avoir beaucoup de contrôle sur le nom de l'hôte, donc je suppose que vous pouvez définir une plage ip spécifique à vos appareils android. -ne pas utiles.

laisse alternativement dire que je vois un appareil inconnu sur le réseau, si bluetooth est activé alors je diffuse une signature de périphérique bluetooth SDPP que je peux utiliser pour déduire mon type de périphérique.

si j'exécutais un service qui soutenait android et je voulais découvrez les appareils android spécifiques sur mon réseau, alors je pourrais simplement enregistrer les adresses mac pour ces appareils et les surveiller sur le réseau.

Autre que vous aurait besoin d'exécuter un bonjour (dns-sd) ou upnpp dameon sur l'appareil.

Mise À Jour De La Réponse

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

Je ne suis pas sûr que ce soit vraiment possible dans la façon dont vous le voulez. Sans service de découverte de réseau fonctionnant sur Android, vous ne trouverez pas l'appareil en premier lieu. Bien sûr, vous pouvez utiliser des 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 (étant un appareil Android, un PC, n'importe quoi d'autre).

l'approche la plus prometteuse serait de vérifier les applications préinstallées qui ont une fonctionnalité de réseau quelconque. Par exemple: Les appareils Samsung ont Kies Air( si l'utilisateur l'active), Motorola utilisent UPnP pour leurs médias Server et HTC ont aussi quelque chose de particulier, si je me souviens bien. Cependant, il n'y a aucune application qui est installé sur tous les appareils Android de tous les vendeurs et les transporteurs. Donc, vous ne pouvez pas compter uniquement sur l'un d'eux, mais aurait besoin de vérifier les différents services 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é dans l'ordre pour vous d'utiliser.

Old réponse

une autre alternative à la liste de yorkw est AllJoyn de Qualcomm. Il s'agit d'une découverte multiplateforme en libre accès et d'un cadre de communication entre pairs que j'ai moi-même utilisé dans le passé.

bien que Qualcomm soit un grand sponsor D'AllJoyn cela ne signifie pas que vous avez besoin D'un chipset Qualcomm dans votre définition. En fait AllJoyn travaille sur n'importe quel chipset y compris Intel et nVidia. Il ne nécessite pas enraciné téléphones ou toute autre modification du cadre Android et fonctionne "out of the box" en utilisant Wi-Fi et/ou Bluetooth comme méthodes d'appariement.

j'apprends beaucoup de ce sujet.

il y a aussi quelque chose qui s'appelle dhcp fingerprinting, apparemment différents appareils agissent différemment du type de scans de réseau dont nous avons parlé comme ceux qui utilisent NMAP un scanner linux. Les cartes du comportement de ces sondes sont disponibles sur l'internet.

http://www.enterasys.com/company/literature/device-profiling-sab.pdf

https://media.defcon.org/dc-19/presentations/Bilodeau/DEFCON-19-Bilodeau-FingerBank.pdf

http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/COTD-DHCP-Fingerprinting-how-to-ArubaOS-6-0-1-0-and-above/td-p/11164

http://myweb.cableone.net/xnih /

Voici une doublure qui pique toutes les machines sur votre réseau (en supposant que votre réseau est 192.168.1.x ) et fait une recherche inversée sur leurs noms:

for i in {1..255}; do echo ping -t 4 192.168.1.${i} ; done | parallel -j 0 --no-notice 2> /dev/null | awk '/ttl/ { print  }' | sort | uniq | sed 's/://' | xargs -n 1 host 

nécessite GNU parallel pour fonctionner. Vous pouvez l'installer sur OSX en utilisant "brew install parallel"

de ceci vous pouvez juste regarder les appareils nommés android-c40a2b8027d663dd.home. ou n'importe quoi.

vous pouvez alors essayer d'exécuter nmap -O sur un périphérique pour voir ce que vous pouvez d'autre figure:

sudo nmap -O android-297e7f9fccaa5b5f.home.

mais ce n'est pas si fructueux.