Posts on less on sec

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.

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

I hacked the Dutch government and all I got was this lousy t-shirt

Thu, 02 Nov 2023 23:25:14 +0100

Recently, I was awarded a cool t-shirt from the Dutch government for disclosing and reporting a vulnerability under their National Cyber Security Centre responsible disclosure program.


Lousy t-shirt

I was able to discover a vulnerability in one of the government’s websites. The platform allows users to compile a survey and offers the possibility to save progress and receive a link via email to resume the it in a second time.

Testing this functionality I was able to find the parameter responsible for setting the URL to resume the survey in a POST request. This parameter was also not subject to sanification, and so it was possible to inject HTML code into email sent from noreply@[governmentdomain].nl effectively allowing unauthenticated users to send emails with forged contents to arbitrary addresses, impersonating the Dutch government.

As a proof of concept, consider this POST request:

POST /[endpoint] HTTP/1.1
Host: [governmentdomain].nl
User-Agent: Mozilla/5.0(X11; Linux x86_64; rv: 108.0) Gecko/20100101 Firefox/108.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: [...]
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 191
Origin: https://[governmentdomain].nl
Connection: keep-alive
Cookie: [...]
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache

[...]
link=https%3A%2F%2Fexample.org<h1>hack</h1>
[...]

With the received email looking like this:


PoC email with injected HTML code

At this point I stopped testing in accordance to the rules of the responsible disclosure program and reported the issue.

Thanks to the Dutch National Cyber Security Centre for promptly fixing the issue and awarding me the t-shirt. It’s great to see a government taking proactive steps towards improving their cybersecurity posture and promoting responsible disclosure.

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.

Walkthrough: BLE CTF

Sun, 17 Apr 2022 14:08:32 +0200

This CTF has been in my todo list for a good while, finally I had the time to solve it and to publish a walkthrough article on it! The challenge is available at: https://github.com/hackgnar/ble_ctf and is an awesome tool to learn about BLE and get your feet wet.

To be fair I expected the CTF to be a bit more security oriented, but I learned way more than I expected, both on BLE technologies and on the tools used to interact with those.

Disclaimer
I’m not a fan of walkthrough articles that ignore the request of the creators not to post those. The reasons I’m publishing this article are that:

No request by the creator has been made not to post the solutions

There are plenty of walkthrough articles on this CTF that don’t really teach anything and barely explain the solutions

The CTF is self-hosted and is more of a teaching tool than a proper challenge

Of course I strongly recommend trying to solve the challenges on your own before checking the solutions here! Anyway I suggest reading the first part of the articles to gather some useful information about the technologies involved in the challenge.

Without further ado, let’s get started!

How does this CTF works?

The CTF is composed of a series of challenges hosted on an ESP32 board. The software required to setup the challenge is in fact a firmware to be installed on the board. I won’t enter in details about the installation in this article, but you can find detailed instructions here: https://github.com/hackgnar/ble_ctf/blob/master/docs/setup.md

When the firmware is installed, the ESP32 will host a GATT server with which we can interact to solve the challenges and gather the flags.

What’s a GATT server

GATT is the name of a protocol that is used to exchange data between two Bluetooth Low Energy devices. This is developed on top of the Attribute Protocol (ATT) and manages device interactions following the advertising and pairing processes. A GATT Server is a device that stores attribute data locally and provides data access methods to a remote GATT Client paired via BLE. A client, on the other hand, is a device that access data on a remote GATT Server. When two devices are paired, each can function as both a GATT Server and a GATT Client.

GATT lists a device’s characteristics, descriptors, and services in a table as either 16 or 32-bits values. A characteristic is a data value sent between the server and the client.

These characteristics can have descriptors that provide additional information about them. Characteristics are often grouped in services if they have purposes related to each other. Services can have several characteristics.


GATT Server content layout Credits - Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things

ATT/GATT basics

It is possible to interact with a GATT server, by interacting with each of the characteristics available. It is possible to do that using handles, or UUID: handles define the address of a characteristic, while the UUID works as an identifier, but also gives the user some indication about the content of a characteristic. In general, handles are to be preferred to reference to a particular characteristic, this is because UUID can vary depending on the GATT implementation, while handles are expected to remain immutable for each device.

As anticipated, UUID contain info about the service or characteristic. These are useful because they are defined by profiles: standards that use known UUID to serve specific information, profiles can be found here: https://www.bluetooth.com/specifications/specs/ While UUID vary depending on the device functionality some UUID remains the same, for example: 0x2800, around which service discovery is built. This UUID allows GATT servers to understand service boundaries without having to know the exact standard the device is following.

Finally, there are characteristic properties. Properties indicate how to interact with a characteristic and what to expect from it.


GATT chatateristic proprieties Credits - devzone.nordicsemi.com

Properties are defined as an hex value and work as bitmasks, so using bitwise operations it is possible reveal the properties of a characteristic starting from its properties value.

Properties need to be interpreted knowing Attribute Protocol Packets, these are:

Commands (Client -> Server, no response required)
Requests (Client -> Server, response required)
Responses (Server -> Client, it’s the response to a request)
Notifications (Server -> Client, no response required - Signal the fact that a

characteristic’s value has changed)
Indications (Server -> Client, ACK response required by the client - Similar to

notifications)
Confirmations (Client -> Server, it’s the response to an indication)

As indicated in the image, the Read and Write properties are like permissions, and allow the reading and writing of the characteristic if set. The other properties are an indication of the behavior of a characteristic in response of an action by the client.

Actions performed by the client are limited to read and write operations. While read operations are requests by nature, write operations can either be commands or requests.

CTF

The tools that will be employed for this challenge are: gatttool and hcitool. There are other tools that can be used, in particular bettercap, which is a bit more user friendly but lacks some functionalities, or libraries that implement GATT operations, that were avoided to allow familiarizing with the tools available on a standard linux system. I think this “Living off the Land” approach helps better understanding GATT operations and also leads to a more generally employable approach to solve BLE related tasks. Of course you’re free to use the tools you prefer for this challenge.

Before starting, I suggest familiarizing with the challenge page and to understand how to operate actions relative to the challenge, like reading the score and submitting a flag. The list of the flags at the bottom of the page is really useful, as understanding exactly what to do can be tricky. There are also hints there, don’t be afraid to check those out. None of the hints gives away too much and in certain cases those are needed to understand the challenge and to get the flag.

NOTE: the score is reset each time the ESP32 is powered off! Keep that in mind.

Let’s begin! First thing first, we need to retrieve the device BT MAC address and we can do that using hcitool:

less@machine:~$ sudo hcitool lescan
LE Scan ...
78:21:84:80:A2:22 BLECTF
[...]

Now we know the address for my board is: 78:21:84:80:A2:22, it will vary on yours.

Once we have the address we can start enumerating services on the GATT server. The first thing to do is to connect to the board, we will do that using gatttool and its interactive mode:

less@machine:~$ gatttool -I
[                 ][LE]> connect 78:21:84:80:A2:22
Attempting to connect to 78:21:84:80:A2:22
Connection successful

Now we need to enumerate the services, we can do that using the primary command or by reading the UUID 0x2800.

[78:21:84:80:A2:22][LE]> primary
attr handle: 0x0001, end grp handle: 0x0005 uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0014, end grp handle: 0x001c uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0028, end grp handle: 0xffff uuid: 000000ff-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> char-read-uuid 0x2800
handle: 0x0001 	 value: 01 18 
handle: 0x0014 	 value: 00 18 
handle: 0x0028 	 value: ff 00

And in both cases we retrieve services boundaries. The first two services are standard, and contain info about the server itself, while the third is the one we want to work with.

