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

[embl3m]

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).

[embl3m]

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.

[Kagi4]

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

[embl3m]

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

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

[lostpixel]

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.rx_buffer += 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]

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]

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]

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]

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

• i started with Interface Version: 0258

• btlejack -i after change of code was able to copy the .hex on the micro:bit but after some secondes ( 20 maybe) he erase it.

• i tried multiple things to make it compatible
  -> transfome python code to javascript then export to .hex using this interface : https://makecode.microbit.org/#editor
  -> copy "stupidly" the code to export in .hex using this interface https://python.microbit.org/v/3
  -> using multiple "way" to upload the .hex (webusb [recommanded] , copy from winodws , copy from linux , ect ... )
  -> downgrade to 0258 to 0255 ( seems like the .hex disapear way faster now xD )

• i had multiple fail.txt who appeared like :

error: The application image is not compatible with the target.
type: user

or

error: The transfer timed out.
type: transient, user 

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]

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]

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