Hardware hacking on less on sec

Reversing the FT100 BLE Fitness Bracelet

Thu, 12 Mar 2026 09:00:00 +0200

The device

The device is called FT100 Fitness Bracelet by TWENTYFIVESEVEN and it offers some basic features such as heart rate and blood pressure monitoring, step count, music control, notifications handling, a find device functionality, and OTA firmware update.

It features a display and a soft touch button, and it is possible to use the manufacturer’s app to configure the device via BLE connection.


FT100 Fitness Bracelet

The watch features a PHY6202 MCU, 512Kb of ROM, 16Kb of RAM and a whopping 50mAh battery (that I promptly swapped with an external power supply as it was giving me troubles).

The companion app Lefun Health allows interaction with device’s functionalities. It offers “data aggregation” features such as recording sport activity or sleep quality. The app itself works ok-ish but it has frequent ads, it often asks for additional permissions and it tries to push to users some unrelated AI services made by Lefun. It’s not my favorite app, but it is good enough to work with.


Lefun App

What I’ll do in this article is try to instrument the android companion app to access BLE traffic between smartphone and our smartwatch to attempt reverse engineering the communication.

Sniffing the BLE traffic with frida

In order to target the functionalities on the FT100 it is necessary to gain visibility of the BLE traffic exchanged between the phone and the bracelet. So we need to work toward that.

To be completely fair, there are multiple ways that could be used to dump the BLE traffic in this exact situation, with android HCI Snoop log being my usual choice. However I’ve been working on mobile applications a lot more recently, I’ve recently checked out this article which uses a similar technique and I figured this project would be a nice way to get practice working with frida, so I decided to go for this way. This method could also come in handy when working on a non-rooted android device as usually there is no access to HCI logs, and a frida gadget could be patched into the apk, bypassing the need for root access.

The first step here would be to perform a static analysis of the apk. Using jadx I decompiled the apk and started digging for clues on the right point to hook into.

During static analysis, the obvious first attempt was to look for and attempt hooking android default functions to handle BLE GATT events in BluetoothGattCallback class. Ideally we would need at least access to onCharacteristicChanged() and onCharacteristicWrite() to intercept characteristic writes and GATT notifications traffic. But simply hooking these functions I was only able to intercept traffic for writes. After further analysis I realized the app was not using the base Android BluetoothGattCallback, but instead some of these functions would be overridden by anonymous classes. So I needed to reliably hook the override implementations used at runtime in order to access incoming data.

The turning point was identifying BluetoothDevice.connectGatt() as the universal entry point for every BLE connection. This method always receives the actual callback instance as an argument. By hooking all overloads of connectGatt() and dynamically extracting the runtime callback class (callback.$className), it became possible to hook the correct implementation of the target functions regardless of anonymous inner classes as observed in jadx.

var BluetoothDevice = Java.use("android.bluetooth.BluetoothDevice");

    var hookedCallbacks = {};

    BluetoothDevice.connectGatt.overloads.forEach(function (overload) {

        overload.implementation = function () {

            logSection("connectGatt intercepted");

            for (var i = 0; i < arguments.length; i++) {
                console.log("arg[" + i + "] = " + arguments[i]);
            }

            // Callback is always argument index 2 in all overloads
            var callback = arguments[2];

            if (callback) {

                var className = callback.$className;
                console.log("[+] Real callback class: " + className);

                hookGattCallback(className);
            }

            return overload.apply(this, arguments);
        };
    });

Then inside the hookGattCallback function each interesting function can be hooked explicitly like this:

if (Callback.onCharacteristicChanged) {
                Callback.onCharacteristicChanged
                    .overload(
                        "android.bluetooth.BluetoothGatt",
                        "android.bluetooth.BluetoothGattCharacteristic"
                    )
                    .implementation = function (gatt, characteristic) {

                        var value = characteristic.getValue();

                        logSection("BLE RX (Notification)");
                        console.log("Device : " + gatt.getDevice().getAddress());
                        console.log("Service: " + characteristic.getService().getUuid());
                        console.log("Char   : " + characteristic.getUuid());
                        console.log("Data   : " + bytesToHex(value));
                        console.log("ASCII  : " + bytesToAscii(value));

                        return this.onCharacteristicChanged(gatt, characteristic);
                    };
            }

With this method it was possible to achieve full visibility over the BLE events including characteristic read and writes, as well as notifications. Now it’s time to analyze the protocol.

GATT traffic overview

We can now check out the extracted data from the frida hooks and having access to GATT level operations, we can start digging into the protocol. Now, if you’ve worked with BLE before you will surely know GATT in more or less details, but if you don’t, feel free to check out this post on solving BLE CTF on esp32 I go through basics there.

For the sake of clarity, let’s explicit that the stack we are working with looks something like this:

App protocol
     ↓
GATT characteristic
     ↓
ATT packets
     ↓
BLE link

For the scope of the article, we may as well just consider App protocol and GATT characteristics.

Picking out a few messages we can start figuring out what’s going on under the hood:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 05 31 01 bf
ASCII  : ..1..

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 05 06 00 a2
ASCII  : .....

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 09 06 00 00 a0 32 14 79 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z.....2.y...........

From these few exchanges we can already tell a few things about the protocol: first off the protocol lives on top of service 000018d0-0000-1000-8000-00805f9b34fb which doesn’t appear to be a standard GATT service.

The app writes on char 00002d01-0000-1000-8000-00805f9b34fb (handle 0x002b) and the BLE notifications from the smart band are received on char 00002d00-0000-1000-8000-00805f9b34fb (handle 0x002e).

We can also see that some commands from the app trigger a response from the device through a BLE notification, and some other don’t.

In order to understand the semantics of the protocol, we need to observe some more traffic. For brevity, char writes by the app will be marked as TX, while BLE notifications from the smartband will be marked with RX.

[TX] AB 05 56 01 8B
[TX] AB 05 E0 01 23
[TX] AB 0A 39 00 01 02 D0 06 40 23
[TX] AB 05 51 00 BB
[TX] AB 05 31 01 BF
[TX] AB 05 06 00 A2
[RX] 5A 09 06 00 00 A0 32 14 79 00 00 00 00 00 00 00 00 00 00 00
[TX] AB 04 00 0C
[RX] 5A 14 00 FF 27 14 F1 50 31 39 02 01 02 32 19 54 4A 44 50 16
[TX] AB 04 03 EE
[RX] 5A 05 03 23 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[TX] AB 04 70 F4
[TX] AB 05 22 00 58
[RX] 5A 07 22 00 1F FF 06 00 00 00 00 00 00 00 00 00 00 00 00 00