Now we can enumerate the characteristic of each service. This can be done using the command characteristics and using the boundaries found as upper and lower limits:

[78:21:84:80:A2:22][LE]> characteristics 0x0001 0x0014
handle: 0x0002, char properties: 0x20, char value handle: 0x0003, uuid: 00002a05-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> characteristics 0x0014 0x0028
handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002aa6-0000-1000-8000-00805f9b34fb
[78:21:84:80:A2:22][LE]> characteristics 0x0028 0x00ff
handle: 0x0029, char properties: 0x02, char value handle: 0x002a, uuid: 0000ff01-0000-1000-8000-00805f9b34fb
handle: 0x002b, char properties: 0x0a, char value handle: 0x002c, uuid: 0000ff02-0000-1000-8000-00805f9b34fb
handle: 0x002d, char properties: 0x02, char value handle: 0x002e, uuid: 0000ff03-0000-1000-8000-00805f9b34fb
handle: 0x002f, char properties: 0x02, char value handle: 0x0030, uuid: 0000ff04-0000-1000-8000-00805f9b34fb
handle: 0x0031, char properties: 0x0a, char value handle: 0x0032, uuid: 0000ff05-0000-1000-8000-00805f9b34fb
handle: 0x0033, char properties: 0x0a, char value handle: 0x0034, uuid: 0000ff06-0000-1000-8000-00805f9b34fb
handle: 0x0035, char properties: 0x0a, char value handle: 0x0036, uuid: 0000ff07-0000-1000-8000-00805f9b34fb
handle: 0x0037, char properties: 0x02, char value handle: 0x0038, uuid: 0000ff08-0000-1000-8000-00805f9b34fb
handle: 0x0039, char properties: 0x08, char value handle: 0x003a, uuid: 0000ff09-0000-1000-8000-00805f9b34fb
handle: 0x003b, char properties: 0x0a, char value handle: 0x003c, uuid: 0000ff0a-0000-1000-8000-00805f9b34fb
handle: 0x003d, char properties: 0x02, char value handle: 0x003e, uuid: 0000ff0b-0000-1000-8000-00805f9b34fb
handle: 0x003f, char properties: 0x1a, char value handle: 0x0040, uuid: 0000ff0c-0000-1000-8000-00805f9b34fb
handle: 0x0041, char properties: 0x02, char value handle: 0x0042, uuid: 0000ff0d-0000-1000-8000-00805f9b34fb
handle: 0x0043, char properties: 0x2a, char value handle: 0x0044, uuid: 0000ff0e-0000-1000-8000-00805f9b34fb
handle: 0x0045, char properties: 0x1a, char value handle: 0x0046, uuid: 0000ff0f-0000-1000-8000-00805f9b34fb
handle: 0x0047, char properties: 0x02, char value handle: 0x0048, uuid: 0000ff10-0000-1000-8000-00805f9b34fb
handle: 0x0049, char properties: 0x2a, char value handle: 0x004a, uuid: 0000ff11-0000-1000-8000-00805f9b34fb
handle: 0x004b, char properties: 0x02, char value handle: 0x004c, uuid: 0000ff12-0000-1000-8000-00805f9b34fb
handle: 0x004d, char properties: 0x02, char value handle: 0x004e, uuid: 0000ff13-0000-1000-8000-00805f9b34fb
handle: 0x004f, char properties: 0x0a, char value handle: 0x0050, uuid: 0000ff14-0000-1000-8000-00805f9b34fb
handle: 0x0051, char properties: 0x0a, char value handle: 0x0052, uuid: 0000ff15-0000-1000-8000-00805f9b34fb
handle: 0x0053, char properties: 0x9b, char value handle: 0x0054, uuid: 0000ff16-0000-1000-8000-00805f9b34fb
handle: 0x0055, char properties: 0x02, char value handle: 0x0056, uuid: 0000ff17-0000-1000-8000-00805f9b34fb

And just like that we retrieved every characteristic available, their value and their properties.

At this point it is useful to define utility functions to work with the handles:

mac="78:21:84:80:A2:22" #change the value to match your board's MAC

# HEX encode
encode() {
        echo -n $1 | xxd -ps;
}

# HEX decode
decode() {
        echo $1 | tr -d "" | xxd -r -p; echo
}

# Write flag to handle 0x002c
submit_flag() {
        gatttool -b $mac --char-write-req -a 0x002c -n `encode "$1"`
}

# Read handle 0x002a to get the score
get_score() {
        read_hnd 0x002a
}

# Read values from handle and decode it
read_hnd() {
        decode "`gatttool -b $mac --char-read -a $1 | awk -F':' '{print $2}'`"
}

# List properties from hex property value
get_properties() {
		if (( ($1 & 0x1) == 0x1 )); then echo "Broadcast"; fi
        if (( ($1 & 0x2) == 0x2 )); then echo "Read"; fi
        if (( ($1 & 0x4) == 0x4 )); then echo "Write without response"; fi
        if (( ($1 & 0x8) == 0x8 )); then echo "Write"; fi
        if (( ($1 & 0x10) == 0x10 )); then echo "Notify"; fi
        if (( ($1 & 0x20) == 0x20 )); then echo "Indicate"; fi
        if (( ($1 & 0x40) == 0x40 )); then echo "Authenticated Signed Writes"; fi
        if (( ($1 & 0x80) == 0x80 )); then echo "Extended Properties"; fi
}

NOTE: properties for each characteristic of interest are listed in the challenge description, so the get_properties function won’t be used explicitly.

Flag #1 To get this flag we need to use the hint!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x002c -n $(echo -n "12345678901234567890"|xxd -ps)
Characteristic value was written successfully

Now, reading the handle 0x002a confirms we got the first flag.

less@machine:~$ get_score
Score:1 /20

Flag 0x002e

Properties: Read

To get this flag we simply need to read the handle 0x002e.

less@machine:~$ read_hnd 0x002e
d205303e099ceff44835
less@machine:~$ submit_flag d205303e099ceff44835
less@machine:~$ get_score
Score:2 /20

Flag 0x0030

“MD5 of Device Name”

Properties: Read

So for this flag we need to submit the MD5 of the Device Name. Note: the MD5 hash needs to be truncated to 20 characters as suggested in the README of the CTF project.

We already know the device name as we encountered it connecting to the device:
```
less@machine:~$ sudo hcitool lescan
LE Scan ...
78:21:84:80:A2:22 BLECTF
[...]
```
Now we only need to get the MD5 digest of the name, cut and submit it:
```
less@machine:~$ echo -n "BLECTF" | md5sum | cut -c 1-20
5cd56d74049ae40f442e
less@machine:~$ submit_flag 5cd56d74049ae40f442e
Characteristic value was written successfully
less@machine:~$ get_score 
Score:3 /20
```
Flag 0x0016

This is a particular challenge, the hint says:

“Bluetooth GATT services provide some extra device attributes. Try finding the value of the Generic Access -> Device Name.”

But the name of the challenge is “Flag 0x0016”, so it gives it away!

Reading the handle we get the flag:
```
less@machine:~$ read_hnd 0x0016
2b00042f7481c7b056c4b410d28f33cf
```
Of course we need to cut it before submitting it (as it is a name and the README clearly states that names and digests need to be cut to the 20th character):
```
less@machine:~$ echo 2b00042f7481c7b056c4b410d28f33cf | cut -c 1-20
2b00042f7481c7b056c4
less@machine:~$  submit_flag 2b00042f7481c7b056c4
Characteristic value was written successfully
less@machine:~$  get_score 
Score:4 /20
```
But it is important to understand the reason why this flag is there. We already talked about profiles and standard UUID, these include an UUID that corresponds to the Device Name, this UUID is: 0x2A00.

