Randomized MAC address about trackerjacker HOT 4 OPEN

(im not the author, i'm just chiming in)
As far as I understand it, the MAC is only random when it is probing for APs stored in the known networks list. Once found, it connects to the AP with it's true MAC. So you can still track people, you just have to wait for them to connect to their AP and reveal their MAC.

An interesting thing about these MACs is that the randomized MAC tends to NOT resolve to a known manufacturer in oui.txt. It could be an interesting addition to label those devices as such for filtering, the way a FingBox does.

Depending on how dense the area is where you are, you might be able to just ignore the randomization issue. Consider this scenario: You live in a house with a long driveway and want to know when someone is driving up it. You place a raspberry pi sensor near your mailbox and have it triggered on any probe request at all. This would notify you much earlier than waiting for the device to connect to an AP.

I kinda remember reading something about a flaw in the MAC generation algo in early on when they started doing it, but it's probably patched.

from trackerjacker.

(im not the author, i'm just chiming in)
As far as I understand it, the MAC is only random when it is probing for APs stored in the known networks list. Once found, it connects to the AP with it's true MAC. So you can still track people, you just have to wait for them to connect to their AP and reveal their MAC.

An interesting thing about these MACs is that the randomized MAC tends to NOT resolve to a known manufacturer in oui.txt. It could be an interesting addition to label those devices as such for filtering, the way a FingBox does.

Depending on how dense the area is where you are, you might be able to just ignore the randomization issue. Consider this scenario: You live in a house with a long driveway and want to know when someone is driving up it. You place a raspberry pi sensor near your mailbox and have it triggered on any probe request at all. This would notify you much earlier than waiting for the device to connect to an AP.

I kinda remember reading something about a flaw in the MAC generation algo in early on when they started doing it, but it's probably patched.

Do you have any scripts to implement in RPi ?

Can you share more information about the paper you read, also my objective is to get the real mac address of device when they are not connected to an AP.

from trackerjacker.

Do you have any scripts to implement in RPi ?
No, I need to brush up on my python first.

Can you share more information about the paper you read, also my objective is to get the real mac address of device when they are not connected to an AP.

https://www.theregister.co.uk/2017/03/10/mac_address_randomization/

they link to the technical paper, which is here: A Study of MAC Address Randomization in Mobile Devices and
When it Fails

from trackerjacker.

From page 16:

The result of sending a RTS frame to the global
MAC address of a device performing randomization
was that the target device responded with a CTS
frame. A CTS frame, having no source MAC address,
is confirmed as a response to our attack based on the
fact that it was sent to the original, crafted source
MAC address. A full device listing utilized for the
control frame attack is available in Appendix D.

Once the global MAC address is known, that device can be easily tracked just as if randomization
were never enabled. This might cause one to wonder why vendors would go to such lengths to include
MAC address randomization in a device only to allow
that same device to divulge the protected information
through an administrative protocol. We assert that
this phenomenon is beyond the control of individual
vendors. The fact is that this behavior occurs across
the board on every device we have physically tested as
shown in Appendix D. This leads us to believe that
RTS/CTS responses are not a function of the OS,
but of the underlying IEEE 802.11 chipset. Manufacturers have configured their chipset hardware with
default RTS/CTS operation which may not even be
accessible to configure at the OS level. If we are correct, this derandomization issue can not be fixed with
a simple patch or OS update. Susceptible mobile devices will be unmasked by this method for the lifetime of the device. Additionally, due to the hardware level nature of this phenomenon, there will be a significant delay in the market until mobile devices
resistant to this attack are produced, assuming manufacturers recognize this as a flaw and subsequently design a process
..snip..

Additional tests, while the target device had WiFi
or Airplane-modes, enabled or disabled respectively,
revealed further concerns. Namely, Android devices
performing location-service enabled functions wake
the 802.11 radio. Our RTS attack was thusly able to
trigger a CTS response from the target, circumventing even extreme privacy countermeasures.

So that looks like a way to have trackerjacker de-anonymize devices.

• On startup, generate a attacker MAC to use to send RTS frames
• read a list of targeted known MACs from config or cmd line
• each second, send out a single RTS frame to a targeted MAC and listen for any CTS frame that contains your attacker MAC (within 1 second?)
• After getting response, send another identical one just to be sure that it's the right MAC and not a lagged response.
• if no reply, try the next target.

This would be pretty killer functionality for trackerjacker as I don't think any other tool is doing this currently. It's of limited use of course, since you need to know the desired MAC, and if you do, that's probably because it's associating to an AP near you. If your listening post is a static location, you probably wouldn't typically see this known MAC sending randomized probes anyway since it would just always be associated to a nearby AP.

There's other good tips in the paper though, like using the WPS UUID-E guid to determine the global MAC. Do you have room for a 2.5TB rainbow table on your laptop? :D

from trackerjacker.