bojak4616 / mobile_phone_tracking Goto Github PK

Main contribution:
if vMAC broadcast probe req -> probe respond with any SSID-> get rMAC -> confirm desired rMAC -> save vMAC tags from initial probe req -> listen to all vMACs with same tags -> start responding to vMACs with confirmed tags in order to track target.

Using named pipes seems to be inefficient. There is a condition where a packet is being read from the pip while the pipe is trying to be opened by another process.

Should try using a try/except with a very small sleep interval. This would slow everything down considerably and is not the best solution. A reimplementation with mutexes would be better.

Basically title. Upon successful deauth, and passively receiving information there should be enough information to determine the global MAC. The paper does not consider the possibility of a dauth, which makes this attack much more potent, but very active.

"This is particularly useful as all authentication and association frames from iOS and Android devices use the global MAC address."

While work can still be done with the provided antenna, the new one would be better.

Use examples from the paper, in earlier sections, to be able to fingerprint devices. Since I'll only really be working with my Nexus 6p, I should be able to pick it out quickly.

Write in scapy the ability to pull the sequence number from probe requests. This should be fed a ESSID/BSSID. Other information might need to be grabbed from probe requests to retrieve the global MAC.

This should be pretty easy. Follow this guide without copying the code too much. Reference cite anyway because he is a cool dude.

http://raidersec.blogspot.com/2013/01/wireless-deauth-attack-using-aireplay.html

The paper covers the ability to use RTS/CTS to retrieve(maybe confirm?) the global MAC address. More research has to be done by reading the main paper and the one it references.

This can be done with the aircrack suite. However, it would be nice to have everything in python functions so that they can be called to quickly grab what is in the air. The benefit to this approach is the ability to grab and use the SSID/BSSID/ESSID's quickly and interchangeably.

This would be good for larger scale operations. Since I only have one device available, maybe not.

I'm leaning yes since it's not much work. Have to look into a tad more.

Either the instructions are missing or the code is broken.

I provided the MAC and waited for like an hour.

The website should be separate from this repo. However, it should have a sym link to this repository for access to the code.

I know this can be done in git, will have to look up how.

@csanders-git What do you think about changing the website to have functionality that lets a user input a MAC address, which gets sent to a listening device that will serve up the attack. It will then respond back to the website with a yes/no and some other info about if the MAC is near the device or not.

Presumably it would keep looking for/tracking the MAC until the user requests it to stop.

To continue to get an understanding of the UUID-E attack I should read this:

http://delivery.acm.org/10.1145/2900000/2897883/p413-vanhoef.pdf?ip=129.21.114.217&id=2897883&acc=ACTIVE%20SERVICE&key=7777116298C9657D%2ECC42FF8DB9519351%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&CFID=909567110&CFTOKEN=39707905&__acm__=1491534305_1c068ece9210fffb95f48fbdc32ed463

According to the paper, additional information needs to be correlated to get to the global MAC.

Paper also implies that you don't need the global MAC as you can follow the generated sequence numbers and connect them to the local MAC. However, this is not as good as getting to the global MAC.

Test to see the pattern created in the sequence number field. This can be done with the aircrack suite.

Create script that sniffs traffic and prints found virtual MAC address. Good to separate from devices that don't use virtual MAC addresses from those that do.