Using gatttool, we can read the UUID and note that the handle is indeed 0x0016:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-read -u 0x2A00
handle: 0x0016 	 value: 32 62 30 30 30 34 32 66 37 34 38 31 63 37 62 30 35 36 63 
```

Flag 0x0032

The content of the handle is: “Write anything here”

Properties: Read, Write

To get the flag we need to write “anything” to the 0x0032 handle.

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0032 -n `encode "anything"`
Characteristic value was written successfully

Now, we can read the handle a second time and it will reveal the flag

less@machine:~$ read_hnd 0x0032
3873c0270763568cf7aa
less@machine:~$ submit_flag 3873c0270763568cf7aa
Characteristic value was written successfully
less@machine:~$ get_score 
Score:5 /20

Flag 0x0034

The content of the handle is: “Write the ascii value “yo” here”

Properties: Read, Write

The task is similar to the last one, but this time we don’t have to hex encode the string

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0034 -n `encode "yo"`
Characteristic value was written successfully

Now, we can get the flag reading the handle again

less@machine:~$ read_hnd 0x0034
c55c6314b3db0a6128af
less@machine:~$ submit_flag c55c6314b3db0a6128af
Characteristic value was written successfully
less@machine:~$ get_score 
Score:6 /20

Flag 0x0036

The content of the handle is: “Write the hex value 0x07 here”

Properties: Read, Write

This task is not different from the previous ones, but since the default encoding used in BLE communications is hex, and the value is to be sent in hex, no encoding needs to be used
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x0036 -n 07
Characteristic value was written successfully
```
Now the flag should be available at the same handle
```
less@machine:~$ read_hnd 0x0036
1179080b29f8da16ad66
less@machine:~$ submit_flag 1179080b29f8da16ad66
Characteristic value was written successfully
less@machine:~$ get_score 
Score:7 /20
```
Flag 0x0038

The content of the handle is: “Write 0xC9 to handle 58”

Properties: Read Handle 58 properties: Write

