search

virtualabs / btlejack

Bluetooth Low Energy Swiss-army knife
MIT License
1.87k stars 196 forks source link

Question: Micro:Bit v2 support? #73

Open whoot opened 3 years ago

whoot commented 3 years ago

Hey,

since the micro:bit v2 was released in october 2020 and is now supporting Bluetooth 5.0 - will btlejack support the new version and may we see some updates regarding Bluetooth 5.0 support?

Regards

Andy-45 commented 3 years ago

for the moment I can tell you: 


pi@raspberrypi:/mnt/MICROBIT $ cat FAIL.TXT
error: The application image is not compatible with the target.
type: user
Tomski-Git commented 3 years ago

Btlejack is not compatible with bbc micro:bit v2 due to a different chip on board.

whoot commented 3 years ago

It seems that my question was not sufficiently formulated. The question was not DOES btlejack support the new micro:bit, the question was more like is it PLANNED to support the new version in near future.

Tomski-Git commented 3 years ago

I dont know, probably not since v1 its already capable of capturing Bluetooth 5.0 traffic.

whoot commented 3 years ago

Well, then maybe we should wait for @virtualabs answer then.

virtualabs commented 3 years ago

Porting Btlejack to Microbit v2 seems to be inevitable as Microbit v1 may be retired pretty soon. I have some concerns about this nRF52833 chip the Microbit v2 relies on:

Anyway, the best answer I can give you is that I need to put my hands on one or two of these Microbit v2, set up a dev environment and see how much work it would take to port Btlejack to this new platform. It could be straightforward or could take ages, I cannot tell now.

If you have some experience with Nordic's nRF51 or nRF52 SoCs and want to help porting Btlejack to this new platform, feel free to ping me and we'll see how we could work on it. In the meantime, I'm going to buy one or two of them in order to test the basic features that are required in order for btlejack to run smoothly on this new platform.

Twitch commented 3 years ago

While I don't have experience with the nRF5[12] SoCs, I may have rushed to grab some micro:bits for a project and ended up with some v2s in my haste. @virtualabs I'm happy to help if there's some way I can with the v2 hardware. The v1 micro:bit boards are getting increasingly hard to come by.

Let me know if there's some way that I can put these v2 boards, or some other efforts, toward validating whether a port to v2 is possible.

Cheers!

cmaile commented 2 years ago

Any news regarding the Micro:Bit v2 support?

wdebbaut commented 2 years ago

May I raise this question again? Is there support for the v2 micro:bit?

virtualabs commented 2 years ago

Not yet, still not have found time to port the code to Microbit v2.

wdebbaut commented 2 years ago

Merci Damien pour la réponse immédiate. In the meantime I will try to look for older v1 micro:bits here and there to organise my workshop in BLE4.0 pentesting in April. The ubertooth devices are way too expensive for pentesting BLE. Looking forwarding for your porting to v2 micro:bit. Unfortunately I can not help you as I am not an embedded developper. Bien-à-vous.

virtualabs commented 2 years ago

I totally understand your concerns about Microbit v1 getting rare on the market, this port to v2 is more than needed now. It has been on top of my todo list for a while, I even bought a Microbit v2, but I'll do my best to work on it as soon as possible.

M45732 commented 2 years ago

@virtualabs thank you for your hard work I'm waiting for this too.

Could you also look into support for the:

and if possile even for these ones? nRF52840 DK (PCA10056) nRF52840 Dongle (PCA10059)

They are often used and listed at the supported devices for the nRF Sniffer for Bluetooth LE: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Fintro.html&anchor=intro__supported_devices So I guess they match the requirements?

dglaude commented 2 years ago

@virtualabs is working on it LIVE (in French) today on https://twitch.tv/virtualabs ...

virtualabs commented 2 years ago

Hi folks, I've just pushed a new version of Btlejack (2.1.0) in the master branch that supports Micro:Bit v1 & v2 so you can give it a try. Please reflash your Micro:Bit with the -i option and the corresponding process mentioned in the documentation, and everything should be fine.

This brings BLE sniffing capabilities (CONN_REQ and Access Address based) as well as jamming and hijacking to Micro:Bit v2 hardware! I've only tested this firmware on a Micro:Bit v2.0 so if you have different versions please post some feedback here !

