Question: Micro:Bit v2 support?

[whoot]

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]

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]

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

[whoot]

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]

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

[whoot]

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

[virtualabs]

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:

• is it still vulnerable to Travis Goodspeed's hack based on an undocumented address length register value ? If not, it won't be able to sniff active connections :(
• is the internals of its RF peripheral quite the same as the one in nRF51822 ? If not, it could imply some hard times rewriting/testing code that handles sniffing and other attacks

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]

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]

Any news regarding the Micro:Bit v2 support?

[wdebbaut]

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

[virtualabs]

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

[wdebbaut]

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]

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]

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

Could you also look into support for the:

• nRF52833 DK - it's the one that v2 uses.

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]

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

[virtualabs]

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]

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]

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]

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]

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]

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]

@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]

It is Interface Version: 0257

[virtualabs]

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]

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]

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

[Kagi4]

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]

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]

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]

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]

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.