Tjyylli

I have a mobile app which connects to my cars wifi and reports data on it.
The app must be connected to the AP the car provides in order to work - I have tested whether the car connects to a public internet api and the phone retrieves this data but this is not the case. It seems that phone directly connects to the car (via the provided AP) in some way.

I am trying to see the network traffic here to replicate the functionality outside of the provided app.

Things I have tried:

Viewing HTTP and HTTPS traffic via Proxy (running app via proxy)

To do this, I connected the phone directly to the AP as required but proxied the phones HTTP and HTTPS traffic via mitmproxy running on a laptop on the same network. Running the app showed traffic but not for the related items Im after (which update in the app)

Running wireshark

I ran wireshark on a laptop connected to the same network (as described above) and captured all traffic. I then loaded the app and reviewed the capture. There seemed to be no direct network connectivty between the devices. There was a broadcast message from the AP, giving an address and description of an API but the phone never seems to then connect to this - I think it may be irrelevant for my needs.
(I tried to telnet to the address/port described and it returned what looked like xml, but i was unable to send any traffic to get any more information)

Neither method I have tried seems to show meaningful traffic between the two devices.

Is there something obvious Ive missed? What else can I try to view the phone communicating with the car?

Using Wireshark to capture unicast traffic between two other devices on an 802.11 network requires using 802.11 monitor mode, which is tricky to pull off. If you were only capturing in promiscuous mode (which is common for wired Ethernet packet captures on hubs or via port mirroring on managed switches), then you wouldn't have seen any unicast traffic to/from other wireless devices.

You should read up on the Wireshark site about how to do 802.11 monitor mode packet captures, and how to decrypt the unicast data frames you capture, if the network uses WPA2-PSK (or original WPA-PSK or even WEP).

Here are some highlights of what you need to deal with:

• In your Wireshark machine, you must have a WNIC and driver that supports 802.11 monitor mode.


• Your monitor-mode-capable WNIC must support all the same flavors of 802.11 transmissions that your AP and the target wireless device (your phone) support. For example, if your AP and phone both support 802.11ac, but your monitor mode WNIC doesn't, it won't be able to receive those 802.11ac transmissions. Even if all three devices support 802.11ac, if the AP and phone support, say, 2 spatial streams (a.k.a. "2x2:2"), but your monitor mode WNIC only supports 1 spatial stream (1x1:1), then your Wireshark machine won't be able to see anything your phone or AP transmit using 2 spatial streams.


• If your Wireshark machine is too far from the AP and wireless client, it might not get enough signal strength to be able to receive the packets reliably.


• If your car's AP uses WPA2-PSK (or original WPA-PSK), and you have no option to disable security, then in order to decrypt traffic to/from the phone, you must capture the WPA2-PSK 4-way handshake that happens when the phone joins the network. Capturing that handshake, and knowing the PSK or passphrase for the network, allows you to decrypt all of the packets you capture from that session. But if the phone falls asleep or otherwise leaves and rejoins the network, that's a new session and you'll need to be sure to capture the WPA2 4-way handshake for that new session if you want to decrypt any of the packets from that new session.