search

whad-team / whad-client

Wireless Hacking Devices Protocol client
MIT License
131 stars 8 forks source link

LL packet capture? #48

Open jsmif opened 2 months ago

jsmif commented 2 months ago

When I was watching the demo7-ble-proxy.mp4 from your defcon talk, I noticed that wireshark didn't show any packets from below the ATT layer. And I didn't see any filter in place. Does this mean that WHAD cannot see LL packets? Or was that just a limitation of that particular tool chain? (Because conceptually it seems like WHAD should be able to do LL MITM if it's using custom firmwares?)

virtualabs commented 2 months ago

If I remember correctly, WHAD interfaces that run custom firmware supporting raw BLE PDU sniffing receive raw PDUs and therefore LL data, while HCI devices send PDUs with a reconstructed header (@RCayre, correct me if I'm wrong). So WHAD can definitely see LL packets, and our BLE stack does have a link layer that process L2CAP data and handles PDU fragmentation.

Our proxy demo relies on a BLE HCI adapter to spawn a device and on a nRF52 interface running custom firmware to connect to the target BLE device. Problem is that the BLE HCI does not give access to raw PDUs, so wireshark will only show ATT packets coming from the central device connected to our HCI adapter but no control PDU as this type of PDU is directly handled by the BLE HCI adapter firmware... When a LL packet (raw PDU) is received by the side of the chain that manages the connection, this tool converts the received packet (raw PDU) into a compatible command (send PDU) that the BLE HCI adapter will support, removing any possibility to report link-layer packets.

In short, WHAD supports BLE link-layer PDUs but as soon as you are using a WHAD interface that does not support it no link-layer packet will be shown in wireshark.

Please note that we still have issues with our ButteRFly firmware when dealing with BLE5 capable central devices, as most of them ask to use a 2 Mbps coded PHY that is not supported (yet) by the hardware... causing our firmware to get completely lost :cry:.

jsmif commented 2 months ago

Don't most things send a LL_PHY_REQ to switch to 2M PHY, and therefore can't the ButteRFly firmware just send back a LL_PHY_RSP saying it doesn't want to use 2M PHY?

Any plans to support the TI hardware that Sniffle supports which supports 2M PHY?

Is there a table somewhere of which physical hardware with which custom firmware is required to support LL packet capture? (Or is that what the "PHY" means in the table here?)

virtualabs commented 2 months ago

  1. ButteRFly definitely needs a rework of its BLE stack at least to better support BLE v4.x devices and the basic connection parameters update procedures. If possible we will also implement support for BLE v5.x with CSA#2 and other features as well.

  2. I've recently acquired a compatible hardware (a few days before DEF CON) with this idea to port Sniffle's firmware to WHAD, IMHO it looks like the quickest way to get a working sniffer for BLE 4/5. But for now I've really been busy polishing the documentation and trying to fix some issues :smile:

  3. We started some kind of compatibility table here but this is far from exhaustive. And no, PHY simply means raw mod/demod (but cannot be used for BLE as the channel hopping mechanism must be implemented in the firmware because it is really time-critical ...)