Messages are tagged with an header depending on the direction of the communications, char writes from phone to device always have 0xAB header, while notifications have a 0x5A header. Additionally notifications always seem to be padded to 20 bytes (padding with zeros).

The other bytes seem to have a straightforward meaning as well, the second byte is in fact the length of the message, while the third and fourth bytes seem to be command bytes (CMD, SUB-CMD).

Reversing the protocol

Now, we could start black box reversing from these messages, but it would be pretty hard to make progress, both because some messages don’t produce an observable result and because payloads and message sending is out of our control. It would be wise to start somewhere simpler and more controlled.

Find my device

From the app, it is possible to use the find my device functionality to have the smarband buzz three times to help the owner find it. This functionality seems straightforward, so for the time being, we can ignore other messages and we can try to intercept the find my device messages only:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 04 09 90
ASCII  : ....

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 05 09 01 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z...................

We see that the smartphone app writes payload ab 04 09 90 on the target service characteristic, it triggers the find my device behavior on the smartband.

Surely enough, if we try on our own, connect to the smartwatch and write on characteristic 00002d01-0000-1000-8000-00805f9b34fb the value ab 04 09 90 we can trigger device vibration.

This can be done quite simply with gatttool -b [MAC] --char-write-req -a 0x002c -n ab040990. (gatttool is technically deprecated, but I was having issues with pairing using bluetoothctl, so I figured it would be alright for quick testing).

NOTE: I wish I had a GIF of the device reacting to the command, but as I’m writing this article I just broke the device screen. My bad.

This was fun, but let’s dig deeper.

Notification handling

We can move on and reverse engineer how smartphone notifications are forwarded to the device. We can trigger android notifications on the smartphone and have the Lefun app relay the notification to the smartband to observe the payloads.

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 12 17 14 01 01 01 74 65 73 74 3a 20 74 65 73 74 67
ASCII  : .......test: testg

For this test, the notification is a whatsapp notification and the text shown on the screen is: test: test. We can see from the logs of our instrumented app that we see ab121714010101746573743a207465737467 payload written to the characteristic with handle 0x2c. By converting it in ASCII we can see that the text payload is shared in cleartext as 746573743a2074657374 is the hex for ASCII test: test. Last byte looks suspicious and I’m sure it’s some kind of CRC, but we will figure this out later.

Based on what we know, we can make an educated guess and suppose that the base message frame looks something like this:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	In case it is a `0x5A` message, it mirrors the command byte
n..m	Payload	Command payload (optional)
last	CRC	?

This fits both the notification message format and the find device message format.

Now, we can replay our notification countless time, but can we modify it? If we change the ASCII payload, we see that the smart band doesn’t react to the message anymore even adjusting the length byte. And just like that, now it’s the perfect time to figure out the CRC.

So we attempt using reveng to understand which CRC we are working with and surely enough it gives us a result:

./reveng -w 8 -s ab121714010101746573743a207465737467

width=8 poly=0x31 init=0x00 refin=true refout=true xorout=0x00 check=0xa1 residue=0x00 name="CRC-8/MAXIM-DOW"

Now, it is possible to implement the function to calculate the CRC and we can start creating valid messages.

Minding the CRC and the length byte, we can generate our own notifications commands to send to the device.


Custom notification

Only one last step is missing for full notification handling as we know the longest payload we can send on the exchanged MTU is 20 bytes. Now, if we remove, header, length, command ID and CRC bytes we are left with 16 bytes for the notification text, which is not much… Also we kind of figured out the packet format, but it doesn’t account for every byte in notification messages. It would make sense for there to be one or more bytes to handle some type of data fragmentation, to handle payloads longer than 16 bytes.

So I’ve sent a dozen of notifications to the smartwatch using the phone and I was able to figure the notification message format out almost entirely: As anticipated we confirm we have a fragmentation mechanism, in particular 2 extra bytes that specify the total fragment number and the current fragment. Then by experimenting I figured out two more bytes that are part of the notification message format which I called sub-command and extra bytes.


Fragmented custom notification

The sub-command byte specifies the notification icon that will be shown on the smart band screen. By creating and sending notification messages to the device, it was possible to compile a list of sub-commands and their respective notification type.

Code	Icon
1	Call
2/3	SMS
4	Snapchat
5/6/7	SMS
8	SMS (style 2)
16/17	Facebook
18	Twitter
19	LinkedIn
20	WhatsApp
21	Line
22	Talk
23	Facebook messenger
24	Instagram
25	WhatsApp Business

Some icons appear on the FT100 for multiple sub-command values. This might be due to the fact that not all the supported notification types have a dedicated icon, but I’m just guessing.

To this day I’m not sure what the extra byte is there for. Sometimes it gets printed as a normal character, sometimes it doesn’t.

The notification message format is completely reconstructed as follow:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	`0x17`
3	Sub-command
4	Total Fragments	Total number of fragment for messages longer than 20 bytes
5	Fragment Index
6	Extra
n..m	Payload	ASCII data
last	CRC8	CRC-8/MAXIM-DOW

Finally, whenever I see fragmentation I have to try and mess with it a little bit and I noticed a weird behavior. Fragment indexes are 1 based, and the device starts buffering fragments at index 1 as expected, however, if a second message sets fragment index = 1, the first chunk of buffered message gets overwritten. The funny part is that fragment 1 is the only one that shows this behavior. Fragments with indexes greater than 1 will be buffered in order of arrival (and not depending on the frame number) until one message with fragment index = total fragments is written on the target characteristic, again not dependent on the actual number of frames received.

Weather data push

Just because there’s way too much stuff to ignore it all, I wanted to reverse engineer another message type: weather data push. I’m not sure if this happens periodically while using the app, but it is possible to trigger a manual weather data push in the app, so it was kind of easy to experiment with this feature as well.

