Android no va a ser tan fácil como iOS. No hay equivalente a Bonjour.

Android 4.0, Ice Cream Sandwich, introducido Wi-Fi Direct Redes de igual a igual. Al principio esperaba que podría ser capaz de ser escaneado en la forma en que su pensamiento, pero ayuda a los dispositivos Android comunicarse sin un punto de acceso, por lo que no son realmente "en su red". Además, ICS se ejecuta en solo una fracción de los dispositivos Android.

En lugar de un enfoque netscan activo, se queda con un enfoque de monitoreo pasivo. Si su red es segura, es posible rastrear el paquete cifrado, pero es inconveniente. Tendrás que

• ponga su interfaz de red en modo de monitor
• captura el apretón de manos de 4 vías
• descifrarlo utilizando la clave pre-compartida de la red
• esto le dará la clave que necesita para descifrar el tráfico

Si quieres ver esto en acción, Wireshark soporta WPA descifrado.

Una vez que pueda ver el tráfico Wi-Fi, notará que los dispositivos Android tienden a comunicarse con ciertos servidores de Google y sus conexiones HTTP tienen cadenas de agentes de usuario que se pueden identificar. Esta es la base para una solución pasiva viable.

Tenable Network Security ofrece productos que parecen adoptar este tipo de enfoque.

Otra idea

@ Michelle Cannon mencionó Meshlium Xtreme de Libelium cuyo enfoque no te llevará hasta allí (no sin buenas tablas de rango de direcciones MAC actualizadas). Pero podría ser parte de alcanzar un objetivo menor. Usted puede:

• Detectar todos los dispositivos inalámbricos
• Elimine los dispositivos Apple utilizando el Identificador Único Organizacional (OUI)
• Tell it's a mobile device by by monitoring signal strength to determine it's moving (and mobile devices will tend to show up and go away)
• Es posible que pueda usar el MAC OUI como una pista es Android
• Usted puede ser capaz de utilizar el MAC OUI como una pista que no es Android (pero una computadora portátil o tarjeta inalámbrica, etc.).

Esto puede ser viable si está dispuesto a detectar dispositivos que son probablemente Android.

DHCP Fingerprinting

@Michelle Cannon sugirió las huellas dactilares DHCP. No estaba seguro al principio, pero tengo que agradecerle por sugerir lo que parece ser la mejor opción para el escaneo pasivo simple. Como advertencia, me gustaría explicar por qué llegué tarde a la fiesta.

Hay cosas que sabemos, que pensamos que no sabemos, y cosas que pensamos que sabemos pero que están equivocadas.

En muchos sentidos, es bueno que Android use el kernel de Linux. Pero no es bueno si quieres descubrir dispositivos Android en tu red. La pila TCP/IP de Android es Linux, por lo tanto, los dispositivos Android se verán como dispositivos Linux o eso pensé al principio. Pero luego me di cuenta de que Linux tiene muchos de parámetros de configuración de compilación, por lo que podría haber algo distintivo acerca de Android cuando se ve en una red, pero ¿qué?

DHCP fingerprinting utiliza las opciones DHCP exactas solicitadas por el dispositivo más el tiempo. Para que esto funcione, generalmente necesita una base de datos de huellas dactilares actualizada para que coincida con. Al principio parecía que fingerbank estaba lleno de fuentes de estos datos, pero luego me di cuenta de que sus archivos no se habían actualizado durante casi un año. Con todos los diferentes tipos de dispositivos Android, no creo que sea práctico mantenerse actualizado huellas dactilares para un solo proyecto.

Pero luego miré las firmas DHCP reales para Android y me di cuenta de esto:

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 normalmente usa dhclient como su cliente DHCP, pero Android está usando dhcpcd. Android tiene una fuerte preferencia por el uso de software con licencia con el estilo BSD cuando sea posible y dhcpcd utiliza una licencia BSD. Parecería dhcpvendorcode podría ser utilizado como un fuerte indicador de que un dispositivo móvil está ejecutando Android.

Monitoreo DHCP

A el cliente utiliza DHCP para obtener una dirección IP al unirse a una red, por lo que se inicia sin una dirección IP. Evita este problema mediante el uso de transmisiones UDP para el intercambio inicial. En Wi-Fi, incluso con WPA, el tráfico de difusión no está cifrado. Por lo tanto, solo puede escuchar en el puerto UDP 67 para el tráfico de cliente a servidor y 68 para el inverso. Ni siquiera necesita poner su interfaz de red en modo promiscuo. Puede monitorear fácilmente este tráfico usando un analizador de protocolos como Wireshark.

