Phuc Nguyen

Solving the Captcha Without a Homelab

Sun, 23 Aug 2026 15:38:54 -0400

Last time I wrote about Cloudflare Turnstile breaking InstaPlayer, and about my plan to fix it by turning an old laptop into a homelab so my downloads would come from a residential connection. I did get it working but with a proxy instead of self-hosting.

Since a recent SpotiFLAC update, the provider endpoints only answer requests signed with a key from a valid session, and you can only get that valid session after passing the Cloudflare Turnstile captcha. Sessions expire after about six hours. So my initial thought was to design a system that forwards that captcha to my phone and I would solve it every 6 hours. But that sounded exhausting.

I had everything figured out for a system to bypass that, except the captcha itself, which checks cookies, IP and all sorts of stuff to make sure a human is actually solving it. Luckily, I found a tool called nodriver designed specifically for this. I registered a handler that hands the challenge URL to a small solver that uses nodriver, which drives a real Chrome inside a Docker container.

flowchart LR
E@{ icon: "logos:go", label: "SpotiFLAC engine", form: "square" }
V@{ icon: "logos:python", label: "my solver", form: "square" }
C@{ icon: "logos:chrome", label: "real Chrome in Docker", form: "square" }
T@{ icon: "logos:cloudflare-icon", label: "Turnstile", form: "square" }
E -->|challenge URL| V
V -->|nodriver| C
C -->|solves| T
T -->|token| E
E --> S[(session, valid 6h)]

Unbeknownst to me, finding nodriver was just the start.

Two captchas

I spent more time solving an unrelated problem than actually bypassing the Captcha. The problem was that due to some finicky default configs of nodriver, two Captcha frames are rendered on top of each other, preventing my code from locating the box to click on. And because I ran Chrome in a headless container, I could not use my eyes to see what the problem was. It ended taking me 2 days just to find out the box isn’t invisible.

My clicks were landing on nothing while the debug tool told me the coordinates were right.

I also learned about fingerprinting while making this Captcha bypass feature. Previously, I already knew that Captcha tools don’t actually check if you click the right images of “cows” or “cars” but they check if your browser is of a real user. But now, I learn the extent to which it checks a browser (and the fact that the check can be bypassed).

Turnstile checks for a lot of things. WebGL is the browser feature that draws 3D graphics using your graphics card, and a real computer always reports some renderer for it. The browser’s timezone also has to match its place of origin. The screen resolution has to look like an actual monitor instead of the odd default size when it’s launched in a container. The browser has to run on a display, even a fake one, rather than the headless mode. The mouse has to travel to the checkbox the way a hand would instead of teleporting onto it.And there shouldn’t by any trace of an automation tool. All of these had to be right at the same time, which is the part that took the longest for me.

Fake IP

After I faked the browser’s fingerprint, I managed to get it working on my local machine. There was only one thing left to take care of: IP. In the last part I did realize that making requests from a datacenter’s IP would alert Cloudflare, and I planned to solve that with my homelab. But I found a less exhausting approach, that is to pay for a residential proxy. For 5 dollars, I get 5GB of traffic which will last me the next 3 years. The reason is that I only route the Captcha and Token I obtain from the Captcha through that proxy. Song downloads are routed normally through the datacenter.

flowchart LR
S@{ icon: "logos:docker-icon", label: "my server", form: "square" }
P["proxy"]
D["datacenter"]
T@{ icon: "logos:cloudflare-icon", label: "Turnstile", form: "square" }
M[(backend)]
S -->|"captcha + token<br/>~75 KB"| P
S -->|"songs<br/>30 to 50 MB"| D
P --> T
D --> M

What I learned

Looking back, this issue taught me how to really mask a browser against Captchas, which would probably come in handy in many places. I also learned how much slower debugging gets when you cannot see the screen. I was also proud of the fact that I optimized the proxy traffic to save me a lot of money.

Learning Shell Scripting

Sun, 16 Aug 2026 10:23:30 -0400

I’ve been learning Shell scripting for a while by following the Linux Command Line and Shell Scripting Bible one chapter at a time. My approach is fairly slow, because I read a chapter and then try to write a small program that uses whatever command or trick it just introduced, since I am a practical learner.

My practice scripts all live in a folder called bible, one file per chapter, and I just keep them to look back and see where I once was. This was one of my earlier programs:

if [ -f "$file" ]; then
 echo "$file is a file"
elif [ -d "$file" ]; then
 echo "$file is a directory"
else
 echo "wtf even is $file?"
fi

Learning Shell makes me appreciate features I take for granted in modern languages. Even simple decimal math requires very precise syntax and a call to the bc command. String handling can feel even more finicky because a wrong quote and it is interpreted as a different datatype.