For the first time, the menu item for this functionality appears on the device only if a weather push has been performed before.

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 08 2a 00 08 0f 05 28
ASCII  : . . . . . . . . (

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE RX (Notification)
======================================
Device : C0:00:A1:A2:1F:04
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d00-0000-1000-8000-00805f9b34fb
Data   : 5a 05 2a 01 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ASCII  : Z...................

Again, I’ve sent a few of these messages and figured out the packet format:

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Length	Length of the message
2	Command ID	`0x2A`
3	Sub-command
4	Extra
5	Max Temp	Maximum temperature value
6	Min Temp	Minimum temperature value
last	CRC8	CRC-8/MAXIM-DOW

Sub-command values in this case change the weather icon shown in the weather menu. Values in this case are:

Code	Icon
0	Sun
1	Cloud + Sun
2	Rain
3	Snow
4	Cloud

Any other value will default to cloud icon.

Here too, no image of the smartwatch because I broke the screen, it sucks I know.

Watchface data push

I meant to keep the analysis of this feature for a part 2 of the article, but as the screen is now broken I figured it was worth wrapping up what I have done to this point.

After identifying several control commands, I wanted to understand how the companion app uploads custom watchfaces to the device. Capturing a full update revealed that the process consists of two distinct phases: a short control exchange that prepares the watch for the transfer, followed by a large stream of fragmented image data.

The actual watchface image is transmitted as a sequence of packets written on the same BLE characteristic used for other commands. Unlike the notification and weather packets analyzed earlier, these frames do not include a length byte. Instead, they are simple fragments of raw pixel data indexed with a 16-bit counter. The start of image stream is probably set up by previous communications.

Typical fragments look like this:

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 00 79 ce 00 00 08 42 c7 39 e7 39 c7 39 08 42 c7 39
ASCII  : .,..y....B.9.9.9.B.9

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 01 c7 39 e7 39 e7 39 a6 31 e8 41 a6 31 c7 39 e7 39
ASCII  : .,...9.9.9.1.A.1.9.9

======================================
BLE WRITE ACK
======================================
Status : 0

======================================
BLE WRITE (TX)
======================================
Service: 000018d0-0000-1000-8000-00805f9b34fb
Char   : 00002d01-0000-1000-8000-00805f9b34fb
Data   : ab 2c 00 02 c7 39 e7 39 c7 39 08 42 21 08 e3 18 86 31 04 21
ASCII  : .,...9.9.9.B!....1.!

======================================
BLE WRITE ACK
======================================
Status : 0

======================================

By analyzing multiple captures it becomes clear that these packets implement a simple fragmentation scheme.

Offset	Field	Note
0	Header	`0xAB` (phone to device)
1	Command ID	`0x2C`
2	Index (MSB)	Fragment index high byte
3	Index (LSB)	Fragment index low byte
4..n	Payload	Raw image data
last	CRC8	CRC-8/MAXIM-DOW

The index field increments sequentially for each fragment, allowing the watch to reconstruct the full image stream.

Once all fragments are concatenated in order, the resulting byte stream contains nothing but pixel data. Now, it was easy to determine how images were sent, but it took a lot of fiddling to make sense of the data.

There are still two unknowns:

Data format
Image size

What I did was use an “easy to debug with” image, I decided to go for a numbered chess board.

I then captured the traffic when performing the upload operation, wrote a small parser that extracts 0xAB 0x2C packets from the BLE dump, sorts them by fragment index, and rebuilds the binary stream. I then tried using different image encoding formats to interpret the payload. I was eventually able to determine that the correct one was RGB565. I focused on common color encodings used in embedded displays, and the payload started to make sense when decoded this way.

Finding out the image size took longer to figure out as at first it wasn’t clear if or how metadata was included in the extracted binary blob. After a few attempts and a couple of hours spent staring at badly distorted images, it was possible to understand that the size is 80 x 160 pixel.


Badly reconstructed image

The correctly extracted watchface image looks like this:


Reconstructed image

This fragmentation approach is fairly typical for BLE devices: instead of relying on large MTU sizes, the application simply slices the image into fixed-size chunks and transmits them sequentially. The watch then reassembles the data internally before updating the displayed watchface.

Now that the format of the watchface stream is understood, the next logical step would be to reproduce the process in reverse, however, I didn’t get to achieve this as I broke the watch.

Response message format

While we are at it we might as well formalize the response format, which looks something like this:

Offset	Field	Note
0	Header	`0x5A` (device to phone)
1	Length	Length of the message
2	Command ID	Reflected from the message the device is responding to
n..m	Payload
last	CRC8	CRC-8/MAXIM-DOW

With the payload being either a status code (0x01 positive outcome, 0x00 negative outcome) or a returned value.

Conclusions

As I’m finishing this article, I’ve found a bunch of interesting classes that could help for future reversing efforts, namely com.tjd.lefun.sdk.ble.BleWatchServiceImpl and com.tjd.lefun.sdk.ble.WristbandCommandByte these classes explain quite well message formats and what operations the SDK supports, however many commands are not implemented in the app or in the smartband as I’ve forging messages for a few of those and got no response from the smartband.


App code handling notifications

This would have saved me some frustration reversing the protocol, but it is what it is. It might be useful for future work.

All relevant scripts and resources are available here: https://github.com/0xless/FT100_fitness_bracelet_reversing

nRF51 RBPCONF bypass for firmware dumping

Thu, 04 Sep 2025 21:41:00 +0200

A while ago I read about the firmware dumping technique proposed by Include Security to bypass RBPCONF (Readback Protection) on nRF51 family MCUs. Recently I could spend some time attempting to replicate the effects of their research.

The nRF51 series is Nordic Semiconductor’s family of low-power SoCs built around an ARM Cortex-M0. If you’ve played with Bluetooth Low Energy (BLE) gadgets from a few years back such as beacons, smart locks or fitness trackers there’s a good chance they had an nRF51 inside.

This technique is significant because retrieving the firmware is almost always the first step before any meaningful reverse engineering. Once the binary is available, an attacker can perform static or dynamic analysis to uncover hardcoded secrets, or look for exploitable bugs that could compromise the security of the system. For connected products such as smart locks, wearables, and IoT sensors, the impact of such access can be substantial.

What makes this bypass interesting is its non-invasive nature. Other approaches often involve some type of glitching, manipulating reset lines, or even destructive decapsulation, all of which risk damaging the device and require specialized equipment. In this case, the attack relies only on software manipulation through standard debugging interfaces. The target remains fully functional while its memory is exfiltrated, making the method practical and appealing.

So I decided to visit Aliexpress, bought two of the cheapest board I could find featuring an nRF51822 and went to work.

nRF51 security in a nutshell

As numerous other MCUs, the nRF51 family offers some way to prevent final users of the device from reading the flash memory of the MCU and recover the firmware. Much of the device’s security posture is controlled through a set of non-volatile registers called User Information Configuration Registers (UICR) located at address 0x10001000. This registers are what allows for enabling protections on this devices family.


UICR overview

Registers inside UICR we are going to focus onto are: CLENR0 and RBPCONF.

Register CLENR0 is what allows dividing code flash in two areas: Code Region 0 (CR0) and Code Region 1 (CR1). CR0 always starts at 0x00000000, and its size is defined by the CLENR0 register. Everything above that boundary falls into CR1. If CLENR0 is left untouched (0xFFFFFFFF), the whole flash is simply treated as CR1.

There are a few differences between CR0 and CR1:

Code running in CR0 cannot be modified by code running in CR1.
Pages of CR0 cannot be erased, CR0 is erasable only via chip-wide wipe (ERASEALL)

Generally speaking, this renders CR0 a more secure memory area suitable for critical software components or sensitive data storage.

Understanding RBPCONF

An nRF51 device can be configured with three different security configurations based on RBPCONF: no protection, PR0 protection and PALL protection.


RBCONF overview

PR0 register allows for locking CR0 memory area. This protection, when enabled, prevents firmware running from CR1 from reading CR0 memory as well as locking the read-back on CR0 area from SWD debugger.

The nRF51 also exposes the PALL protection, which locks down all code memory (both CR0 and CR1). Once PALL is enabled, no external debugger reads are possible. The only way to disable this protection is to perform a full chip erase (ERASEALL), which wipes both application and configuration data, protecting the firmware from exfiltration. The PALL mechanism is intended as “production lock” and is the strongest protection mechanism available in these MCUs.

One security measure other SoCs offer, is to completely disable debugger accesses. However this is not a possibility with the nRF51 and even though the debugger won’t be able to access flash memory directly, this poses a risk to the device and it is exactly the weakness we are abusing to access the whole memory.

Exploiting RBPCONF

The protection mechanisms in place allow only code already present in the CR0 to read flash memory.

External debuggers are blocked from issuing flash memory reads directly. So, in order to extract data from the protected memory we will abuse the execution environment against itself. The register state, unlike the flash, remains observable and editable through the debugger interface.

The RBPCONF bypass is based on the fact that, being able to control CPU registers, it would be possible to halt and single step the CPU executing the firmware and change the behavior of instructions by altering generic purpose CPU registers values. This way it is possible to hijack instructions already residing in CR0 memory area. With this knowledge available it’s just a matter of finding a load instruction that will take an address from one of the registers and puts the value from that address back to one of the registers.

Nordic’s model assumes that isolating CR0 and requiring ERASEALL for modification is sufficient to protect sensitive firmware. However, the lack of debugger lockout means these guarantees can be bypassed.

The Setup

Hardware:

nRF51822 dev board
SEGGER J-Link
Linux host machine

Software:

SEGGER Embedded Studio
OpenOCD
nRF Command Line Tools (not strictly required, but handy for enabling protections & restoring a locked device)
arm-none-eabi-gdb + Python for automation

The board I’m using is this one:


nRF51822 dev board

Fortunately SWD pins (SWDIO, SWDCLK) are exposed and it was possible to attempt opening a debug interface straight away. However pin distancing was not compatible with any breakout or breadboard I had at home, so I resorted to using some integrated circuit hooks and these ended up working just as fine.


Dev board connected to debugger

Once board’s pins VCC, GND, SWDIO and SWDCLK are connected to J-Link’s corresponding pins it was possible to obtain SWD debug access both with J-Link suite tools and with OpenOCD using the commands:

openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -c "transport select swd" -f /usr/share/openocd/scripts/target/nrf51.cfg

JLinkGDBServer -device nrf51822_XXAA -if SWD

Personally I’m more keen on using OpenOCD for this exploitation specifically because J-Link suite wouldn’t allow opening a GDB connection to nRF51 if the PALL protection is enabled.

Once the SWD connection is achieved, we need to flash the device with a custom firmware, to do so I used SEGGER Embedded Studio as it was the fastest way to setup the SDK and toolchain for our target device.

For this demo a firmware containing a single printf("SECRET") is used and the objective will be to confirm whether the string can still be retrieved with PALL protection enabled.


Dummy firmware

Once the firmware is flashed, we can perform a few tests without protection enabled in order to better understand the differences in the behavior of the debugger when the protection is OFF and when it is ON.

With the GDB server running, we can attempt connecting and reading some memory:


Memory read demo - no protection

As it is possible to see, bytes are correctly read back from flash memory. In addition notice how we also read 0xE000ED00 (CPUID) this register will always be populated with 0x410CC200 on nRF51 and the value is readable when PALL protection is in place as well, rendering it a good reference value for future experiments.

At this point we can enable the PALL protection with command nrfjprog --rbp ALL, reboot the target device and attempt performing the same operations again.


Memory read demo - with protection

We note how the same addresses come back as 0x00000000 when read back.

Dumping the firmware

The exploitation of the vulnerability goes through 2 steps: locating a load instruction and abusing it to read protected memory.

To achieve the first, it is possible to use GDB to set each register to address 0xE000ED00 since it contains a known value. If the instruction PC is pointing is a load, we should find the expected value (0x410CC200) in one of the registers.

We will simply need to issue commands:

set $r0=$r1=$r2=$r3=$r4=$r5=$r6=$r7=$r8=$r9=$r10=$r11=$r12=0xE000ED00
stepi
info registers

And we will monitor the output of info registers to see if any of the register gets populated with the expected value.

That’s exactly what happens after a few iterations of this:


Load instruction found

We can see that after the execution of instruction at PC=0x82 we have our expected value in register r0. Once the load instruction is located, it is necessary to attempt reading bytes from the protected memory.

So now we populate registers with value 0x00000000 and attempt reading that word.


Value read from CR0

and as expected we are able to read the first byte of protected memory.

Now it’s time to render the exploit practical and to automate the firmware extraction and we can achieve this in several ways, I’ve decided to simply script the interaction with GDB commands. Depending on the exact MCU you’re working with, you may encounter different flash sizes. In this case we are working with an nRF51822_XXAA which is the most commonly available variant of nRF51822 around and features 256kB of flash memory.

The extraction script will look something like this:

set $i = 0
set $end = 0x3FFFF
while $i <= $end
  set $pc=0x82

  set $r0=$r1=$r2=$r3=$r4=$r5=$r6=$r7=$r8=$r9=$r10=$r11=$r12=$i
  stepi

  printf "0x%08x\n", $r0
  set $i=$i+4
end

and the output on the terminal when the script is executed looks like this:


Scripted memory read

After letting it run the script will have gone through the entire code space. A simple parser will then be used to cleanup the retrieved data and rebuild the binary file.

For ease of use I’ve decided to write a more usable script capable of automatically detecting the load function, dump the firmware and reassemble it to generate a binary output.

You can find it at: https://github.com/0xless/nRF51-RBPCONF-Bypass

Once the script has finished running, in under 54 minutes, we get firmware.bin file:


Dump completed in 54 minutes

And performing xxd on the extracted firmware allow us to recover out SECRET value.


Secret value recovered from firmware

This proves the functioning of the exploit and the practicality of this attack.

The PoC script developed for this attack is far from perfect, it takes a lot of time to execute and the GDB + Python interaction is a bit “hacky”. A huge improvement it is possible to make is to aim to find instructions that load more bytes of flash memory to registers; an example would be LDMIA Rn!, {Rlist} that allow up to 32 bytes loads in a single step. When reading the memory, it is easy to evaluate the OPCODE of the instruction just read, if it’s a LDMIA instruction, then we can edit the PC register value to jump there and attempt exfiltrating memory at higher speed.

I’ve attempted sketching this using GDB scripting, but as the complexity of the project increased I realized this scripting language was not the tool for the job. For future developments I want to rewrite the whole script in python using library pyswd which looks promising in handling SWD interactions directly via python, however it is compatible with ST-Link debuggers only (which I don’t own).

Conclusions

The nRF51’s RBPCONF was designed to keep firmware safe, but not allowing final users to disable debugger access weakens the model. Even under PALL protection, careful register manipulation and instruction reuse make full extraction possible with modest tools.

In this post we demonstrated how it is possible to do so and walked all the steps needed to discover the issue and replicate the attack.

Attacking RKE: How to hack a car open

Fri, 30 Dec 2022 22:30:14 +0100

I’ve always found cybersecurity to be more interesting when implications reflect in the “real world” and this is the reason hacking physical devices is fun to me. Well, it turns out that the more the hack is controversial, the funnier it is to carry out! For this reason I got into remote controlled devices hacking, and in particular into car remotes hacking. A while ago I got all the hardware needed to attempt attacking these devices, so I could finally attempt some attacks.

Analysis of a Remote Control

Thu, 15 Jul 2021 16:45:40 +0200

A couple of days ago I found some old remote controls around the house and decided it was time to take out my old RTL-SDR and put it to good use. In this article I will describe step-by-step my experience with studying, reversing and understanding these devices.

In particular the analysis will comprehend:

Analysis of the board
Analysis of the behavior
Analysis of the signal

This will allow to have a complete overview of the remotes.


Remote to analyze

Board analysis

The first thing I did was to operate the remote: of course whenever the yellow button was pressed, the led on its side would light up signaling that everything was working fine. The device could use different communication methods, but since there is no visible IR LED, it is possible to assume that the device works via radio signals.

The very next step was to open up the remote and visually inspect the board.

Inside the plastic casing I found this simple PCB.


PCB board

At first glance it’s possible to notice that there’s an antenna, a crystal oscillator, a trimmer an integrated circuit and of course led, button and battery. As expected, there’s everything needed for a radio transmitter to work.


30.875MHz oscillator

Looking at the components further it’s possible to gather insights about how the device works. In particular the oscillator gives away that the device probably operates at 30.875MHz - this isn’t what I was expecting.

In my country, Short Range Devices should work in the ranges:

27,5000 – 28,0000 MHz
29,7000 – 30,0050 MHz

Or, for general purpose applications they can work in the ranges:

433,000 – 435,0000 MHz (devices without a specific use)
862,0000 – 876,0000 MHz (devices without a specific use, wireless audio, alarm systems, social alarms, radio microphones, and RFID devices)

Radio transmitters are not forced to adopt the crystal oscillator frequency as working frequency, in fact it’s not uncommon that they use a multiple of such frequency instead. Said that, at this point it’s only a guess, but even if it’s not in the expected ranges, it’s possible that the working frequency of the remote would be around 30.875MHz.


10-position DIP switch

We can also see that there’s a 10-position DIP switch.

The first pin (1) of the DIP switch has written “ON” on top of it, meaning that the switch closes the circuit when the lever is in the “high” position. This component suggests us that the remote sends at least 10 bits of data. I say at least, because it’s possible that the device sends preamble/ending bits and/or checksum or parity bits.

Also, given the position of the switches, it’s possible to assume that the code sent by the remote would either be 0001000110 or 1110111001.


ITF CIE9101 Integrated Circuit

On the back of the PCB there’s the ITF CIE9101 integrated circuit. Sadly I wasn’t able to find any datasheets or information about this component (hit me up if you know something about it!).

Inspecting the PCB it’s possible to see that this device is connected to the DIP switch, to the oscillator and to the antenna. We can make an educated guess and say that this IC is probably responsible for the radio transmission (in future it would be worth reverse engineering this IC to better understand how this device work).

Behavior analysis

To validate the hypothesis of the device being a radio transmitter, it’s fundamental to try to intercept and visualize the communication.

The goal now is to find the transmitted signal. There is a limited set of possible frequency ranges, but it’s not always easy to blindly spot the signal you’re looking for, especially in areas in which similar devices are widely employed (think of remote car keys, AC remotes, radio weather stations and so on).

To figure out the frequency and to work with the raw radio signal I used a Silver dongle RTL-SDR and gqrx.


RTL-SDR and Antenna

Once gqrx was open, it was necessary to spot the correct frequency. Since there is a 30.875MHz crystal oscillator in the remote, that was the first frequency I checked. And luckily the signal was right there. Well, for this remote in particular it was at 30.889MHz, but at least we got the working frequency.

NOTE: I could work with 3 of these remotes, and each one was using a slightly different frequency, that’s why it was possible to find the signal at 30.889MHz and not exactly at 30.875MHz. This can depend on a number of factors and it’s completely normal.


Signal interception

Now it’s time to analyze the signal.

Signal analysis

What I did at this point was to record the signal in gqrx to analyze it. Opening the signal in audacity shows the recorded waveform.


Signal waveform

We can see noise at the beginning and at the end of the recording, while the center part represent the communication.

It’s possible to notice immediately that there are numerous spikes, this is due to the fact that I kept the button pressed for a few seconds while recording. Visually it’s possible to say that the spikes are identical, so our scope is limited to understanding what one of these spikes represent.

Now we need to zoom in on one spike to try and decode the actual digital data.


Zoomed waveform

Of course it’s a digital communication and It’s now clear that we are dealing with Pulse Width Modulation (PWM). If we look closely at the signal, we can see that there are “short” and “long” pulses. Those represent either 1s or 0s depending on the protocol shared by the remote and the receiver.

Counting the bits reveals that that’s more than a simple 10 bit communication. In fact, we are dealing with 14 bits. If we compare the signal to the position of the switches in the remote, we see that the pattern matches, with the exception of the last 4 bits. These bits (either 0000 or 1111) are trailing bits, needed to signal the end of the communication.

To prove that the signal actually corresponds to the one encoded by the switch + 4 trailing bits, I’m using rtl_433 to read and decode the signal. So we run rtl_433 -f 30888000 -A and we get this output:

Attempting demodulation... short_width: 748, long_width: 1516, reset_limit: 5420, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=748,l=1516,r=5420,g=1556,t=307,y=0'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 6 
[00] {14} ee 40     : 11101110 010000
[01] {14} ee 40     : 11101110 010000
[02] {14} ee 40     : 11101110 010000
[03] {14} ee 40     : 11101110 010000
[04] {14} ee 40     : 11101110 010000

And we confirm that the signal uses a PWM modulation and is in fact 1110111001 followed by 0000.

To exclude the possibility that the last 4 bits are parity bits, we need to try other configurations in the remote and analyze the signal. I proceeded to do so and one-by-one I lifted the switches corresponding to the 0s in the signal to see what would change in the transmitted bits.

Changing bit 9 from 0 to 1 produced the following signal:

[00] {14} ee c0     : 11101110 110000
[01] {14} ee c0     : 11101110 110000
[02] {14} ee c0     : 11101110 110000
[03] {14} ee c0     : 11101110 110000
[04] {14} ee c0     : 11101110 110000
[05] {14} ee c0     : 11101110 110000

Similarly, changing bit 8, produced this signal:

[00] {14} ef c0     : 11101111 110000
[01] {14} ef c0     : 11101111 110000
[02] {14} ef c0     : 11101111 110000
[03] {14} ef c0     : 11101111 110000
[04] {14} ef c0     : 11101111 110000
[05] {14} ef c0     : 11101111 110000

Finally I changed bit 4 and I decoded signal was:

[00] {14} ff c0     : 11111111 110000
[01] {14} ff c0     : 11111111 110000
[02] {14} ff c0     : 11111111 110000
[03] {14} ff c0     : 11111111 110000
[04] {14} ff c0     : 11111111 110000
[05] {14} ff c0     : 11111111 110000

As I suspected the last 4 bits don’t change even if the signal changes. This means that they are simple trailing bits and not parity bits or a form of checksum.

Conclusions

After the analysis, everything about how this board operates is known. Since this device was pretty old I wasn’t expecting behaviors any more complex that the ones we observed.

I was left with a deeper understanding on radio communications, in particular of the concept of modulations. This was in fact the first time I was confronted with the PWM modulation in a real life scenario. Decoding these signals both visually and using specialized software allowed me to learn new tools I’ll be using for future experiments.

Cloning RFID tags for fun and profit

Tue, 20 Apr 2021 16:27:00 +0200

RFID tags are a technology commonly used but not limited to industrial purposes. These systems are in fact used every day as public transport passes, as security token in access control systems or as a digital “bar code” in shops. Given the diffusion these tags have, it’s important to understand how they work and the security implication of their use.

Radio-frequency identification (RFID) uses electromagnetic fields to automatically identify and track tags attached to objects.
An RFID system consists of a tiny radio transponder, a radio receiver and transmitter. When triggered by an electromagnetic interrogation pulse from a nearby RFID reader device, the tag transmits digital data, back to the reader. - Wikipedia


RFID tools

What’s RFID?

RFID is a set of standards and technologies because it includes multiple frequency ranges such as:

LF: 120–150 kHz
HF: 13.56 MHz
UHF: 433 MHz
UHF: 865–868 MHz (Europe) 902–928 MHz (North America)
microwave: 2450–5800 MHz
microwave: 3.1–10 GHz

In practice, only tags operating in the LF range are commonly called RFID tags while tags operating in the HF range are called NFC tags.
The rest are radio technologies not limited to the near field use (i.e. bluetooth).

There’s a big difference between RFID and NFC tags and it hides in the specifications. They operate on different frequencies, use different protocols, offer different features and have different uses. Some RFID devices can be compatible with NFC readers, but that doesn’t mean that they strictly follow the NFC specs. Further considerations on the difference between these technologies are out of the scope of this article, but it’s important not to confuse the two.

LF tags operate in the 120–150 kHz range, but the most commonly used frequencies are 125kHz for access control tags and 134kHz for uses like pet chips. Other frequencies can be used but the vast majority of tags use either 125kHz or 134kHz. Such low frequencies can limit the data transmission speed.

RFID LF tags can be passive. This means that the tag is powered and interrogated by the reader. Or active, meaning that the tag is powered with a battery and that it continuously broadcasts data. While active tags are used, they often have specific purposes. This article will focus on RFID LF passive tags since it’s the most common variant found in everyday life.

RFID LF tags have poor transmission speed but are incredibly cheap to produce. Due to this, they are so widely employed where speed is not fundamental. The reading distance of LF tags is usually better compared to HF reading distance. In fact, LF is referred as a vicinity technology, while HF is generally called a proximity technology.

Industrial uses aside, one of the main uses of these tags is as access control tokens. It’s common to see these tags in form of badges or key fobs, and these can be used to access homes, offices or critical infrastructures.

There are numerous models of RFID LF tags each with it’s specific features and peculiarities, but the use as a security token is not ideal for one main reason: RFID LF tags can be an insecure option. (note that are exceptions: some tags can employ a password or crypto mode, one of the very few examples are Hitag2 tags and these security measures can still be circumvented!)

In this article, we will see how it’s possible to read, write and clone these tags and learn about possible implications due to misuse of this technology.

How to work with RFID tags

To work with RFID tags, specialized hardware is necessary.

Different devices exist:

Chinese cloners
Simple devices that read from one tag and write on another. Generally, these are hand-held, feature read and write buttons, and have a couple of status LEDs. Some are more advanced than others and can feature a little screen. Compatibility for frequencies and standards may vary, but these devices are usually good enough for simpler tasks.
RFID Chameleon
Developed to be used in RFID security assessments. Doesn’t offer the most advanced features, but is designed to be used in the field, is battery powered and supports tag simulation and manipulation. It is also programmable and you can use it with an app.

It’s probably the best solution for a standalone use.
More here: https://kasper-oswald.de/gb/chameleonmini/
Proxmark3
As the website puts it: Proxmark is an RFID swiss-army tool. It represents the state of the art when it comes to RFID research. It allows interacting with the tags both high and low level. Different versions have different features, including bluetooth support, battery packs, swappable antennas and so on.

It supports a standalone use, but it’s more powerful when connected to a PC. It’s to be intended as a research tool.
More here: https://www.proxmark.com/
Generic boards
Other boards exist. These are usually sold as an Arduino add on, but dongles featuring the same integrated circuits are available. These are not widely used outside the makers world, but many are compatible with libnfc and can be useful to perform simple to advanced operations.

The only device that I have available is a Proxmark3 easy (cheap Chinese version) so this article will focus on its use. The underlying concepts about RFID tags should translate to other devices.

Tags that emulate other tags

When it comes to working with RFID LF tags, there’s one main player: the T55xx tag

They are a family of tags developed to emulate a wide range of regular tags. This means that it’s possible to clone most of the RFID tags around using one of these without having to carry writable cards for each and every tag model.

This tag features 8 x 32 bit blocks in page 0 and 4 x 32 blocks in page 1. Page 1 blocks are meant to be used for configuration purposes along with block 0 and 7 in page 0. Blocks 1 to 6 in page 0 are dedicated to user data.


T55xx memory layout Credit - Microchip ATA5577C datasheet

Of course, it’s possible to work directly on the configuration blocks, and this is what allows the emulation of other type of tags, but doing so carelessly can easily lead to a brick!


Bricked T55xx

Original Atmel T5577 tags have a test mode and that can be helpful to recover soft-bricked cards.

Cloning tags

Using the proxmark3 CLI, reading and writing devices is pretty straightforward. First off you need to look for the device:

[usb] pm3 --> lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=] 
[=] Checking for known tags...
[=] 
[+] EM 410x ID 1122334455
[+] EM410x ( RF/64 )
[=] -------- Possible de-scramble patterns ---------
[+] Unique TAG ID      : 8844CC22AA
[=] HoneyWell IdentKey
[+]     DEZ 8          : 03359829
[+]     DEZ 10         : 0573785173
[+]     DEZ 5.5        : 08755.17493
[+]     DEZ 3.5A       : 017.17493
[+]     DEZ 3.5B       : 034.17493
[+]     DEZ 3.5C       : 051.17493
[+]     DEZ 14/IK2     : 00073588229205
[+]     DEZ 15/IK3     : 000585269781162
[+]     DEZ 20/ZK      : 08080404121202021010
[=] 
[+] Other              : 17493_051_03359829
[+] Pattern Paxton     : 289899093 [0x11478255]
[+] Pattern 1          : 5931804 [0x5A831C]
[+] Pattern Sebury     : 17493 51 3359829  [0x4455 0x33 0x334455]
[=] ------------------------------------------------