ppallynyu commented 1 year ago

I was able to mount my Micro:Bits and the btlejack -i command says that they are flashed: however, when I attempt to run Btlejack I get an error that says no sniffing device found. Any ideas what I;m doing wrong? thank you in advance!

ppallynyu commented 1 year ago

Wait nevermind! It's working for me now. Ofcourse it works right when I give up and make a post. This is so cool!

Luritu commented 1 year ago

Hello, I use a Micro:Bits V2.2 and the automatic installation does not work for me. I did resolve the problem, with manually putting the Firmware onto the Micro:Bits. But I still have a problem with detecting existing connections. My Board will randomly detect far away Signals (-80 dBm), but loses them too quickly to follow them. I have some Sensor Tags which communicate with BLE, that I want to sniff, but the board does not find them. Please help me if you have any idea what could be the Problem. Many thanks in advance

alperoot commented 1 year ago

I am also getting the same exact issue on Micro:Bit v2.21, although I didn't have a problem with firmware installation. Nearby connections don't seem to be detected, and only rarely does a remote one pop up on the screen, disappearing after 1-2 packets.

Edit: Forgot to mention; thank you for the awesome work!

virtualabs commented 1 year ago

It could be interesting to known which Bluetooth Low Energy version is supported by these devices as the channel selection algorithm may vary (there are now 2 of them, the last one being more difficult to attack). So basically, are the target devices using BLE version 5.x or 4.x, and do they support CSA #2 ? A PCAP file of an intercepted connection (through the -c option in order to intercept the connection request) could help debugging this for sure.

virtualabs commented 1 year ago

@alperoot by th way, can you give me here the interface version of your Micro:Bit v2.21 (normally present in the DETAILS.TXT file available when you plug your device into a computer) ? I will add support for this specific version.

alperoot commented 1 year ago

It is Interface Version: 0257

virtualabs commented 1 year ago

Allright, I updated the firmware install procedure in the last release (also available on master branch) and it should be supported now. I used Micro:Bit DAP Link interface documentation to include all missing versions with the corresponding firmware (https://tech.microbit.org/software/daplink-interface/).

alperoot commented 1 year ago

I'm running into this issue:

Traceback (most recent call last): File "/usr/local/bin/btlejack", line 11, in load_entry_point('btlejack==2.1.1', 'console_scripts', 'btlejack')() File "/usr/local/lib/python2.7/dist-packages/btlejack-2.1.1-py2.7.egg/btlejack/init.py", line 363, in main devices=args.devices File "/usr/local/lib/python2.7/dist-packages/btlejack-2.1.1-py2.7.egg/btlejack/ui.py", line 371, in init super().init(bd_address, devices=devices) TypeError: super() takes at least 1 argument (0 given)

virtualabs commented 1 year ago

Well, you should use python 3 instead of python 2 (now deprecated) and I think everything should be ok.

Kagi4 commented 1 year ago

Hello, i ve just got my MicroBit V2.21, i ve read all the issue and I still don t understand how to use it, how should I install the new version. Please someone could help making a tutorial o something. Thnaks

p0px commented 1 year ago

Can confirm the new firmware is able to be installed on the MicroBit v2.21 Interface Version: 0257. I copied the embedded btlejack-fw-v2.hex directly to the Microbit instead of using the -i option.

However, as others have reported, I am not seeing anything with -s or -c any options.

Could you update your firmware repo @virtualabs? I would like to take a peak and be able to modify things or compile with some logging.

Thanks for this work.

virtualabs commented 1 year ago

The whole point was to check if btlejack -i correctly deploys firmware v2 (designed for nRF52840) on Micro:Bit v2.21 :D.

Anyways, is it possible to give me more insight on the target devices you are testing, the command line options you are using in order to try to reproduce this behavior ? I've just tested with a BLE v4.x device of mine and managed to capture a connection between a smartphone and this device.

The more details you can give me the better I can sort it out (reproducing the issue, analyzing it, finding the root cause and releasing a fix).

p0px commented 1 year ago

I can confirm that btlejack -i did successfully deploy the v2 firmware.

Here are the devices setup I tested:

  1. ) Flipper Zero with nRF Connect (on Samsung S8) / Android Flipper App (on Samsung S8)
    • I could capture the initial connection with -c any but not find an existing connection -s
    • I could capture the initial connection with -c any -5 or -c any
    • I could NOT find/capture an existing connection with -s
  2. ) Physical Eddystone Beacon with nRF Connect
    • I could capture the initial connection with -c any but not find an existing connection -s
    • I could capture the initial connection with -c any -5 or -c any
    • I could NOT find/capture an existing connection with -s
  3. ) RPI Zero 2W with nRF Connect
    • I could capture the initial connection with -c any but not find an existing connection -s
    • I could capture the initial connection with -c any -5 or -c any
    • I could NOT find/capture an existing connection with -s