Scripts I use

I originally wanted to learn Shell because I work with CLIs frequently and wanted to cut useless actions by writing scripts to automate them. Here’s one of them called mf to make a sequence of test files with similar names.

for ((i=1; i<=n; i++))
do
 touch "$basename$i.txt"
done

A couple of others do similarly modest jobs, like xlist, which lists the executable files in a folder, and read_env, which pulls variables out of a .env file. On their own they are simple but when I repeat a command a hundred times everyday, a script can feel much quicker and robust.

init

I’m still in the Linux Distro-hopping phase, so I switch OS often and don’t want to deal with setting up a system every time. I made a script called init to set up a fresh machine for me. It makes my other scripts executable, installs the packages I use, updates the system, clones my dotfiles, and stows them into place, though it is still full of TODO features.

Shell scripting is a useful language to learn because it is useful no matter what your tech stack is. And it gives you a new perspective on programming as a student. I feel like this skill will stick with me for the rest of my career.

Turning My Old Laptop Into a Homelab

Sun, 09 Aug 2026 14:21:49 +0700

There is an old laptop sitting in my drawer, and this week I decided it is going to become a server.

I’ve been wanting to self-host my homelab for a long time for the sake of being cool, but recently there’s been a bigger motivation. If you read the last post, you probably know the reason. Cloudflare Turnstile broke my free, opensource, awsome music downloader, and the fix is to send requests from a residential IP instead of from a datacenter. My laptop at home has exactly that kind of connection. So the plan is to move InstaPlayer onto it, and while I am there, turn the laptop into a cheap homelab for me to tinker around.

Here is the plan so far. Some of this I am honestly figuring out as I go.

My own PaaS

I used to deploy InstaPlayer on Zeabur (a Taiwan PaaS startup) and I loved how simple it felt. You can spin up instances of Docker, PostgreSQL and Redis very easily. I want that same from my homelab, so I choosed Coolify as it has the most similar features to Zeabur. My tech stack will be:

flowchart LR
P@{ icon: "logos:android-icon", label: "My phone", form: "square" }
L@{ icon: "logos:ubuntu", label: "Ubuntu + Coolify", form: "square" }
N@{ icon: "logos:chrome", label: "nodriver", form: "square" }
S@{ icon: "logos:cloudflare", label: "Music sources", form: "square" }
P -->|Tailscale| L
L -->|runs the app| N
N -->|residential IP| S

Ubuntu Server as the base
Coolify on top to handle deployment, dashboard and HTTPS
Tailscale to reach my server
nodriver to solve the Turnstile captcha

Setting it up is not too bad. I install Ubuntu, make a normal user instead of living as root, run the Coolify install script, and put the laptop and my phone on the same Tailscale network. Then I deploy InstaPlayer straight from the dashboard and drop in my API key. Last time I set up Caddy to handle HTTPS, but Coolify comes with its own proxy so I probably won’t have to worry about that.

The catch

My server is not that powerful, with an 8th gen i5 with 8GB of RAM. Memory is my main worry because nodriver runs a real Chrome browser which eats up ~1GB. One upside is that my laptop has a battery so I don’t need a power supply in case of a blackout.

Another issue with nodriver. Getting it to run on a headless server is probably finicky. For now this is just the plan, and next week I find how much I need to fix.

Cloudflare broke my music downloader

Sat, 01 Aug 2026 05:00:00 +0700

Part 1 Part 3

This week, I learned the hard way how a dependency can break your whole app.

My music app, InstaPlayer depends entirely on the SpotiFLAC engine to actually fetch songs. In the latest release, the author put a Cloudflare Turnstile captcha in front of the download requests. That means my backend can no longer just ask for a song and get one back, but it must involve a real human behind the scenes to solve the captcha. This absolutely demolishes the user experience, my download flow, and everything I had been planning around it.

flowchart LR
B@{ icon: "logos:docker-icon", label: "InstaPlayer backend", form: "square" }
T@{ icon: "logos:cloudflare-icon", label: "Cloudflare Turnstile", form: "square" }
B -->|download request| T
T -->|looks like human| S[(Music provider)]
T -->|"looks like bot </br>(missing cookies, sus IP,...)"| X[Blocked]

Discovering nodriver

I love web scraping, and if you do too then you know captchas are the biggest enemy. Previously I just ignored them to go a different route but this time, it’s not possible and I had to look for some direct soltuion. I found nodriver, a python package built to get through exactly this kind of Turnstile captcha. After a lot of effort I got it working on my own machine, and for a brief moment I thought that was the solution I needed and I could move on from this mess.

The IP problem