[+] Valid EM410x ID found!

The proxmark found an EM410x tag! We can now try to read it:

[usb] pm3 --> lf em 410x reader
[+] EM 410x ID 1122334455

Let’s try with another type of tag:

[usb] pm3 --> lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=] 
[=] Checking for known tags...
[=] 
[+] [H10301] - HID H10301 26-bit;  FC: 118  CN: 1603    parity: valid
[=] raw: 000000000000002006ec0c86

[+] Valid HID Prox ID found!

It’s an HID Prox tag, let’s try and read its ID:

[+] [H10301] - HID H10301 26-bit;  FC: 118  CN: 1603    parity: valid
[=] raw: 000000000000002006ec0c86

And just like that we got the devices ID. That ID is the authentication token! If we can write this token on a T55xx tag, we can emulate the card and possibly gain access to a restricted perimeter.

Let’s see how it’s done.
First we need to get a T55xx tag and position it on the reader. When empty this device can’t be found using lf search, so we can make sure it’s a T55xx tag using the detect command:

[usb] pm3 --> lf t55xx detect
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 32
[=]  Seq. terminator... Yes
[=]  Block0............ 00088048 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... No

The lf t55 detect command is also necessary before using this tag because it detects the configuration in use and helps avoiding problems running other lf t55 commands.

