Forem: Douxx

An Attempt to Ban Bad Bots Crawling My Sites

Douxx — Tue, 31 Mar 2026 17:23:16 +0000

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 🤡

Building a Web Server from Scratch (No, Actually)

Douxx — Mon, 16 Mar 2026 00:20:44 +0000

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:

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




The [`accept`](https://manpages.debian.org/unstable/manpages-dev/accept.2.en.html) syscall handles both waiting (blocking) and accepting in one shot. And guess what it returns? A file!!
[[-> program.asm]](https://github.com/douxxtech/nasmserver/blob/0f7cab0cbe27963e078fb7257371919416c107b9/program.asm#L142-L156)

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`](https://manpages.debian.org/unstable/manpages-dev/read.2.en.html) syscall and dump it into a buffer.

[[-> program.asm]](https://github.com/douxxtech/nasmserver/blob/0f7cab0cbe27963e078fb7257371919416c107b9/program.asm#L222)
[[-> fileutils.asm]](https://github.com/douxxtech/nasmserver/blob/0f7cab0cbe27963e078fb7257371919416c107b9/macros/fileutils.asm#L113-L121)

Then we check if it's a valid HTTP request. If not, we send back a [400 Bad Request](https://developer.mozilla.org/de/docs/Web/HTTP/Reference/Status/400). A very minimal valid request looks like:



```plaintext
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:

HTTP/1.0 200 OK: static string, HTTP version + status code
Server: NASMServer/1.0: not required, but nice to have
Content-Type: text/html: tells the client what it's receiving, must follow Media Types format
Content-Length: 1442: byte count of the response, grabbed from stat
Connection: close: we won't keep the connection alive after sending
\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:

shutdown: tell the client we're done
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:

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

Results

Server	Localhost	Windows Host	Network	Average
BusyBox HTTPD	0.0004677s	0.0075919s	0.0038408s	0.0039668s
NASMServer	0.0005997s	0.0082924s	0.0076072s	0.0054998s
Apache2	0.0004769s	0.0102861s	0.0062916s	0.0056849s

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.

Bringing Web Radios Back to FM

Douxx — Sat, 28 Feb 2026 12:00:29 +0000

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 !~~

How I Built a Random Number Generator (Sort Of)

Douxx — Sat, 07 Feb 2026 22:26:59 +0000

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 the "randomizer". 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:

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

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)

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

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.

Questions? Ideas?

If you have any questions about the implementation, suggestions for improvements, or you've experimented with similar approaches, feel free to drop a comment below. I'm curious to hear what you think!

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