I prefirió escribir código para monitorear el tráfico y decidió usar Python. Seleccioné pydhcplib para manejar los detalles de DHCP. Mi experiencia con esta biblioteca no fue fluida. Necesitaba descargar y colocar manualmente IN.py y TYPES.py archivos de soporte. Y su conversión de paquetes a cadenas dejaba el dhcpvendorfode en blanco. Analizó los paquetes DHCP correctamente, así que escribí mi propio código de impresión.

Aquí está el código que monitorea el tráfico DHCP del cliente al servidor:

#!/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()

Esto el código se basa en el ejemplo de servidor de pydhcplib porque escucha las solicitudes de los clientes, como un servidor.

Cuando mi Nexus 7 Android 4.2 tablet se conecta, esta información interesante se captura (eliminado):

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

El nombre de host parece tener un formato fijo y se analiza fácilmente. Si necesita la dirección IP, puede supervisar el tráfico del servidor al cliente. Nota: solo el intercambio inicial, cuando un nuevo cliente aparece por primera vez sin una dirección IP, se transmite. Futuras extensiones de arrendamiento, etc., no se emiten.

Búsqueda inversa de DNS

@Luis publicó una gran solución que demuestra lo simple que es mejor. Incluso después de ver el cliente DHCP de Android estaba configurando host_name a android-5c1b97cdffffffff, no pensé en preguntar al enrutador por su lista de nombres utilizando búsquedas DNS inversas. El enrutador agrega el host_name a su servidor DNS para que pueda acceder al dispositivo si cambia su dirección IP.

Se espera que el host_name permanezca listado en el DNS para la duración del contrato de arrendamiento DHCP. Usted podría comprobar si el dispositivo todavía está presente por haciendo ping.

Un inconveniente de depender del host_name es que hay formas en que esto podría cambiarse. Es fácil para el fabricante del dispositivo o el operador cambiar el host_name (aunque después de buscar, no he podido encontrar ninguna evidencia que alguna vez tengan). Hay aplicaciones para cambiar el nombre de host, pero requieren root, por lo que es, a lo sumo, un caso de borde.

Finalmente hay un abierto Problema de Android 6111: Permite especificar un nombre de host que actualmente tiene 629 estrellas. No sería sorprendente ver configurable host_name en la configuración de Android en algún momento en el futuro, tal vez pronto. Así que si comienza a depender de host_name para identificar dispositivos Android, darse cuenta de que podría ser arrancado de debajo de usted.

Si está haciendo seguimiento en vivo, otro problema potencial con la Búsqueda inversa de DNS es que tiene que decidir con qué frecuencia escanear. (Por supuesto, esto no es un problema si solo estás tomando una instantánea de una sola vez.) El escaneo frecuente consume recursos de red, lo infrecuente lo deja con datos obsoletos. Así es como agregar monitoreo DHCP puede ayudar:

• Al iniciar use la búsqueda inversa de DNS para encontrar dispositivos
• Ping dispositivos para ver si todavía están activos
• Monitoree el tráfico DHCP para detectar nuevos dispositivos al instante
• Ocasionalmente vuelve a ejecutar la búsqueda de DNS para encontrar dispositivos que podrías haber perdido
• Si necesita notar que los dispositivos se van, ping dispositivos a la resolución de tiempo deseada

Si bien no es fácil (ni 100% preciso), hay varias técnicas que hacen que sea posible descubrir dispositivos Android en su red.

AFAIK, sistema Android no proporciona ningún zeroconf aplicación/servicio en su sistema integrado app/pila de servicios. Para habilitar la detección automática en el dispositivo real conectado a la red local, necesita instalar alguna aplicación zeroconf de terceros o desarrollar su propia aplicación/servicio e instalarla en el dispositivo real, algunas opciones de API son:

• JmDNS (para el protocolo bonjour de Apple)
• Cling (para el protocolo UPnP de Microsoft)
• Android NSD API (introducido desde Android 4.1)

No estoy muy claro acerca de sus requisitos, si desea algo similar (es decir, auto discover and connect) en dispositivos Android vanilla, probablemente puede usar Wi-Fi direct que ahora está disponible en algún dispositivo posterior que ejecute Android 4.0, sin embargo, requiere que ambos dispositivos admitan Wi-Fi Direct y solo creen una conexión P2P ad-hoc con Wi-Fi desactivado, al igual que una conexión bluetooth con rango:

Para obtener compatibilidad con Wi-Fi Direct API, consulta la guía oficial - Conectar dispositivos de forma inalámbrica.

Estoy mirando esto un pensamiento