virtualabs commented 1 year ago

In summary, you managed to capture initial connections with -c any but looking for access addresses gave you no valid result. Since the nRF51 and nRF52 series are different, the hack btlejack uses to enumerate access addresses (based on Travis Goodspeed's nRF24L01 hack) may not be as accurate on nRF52 as it was on nRF51. I did some additional tests with a Micro:Bit v1 device against a v2 and I noticed that the v2 had a hard time detecting the access address of my connection while the v1 had no real issue figuring out all the parameters.

The problem comes from the firmware (and maybe the hardware too) as it seems difficult for the moment to sniff valid access addresses. I need to experiment a bit more with my MicroBit v2 in order to figure out how to solve this behavior with the nRF52 SoC.

Kagi4 commented 1 year ago

Hello @virtualabs @p0px I have update my MicroBit 2.21 firmware, and it flashes correctly with btlejack -i.I was making a sniffing test on an ESP32 (SoC with blt and wifi features) with a simpleBLE configuration to see if i can sniff. But when i do "btlejack -c [Esp32 MAC]" it does not do anything, it "freeze". Myabe becasue i need more MicroBits? Or maybe is another thing? Sorry for my english

p0px commented 1 year ago

@Kagi4 I was able to -c TARGET_MAC without issue.

Only thing I have noticed so far is that after some uses I will need to re-plug in my MicroBits or else the connections will be quickly lost once they are found.

DheerajSakkuri commented 1 year ago

hello sir it is possible to interface Btlejack with the nRF 52840 dongle???

lostpixel commented 9 months ago

Hi @virtualabs to let you know that micro:bit is found in version 2.2 (Oct 2023) that make the deployement with btlejack -i not working.

Hi folks, I've just pushed a new version of Btlejack (2.1.0) in the master branch that supports Micro:Bit v1 & v2 so you can give it a try. Please reflash your Micro:Bit with the -i option and the corresponding process mentioned in the documentation, and everything should be fine.

This brings BLE sniffing capabilities (CONN_REQ and Access Address based) as well as jamming and hijacking to Micro:Bit v2 hardware! I've only tested this firmware on a Micro:Bit v2.0 so if you have different versions please post some feedback here !

As requested here some feedback :

The output after btlejack -i : └─# btlejack -i
BtleJack version 2.1

[!] Micro:Bit version could not be determined for /media/MICROBIT [i] No sniffer found, make sure all your devices are mounted as mass storage devices before flashing.

================== i guess the version Interface Version : 0258 is unknown as i understood you had to modify for the 0257 in previous messages.

Info i've in the file details.txt :

DAPLink Firmware - see https://daplink.io Build ID: v0258-gcbc2daa8 (gcc) Unique ID: 9904360273554e450065600600000046000000009796990b HIC ID: 9796990b Auto Reset: 1 Automation allowed: 0 Overflow detection: 0 Incompatible image detection: 1 Page erasing: 0 Daplink Mode: Interface Interface Version: 0258 Bootloader Version: 0255 Git SHA: cbc2daa8815f02c580fbfc5daa441bfc31db2051 Local Mods: 0 USB Interfaces: MSD, CDC, HID, WebUSB Bootloader CRC: 0x828c6069 Interface CRC: 0x70bfa202 Remount count: 1 URL: https://microbit.org/device/?id=9904&v=0258

When i manualy force 0258 to 0257 in details.txt the result is : └─# btlejack -i
BtleJack version 2.1

[i] Flashing /media/MICROBIT with btlejack-fw-v2.hex ... [i] Flashed 1 devices

┌──(root㉿kali)-[/media/MICROBIT] └─# btlejack -s
BtleJack version 2.1

^CTraceback (most recent call last): File "/usr/local/bin/btlejack", line 8, in sys.exit(main()) ^^^^^^ File "/usr/local/lib/python3.11/dist-packages/btlejack/init.py", line 297, in main supervisor = CLIAccessAddressSniffer(verbose=args.verbose, devices=args.devices) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/btlejack/ui.py", line 334, in init super().init(devices=devices) File "/usr/local/lib/python3.11/dist-packages/btlejack/supervisors.py", line 92, in init self.interface = SingleSnifferInterface() ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/btlejack/jobs.py", line 28, in init self.link.reset() File "/usr/local/lib/python3.11/dist-packages/btlejack/link.py", line 155, in reset self.wait_packet(ResetResponse) File "/usr/local/lib/python3.11/dist-packages/btlejack/link.py", line 145, in wait_packet pkt = PacketRegistry.decode(self.read()) ^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/btlejack/link.py", line 137, in read packet = self.async_read() ^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/btlejack/link.py", line 105, in async_read self.rxbuffer += self.interface.read() ^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 565, in read ready, , _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KeyboardInterrupt

And the board show in sequence with led "5" , "0" , "4" , ":(" in loop.

If you need more info i will be more than happy to provide them. Thank's for the amazing job so far.

virtualabs commented 9 months ago

i guess the version Interface Version : 0258 is unknown as i understood you had to modify for the 0257 in previous messages.

I think you're right and this version is not supported. I pushed a patch into the main branch, can you give it a try and tell me if this fixes your issue ?

lostpixel commented 9 months ago

What a quick response ! Regarding the -i it's seems flawless and the micro:bit seems stable. No more sad face ^^

─# btlejack -i
BtleJack version 2.1

[i] Flashing /media/kali/MICROBIT with btlejack-fw-v2.hex ...
[i] Flashed 1 devices

But i'm in a very dense environement in bluetooth device , i should see a lot a things and i 've currently no "output" with : 

└─# btlejack -s -5 -v
BtleJack version 2.1

[i] Enumerating existing connections ...
^C[i] Quitting

or 

└─#  btlejack -d /dev/ttyACM0 -c any
BtleJack version 2.1

[i] Detected sniffers:
 > Sniffer #0: version 2.1
^C[i] Quitting

i've waiting arroung 2-3 min for each test Does the "> Sniffer #0: version 2.1" confime that he acctually use the micro:bit ? The orange led is blinking when i start de command but no longer after. (never blinking like data is processed)

I'm playing with one currently even three is recommanded , how much should i be patient and make test before i could see somethings ? I'm encline to buy two more if the first one give some result.

When i retry to : 

─# btlejack -i 
BtleJack version 2.1

[i] No sniffer found, make sure all your devices are mounted as mass storage devices before flashing.

Is it normal ? Shouldn't do re flash ?

virtualabs commented 9 months ago

But i'm in a very dense environement in bluetooth device , i should see a lot a things and i 've currently no "output"

Well, Micro:Bit v2.x hardware is a bit different from version 1, and the trick used to turn a nRF51822 (SoC used in version 1) into a sniffer does not work properly on nRF52832 (SoC used in version 2). I still need to fix this.

Does the "> Sniffer #0: version 2.1" confime that he acctually use the micro:bit ?

It means your Micro:Bit is correctly detected, absolutely !

If you use only one sniffer it may miss the connection request when a connection is started, but it should at least catch one at some point. What device are you trying to sniff ? Are you sure it is using Bluetooth Low Energy ?

The last issue you mention looks like you plugged in your Micro:Bit while pressing the reset button, thus enabling Micro:Bit's flashing mode.

lostpixel commented 9 months ago

@virtualabs Hi , So it never worked for me with the the board version : V2.00 History of testing for record purpose :

I beleive that the .hex is deleted because there is some sort of checksum calculation and other check that if the .hex in'st conform he's simply deleted. I guess as a larning board they make it to avoid any human error to brick it.

Fun fact , at start , (0258) with i use fixed value like this : btlejack -d /dev/ttyACM0 -f 0x8e89bed6 -k 0x18a449 , i had short a reponse like that : 

└─#` btlejack -d /dev/ttyACM0 -f 0x8e89bed6  -v           
BtleJack version 2.1

[i] Using cached parameters (created on 2023-10-06 12:11:53)
[i] Detected sniffers:
 > Sniffer #0: fw version 2.1

[i] Synchronizing with connection 0x8e89bed6 ...
✓ CRCInit: 0x18a449
\ Determining channel map@> b'_'
- Determining channel map^C[i] Quitting

I had to rush command before the delete of the .hex but that the farthest i could reach has result. i finaly founded some sell of the micro:bit V1 at a decent price , i will try it.

banditRanit commented 5 months ago

Hello @virtualabs, Having couple of doubts regarding the tool

  1. Can we use Micro:Bit v2.0 now? Is the firmware working?
  2. Is there any way to use nRF52840 dongle in place of Micro:Bit?
  3. In which Micro:Bit dongle BtleJack works perfectly? Is this the correct one? please confirm.
31415pi commented 2 months ago

Microbit:BBC V2; Works up until Determining channel map. Was poking into the code and saw the packet structure. Using -5 or not, LANG=c or not, it dies at chan map. Might dump the packets and peep it later. 

λ btlejack -i
BtleJack version 2.1

[i] Flashing /run/media/HOSTNAME/MICROBIT with btlejack-fw-v2.hex ...
[i] Flashing /run/media/HOSTNAME/MICROBIT1 with btlejack-fw-v2.hex ...
[i] Flashing /run/media/HOSTNAME/MICROBIT2 with btlejack-fw-v2.hex ...
[i] Flashed 3 devices

 ╭─HOSTNAME@USERNAME in ~/Documents/BT/BTLEJACK via  v3.11.8 (BTLEJACK) took 27s
 🕙 15:23:18
[🔴] × btlejack -5 -s
BtleJack version 2.1

[i] Enumerating existing connections ...
[ - 57 dBm] 0xAAFOUND | pkts: 1
[ - 54 dBm] 0xAAFOUND | pkts: 2
[ - 54 dBm] 0xAAFOUND | pkts: 3
[ - 54 dBm] 0xAAFOUND | pkts: 4
[ - 50 dBm] 0xAAFOUND | pkts: 5
[ - 54 dBm] 0xAAFOUND | pkts: 6
[ - 58 dBm] 0xAAFOUND | pkts: 7
[ - 57 dBm] 0xAAFOUND | pkts: 8
[ - 53 dBm] 0xAAFOUND | pkts: 9
[ - 51 dBm] 0xAAFOUND | pkts: 10
[ - 57 dBm] 0xAAFOUND | pkts: 11
[ - 57 dBm] 0xAAFOUND | pkts: 12
^C[i] Quitting

 ╭─HOSTNAME@USERNAME in ~/Documents/BT/BTLEJACK via  v3.11.8 (BTLEJACK) took 68ms
 🕙 15:28:38
 ╰─λ btlejack -5 -f 0xAAFOUND
BtleJack version 2.1

[i] Detected sniffers:
 > Sniffer #0: fw version 2.1
 > Sniffer #1: fw version 2.1
 > Sniffer #2: fw version 2.1

[i] Synchronizing with connection 0xAAFOUND ...
✓ CRCInit = 0xCRCInitFOUND
\ Determining channel map^C[i] Quitting

UPDATE: Forgot about -v! Oops, unfortunately it is result same as this issue

λ LANG=c btlejack -v -5 -f 0xAAFOUND -j
BtleJack version 2.1

[i] Using cached parameters (created on 2024-04-17 16:03:16)
[i] Detected sniffers:
 > Sniffer #0: fw version 2.1
 > Sniffer #1: fw version 2.1
 > Sniffer #2: fw version 2.1

[i] Synchronizing with connection 0xAAFOUND ...
✓ CRCInit: 0xCRCInitFOUND
/ Determining channel map@> b'_'
@> b'_'
@> b'_'
- Determining channel map@> b'_'
\ Determining channel map@> b'gcd: 0'
/ Determining channel map@> b'_'
/ Determining channel map@> b'gcd: 0'
\ Determining channel map@> b'_'
/ Determining channel map^C[i] Quitting