CLI
- macOS (10.14.6)
airportbinary symlink:
$ sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
- While connected, view current station's channel:
airport -I - Must be disassociated with wireless station:
sudo airport -z - Must be on the correct wireless wireless channel:
airport -c $CHANNEL While disconnected, CLI dump:
sudo tcpdump -Ini en0Currently unsure of how to decrypt a capture via
tcpdump, but any format-compatible traffic captured viatcpdumpcan be opened in Wireshark, where it can do the decryption.
GUI
- Wireshark 802.11 decryption:
wpa-pwd:pa55w0rd:Clever_SSID_Name - Disconnect with option(⌥)+click on WiFi bars.
Applies to either method
- Be aware: Depending on the encryption scheme (namely WPA), you may need to capture the WiFi association process of the device you're wanting to capture. Meaning, you'll want the device you want to capture traffic for in an unassociated state, and then join the SSID after capturing has begun.
- The association process may be required, involving 802.11 and EAPOL messages:
Why is this interesting?
WiFi traffic is just radio chatter on a certain channel, so it's easy to observe this chatter. However, if the WiFi network employs a form of encryption, said chatter only shows physical, layer 1 communications, commonly known as "beacons" in the wireless world. These encrypted beacons do not expose the internal protocols being used by the devices on the network. (So no TCP, no UDP, no HTTP, etc.)
However, if you know the WiFi name (Service Set Identifier, SSID) and password, you can decrypt these beacons and see the internal protocols. This is what we're after.
Learning the value of not being seen
Once captured and decrypted, we can now see application-level, or at least layer 2 traffic and above, up to other SSL/TLS-encrypted data:
