네트워크에서 Android 장치를 검색하는 방법이 있습니까?
내 네트워크에서 Android 장치를 검색하고 해당 장치에 대한 일부 장치 정보를 검색 할 수 있기를 원합니다. Bonjour 서비스를 실행하기 때문에 Apple 장치에서는 매우 쉽습니다. 그러나 Android에서 실행되는 유사한 서비스를 찾을 수없는 것 같습니다.
이는 Android 장치를 수정하거나 일부 서비스를 설치하거나 일부 포트를 열지 않고도 작동해야합니다. Bonjour가 기본 Apple 장치를 찾는 데 도움이되는 방식으로 기본 Android 장치에서 작동하도록 설계되었습니다. 기기가 Android를 실행 중인지 확인하는 것만으로도 충분합니다.
선택한 답변 : 아직 최고 평점은 아니지만 Luis의 답변을 살펴보세요. 그가 언급했듯이 DNS 조회 (로컬 DNS 서버 사용)를 사용하여 Android 장치를 검색 할 수 있습니다. Android가 기기에서 android- _ ____ 의 호스트 이름을 사용하도록 강제하기 때문에 성공률이 100 % 인 것으로 나타났습니다 . 이것은 루팅 된 경우에도 전화로 변경하기가 분명히 어렵습니다. 그래서 저는 이것이 매우 정확한 방법이라고 생각합니다. 고마워, 루이스!
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.
샘플 코드 : 이를 Java로 구현하려는 경우 (예 : Android에서 실행) 외부 DNS 서버를 사용하기 때문에 getHostName ()을 쉽게 사용할 수 없습니다. 예를 들어 라우터에서 로컬 DNS 서버를 사용하려고합니다. Luis는 Wi-Fi 연결의 DNS 서버를 수정할 수 있지만 다른 문제가 발생할 수 있다고 아래에서 언급합니다. 대신 dnsjava라이브러리가 대상 DNS 요청을 보내는 데 매우 유용 하다는 것을 알았습니다 . 다음은 라이브러리를 사용하는 몇 가지 샘플 코드입니다.
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);
}
이것은 나에게 출력을 제공합니다.
DNS Record: android-711c129e251f14cf.\001.
빙고.
몇 가지 다른 장치에서 긍정적 인 결과를 제공하는 매우 간단한 접근 방식이 있습니다.
장치가 라우터에 연결되면 IP (예 : DHCP)를 수신하고 DNS에 이름을 등록합니다. 등록 된 이름은 항상 형식 인 것 같습니다 android_nnnnnnnn.
당연히 동일한 접근 방식으로 컴퓨터의 이름을 지정하고 검사를 속여서 오 탐지 결과를 초래할 수 있습니다.
또한 모든 장치 공급 업체가 동일한 접근 방식을 따르고 있는지 확인할 수는 없지만 테스트 한 여러 브랜드 (다른 SDK 수준 포함)의 일부 장치에서 제대로 작동하는 것으로 나타났습니다.
-편집 됨-
그것을하는 방법
Android 장치를 검색하기 위해 코드를 실행하는 위치에 따라 다릅니다. Android 장치에서 코드를 실행한다고 가정합니다.
- 먼저
Ping네트워크에서 응답하는 장치를 찾습니다 . 이 게시물에 대한 내 답변의 코드 execComd () 를 사용하여 ping 명령을 실행할 수 있습니다. 코드를 사용하여 응답 장치의 이름을 가져옵니다.
InetAddress inetAddress = InetAddress.getByName (string_with_ip_addr);
문자열 이름 = inetAddress.getCanonicalHostName ();
-편집 2--
개념의 증거
아래 방법은 내가 위에서 쓴 것에 대한 개념의 교수 일뿐입니다.
나는 isReachable()ICMP 요청을 생성하는 방법을 사용하고 있는데, 이는 테스트에 사용되는 장치의 경우 루팅 된 장치에서만 작동하는 많은 게시물에서 언급되고 있습니다. 그러나이 코드를 실행하는 애플리케이션에 대한 루트 권한을 부여하지 않았기 때문에 SIUD 비트를 설정할 수 없다고 생각합니다. 이것이이 메서드가 실패하는 이유입니다. 루팅되지 않은 장치에서 누군가를 테스트하고 싶습니다.
사용을 호출하려면 :
ArrayList<String> hosts = scanSubNet("192.168.1.");
hostsping 요청에 응답하는 장치의 이름 목록으로 반환됩니다 .
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;
}
문안 인사.
Android는 iOS만큼 쉽지 않을 것입니다. Bonjour에 해당하는 것은 없습니다.
Android 4.0, Ice Cream Sandwich는 Wi-Fi Direct P2P 네트워킹을 도입했습니다. 처음에는 여러분의 생각대로 스캔 할 수 있기를 바랐지만 Android 장치가 액세스 포인트없이 통신하는 데 도움이되므로 실제로 "네트워크에"있지 않습니다. 게다가 ICS는 Android 기기의 일부에서만 실행됩니다.
능동적 넷 스캔 접근 방식이 아니라 수동적 모니터링 접근 방식이 남아 있습니다. 네트워크가 안전하면 암호화 된 패킷을 스니핑 할 수 있지만 불편합니다. 당신은해야합니다
이것을 실제로보고 싶다면 Wireshark 는 WPA 복호화를 지원합니다 .
Wi-Fi 트래픽을 볼 수있게되면 Android 기기가 특정 Google 서버와 통신하는 경향이 있으며 HTTP 연결에 식별 가능한 사용자 에이전트 문자열이 있음을 알 수 있습니다 . 이것이 실행 가능한 수동 솔루션의 기초입니다.
Tenable Network Security 는 이러한 유형의 접근 방식을 취하는 것처럼 보이는 제품을 제공합니다.
또 다른 아이디어
@Michelle Cannon은 Libelium의 Meshlium Xtreme에 대해 언급했습니다. Libelium의 Meshlium Xtreme은 접근 방식이 끝까지 도달하지 못할 것입니다 (최신 MAC 주소 범위 테이블이 없으면 안 됨). 그러나 그것은 더 작은 목표에 도달하는 일부일 수 있습니다. 다음을 수행 할 수 있습니다.
- 모든 무선 장치 감지
- MAC의 OUI (Organizationally Unique Identifier)를 사용하여 Apple 장치 제거
- 신호 강도를 모니터링하여 이동 중인지 확인하여 모바일 장치임을 알립니다 (모바일 장치는 표시되고 사라지는 경향이 있음).
- MAC OUI를 Android에 대한 힌트로 사용할 수 있습니다.
- MAC OUI를 Android가 아닌 힌트로 사용할 수 있습니다 (노트북 또는 무선 카드 등).
Android 일 가능성 이있는 기기를 감지하려는 경우이 방법을 사용할 수 있습니다 .
DHCP 지문
@Michelle Cannon은 DHCP 지문을 제안했습니다. 처음에는 확신 할 수 없었지만 간단한 수동 스캔을위한 최선의 방법을 제안 해준 그에게 감사해야합니다. 조심스러운 꼬리로 내가 왜 파티에 늦었는지 설명하고 싶습니다.
우리가 알고 있고, 모른다고 생각하는 것, 우리가 알고 있지만 잘못되었다고 생각하는 것이 있습니다.
여러면에서 Android가 Linux 커널을 사용하는 것이 좋습니다. 그러나 네트워크에서 Android 장치를 검색하려는 경우에는 좋지 않습니다. Android의 TCP / IP 스택은 Linux이므로 Android 기기는 Linux 기기처럼 보일 것이므로 처음에는 생각했습니다. 하지만 Linux에는 많은 빌드 구성 매개 변수가 있으므로 네트워크에서 볼 때 Android에 특이한 점이있을 수 있다는 것을 깨달았습니다 .
DHCP 지문은 장치에서 요청한 정확한 DHCP 옵션과 타이밍을 사용합니다. 이 작업을 수행하려면 일반적으로 일치시킬 최신 지문 데이터베이스가 필요합니다. 처음에는 fingerbank 가이 데이터를 소싱하는 것처럼 보였지만 그 파일이 거의 1 년 동안 업데이트되지 않은 것을 알았습니다. Android 기기 유형이 다르기 때문에 단일 프로젝트에 대해 업데이트 된 지문을 유지하는 것이 실용적이지 않다고 생각합니다.
하지만 Android의 실제 DHCP 서명을 살펴 보았는데 다음과 같은 사실을 발견했습니다.
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는 일반적으로 dhclient를 DHCP 클라이언트로 사용하지만 Android는 dhcpcd를 사용합니다. Android는 가능한 경우 BSD 스타일로 라이선스가 부여 된 소프트웨어를 사용하는 것을 선호하며 dhcpcd는 BSD 라이선스를 사용합니다. dhcpvendorcode는 모바일 장치가 Android를 실행하고 있다는 강력한 지표로 사용될 수 있습니다.
DHCP 모니터링
클라이언트는 네트워크에 연결할 때 DHCP를 사용하여 IP 주소를 가져 오므로 IP 주소없이 시작됩니다. 초기 교환에 UDP 브로드 캐스트를 사용하여이 문제를 해결합니다. Wi-Fi에서는 WPA를 사용하더라도 브로드 캐스트 트래픽이 암호화되지 않습니다. 따라서 클라이언트 대 서버 트래픽의 경우 UDP 포트 67에서, 그 반대의 경우 68에서 수신 대기 할 수 있습니다. 네트워크 인터페이스를 무차별 모드로 설정할 필요도 없습니다. Wireshark와 같은 프로토콜 분석기를 사용하여이 트래픽을 쉽게 모니터링 할 수 있습니다.
나는 트래픽을 모니터링하는 코드를 작성하는 것을 선호했고 Python을 사용하기로 결정했습니다. DHCP의 세부 사항을 처리하기 위해 pydhcplib를 선택했습니다. 이 도서관에 대한 나의 경험은 부드럽 지 않았습니다. IN.py 및 TYPES.py 지원 파일을 수동으로 다운로드하여 배치해야했습니다. 그리고 그들의 패킷에서 문자열로의 변환은 dhcpvendorcode를 비워 두었습니다. DHCP 패킷을 올바르게 구문 분석 했으므로 방금 인쇄 코드를 작성했습니다.
다음은 클라이언트에서 서버로의 DHCP 트래픽을 모니터링하는 코드입니다.
#!/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()
이 코드는 서버와 같은 클라이언트 요청을 수신하기 때문에 pydhcplib의 서버 예제를 기반으로합니다.
내 Nexus 7 Android 4.2 태블릿이 연결되면 다음 흥미로운 정보가 캡처 (수정)됩니다.
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
The host name seems to have a fixed format and is easily parsed. If you need the IP address you can monitor the server to client traffic. Note: only the initial exchange, when an new client first shows up without an IP address, is broadcast. Future lease extensions, etc., are not broadcast.
Reverse DNS Lookup
@Luis posted a great solution that demonstrates how simpler is better. Even after seeing Android's DHCP client was setting host_name to android-5c1b97cdffffffff, I didn't think to ask the router for it's list of names using reverse DNS lookups. The router adds the host_name to it's DNS server so you can still access the device if its IP address changes.
The host_name is expected to remain listed in the DNS for the duration of the DHCP lease. You could check if the device is still present by pinging it.
One drawback to depending on host_name is there are ways this could be changed. It's easy for the device manufacturer or carrier to change the host_name (though after searching, I've been unable to find any evidence they ever have). There are apps to change host name, but they require root so that's, at most, an edge case.
Finally there's an open Android Issue 6111: Allow a hostname to be specified that currently has 629 stars. It would not be surprising to see configurable host_name in Android Settings at some point in the future, maybe soon. So if you start depending on host_name to identify Android devices, realize it could be yanked out from under you.
If you're doing live tracking, another potential problem with Reverse DNS Lookup is you have to decide how frequently to scan. (Of course this is not an issue if you're just taking a one-time snapshot.) Frequent scanning consumes network resources, infrequent leaves you with stale data. Here's how adding DHCP monitoring can help:
- On startup use Reverse DNS Lookup to find devices
- Ping devices to see if they are still active
- Monitor DHCP traffic to detect new devices instantly
- Occasionally rerun DNS Lookup to find devices you might have missed
- If you need to notice devices leaving, ping devices at desired timing resolution
While it's not easy (nor 100% accurate), there are several techniques that make it possible to discover Android devices on your network.
AFAIK, Android system doesn't provide any zeroconf app/service on it's built-in system app/service stack. To enable the auto-discovery on the actual device attached to local network, you need either install some third-party zeroconf app or develop your own app/service and install it on the actual device, some API options are:
- JmDNS (for Apple's bonjour protocol)
- Cling (for Microsoft's UPnP protocol)
- Android NSD API (introduced since Android 4.1)
I am not quite clear about your requirements, if you want something similar (i.e. auto discover and connect) on vanilla Android devices, you can probably use Wi-Fi direct which is now available on some later device running Android 4.0, however, it requires both devices support Wi-Fi Direct and only create an ad-hoc P2P connection with Wi-Fi turned off, much like a bluetooth connection with a longer range:
For Wi-Fi Direct API support, check out official guide - Connecting Devices Wirelessly.
I am looking at this an thinking
http://www.libelium.com/smartphones_iphone_android_detection
pay special note to this
Do the users need to have an specific app installed or interact somehow to be detected?
No, the scan is performed silently, Meshlium just detects the "beacon frames" originated by the Wifi and Bluetooth radios integrated in the Smartphones. Users just need to have at least one of the two wireless interfaces turned on.
Long time ago I use to use an app called stumbler on my mac to find wifi networks, I think this is similar
Other ideas
Well if I need to determine android phones on a local network how would I do it. Absent of a dns service running I only have a couple possibilities
The SSID if its being broadcast - can't tell me anything The ip address - android lets you have a lot of control over host naming so I guess you could define a specific ip range to your android devices. -not to useful.
Alternately lets say I see an unknown device on the network, if bluetooth is turned on then I am broadcasting a bluetooth device signature SDPP that I can use to deduce my device type.
If I were running a service that supported android and I wanted to discover specific android devices on my network, then I could just register the mac addresses for those devices and watch for them on the network.
Other than that you would need to run either a bonjour (dns-sd) or upnpp dameon on the device.
Updated Response
Sorry, I haven't understood the original question correctly. Only your comment made it really clear to me that you do not want to have to install anything on the target devices but you just want a way of discovering random phones in your network.
I'm not sure if this would really be possible in the way you want it. Without having any network discovery service running on Android you will not find the device in first place. Of course you can use some low-level network protocols but that would only give you an indicator that there's something but not what it is (being an Android device, a PC, a whatever else).
The most promising approach would be to check for preinstalled apps that have network functionality of some kind. E.g. Samsung devices have Kies Air (if the user enables it), Motorola are using UPnP for their Media Server and HTC has something own as well, if I remember correctly. However, there's no app that is installed on all Android devices of all vendors and carriers. So you can't rely on solely one of those but would need to check for various different services using their specific protocols and behaviors in order to get additional information about the device. And, of course, the user would have to enable the functionality in order for you to use it.
Old response
An additional alternative to yorkw's list is AllJoyn by Qualcomm. It's an open source cross-platform discovery and peer-to-peer communication framework I've used in the past myself already.
Though Qualcomm is a big sponsor of AllJoyn this does not mean that you need a Qualcomm chipset in your define. In fact AllJoyn works on any chipset including Intel and nVidia. It doesn't require rooted phones or any other modifications to the Android framework and just works "out of the box" using Wi-Fi and/or Bluetooth as pairing methods.
I am learning a lot from this topic.
there is also something called dhcp fingerprinting, apparently different devices act differently to the kind of network scans we've been discussing such as those using NMAP a linux scanner. Maps of the behavior from these probes are available on the 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://myweb.cableone.net/xnih/
Here's a one liner that pings all of the machines on your network (assuming your network is 192.168.1.x) and does a reverse lookup on their names:
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
Requires GNU parallel to work. You can install that on OSX using "brew install parallel"
From this you can just look at the devices named android-c40a2b8027d663dd.home. or whatever.
You can then trying running nmap -O on a device to see what else you can figure out:
sudo nmap -O android-297e7f9fccaa5b5f.home.
But it's not really that fruitful.
ReferenceURL : https://stackoverflow.com/questions/13198669/any-way-to-discover-android-devices-on-your-network
'Program Tip' 카테고리의 다른 글
| "중앙값의 중앙값"알고리즘 이해 (0) | 2021.01.08 |
|---|---|
| git에서 ^ {}은 무엇을 의미합니까? (0) | 2021.01.08 |
| NaN === NaN이 거짓 인 이유는 무엇입니까? (0) | 2021.01.08 |
| isset ()과 __isset ()의 차이점은 무엇입니까? (0) | 2021.01.08 |
| Chrome의 네트워크 탭에서 모든 Ajax 응답을 검색하는 방법은 무엇입니까? (0) | 2021.01.08 |