Http://www.libelium.com/smartphones_iphone_android_detection

Preste especial atención a esto

¿Los usuarios necesitan tener instalada una aplicación específica o interactuar de alguna manera para ser detectados?

No, el escaneo se realiza en silencio, Meshlium solo detecta los "marcos de baliza" originados por las radios Wifi y Bluetooth integradas en los teléfonos inteligentes. Los usuarios solo necesitan tener al menos una de las dos interfaces inalámbricas encendidas en.

Hace mucho tiempo que uso una aplicación llamada stumbler en mi mac para encontrar redes wifi, creo que esto es similar

Otras ideas

Bueno, si necesito determinar los teléfonos Android en una red local cómo lo haría. Ausente de un servicio dns en ejecución solo tengo un par de posibilidades

El SSID si se está emitiendo - no me puede decir nada La dirección ip-android le permite tener mucho control sobre el nombre del host, así que supongo que podría definir un rango de ip específico para tus dispositivos Android. - no es muy útil.

Alternativamente, digamos que veo un dispositivo desconocido en la red, si Bluetooth está activado, estoy transmitiendo una firma de dispositivo bluetooth SDPP que puedo usar para deducir mi tipo de dispositivo.

Si estuviera ejecutando un servicio compatible con Android y quisiera descubrir dispositivos Android específicos en mi red, entonces podría registrar las direcciones mac de esos dispositivos y vigilarlos en la red.

Aparte de eso, lo haría necesita ejecutar un bonjour (dns-sd) o un upnpp dameon en el dispositivo.

Respuesta actualizada

Lo siento, no he entendido correctamente la pregunta original. Solo su comentario me dejó muy claro que no desea tener que instalar nada en los dispositivos de destino, sino que solo desea una forma de descubrir teléfonos aleatorios en su red.

No estoy seguro de si esto realmente sería posible de la manera que lo desea. Sin tener ningún servicio de detección de red que se ejecute en Android, no encontrará el dispositivo en primer lugar. De por supuesto, puede usar algunos protocolos de red de bajo nivel, pero eso solo le daría un indicador de que hay algo, pero no lo que es (ser un dispositivo Android, una PC, una cualquier otra cosa).

El enfoque más prometedor sería comprobar si hay aplicaciones preinstaladas que tengan algún tipo de funcionalidad de red. Por ejemplo, los dispositivos Samsung tienen Kies Air (si el usuario lo habilita), Motorola está utilizando UPnP para su servidor de medios y HTC tiene algo propio también, si no recuerdo mal. Sin embargo, no hay aplicación que se instala en todos los dispositivos Android de todos los proveedores y operadores. Por lo tanto, no puede confiar únicamente en uno de ellos, pero tendría que verificar varios servicios diferentes utilizando sus protocolos y comportamientos específicos para obtener información adicional sobre el dispositivo. Y, por supuesto, el usuario tendría que habilitar la funcionalidad para que usted pueda usarla.

Antigua respuesta

Una alternativa adicional a la lista de yorkw es AllJoyn de Qualcomm. Es un descubrimiento multiplataforma de código abierto y marco de comunicación peer-to-peer que ya he utilizado en el pasado.

Aunque Qualcomm es un gran patrocinador de AllJoyn, esto no significa que necesite un chipset Qualcomm en su definición. De hecho AllJoyn funciona en cualquier chipset incluyendo Intel y nVidia. No requiere teléfonos arraigados o cualquier otra modificación al marco de Android y solo funciona "fuera de la caja" utilizando Wi-Fi y/o Bluetooth como métodos de emparejamiento.

Estoy aprendiendo mucho de este tema.

También hay algo llamado huellas dactilares dhcp, aparentemente diferentes dispositivos actúan de manera diferente al tipo de análisis de red que hemos estado discutiendo, como los que utilizan NMAP un escáner de Linux. Los mapas del comportamiento de estas sondas están disponibles en el 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 /

Aquí hay un trazador de líneas que hace ping a todas las máquinas en su red (suponiendo que su red es 192.168.1.x) y hace una búsqueda inversa en sus nombres:

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 $4 }' | sort | uniq | sed 's/://' | xargs -n 1 host 

Requiere GNU parallel para funcionar. Puede instalar eso en OSX usando "brew install parallel"

A partir de esto, solo puede mirar los dispositivos llamados android-c40a2b8027d663dd.home. o lo que sea.

Luego puede intentar ejecutar nmap-O en un dispositivo para ver qué más puede averiguar:

sudo nmap -O android-297e7f9fccaa5b5f.home.

Pero no es realmente tan fructífero.