Now we can see the content of the device:

[usb] pm3 --> lf t55xx dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 00088048 | 00000000000010001000000001001000 | ...H
[+]  01 | 00000000 | 00000000000000000000000000000000 | ....
[+]  02 | 00000000 | 00000000000000000000000000000000 | ....
[+]  03 | 00000000 | 00000000000000000000000000000000 | ....
[+]  04 | 00000000 | 00000000000000000000000000000000 | ....
[+]  05 | 00000000 | 00000000000000000000000000000000 | ....
[+]  06 | 00000000 | 00000000000000000000000000000000 | ....
[+]  07 | 00000000 | 00000000000000000000000000000000 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 00088048 | 00000000000010001000000001001000 | ...H
[+]  01 | E03900D0 | 11100000001110010000000011010000 | .9..
[+]  02 | C60337D7 | 11000110000000110011011111010111 | ..7.
[+]  03 | 00A00003 | 00000000101000000000000000000011 | ....

Note that it’s possible to operate on single blocks too, but for the purpose of this article, it’s easier to dump the whole memory instead.

We see that the card doesn’t contain user data. If it did, wiping the card with the lf t55xx wipe command would be suggested. We can now try and emulate tags on it! To do that we only need to have the ID of the tags we want to emulate. We already saw how that’s done.