Then I deployed it to my server and it stopped working. The reason is that my server’s IP is blocked by Cloudflare, which is honestly a given. Servers live in datacenters, and it’s not surprising that Cloudflare doesn’t trust this source.

flowchart LR
CFh@{ icon: "logos:cloudflare-icon", label: "Cloudflare", form: "square" }
CFs@{ icon: "logos:cloudflare-icon", label: "Cloudflare", form: "square" }
H[Laptop/Homelab] -->|residential IP| CFh
CFh -->|looks human| OK[Allowed]
S[Rented server] -->|datacenter IP| CFs
CFs -->|looks bot| No[Blocked]

The homelab plan

I plan to build a homelab in a few months with my old laptop, which gives me a real IP address I can use for this. A home connection comes with a real residential IP, which hopefully gets Cloudflare’s trust. I don’t know exactly how well this will hold up, but it is the most plausible and cheapest option I have right now. I am a broke college student, so cheap matters a lot to me.

A possible shortcut

Today, something unexpected happened. Someone from anyip.com looked at my repository and suggested that their service could solve this for me by providing a real residential IP adress. That could open up a much nicer path where I do not have to sacrifice my old laptop. The downside is the pricing. I checked the website and five gigabytes of requests costs twenty five dollars, which is well out of my budget. I am going to reach out to their representative and see if there is any room on pricing for a small project like mine.

flowchart LR
Need@{ icon: "logos:cloudflare-icon", label: "Needs legit-looking IP", form: "square" }
Need --> Home[Homelab, residential IP]
Need --> Proxy[Paid proxy, anyip.com]
Home --> Fixed[Downloads work again]
Proxy --> Fixed

What this could teach me

If that path works out, it changes the kind of problem I get to work on. Now, every request costs real money, so I would have to learn how to optimize request volume and cut out anything wasteful. It would be my first time working with a paid API where my actions have consequences, and I am quite excited about that.

Stay tuned to see how I chase free music!

Why I want a j*b

Mon, 27 Jul 2026 13:00:00 +0700

One of my seniors told me that knowing how to solve a problem makes you a great student, but knowing how to solve the same problem at scale makes you a great engineer. I saw a great example of this on an instagram reel recently and I wanted to share it with you.

The question

You have a table with 300 million rows and you need to add a new column. The catch is that the table is being read and written constantly by users. You cannot take the database offline and you cannot afford any downtime. How do you do it?

The naive approach

If this was one of my projects, I’d say to just add the column and fill it in for every row. That works because nobody is watching and nothing breaks if the database freezes. But if you tried this on your company’s live services, your boss would probably scream at you.

The experienced approach

Like any change on a scaled service, this needs to be broken into stages, and each stage should have minimal impact on users. Here’s how the creator approached the problem.

First you add the column as nullable with no default value. In most modern databases this is only a change to the table description, so the database does not rewrite a single row and the whole thing finishes in milliseconds. The column now exists but it is empty.

The instinct is to start filling in the old rows, but that is not the right next step. Users are still writing new rows every second, and those new rows keep arriving with the column empty. If you fix old rows while new empty rows keep coming, you will never catch up. So you fix the new rows first. You update the application so that every new row already includes the new column, and you deploy that.

Only now do you deal with the old data. You run a background job that fills the column for the old rows in small batches of a few thousand at a time while checking the database load. When that’s finished, the database is successfully miragted!

Why this makes me want a j*b

I used one paragraph to explain the naive approach, and four to explain the experienced approach. This just shows us how harder working on systems with real users can be.

This is the part of engineering I cannot really practice alone. My projects have one user, which is me, so I can take my database down whenever I feel like it and nothing bad happens. Problems like this only show up when a system already carries real traffic and real users. That is a big reason I want to work on real systems at real companies, because it is the one place I get to put my hands on systems at this scale and learn how people actually keep them running.

My music downloader

Thu, 16 Jul 2026 02:30:00 +0700

Part 2 Part 3

On some days, I just need music to function. But as the unemployed college student I am, I’m too poor to afford Spotify premium. I wanted to create a free music player that works out of the box, with my music saved locally. So I built InstaPlayer.

There was one key library that enabled this whole app and it’s SpotiFLAC. It enables me to download songs from multiple providers for free, and I built my app around it. Please give the repo a star!

Architecture

There are two parts. The first is a mobile app written in React Native. The second is a small backend that I self-host behind a Caddy reverse proxy, which does the actual downloading. They talk to each other over a normal REST API, plus a WebSocket for live progress updates (This project helped me learna about websockets for me first time).

A download goes like this:

The app sends a Spotify playlist link to the backend, reaching it through Caddy reverse proxy.
The backend hands the link to the SpotiFLAC engine, which finds the matching lossless file for each track.
As soon as a song finishes, the backend tells the app over the WebSocket.
The app pulls that song and its album art down to the phone.
Once the app has everything, it tells the backend to delete its copy to save storage.

The VPS I rented for the backend had only 50GB, so the last step is pretty important.

Song matching

The interesting problem is how the backend actually finds a song. SpotiFLAC handles this part and this is what I understand it does: Spotify does not let you download anything, so I cannot pull the file from there. Instead, every track carries an ISRC, which is a standard code that identifies a recording no matter which service it lives on. The backend reads the ISRC from the Spotify track, then uses it to find the exact same recording on Tidal, Qobuz, or Amazon, where it can grab the lossless version.

Those sources are community-run and go down fairly often, so a good chunk of the work went into the backend knowing whether it can download right now, and telling the app before you waste time trying. The app shows this as a simple status light, and it will not start a download when the light is red.

What I learned

This was the first time I had to think about a lot of these things, so here are the bits that stuck with me.

manifest.json This project is the first time I implement what I call the manifest.json architecture, which is a json file storing information of each job that allows the client to transfer songs independently and asynchronously from the backend instead of having to wait for it

Using SQLite as the job store. I’ve only used NoSQL (Firebase, MongoDB) and Object (Cloudflare R2, AWS S3) database before. But for this project, I needed something light and works natively, so I chose SQLite.

Reverse proxy with Caddy. I usually use Nginx but I tried out Caddy for its simplicity. It handles HTTPS, TLS and encryption for me with only a few lines of config. I might switch to this from now on!

Building the engine from source instead of installing the package. I first used the Python package for SpotiFLAC, but it kept breaking, so instead I itegrated the upstream Go engine directly into the backend. This took uptime from 20% to 50%, which I’m very happy with.

Update: One serious caveat with trying to integrate the Go binary into my app is that I have to deal with whatever rate-limiting method added upstream. As of now (07/18/26), a new release has just dropped that adds Cloudflare Turnstile capcha. This completely breaks my app and I’m dealing with it now. I might have to revert to the Python Module, which I really don’t want to.

Secure String Comparison

Fri, 10 Jul 2026 15:04:56 +0700

Coincidence

I was tasked with creating a mock login system my club, Google Developers Group at USF, when I came across a very interesting aspect many people overlook while making login systems. On this website, the admin credentials were hardcoded on the frontend. Usernames and passwords were sitting right in the JavaScript, which meant that anyone who opened their browser’s developer tools could read them.

The obvious fix was to move the check to the backend, so that the real credentials never leave the server since NextJS offers SSR. That is where I ran into something that I never gave any though to: how to compare the password the user sent with the one I have stored.

The obvious way

My instinct was to do this:

function safeEqual(a: string, b: string): boolean {
 return a === b
}

This looks fine, and for most things it is. The problem is that string comparison walks through the two values byte by byte and returns immediately when it hits the first byte that does not match. If the very first byte is wrong, it stops right there and returns false. This is where the vulnerability is.

Timing attacks

It is very easy to measure how long the server takes to reject each guess.For example, “aaaa…” that gets rejected in 1µs matched 0 bytes; “maaa…” rejected in 2µs matched 1 byte.

By maximizing the response time one byte at a time, the attacker can rebuild the secret from start to finish without ever guessing the whole thing at once. This is called a timing attack, and it’s why using normal string comparisons can leak passwords.

Comparing in constant time

The fix is to compare the values in constant time. Node gives you this through timingSafeEqual:

import { timingSafeEqual } from 'crypto'

timingSafeEqual(Buffer.from(a), Buffer.from(b))

For two strings of the same length, this function always takes the same amount of time to compare them. This prevents the attacker from guessing the password from the time difference.

The length problem

However, timingSafeEqual is not quite perfect. It throws if the two buffers are not the same length, and a length difference is itself a leak. If a short guess fails instantly with an error while a longer guess runs the full comparison, the attacker learns something about how long the real secret is.

So we need both sides to always be the same length before they reach the comparison, and we need the real length of the secret to never show up there at all.

Hashing first

The way to get that is to run both values through HMAC before comparing them:

// hmac is not a real function

function safeEqual(a: string, b: string): boolean {
 return timingSafeEqual(hmac(a), hmac(b))
}

An HMAC output is a fixed size no matter what you feed it. With something like HMAC-SHA256, every output is exactly 32 bytes, whether the input was one character or ten thousand. That gives us two things at once. The two buffers always have the same length, so timingSafeEqual never throws, and the actual length and content of the secret never reach the comparison.

P/S: JWT is an alternative to HMAC, but for this particular app, where only one pair of credentials is hardcoded, there is little purpose in using JWT.