First off we need to convert 58 in hex to get the hex value for the handle, hex(58) is 0x3A. Now we need to write the hex value 0xC9 to the handle, this can be done exactly like we did for the last challenge:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x003A -n C9
Characteristic value was written successfully
```
Now reading the handle 0x0038 again reveals the flag
```
less@machine:~$ read_hnd 0x0038
f8b136d937fad6a2be9f
less@machine:~$ submit_flag f8b136d937fad6a2be9f
Characteristic value was written successfully
less@machine:~$ get_score 
Score:8 /20
```
Flag 0x003C

The content of the handle is: “Brute force my value 00 to ff”

Properties: Read, Write

This can be achieved in multiple ways, but for consistency gatttool and a bit of bash scripting will be used.
```
less@machine:~$ for i in {0..255};
> do gatttool -b 78:21:84:80:A2:22 --char-write-req -a 0x003c -n $(printf '%02x\n' $i) > /dev/null;
> done;
```
This script iterates through every value from 0 to 255 (which is FF in hex) and writes such value in the handle 0x003C. The $(printf '%02x\n' $i); command converts the value to write from decimal to hex.

Once the script has finished, it’s possible to read the handle 0x003C again to get the flag
```
less@machine:~$ read_hnd 0x003c
933c1fcfa8ed52d2ec05
less@machine:~$ submit_flag 933c1fcfa8ed52d2ec05
Characteristic value was written successfully
less@machine:~$ get_score 
Score:9 /20
```

Flag 0x003E

The content of the handle is: “Read me 1000 times”

Properties: Read

This can be done simply modifying the script used in the previous challenge

less@machine:~$ for i in {0..1000}; 
> do gatttool -b 78:21:84:80:A2:22 --char-read -a 0x003e;
> done;

This command will print out the content of the reads, and after a while you’ll notice that the output changes like in the example here:

[...]
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 52 65 61 64 20 6d 65 20 31 30 30 30 20 74 69 6d 65 73 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65 
Characteristic value/descriptor: 36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65

The values printed after the variation represent the flag!

So we just need to submit it to complete this challenge

less@machine:~$ decode "36 66 66 63 64 32 31 34 66 66 65 62 64 63 30 64 30 36 39 65"
6ffcd214ffebdc0d069e
less@machine:~$ submit_flag 6ffcd214ffebdc0d069e
Characteristic value was written successfully
less@machine:~$ get_score 
Score:10/20

Flag 0x0040

The content of the handle is: “Listen to me for a single notification”

Properties: Read, Write, Notify

To listen for a notification, we first need to send a write request, but we will have to listen to the notification, this can be achieved with the following command:

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0040 --value=dummy --listen
Characteristic value was written successfully
Notification handle = 0x0040 value: 35 65 63 33 37 37 32 62 63 64 30 30 63 66 30 36 64 38 65 62

The notification value is the flag!

less@machine:~$ decode "35 65 63 33 37 37 32 62 63 64 30 30 63 66 30 36 64 38 65 62"
5ec3772bcd00cf06d8eb
less@machine:~$ submit_flag 5ec3772bcd00cf06d8eb
Characteristic value was written successfully
less@machine:~$ get_score 
Score:11/20

Flag 0x0042

The content of the handle is: “Listen to handle 0x0044 for a single indication”

Properties: Read

Handle 0x0044 Properties: Read, Write, Indicate

This flag can be obtained just like the last one:

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0044 --value=ffff --listen
Characteristic value was written successfully
Indication   handle = 0x0044 value: 63 37 62 38 36 64 64 31 32 31 38 34 38 63 37 37 63 31 31 33

Once the notification value is retrieved we can decode and submit it:

less@machine:~$ decode "63 37 62 38 36 64 64 31 32 31 38 34 38 63 37 37 63 31 31 33"
c7b86dd121848c77c113
less@machine:~$ submit_flag c7b86dd121848c77c113
Characteristic value was written successfully
less@machine:~$ get_score 
Score:12/20

Flag 0x0046

The content of the handle is: “Listen to me for multi notifications”

Properties: Read, Write, Notify

And with the same command we can get this flag too!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0046 --value=ffff --listen
Characteristic value was written successfully
Notification handle = 0x0046 value: 55 20 6e 6f 20 77 61 6e 74 20 74 68 69 73 20 6d 73 67 00 00 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64 
Notification handle = 0x0046 value: 63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64

After the first notification, we get the content of the flag! (The decoded content of the first notification is “U no want this msg”).

less@machine:~$ decode "63 39 34 35 37 64 65 35 66 64 38 63 61 66 65 33 34 39 66 64"
c9457de5fd8cafe349fd
less@machine:~$ submit_flag c9457de5fd8cafe349fd
Characteristic value was written successfully
less@machine:~$ get_score 
Score:13/20

Flag 0x0048

The content of the handle is: “Listen to handle 0x004a for multi indications”

Properties: Read

Handle 0x004a Properties: Read, Write, Indicate

Once again the same command is the key to the flag!

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x004a --value=ffff --listen
Characteristic value was written successfully
Indication   handle = 0x004a value: 55 20 6e 6f 20 77 61 6e 74 20 74 68 69 73 20 6d 73 67 00 00 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61 
Indication   handle = 0x004a value: 62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61

Now we can decode and submit the flag like always.

less@machine:~$ decode "62 36 66 33 61 34 37 66 32 30 37 64 33 38 65 31 36 66 66 61"
b6f3a47f207d38e16ffa
less@machine:~$ submit_flag b6f3a47f207d38e16ffa
Characteristic value was written successfully
less@machine:~$ get_score 
Score:14/20

Flag 0x004c

The content of the handle is: “Connect with BT MAC address 11:22:33:44:55:66”

Properties: Read

Now, this challenge depends on the BT card you’re using. I’m using a raspberry pi 3b+ and I could solve the challenge in the following way:

less@machine:~$ sudo hcitool cmd 0x3f 0x001 0x66 0x55 0x44 0x33 0x22 0x11
< HCI Command: ogf 0x3f, ocf 0x0001, plen 6
  66 55 44 33 22 11 
> HCI Event: 0x0e plen 4
  01 01 FC 00 
less@machine:~$ sudo hciconfig hci0 reset
less@machine:~$ systemctl restart bluetooth.service
Authentication is required to restart 'bluetooth.service'.
Authenticating as: ,,, (less)
Password: 
==== AUTHENTICATION COMPLETE ===

At this point we can confirm our BT MAC address executing hciconfig:

less@machine:~$ hciconfig
hci0:	Type: Primary  Bus: UART
	BD Address: 11:22:33:44:55:66  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING 
	RX bytes:13820 acl:117 sco:0 events:824 errors:0
	TX bytes:16604 acl:108 sco:0 commands:606 errors:0

And of course now, reading the handle gives us the flag:

less@machine:~$ read_hnd 0x004c
aca16920583e42bdcf5f
less@machine:~$ submit_flag aca16920583e42bdcf5f
Characteristic value was written successfully
less@machine:~$ get_score 
Score:15/20

Check out these resources for more info on this solution: https://www.lisha.ufsc.br/teaching/shi/ine5346-2003-1/work/bluetooth/hci_commands.html and https://raspberrypi.stackexchange.com/a/124117

Flag 0x004e

The content of the handle is: “Set your connection MTU to 444”

Properties: Read

Even if there is the option to do that (-m), I can’t seem to get the flag without using the interactive mode of gatttools, so my solution to this flag is:

less@machine:~$ gatttool -I
[                 ][LE]> connect 78:21:84:80:A2:22
Attempting to connect to 78:21:84:80:A2:22
Connection successful
[78:21:84:80:A2:22][LE]> mtu 444
MTU was exchanged successfully: 444
[78:21:84:80:A2:22][LE]> char-read-hnd 0x004e
Characteristic value/descriptor: 62 31 65 34 30 39 65 35 61 34 65 61 66 39 66 65 35 31 35 38 
[78:21:84:80:A2:22][LE]> exit

And just like that we got the flag

less@machine:~$ decode "62 31 65 34 30 39 65 35 61 34 65 61 66 39 66 65 35 31 35 38 "
b1e409e5a4eaf9fe5158
less@machine:~$ submit_flag b1e409e5a4eaf9fe5158
Characteristic value was written successfully
less@machine:~$ get_score 
Score:16/20

Flag 0x0050

The content of the handle is: “Write+resp ‘hello’ "

Properties: Read, Write

I suggest checking the hint for this challenge! The key is in correctly handling the ACK response from the write instruction, this is the reason

--char-write-req needs to be used.

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0050 --value=`encode hello`
Characteristic value was written successfully
less@machine:~$ read_hnd 0x0050
d41d8cd98f00b204e980

Now we only need to submit the flag.

less@machine:~$ submit_flag d41d8cd98f00b204e980
Characteristic value was written successfully
less@machine:~$ get_score 
Score:17/20

Flag 0x0052

The content of the handle is: “No notifications here! really?”

Properties: Read, Write

In fact even if there is no notification property set…

less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0052 --value=`encode hello` --listen
Characteristic value was written successfully
Notification handle = 0x0052 value: 66 63 39 32 30 63 36 38 62 36 30 30 36 31 36 39 34 37 37 62

The flag is revealed through a notification! Now we can decode and submit it.

less@machine:~$ decode "66 63 39 32 30 63 36 38 62 36 30 30 36 31 36 39 34 37 37 62"
fc920c68b6006169477b
less@machine:~$ submit_flag fc920c68b6006169477b
Characteristic value was written successfully
less@machine:~$ get_score 
Score:18/20

Flag 0x0054

The content of the handle is: “So many properties!”

Properties: Broadcast, Read, Write, Notify, Extended properties

…and to be fair this handle has “Broadcast, Read, Write, Notify, Extended properties” properties. It’s a bit of a mess!

But getting the flag is fairly simple. The first half can be retrieved simply listening for a notification:
```
less@machine:~$ gatttool -b 78:21:84:80:A2:22 --char-write-req --handle=0x0054 --value=ffff --listen
Characteristic value was written successfully
Notification handle = 0x0054 value: 30 37 65 34 61 30 63 63 34 38 
```
For the second half we need to read the handle once more:
```
less@machine:~$ read_hnd 0x0054
fbb966958f
```
Now we just need to put the two halves together and submit the flag (the second half of the flag goes first!):
```
less@machine:~$ submit_flag fbb966958f07e4a0cc48
Characteristic value was written successfully
less@machine:~$ get_score 
Score:19/20
```
Flag 0x0056

The content of the handle is: “md5 of author’s twitter handle”.

Properties: Read

So we need to do a bit of OSINT to solve this challenge!

The starting point is the github page of the challenge: https://github.com/hackgnar/ble_ctf Luckily in the README.md file we can find a twitter follow button, this leads us to: https://twitter.com/hackgnar And now we know the handle is: @hackgnar

Now we can get the MD5 digest of the handle and cut it to 20 chars:
```
less@machine:~$ echo -n "@hackgnar" | md5sum | cut -c 1-20
d953bfb9846acc2e15ee
```
We can now submit it as a flag
```
less@machine:~$ submit_flag d953bfb9846acc2e15ee
Characteristic value was written successfully
less@machine:~$ get_score 
Score:20/20
```

Conclusions

Hope this article is useful to anyone who’s stuck on one of these challenges or to anyone who’s trying to learn about BLE technologies. Writing this article has helped me formalizing most of the things I learned solving these challenges and my main takeaways are an improved understanding of BLE, GATT and ATT, but also the ability to use the tools needed to work with these technologies.

In future I’ll try working with GATT libraries to programmatically interact with GATT servers!

Resources:

https://epxx.co/artigos/bluetooth_gatt.html (ATT/GATT basics)
Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things (General BLE introduction)
https://axodyne.com/2020/08/ble-uuids/ (Explanation on standard UUIDS)
https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt (Profiles and services)
https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/ble-characteristics-a-beginners-tutorial (Properties)

Email spoofing 101

Sat, 05 Feb 2022 16:40:50 +0100

Email spoofing is a technique mostly linked to malicious activities including phishing and spamming. From a formal(ish) standpoint, email spoofing is the act of sending an email with a forged sender address.

I got interested in this technique in the last few days, so I decided to experiment a bit with it.

Email spoofing basics

This technique is as old as emails are, in fact original transmission protocols (such as SMTP) don’t have authentication methods, and while security measures have been adopted these are not widely employed yet.

An email is composed of three different parts:

Envelope: data about sender and receiver addresses. This part of message is destined to the server, it’s generally not shown to the user by the client.
Header: meta-data of the email. Contains information like the subject of the email, the date and some info about sending/receiving addresses.
Body: the content of the email.

To get a bit more into details, the SMTP protocol specify two addresses in the envelope addressing part of the message:

MAIL FROM: it specifies the “return address” in case an email bounces.
RCPT TO: address to which the email will be delivered.

Other headers are often present, this set of information represent what the receiver will see when reading the email inside of a client. The addresses in each header will be present in the form of: Foo Bar <foobar@spam.com>.

In particular, these headers are: From:, Reply-to:, Sender:. Each of these headers represents the address visible to the receiving part.

In general, it’s important to notice the difference between the envelope MAIL FROM or RFC5321.MailFrom and the header From:or RFC5322.From since the latter is shown to the user and can be easily spoofed and it’s shown to the recipient of the email by the client.

As anticipated, SMTP doesn’t check whether an user is authorized or not to use a particular address in these fields and this is the reason why it’s so easy to spoof emails. The only reliable information we can harvest from a spoofed email is the IP from which the email was sent.

Available security measures

There are three main security measured against email spoofing:

Sender Policy Framework (SPF) This method allows the detection of forged sender addresses and it’s based on envelope information. In particular SPF information are contained inside a TXT DNS record. These info specify which IP addresses are allowed to send emails on the behalf of the domain. Allowed senders can be listed explicitly specifying authorized IP ranges, or checking if A, AAAA or MX records resolve to the sender’s address.

SPF also use 4 qualifiers, these represent the status of the SPF validation. Qualifiers can be:
- PASS (+) : if the check is passed. The email can be accepted.
- NEUTRAL (?) : if no policy is in use.
- FAIL (-) : if the check wasn’t successful. The email should be rejected.
- SOFTFAIL (~) : like fail, but used for debugging. In general emails with SOFTFAIL qualifier are accepted but flagged.
The SPF TXT DNS record is composed of SPF version (specified with the tag v= it can only be followed by the value spf1) and one of more mechanisms. Mechanisms are used to specify if a domain can send the email. Mechanisms include specifying IPv4/IPv6 address ranges or checking if A, MX or PTR records resolve to the domain. Other mechanisms exist but are rarely used.

SPF alone is not enough to detect email forging because it checks envelope information only, it would still be possible to keep the original sender in the envelope information and forge only the headers that are interpreted by the client and can’t be checked with SPF. Usually a failed SPF check is enough to mark the email as spam or even reject it. It’s worth noting that SPF policies could cause troubles in case of email forwarding even if the sender is authorized. That’s because the “forwarder” is technically not authorized to send emails on the behalf the original domain.
DomainKeys Identified Mail (DKIM) DKIM is an authentication method that allows the receiver to check if the email was authorized by the owner of the domain and functions as an integrity check to make sure the message hasn’t been modified. This check is possible thanks to an additional header containing a digital signature. A public key, that makes the signature validation possible, is available in a dedicated TXT DNS record. This method only checks the validity of email’s header and body, the envelope addresses are ignored. It’s possible to specify which headers to check, but the RFC5322.From header must always be checked. DKIM checks can and should be done at every SMTP hop and should resist relaying across MTAs .

Important info contained in the DKIM headers of an email are:
- b: signature of header and body
- bh: body hash
- d: signing domain
- s: selector
- h: header fields that has been signed
But information about the protocol, the algorithm used to sign and more can be present in optional tags.

The information useful to verify the signature are present in the TXT DNS record and are presented in the form of key-value pairs:
- k: algorithm to be used
- v: version of DKIM
- p: public key to validate the signature
More tags can be present, but are not useful for our analysis.

DKIM records are published at selector._domainkey.example.com.
Domain-based Message Authentication, Reporting and Conformance (DMARC) DMARC is an email authentication protocol. Using a TXT DNS record, it dictates the conditions under which an email is considered authenticated. It works on top of DKIM and SPF: these two mechanisms, as shown above, offer different checks on the authenticity of an email sender.
Both DKIM and SPF can offer authenticated identifiers in DMARC, meaning that DKIM d= tag of a validated DKIM-Signature header field and SPF validated MAIL FROM field can be used to validate an email’s sender.

DMARC alignment basically checks that the domain name in the RFC5322.From field, is “aligned” (matches) with either DKIM or SPF authenticated identifier. There are two types of alignment in DMARC, strict or relaxed. With strict alignment, the domain needs to be identical, while with relaxed alignment, a domain is considered aligned if the top-level domain match.

It’s also possible to define policies to specify how to deal with authentication failures. These policies are:
- none: no action required by the receivers. It allows the domain to receive feedback reports.
- quarantine: suggests that emails that fail DMARC check are flagged (marked as spam).
- reject: suggests that emails that fail DMARC check are discarded.
A TXT DNS entry for DMARC is composed of:
- v: version
- p: policy
- sp: sub-domain policy
- pct: percentage of non authenticated emails to which apply the policy
- rua: email address to send reports to
The use of pct is interesting because it can lower the protection offered by DMARC. By default pct is set to 100%, but if it wasn’t, the receiver should use a Bernoulli sampling algorithm to check how the policy is to be applied to the email. If an email doesn’t fall under the percentage specified in pct, a lower policy is to be applied to the email. So if p=reject, the quarantine policy is to be used and if p=quarantine, the none policy is to be applied.

DMARC records are published at _dmarc.example.com.

While SPF and DKIM work properly, they both have defects:

SPF checks the envelope from address, leaving the header from address not considered. This means that a malicious user can send an email from a whitelisted domain and spoof the header from address. This can lead to a situation in which the email is considered valid, but a domain different than the expected one is shown to the receiver.
DKIM only checks parts of the email, this means that, leaving such parts untouched, a malicious user can add other headers and make the receiving part see an apparently valid message, but with spoofed parts.

This leaves DMARC as the only viable solution for a more comprehensive domain security.

Vulnerable configurations

When it comes to email security implemented with DMARC, there are 4 main vulnerable scenarios to consider:

Case 1
There is a DMARC DNS record, this entry describes a DMARC entry and it has a policy different than “none”. In this case it’s impossible to spoof an email from this domain.
Case 2
There is a DMARC DNS record and a valid DMARC entry, but the policy is set to “none”, meaning that, even if feedback reports will be sent, the domain is spoofable in emails.
Case 3
There is no DMARC DNS record in a domain that is used to send emails. This is the worst possible scenario because the domain is completely unprotected.
Case 4
There is no DMARC DNS record in a domain not used to send emails. The domain is spoofable, but the impact is not as big as in case 3. It is suggested to have DMARC in place even for domain not used to send emails, but it’s not fundamental.

Of course to thoroughly evaluate the security in place, it’s important to consider eventual SPF and DKIM policies, even if no DMARC protection is set up.

The most direct way to check the configuration is to query the DNS, for this article I’ll specify the way to do this in a unix based system, but more info can be found here. We will use google.com as a domain for our experiments.

Find the SPF record

Using dig it’s possible to get TXT records for a domain. The command is dig google.com txt and the output looks like this:

; <<>> DiG 9.16.8-Ubuntu <<>> google.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8353
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.			IN	TXT

;; ANSWER SECTION:
google.com.		3600	IN	TXT	"MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
google.com.		3600	IN	TXT	"v=spf1 include:_spf.google.com ~all"
google.com.		3600	IN	TXT	"google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
google.com.		3600	IN	TXT	"google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com.		3600	IN	TXT	"apple-domain-verification=30afIBcvSuDV2PLX"
google.com.		3600	IN	TXT	"docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com.		3600	IN	TXT	"globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com.		3600	IN	TXT	"facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com.		3600	IN	TXT	"docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"

;; Query time: 328 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 23 22:29:59 CET 2021
;; MSG SIZE  rcvd: 625

then we need to find the SPF record between TXT records. We simply need to find the one starting with v=spf, in this case it is google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all". Or we can use grep to extract the information directly: dig google.com txt | grep spf.

Find the DKIM record

The DKIM entry is located at selector._domainkey.example.com, so to find the DKIM record we first need to find the DKIM selector. This can be done in two ways, get it from an email received from the domain we are researching or trying to achieve a zone transfer.

From an email, we just need to look for the original message (containing the headers), if DKIM is enabled, one of the fields will be DKIM-Signature: followed by different elements; what we are looking for is s= that is followed by the selector. If we can’t receive an email from a specific domain, it’s possible to try and get a zone transfer, it’s basically a dump of every DNS record from a nameserver. This can be done with the command: dig axfr @nameserver example.com. The nameservers can be found using the command dig ns example.com. Sadly google.com won’t allow zone transfer. It’s possible to practice this technique using zonetransfer.me, this website also contains a lot of cool info about DNS and zone transfers.

I was able to recover the selector from an email received from google.com. Once we have the selector, we can get info about DKIM using the command: dig 20210112._domainkey.google.com txt. The output looks like this:

; <<>> DiG 9.16.8-Ubuntu <<>> 20210112._domainkey.google.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52118
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;20210112._domainkey.google.com.	IN	TXT

;; ANSWER SECTION:
20210112._domainkey.google.com.	3600 IN	TXT	"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtnbQAeqvEP2pG2L540W9JvVU7qy767Zs83Hjw34PCkZ9/9dWE6cK+CYaMNIQqTGfwq4uUe3diBuz3Uikkr+WPMj9AuxtxJqUAO8PsZ2Y5DneFpz5kVesC9/rtXgCwgYOmO" "9UjSy4IN11ewXUBuCH+zp2v5Abv5T0Lol/nWl8wLgRI1IesstingY4cnSfo3Pq3U0I1GAxdNFCK2FPedPpg4sdPpHqtxVvRLMLamRKoUfySBMjpXuMNL0UeCizmFfdUL73ZdiS+MNxGECzFNmeCngFBscLQN++urvfB9OqHQrbxLIwNyni3KMbE/E+cxPkx4KxhyGHSU2klV1vvIAHfwIDAQAB"

;; Query time: 92 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 23 22:23:32 CET 2021
;; MSG SIZE  rcvd: 483

Find the DMARC record

The DMARC record is easy to find, just for the SPF record, we can use dig _dmarc.google.com txt to get what we are looking for.

The output is:

; <<>> DiG 9.16.8-Ubuntu <<>> _dmarc.google.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28825
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_dmarc.google.com.		IN	TXT

;; ANSWER SECTION:
_dmarc.google.com.	300	IN	TXT	"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

;; Query time: 44 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 23 22:29:14 CET 2021
;; MSG SIZE  rcvd: 117

Another way to find these information is to use online tools like this, but I think that it’s better to query the DNS server manually to better understand how these things work.

Actually spoofing an email

Now that we have an overview of email security, we can go ahead and try to actually spoof an email.

Now, if you tried sending an email via code in past, you know for sure that it’s really hard to avoid ending up in the spam folder, even if you are trying to send an email from a legitimate domain and you are authorized. Said that, let’s go through some experiments I made and examine how feasible it really is to send spoofed emails from scratches.

Anyway, let’s dive into it.

First of we need to setup a vulnerable server or try to find a vulnerable domain administrator that will allow you to spoof their domain name. Luckily using bug bounty programs it’s easy to find vulnerable domains you’re allowed to work with.

Now, if you are familiar on the “raw” email format, you’ll know that the email is nothing but a text composed of headers-values and the content of the email. For this reason it’s possible to “spoof” headers like From, Reply-to, Sender.

First attempt: using Gmail SMTP server

I tried using my gmail account to send an email using google servers. To do that I had to enable access from less secure apps on my account. This is the only way to login into a google service from code you write.

Now, it’s not possible to specify envelope information, but it’s possible to send the email and specify the From:, Reply-to: and Sender: headers. Using the From: field, I was able to change the sender name, but the email displayed by the client would be the one from the account used to login into gmail. If no From: header was specified, the header will be inferred by gmail servers and the email address (without the domain) will be used. Specifying the Sender: header didn’t do much, if it was simply ignored, both with or without the From: header. The Reply-to: header was interpreted just like Sender:, but if specified, emails would be marked as “promotions” by gmail’s client.

Using different SMTP servers or clients will possibly lead to different results.

This is the code snippet used for this experiment:

import smtplib

gmail_user = 'YOUR-EMAIL-HERE@gmail.com'
gmail_password = 'YOUR-PASSWORD-HERE'

sent_from_name = "Foo"
sent_from = 'foobar@spam.com'
to = 'receiver@email.com'
subject = 'This is a spoofed email'
body = "This is the content of a spoofed email"


email_text = f"""\
MIME-Version: 1.0
Date: Thu, 29 Apr 2021 18:49:13 +0200
Subject: {subject}
From: {sent_from_name} <{sent_from}>
To: {to}

{body}
"""

try:
    server = smtplib.SMTP_SSL('smtp.gmail.com', 465)
    server.ehlo()
    server.login(gmail_user, gmail_password)
    server.sendmail(sent_from, to, email_text)
    server.close()

    print("Email sent!")
except Exception as e:
    print(e)
    print("Email not sent!")

Second attempt: setting up your personal SMTP server

Installing an SMTP server on your machine would make it possible to send emails from your computer using a script similar to the one used for google. Sadly this experiment won’t let you send emails, this is for different reasons: for starters the IP address from which the email is sent is from a residential IP range. This means that if your ISP doesn’t block the email (very possible), the receiving client will ignore the email because of the poor IP reputation.

I think it’s possible to send emails using this technique if an AWS, GCP or Azure VM is used, this simply because the IP wouldn’t be from a residential range anymore. I didn’t try this yet, but I’m confident that emails would be at least delivered.

Third attempt: using online services

With this approach I was able to send spoofed emails! I’m not linking any of the services I tried using, but there are free or paid services that actually work and let you specify the headers we are interested into.

Sadly most of the emails will end up in the spam folder or discarded by the client due to bad IP reputation (I think). But it’s a fun experiment to see how the emails are treated. Using a client with less protections (like online temporary email addresses ones) will allow the reception of the email.

Conclusions

I think that the main take-away from this article should be an increased awareness about email security, mainly because of a deeper understanding of spoofing techniques. For me personally, experimenting and researching on this topic was useful because I could work with DNS queries and gather insights about DNS security, a topic I’d love to further explore.

Sadly I couldn’t experiment much at the moment, but I will for sure try and send emails from a VPS or Virtual Machine in the cloud that use a non-residential IP, I’m confident this approach would work in sending spoofed emails on vulnerable domains.

This article was reviewed by Nicola Selenu from topdeliverability.com, big thanks to him!

Walkthrough: CryptoHack CTF

Sun, 03 Oct 2021 12:41:44 +0200

Recently I’ve been meaning to get into cryptography more seriously, and to be honest I’ve also been postponing it for a while too, so I figured it was time I wrote this article to get motivated!

I’m approaching this cryptography deep dive with https://cryptohack.org/. Cryptohack it’s website offering CTF style challenges to understand and try to break modern cryptography. I really like this gamified approach so I decided to give it a shot.

Disclaimer

You always need to be extra careful when sharing CTFs solutions online. That’s the reason why I’m strictly following cryptohack’s guidelines. As requested in the website’s FAQ I’m only sharing solutions for challenges worth 10 points or less. These challenges are pretty basic, but I felt like it would be useful to have this kind of content published for those who are not familiar with basic cryptography or with the coding tools and technologies needed to solve the challenges. Each challenge solution will be explained but no flag will be available in this article.

Cryptohack also has a functionality to share the solution once you get the flag for the challenge. Solutions to more complex challenges are to be shared exclusively there. The solutions are however only available for the solvers of the relative challenge.

Make sure to download the python notebook with the code snippets from this article here.

Page index

Setup

Before starting I suggest getting the official docker image provided in the FAQs. You simply need to pull hyperreality/cryptohack:latest.

To run the container simply run the provided command: docker run -p 127.0.0.1:8888:8888 -it hyperreality/cryptohack:latest

This will start a Jupyter Notebook server reachable at localhost:8888. If you don’t want to use notebooks to solve the challenges but still want to use the container because of dependencies, you can overwrite the entrypoint of the image with the following command: docker run -it --entrypoint /bin/bash -p 127.0.0.1:8888:8888 -v hyperreality/cryptohack:latest

Once the docker situation is under control, we can start working on the challenges.

Introduction Challenges

These challenges are basically tutorials to get familiar with how the challenges on this website works. They show the flag format, how to work with the challenge scripts and how to approach the network based attacks.

Finding Flags (2 pts.)

Simply follow the instructions and copy-paste the flag in the text field.

Great Snakes (3 pts.)

For this one you need to execute the provided python script, that will print out the flag.

Network Attacks (5 pts.)

We need to interact with a TCP server using JSON messages. The website suggests using python and telnetlib to do so. It also provides an example showing how to interact with the server of this challenge.

What we need to do to get the flag is to play around a little bit with the server and find the correct request to buy a flag.

Solution:

# import the libraries needed for the challenge
import telnetlib
import json

HOST = "socket.cryptohack.org"
PORT = 11112

# initialize the connection
tn = telnetlib.Telnet(HOST, PORT)

# define functions to receive and send JSON payloads over TCP
def readline():
    return tn.read_until(b"\n")

def json_recv():
    line = readline()
    return json.loads(line.decode())

def json_send(hsh):
    request = json.dumps(hsh).encode()
    tn.write(request)
  
# reads the banner printed by the server
print(readline())
print(readline())
print(readline())
print(readline())

# ------ Request example ------
# Compose a request for the server
request = {"buy": "clothes"}

# Sends the request
json_send(request)

# Gets the response
response = json_recv()

print(response) # {'error': 'Sorry! All we have to sell are flags.'}

# ------ Real request ------
# mhhh flags you say?
request = {"buy": "flag"}

# Sends the request
json_send(request)

# Gets the response
response = json_recv()

print(response)

General Challenges

Encoding

For these challenges it’s not really necessary to write any code. While writing your own scripts can help getting familiar with tools and techniques, a deeper understanding of encodings can be obtained solving the challenges in different ways.

A super-versatile and commonly used tool for this kind of task is CyberChef.

ASCII (5 pts.)

We are given a 7-bit ASCII encoded string and we need to decode it to get the flag. The challenge hint suggests that we use the python chr() function to do to.

Solution:

# ASCII values to decode
values = [99, 114, 121, 112, 116, 111, 123, 65, 83, 67, 73, 73, 95, 112, 114, 49, 110, 116, 52, 98, 108, 51, 125]

solution = ""
for v in values:
    solution += chr(v)
    
print(solution)

Hex (5 pts.)

In this challenge we are provided with an hex encoded string we need to decode. This time the challenge hint suggests using the bytes.fromhex() function.

Solution:

# HEX values to decode
values = "63727970746f7b596f755f77696c6c5f62655f776f726b696e675f776974685f6865785f737472696e67735f615f6c6f747d"

solution = bytes.fromhex(values).decode('utf-8')

print(solution)

Base64 (10 pts.)

For this challenge we are given an hex encoded string, to be decoded and then encoded in base64 to be used as flag. In this case we will be using the base64 python module, in particular the base64.b64encode().

Solution:

import base64

# HEX values to decode
values = "72bca9b68fc16ac7beeb8f849dca1d8a783e8acf9679bf9269f7bf"

# Decoded values
tmp = bytes.fromhex(values)
# print(tmp)
solution = base64.b64encode(tmp).decode('utf-8')

print(solution)

Bytes and Big Integers (10 pts.)

Some cryptosystems like RSA work only when applied to numbers. We need to encode our messages as numbers in order to work with these cryptosystems. One method to do so is to represent the data as bytes and convert these in a base-16 or base-10 number.

In this challenge we are provided with a message encoded in this way and we need to get the original message out.

For this challenge the PyCryptodome library it needed, we can work with this encoding using the functions: Crypto.Util.number.bytes_to_long() and Crypto.Util.number.long_to_bytes().

Solution:

from Crypto.Util.number import long_to_bytes

# Message encoded as number
values = 11515195063862318899931685488813747395775516287289682636499965282714637259206269

solution = long_to_bytes(values).decode('utf-8')

print(solution)

XOR

XOR Starter (10 pts.)

In this challenge we need to XOR the value 13 to each character of the provided string, then we need to put the result in the cyber{flag} format. The hint suggests that it’s possible to use the xor() function from pwntools but it’s just as easy to do the same in pure python.

Solution:

# Provided string
values = "label"

solution = ""
for v in values:
    solution += chr(ord(v) ^ 13)
    
# The {{{var}}} syntax is needed to excape curly braces in python f-strings
print(f"crypto{{{solution}}}")

Mathematics

Lattices

Vectors (10 pts.)

In this challenge we are asked to perform operations on a three dimensional vector space. If this sounds new to you make sure to carefully read the challenge description and check the suggested materials.

Solution:

v = (2,6,3)
w = (1,0,0)
u = (7,7,2)

def vector_minus(a, b):
   return [x - y for x, y in zip(a,b)]

def vector_dot(a,b):
    return sum([x * y for x, y in zip(a,b)])
    
def scalar_times(a, times):
    return list(map( lambda x: x * times , a))

# calculate 3*(2*v - w) ∙ 2*u
vector_dot(scalar_times(vector_minus(scalar_times(v, 2), w), 3), scalar_times(u, 2))

Symmetric Ciphers

How AES Works

Keyed Permutations (5 pts.)

In this challenge we are asked to answer a question: What is the mathematical term for a one-to-one correspondence? Google is your friend for this one!

Resisting Bruteforce (10 pts.)

This time we are asked: What is the name for the best single-key attack against AES?
Just make sure you carefully read the challenge description and you’re good to go!

RSA

Starter

RSA Starter 1 (10 pts.)

The basis of RSA encryption is modular exponentiation. In this challenge we are asked to use such technique to create a “trapdoor function” (a function easy to calculate but hard to reverse). This can be done using the pow() function that python provides.

Solution:

# Calculate 101^17 mod 22663
pow(101, 17, 22663)

Diffie-Hellman

Starter

Diffie-Hellman Starter 1 (10 pts.)

The Diffie-Hellman algorithm works with finite fields and modular exponentiation to allow to parties to exchange a shared secret. If you’re not familiar with this algorithm or with the math behind it I would suggest to check out the Wikipedia page to get started.

In this challenge we are asked to find an inverse element given the prime number and the modulo.

Solution:

g = 209
p = 991
fc = 1

for x in range(1, p):    
    if (g * x) % p == fc:         
        print(x)        
        break

Crypto On The Web

JSON web tokens

Token Appreciation (5 pts.)

JWTs or JSON Web Tokens are a standard method to safely represent claims between two parties. This kind of token is not encrypted by default, and this is the reason why it’s possible to reverse the encoding and extract the original message.

We are given the token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmbGFnIjoiY3J5cHRve2p3dF9jb250ZW50c19j YW5fYmVfZWFzaWx5X3ZpZXdlZH0iLCJ1c2VyIjoiQ3J5cHRvIE1jSGFjayIsImV4cCI6MjAwNT AzMzQ5M30.shKSmZfgGVvd2OSB2CGezzJ3N6WAULo3w9zCl_T47K

Now, there are a few ways to solve this challenge, the suggested one is to use Python’s PyJWT library, but since it’s not installed in the docker container we are using, it’s easier to use an online tool like CyberChef or jwt.io.

JWT Sessions (10 pts.)

In this challenge we are given some information about the use of JWT tokens, now we are asked the HTTP header used by the browser to send JWTs to the server. Once again Google is your friend!

If you want to solve this challenge on your own, take out the developer tools in your browser, go to the network tab and start looking around for HTTP headers that could refer to the use of JWT tokens. You’re authorized to do that!

Conclusions

Hope this article is useful to anyone who’s meaning to get into cryptography or CTFs in general. Writing this article allowed me to go back and review my knowledge of basic cryptography as well as exploring a bit out of my comfort zone (when it came to more complex challenges not included in the writeup).

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!

Dev Chronicles: Creating an HTTP attack client

Thu, 01 Apr 2021 23:23:00 +0200

Intrudo is a tool for automating customized attacks against web applications loosely shaped after burp intruder.


Intrudo logo

Check it out: https://github.com/0xless/Intrudo

A little of background

While working on CTFs I would usually write a bunch of lines of python to automate attacks, it worked fine, but I felt like I needed to improve my workflow. So I decided to learn new approaches and strengthen my use of commercial offensive tools.
I have used burp suite in the past, but I have not taken the time to explore it thoroughly, so I figured the best way to do that would be the labs that PortSwigger created for this reason.

The idea of developing this tool came to me when working on SQL injection challenges. The labs and the learning material were great, but the throttling on the requests in burp intruder (community version only) was making it difficult to complete these challenges. Due to the throttling, completing a challenge would take several hours since for every request sent, you have to wait more and more.

Every challenge was focused on retrieving an administrative password, in some of these challenges a request needed to be sent for every possible letter and digit for each character of the password. Now these challenges could be solved in two ways. You could either send requests to discover one character at time or try to automate it using the “cluster bomb” attack. In the first scenario, you’d have to adjust the parameters and manually launch the attack every 30 minutes or so. In the second scenario, you could automate the whole thing, if the challenge password didn’t change mid-attack because the client took so long to send the requests.

One would assume these challenges were developed specifically to make it harder to solve for those who didn’t have a paid version of the software. I’m not implying they have a malicious intent, but they could have made it easier for everybody to solve the challenges and learn from the awesome materials they share.

After my experience with PortSwigger’s labs, I decided to develop Intrudo; a fast, throttling free alternative to burp intruder.

The initial approach

My first idea was to use multithreading so I started surfing the web for ideas and found aiohttp, and asynchronous HTTP Client/Server based on asyncio. It wasn’t multithreading but it seemed perfect for this project.

Unfortunately, I was not lucky with the choice of developing around aiohttp as the client was strict on what requests can be sent and how they are sent.

I learned this the hard way, of course. I spent a few days developing with aiohttp and all I could achieve was an incredibly fast fuzzer that would only work on URL parameters. Big let down.

At this point I could try two things:

see if I could find some libraries I could fork
implement my own client consisting of bare bones sockets and some good ol' asyncio magic

The wrong way

So I decided to try and modify some libraries first. It turns out every library that implements an HTTP client wants to ensure it is compliant and do so by thoroughly reviewing the data an user would want to send. Usually these libraries make you specify method, URL, headers and body of the request separately.

While this approach with HTTP complaint requests works well for standard clients and preventing errors, it is not flexible enough for this type of project. This makes it incredibly hard to implement complex attack logic, work with headers and cookies and send non-HTTP compliant malformed data.

After looking around, studying the HTTP protocol specifications and coding for a few hours, I was able to read some requests (non-chunked transfer encoding ones) and manage content compression!

Well, to be completely honest, I borrowed and modified some code from urllib3 to handle the decompression.

I did this for two reasons:

the code is clean, simple and well tested
someone has already considered aspects of the HTTP standard I didn’t even know existed

Since urllib3 worked so well I decided to try and use as much code as I could.
One tweak here and one tweak there and I got myself into completely modifying urllib3… Bad idea!
urllib3 offers great client functionalities, but it’s too high level and wouldn’t let me work with asyncio streams to read data.

urllib3 requests are made by http.client, a standard python library. So guess, what I tried next? You guessed correctly, I attempted to hack http.client to work with asyncio. I knew from the beginning that it wasn’t a smart idea, and it turns out I was right: modifying the http library to suit my needs is an hard task. http.client would only read file-like objects and there was no way I could make it to use asyncio streams (without rewriting a huge portion of the code, of course).

If you can’t beat ‘em, join ‘em, right? So I decided to “transform” asyncio streams into files with the hope urllib3 will come to like them. At this point you may think: “less, if you read the whole content of a socket, the client would not be asynchronous anymore!”, and my answer to that would be ~~"mind your own business"~~ “we can manage sockets in some kind of spooled way!”. But of course that didn’t pan out.

After a few hours of unsuccessful attempts, I decided to take a step back and code the whole client from scratch.

The right way?

I quickly realized it wasn’t as easy as I expected it to be, but I did find some well written documents that helped me better understand what I was I was looking for. So, the custom HTTP client adventure begins!

I was able to put together some code I had already written and the decompression module from urllib3. That resulted in an HTTP 1.0 semi-compliant client (it would have been nice if HTTP 1.0 was used anytime in history, but sadly it has not). I want to make it HTTP 1.1 compliant to the extent that I need the client to be compliant, so the only thing missing would be to manage chunked transfer encoding.

After avoiding this for a whole week, I realized it was easier than I expected. If I hadn’t wasted so much time trying to poke at the libraries, I probably would have had a nice piece of client already. But you can’t cry over spilled milk, so let’s get back to work! After 1 hour of coding and 1 hour of debugging, I was able to achieve HTTP 1.1 compliance!

And just like that “cliente” was born: a fully asynchronous, unrestricted, HTTP attack client. Simple yet effective.

The right way!

Everything seemed to work smoothly after the custom client was complete. I implemented the payload position logics just like in burp intruder (pitchfork, sniper, cluster bomb and battering ram), it was not easy to work with two delimiters: I had to play around a little bit with regex and had to work with payload position offsets given by the substitution of a text with a payload. To this day I’m sure there must be a better solution.

After that I implemented a few simple callback mechanisms to manage, analyze and store incoming responses which match user specified criteria.

It’s only a draft, but the very first version of Intrudo was complete!

Here’s a little demo of the speed Intrudo can offer at the moment:

What I learned

Of course the main takeaway is a deeper understanding of the HTTP protocol, especially when it comes to encodings and compression methods, since I had to work with these directly.

Working with raw HTTP requests was also the main challenge, ensuring that an user specified request is acceptable by the server was an hard task. Since there are no debug messages this process was based on a “try and fail” method and I had to read multiple rfc documents on the standard but I could complete this task, at least for the majority of servers I’ve experimented with.

Another interesting thing I got from this project is a grasp of asynchronous programming. I had studied it in theory but learning a framework to actually write asynchronous programs is different thing. asyncio is a powerful tool I will be using in other projects.

Finally I had to mess around with regex and learned about greedy regex. Handling the placeholder delimiters in the requests wasn’t straightforward and for the sake of performance (to avoid recomputing placeholder positions for each payload inserted) I had to develop a module that would insert the payload in the desired position considering the offsets from previously inserted payloads.

To be continued

There are a few things that need to be done:

The callbacks are not as complete as burp intruder ones.
There is no payload generator (but that’s because Intrudo is to be used as a framework, not with a GUI).
Some servers will always respond with “bad request” (can’t figure out why).
Some serious testing is yet to be done.
The timeout on requests is to be calculated with an adaptive function to optimize the throughput.