We can now go ahead and clone the tags, let’s try the em410x first:

[usb] pm3 --> lf em 410x clone --id 1122334455
[+] Preparing to clone EM4102 to T55x7 tag with ID 1122334455 (RF/64)
[#] Clock rate: 64
[#] Tag T55x7 written with 0xff8c65298c94a940

Once the command is issued, we can read the device and verify that it emulates an em410x tag:

[usb] pm3 --> lf em 410x reader
[+] EM 410x ID 1122334455

Of course it’s still a T55xx tag (and the detect command will tell you that) but it behaves exactly like and em410x.

Now we can try with the HID Prox.

[usb] pm3 --> lf hid clone --r 000000000000002006ec0c86
[=] Preparing to clone HID tag using raw 000000000000002006ec0c86
[=] Done

And of course reading it reveals that we successfully cloned the tag:

usb] pm3 --> lf hid reader
[+] [H10301] - HID H10301 26-bit;  FC: 118  CN: 1603    parity: valid
[=] raw: 000000000000002006ec0c86

We now have two key fob tags copied on T55xx cards!


Original and cloned tags

In this demo only HID Prox and em410x tags are examined, but it’s possible to clone and work with many more of these tags.

Since it’s possible to emulate cards knowing the ID, we can clone some RFID LF cards “by sight” simply reading the ID printed to the device body. This completely removes the limit of having to read the card with a specialized tool. Some of these printed ID are “encoded” (or shifted by some value). This allows organizations to “decode” it, but prevents attackers from obtaining the ID by sight.

At this point you might be wondering if it’s THAT easy to clone a tag in the real world, the answer is no. That’s for a simple reason, the tag is passive and if we use the standard antennas provided with whichever device, the reading range is limited to a few centimeters.

Luckily, it’s possible to weaponize a bigger antenna! If we use a bigger and more powerful antenna, it’s possible to clone a LF tag from a usable distance. Of course the antenna will need to be powered by a big battery pack and carried in some kind of backpack or messenger bag, but that’s the price to pay.

More here: https://www.youtube.com/watch?v=wYmVtNQPlF4
(NOTE: many other implementations exist!)

Defeating password protection

When examining the T55xx tag, you may have noticed a parameter “Password set”. That’s because this tag can be password protected!

[usb] pm3 --> lf t55xx protect -n 00001234
[=] Checking current configuration
[+] Wrote new password
[+] Validated new password
[+] Wrote modified configuration block
[!] ⚠️  Safety check: Could not detect if PWD bit is set in config block. Exits.
[?] Consider using the override parameter to force read.
[=] Block0 write detected, running `detect` to see if validation is possible
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 33
[=]  Seq. terminator... Yes
[=]  Block0............ 000880F0 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... Yes
[=]  Password.......... 00001234

[+] New configuration block 000880F0 password 00001234
[+] Success, tag is locked

At this point we can’t operate on this tag without knowing the password, for instance the detect command won’t work as expected:

[usb] pm3 --> lf t55xx detect 
[!] ⚠️  Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

But it does if the correct password is specified:

[usb] pm3 --> lf t55xx detect -p 00001234
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 33
[=]  Seq. terminator... Yes
[=]  Block0............ 000880F0 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... Yes
[=]  Password.......... 00001234

Can we circumvent this? The simple answer is no. The device is completely locked and without the password it’s impossible to do anything.

Luckily the proxmark allows bruteforce attacks.

While this type of attack works, it’s a really slow and instable method. This means it’s hard to try all the possible passwords before the connection drops. It may seem that the password protection is effective and that’s true if you don’t have the right tools. On the other hand, with quality reading devices and unlimited access to the target tag, success is granted.

Here’s a demo on the tag we just password protected:

[usb] pm3 --> lf t55xx bruteforce -s 00000000 -e FFFFFFFF
[=] press 'enter' to cancel the command
[=] Search password range [00000000 -> FFFFFFFF]
.[=] Trying password 00000000
.[=] Trying password 00000001
.[=] Trying password 00000002
.[=] Trying password 00000003
.[=] Trying password 00000004
.[=] Trying password 00000005
.[=] Trying password 00000006
.[=] Trying password 00000007
.[=] Trying password 00000008
.[=] Trying password 00000009
.[=] Trying password 0000000A
.[=] Trying password 0000000B
.[=] Trying password 0000000C
.[=] Trying password 0000000D

[...]

.[=] Trying password 0000122D
.[=] Trying password 0000122E
.[=] Trying password 0000122F
.[=] Trying password 00001230
.[=] Trying password 00001231
.[=] Trying password 00001232
.[=] Trying password 00001233
.[=] Trying password 00001234
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 33
[=]  Seq. terminator... Yes
[=]  Block0............ 000880F0 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... Yes
[=]  Password.......... 00001234

[+] Found valid password: [ 00001234 ]
Downlink Mode used : default/fixed bit length

[+] time in bruteforce 1215 seconds

As you can see, it took ~20 minutes to crack a 4 hex digit password. It may seem to be a reasonable time but we must consider that the password can be double the length and that having access to the card for long periods of time is not always an option.

Attacks on RFID readers

Finally, we can talk about attacks on the readers. There are two main attacks:

Tag simulation
Data exfiltration

We saw that we can simulate a tag using the proxmark, but what if the ID we have read and simulated doesn’t have enough permission to grant us access somewhere? In this scenario, it’s possible to use the read value as an upper limit to the ID space to research, and simulate every ID lower than that value hoping to find an ID with higher privileges. This attack is based on the assumption that lower IDs may have higher privileges because such privileges are associated with users registered earlier into the system, hence the lower ID value. As for the bruteforce attack, this process may take a while, so it’s not always a usable technique.

A sneakier way to get valid IDs is to install a device such as the ESPKey inside the reader. This approach allows the interception of data directly from the wires and can harvest valid IDs. Of course, this requires a physical access to the reader.

Using the proxmark is also possible to sniff data from a tag to a reader.
Given the antenna range, this is not a widely used technique and personally I haven’t tried it yet.

Conclusions

This article shows how, with the right hardware, it is possible to clone RFID tags with relatively low skills.

What’s scary is how easy it is to “steal” valuable credentials. In an access control context, a stolen ID constitutes a danger for a business because of the implications of a possible unauthorized entry into a critical infrastructure.

Possible mitigations include using a stronger authentication mechanism and trainings on RFID security and how to keep access tokens safe. Simple precautions like using an RFID shield (test those! some doesn’t work!) and avoiding to keep a tag in sight can often be a huge improvement in access token security.

A secure reader is also crucial. Some readers offer tamper detection mechanisms and actively try to detect and disable rewritable tags to avoid unauthorized entry.

RFID credentials cloning can be one of the strongest tools in the arsenal of a physical penetration tester.

This article was reviewed by an external source, big thanks to them!