btlejack icon indicating copy to clipboard operation
btlejack copied to clipboard

No data being written to pcap or FIFO

Open dpsi opened this issue 4 years ago • 3 comments

I am trying to figure out why nothing ever gets written to the pcap file or FIFO. The tool clearly shows packets being received, but nothing ever gets written out.

The only time I ever get something written out is with the -c option, but all the packets are reported as malformed in Wireshark.

I am not too interested in the payloads for the most part, but expect the link layer frame headers to be available.

I am using the current HEAD on a BLE400

btlejack -d /dev/ttyUSB0 -v -s -w /tmp/sharkfin 
BtleJack version 2.0

[i] No output format supplied, pcap format will be used
[i] Waiting for wireshark ...
[i] Enumerating existing connections ...
[ - 80 dBm] 0x2cf057cf | pkts: 1
[ - 81 dBm] 0x2cf057cf | pkts: 2
[ - 77 dBm] 0x2cf057cf | pkts: 3
[ - 77 dBm] 0x2cf057cf | pkts: 4
[ - 77 dBm] 0x2cf057cf | pkts: 5
[ - 75 dBm] 0x2cf057cf | pkts: 6
[ - 89 dBm] 0x5065456c | pkts: 1
[ - 80 dBm] 0x2cf057cf | pkts: 7
[ - 73 dBm] 0x2cf057cf | pkts: 8
[ - 72 dBm] 0x2cf057cf | pkts: 9
[ - 78 dBm] 0x2cf057cf | pkts: 10
[ - 74 dBm] 0x2cf057cf | pkts: 11

dpsi avatar Nov 13 '19 23:11 dpsi

I managed to sort of hack it to output. Not sure why the output is never passed to CLIAccessAddressSniffer. I don't know much about python either.

I'm not sure where to get the Access Address, so I used a constant of 1 for now. So I am at least getting some output. Not sure how to get the rest of the data, any suggestions on where to plug into?

diff --git a/btlejack/__init__.py b/btlejack/__init__.py
index 185f21a..bffbe55 100755
--- a/btlejack/__init__.py
+++ b/btlejack/__init__.py
@@ -260,7 +261,7 @@ def main():
 
     if args.scan_aa:
         try:
-            supervisor = CLIAccessAddressSniffer(verbose=args.verbose, devices=args.devices)
+            supervisor = CLIAccessAddressSniffer(verbose=args.verbose, devices=args.devices, output=output)
         except DeviceError as error:
             print('[!] Please connect a compatible Micro:Bit in order to use BtleJack')
             sys.exit(-1)
diff --git a/btlejack/supervisors.py b/btlejack/supervisors.py
index 61b3d3f..f7ba4b5 100755
--- a/btlejack/supervisors.py
+++ b/btlejack/supervisors.py
@@ -99,6 +99,7 @@ class AccessAddressSniffer(Supervisor):
         self.interface.scan_access_addresses()
 
     def on_packet_received(self, packet):
+        self.on_ll_packet(packet)
         """
         Dispatch received packets.
         """
diff --git a/btlejack/ui.py b/btlejack/ui.py
index 1f8820f..d500e7d 100755
--- a/btlejack/ui.py
+++ b/btlejack/ui.py
@@ -346,9 +346,22 @@ class CLIAccessAddressSniffer(AccessAddressSniffer):
 
     def on_ll_packet(self, packet):
         """
-        Called when a BLE LL packet is captured.
+        A BLE LL packet has been captured.
         """
-        pass
+        timestamp = time()
+        ts_sec = int(timestamp)
+        ts_usec = int((timestamp - ts_sec)*1000000)
+        if self.output is not None:
+
+            # Is it a Nordic Tap output format ?
+            if isinstance(self.output, PcapNordicTapWriter) or isinstance(self.output, PcapBlePHDRWriter):
+                self.output.write_packet(ts_sec, ts_usec, 1, packet.data)
+            else:
+                self.output.write_packet(ts_sec, ts_usec, 1, packet.data[10:])
+
+        pkt_hex = ' '.join(['%02x' % c for c in packet.data[10:]])
+        print('LL Data: ' + pkt_hex)
+
 
     def on_verbose(self, packet):
         """

dpsi avatar Nov 14 '19 00:11 dpsi

Oh, I see. There is no capture during access address discovery (-s option), only while following an existing connection (-f or -c options). During the connection discovery process, btlejack does not capture and decode BLE packets but instead only focuses on the first bytes of every packet received.

This is a statistical attack aiming at identifying every access address used by packets sent in the air, and only that. No way it will capture data during this step (and that would be useless as we don't know how to check CRC since CRCInit has not been recovered yet, without mentionning channel hopping and sync as well ...)

virtualabs avatar Nov 14 '19 07:11 virtualabs

I am working on an embedded systems project for school and essentially I want to passively capture the BLE packets. I am really only interested in the metadata, so things like frame headers and MAC addresses. Is btlejack the right tool for this?

dpsi avatar Nov 14 '19 18:11 dpsi