I want to track my iPhone 6s device for the probe requests it is sending to connect to the WiFi router.
This is my current setup:
I have kept the WiFi on and have forgotten the network, in the phone so that it probes new APs.
1.The location and services is disabled.
2.The Mobile-Data is also On.
3.I am using Aircrack-ng to trace the probe requests to the router.
4.I ran the setup to get the probe requests for 1 hour, but still couldn't get the entry for the iPhone.
5.I also used wireshark and a different router to detect the iPhone but still it is not available. The capture duration was 1 hour.
6.The phone screen was randomly on and off.
I have read that from iOS8 Apple uses MAC randomization for the user safety so that they can't be tracked, but now I have a clear insight of what are the conditions when the randomization occurs(location disabled and packet data disabled and phone in sleep mode.)
I want to know that is the randomization actually happening and even if it is happening, how do I know the new Locally Randomized address of my device to trace it on Aircrack-ng/Wireshark.
And If the randomization process is actually not happening then why can't I see my iPhone in the list.
Some articles I followed:
http://blog.mojonetworks.com/ios8-mac-randomization-analyzed/.
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html#concept_79EB523637BD49F3AE876F9C1C95DD69
Related
I am trying to reverse engineer the API of an IoT device using mitmproxy. My setup is an iphone, computer running on MacOS 10.14, and an IoT device (watering pump) that can only access the wireless network after being plugged into the computer via USB connection, i.e. a not genuinely WiFi device. My phone is configured to point to the computer, which is running mitmproxy on a standard configuration.
When I send instructions from the app controlling the device on my phone to the device itself, presumably these instructions are sent to the computer, to the device cloud server, and then to the device. With these assumptions, one would think that they would see the flow of POST requests in mitmproxy before observing the results of those instructions. That is, if you send an instruction to turn on the pump, you'd think you'd see POST request containing that instruction show up in the mitmproxy flows before you see the pump turn on.
However that is not the case here. What happens is that, when I send instructions from the app, I observe the expected behavior from the IoT device, and then the flow of requests appear on the mitmproxy console seemingly at random. There seems to be no determinate relationship between the instructions I send and the requests that appear; they show up 5 seconds later, 5 minutes later, or 30 minutes later. Is this an intentional security feature? To somehow jam MITMproxies so that hackers cannot easily isolate the knowledge of which packet is performing which instruction? Or is it just something that I am doing wrong? Does anyone have any ideas as to what could be happening hear and potential solutions for making the flow of requests appear in real time? Ty
my system consists of a bluetooth accessory and an iPhone. Sometimes I see a link loss between the two devices in idle mode. I have only seen it in idle (sniff) mode so far. Sometimes it happens every few minutes, sometimes after an hour or so. I have no clue why. My accessory does a reconnect right after loosing the connection, but that is very bad user experience.
What I did so far:
I read the iPhone accessory guide and was a bit surprised about the advice to set the sniff period to 15 ms. In the example application of my chipset (CSR) I see a period of 800 slots == 500 ms. I configured my application to use minimum of 15 ms. Nevertheless the iPhone indicated a period of 384 slots.
I also checked the supervision timeout. It is set to 8000 slots == 5 seconds. Seems ok.
I also have the impression that it mainly happens if two phones are connected to the accessory. The second phone is an android. The android phone does not have a problem.
Now I run out of ideas what to do. Do you have a idea here?
Thank you,
After a lot of sniffing and debugging I found out the reason on physical layer. The situation was the following: I have a headset (HS), an iPhone (I) and an Android (A).
To reproduce I had to:
Connect HS and iPhone
Connect HS and Android. Important: The Android device had to initiate the connection.
Now the HS is in the situation where both peer devices are in bluetooth master role, the HS is in slave role on both connections.
What now happens is that both master may set the HS into sniff mode with some sniff interval which is conflicting with each other. Due to time slot collisions the connections is then lost.
One possible solution is to detect this situation on the HS and either never go to sniff mode or use a shorter timeout to change from active to sniff mode. In this case, the HS can propose the sniff intervals for both connections and prevent conflicts.
I am trying to detect if my iPhone is in the same network as my Raspberry Pi. I would like to execute a script when I am at home and my iPhone's presence is registered in my LAN.
It seems that when the phone is in standby not even the iphone-sync port (6207/tcp) is found. "/usr/bin/nmap -n -sT -p62078 [my phone's local IP]" shows no host. I wonder what else I could scan for. Obviously the phone is online and ready to accept facetime calls (data via 3G is deactivated). Could I accomplish something with avahi which I am using on my Raspberry Pi, or are there other ways.
I've just spent a week beating on this problem so I can refrain from sending SMS home alarms to my wife when she's at work.
Pinging won't work because the iPhone won't respond to ICMP when asleep. Reading the ARP cache won't work because a sleeping iPhone will come and go (check it every 30 seconds for a few minutes).
The only way I have found to 'reliably' determine when my two iPhones are on my local (home) network is to use the PCAP dotnet library to look for any packets originating from either of the phones' MAC addresses. For example, if you run Wireshark with the capture filter
ether src <iphone-mac-address>
you will see a surprising amount of network discovery/announcement traffic from the phone. It still has quiescent states, but so far the longest interval I have seen between captured packets is around 10 minutes. You would have to wait until you have not heard from the phone for some interval (I use 15 minutes) before declaring it not-home.
With this technique you will find a phone quickly when it rejoins the home network, assuming your phone is configured for DHCP. I also use port mirroring on my main Ethernet switch to include traffic from my wireless access points.
I don't have a Raspberry Pi solution for this, because my linux expertise is very limited, but someone else may be able to help you along those lines. I have a Windows Service using the PCAP library and so far it works reliably, with the limitation of waiting 15 minutes before deciding an iPhone has left the network.
* update 2-3-2018 *
I have this detection algorithm down to about 5 minutes, using a combination of ping/arp messages directed to each phone, about once per minute. Seems to work great.
You can find a list of devices on your network by investigating your arp cache.
arp -a
Simply write a bash script to run arp -a at a regular interval, and search for the mac address of your phone.
You could go even further with this and perform different actions depending on what brand of device is connected.
The first 3 hexadecimal digits of a mac address are the vendor id.
Take the following mac address:
00:19:E3:AB:CD:EF
00:19:E3: is one of the registered mac address for apple devices.
By comparing the devices on your network with this list, you could detect when for example a '3com' device, or a 'dell' device attaches to your network.
http://www.coffer.com/mac_find/?string=apple
You can do "arp-scan -l -r10" for that (tested this myself), but the problem is if mobile data enabled the iphone will go and suspend wifi if screen is locked to safe battery. so you need to disable mobile data .. then arp-scan will work.
My iPhone app sends data persistently over the network, and can handle having the network completely unavailable for a time. However I do my dev on an ipod and have difficulty testing 3G connectivity issues; My question: is there period of non-connectivity, while an app is in the foreground, after which the iphone will stop checking for the network, such that there are no bars and reachability returns 0 until the user "wakes" the phone, e.g. by locking/unlocking? Or can e.g. 1 hr without data network pass and the iphone will recognize that the network is back and reachability will start returning true (I am polling every 1 minute while there is not connection to my server).
This is my experience with wifi: if, while running my app, the ipod hasn't connected to a wifi network for 1/2 hr, it stops looking for networks, and I need to lock and unlock it to stir the device into looking again.
One other thing: the iPhone has the screen dimmed by the proximity sensor while all this persistent network use is happening.
Wi-Fi going down after 30 min of inactivity is a documented behavior. Cellular network is always active, unless turned off by the user. So if it goes down for a while it should get back online automatically when possible even if there was no user activity.
I studied the iOS programming guide in the iOS SDK. In that in "Tuning for Performance and Responsive ss" section I am having problem. In the subsection named "Using Wi-Fi" under the above section there is one note which is like below:
Note: Note that even when UIRequiresPersistentWiFi has a value of true, it has no effect when the device is idle (that is, screen-locked). The application is considered inactive, and although it may function on some levels, it has no Wi-Fi connection.
According to my interpretation what this note says is that once the screen is locked of iPhone there is no Wi-Fi connection with iPhone. To check this what I did is, I implemented one simple application which sends one UDP packet every 6 minutes and then sleeps using usleep function of C. Now after starting this application I lock my iPhone with the button above iPhone, but still it can send the packet every 6 minute. If Wi-Fi connection really gets closed according to above note then how can it send the packet. I seen the packet in wireshark, it is having the ip address what Wi-Fi router provided to it. So I think documentation of iPhone SDK is wrong.
You didn't say if the iPhone is in its dock when you did the test. With the screen locked and the charging cable disconnected the iPhone will close the Wifi connection. When the charging cable is connected then the WIfi connection will remain open.