I bypassed the anti-bot of Castle.io. Here is what I learned.
A few days ago, I came across a video from Underscore. In this episode, Antoine Vastel, research director at Castle, talks about the fight against bots... and mentions a certain Sylvestre, creator of a service that bypassed their protections. Nice to meet you 👋
For those who don't know, Castle is a bot detection and fraud solution used by many sites (Rockstar Games, Canva…) to distinguish real users from automated scripts. CastleSolver, my service, did the opposite: it allowed users to bypass the protections.
I launched this project in August 2025, without much ambition: I was mainly looking to have fun and see how far I could go. I stopped it many months ago, and I deliberately chose never to publish the code so it wouldn't be reused.
We often hear about bot detection from the defenders' perspective, much less frequently from the perspective of those on the other side. Hearing my project mentioned in a podcast made me want to tell this other version: how I approached the problem, the cat-and-mouse game with the Castle teams, what it taught me technically and personally, and why I ultimately decided to stop everything.
Important clarification: this article is not a tutorial. I will not provide any details that would allow reproducing what I did. What interests me here is the approach, not the recipe.
Let's go.
1. How I Discovered Castle
It all starts on July 31, 2025. I was bored in front of my computer, hanging out in reverse engineering communities... and I discovered that Twitter had just integrated Castle.
Seizing the opportunity to keep myself busy, I decided to dig deeper.
Castle didn't have a great reputation: many considered it to be an incompetent anti-bot.
But hey, nothing like a good little challenge to occupy my vacation!
2. First Impressions
My first step: search the internet for services or traces left by others who had attempted the same thing.
Result: nothing (except for a blog that was largely outdated). I then thought that I would probably have to do everything myself.
After a quick look on Twitter, I noticed that Castle was well integrated there, but that its results were not yet verified on the server side. In other words, it was probably still in a testing phase.
So, I turned to another site protected by Castle, to be able to develop everything from end to end and verify that my tool really worked.
3. Reverse Engineering
I won't go into details, but what you need to remember is that the method is always the same and quite simple:
- Find the function, the entry point of the script (usually publicly documented)
- Trace the operation of this function
- Go further up to find the collected data, encryption algorithms, compression, etc.
Once all that is traced, you can write a script that replicates Castle's functionality, but without a browser.
I start by transcribing the encryption algorithms, encoding, etc., in a readable manner, until I can encrypt the data of my choice.
All that's left is to simulate user fingerprints that appear real.
For that, I use a simple method:
- I retrieve my browser's fingerprint
- I slightly modify it to change certain values
After setting up a simple site, I start talking about it in a few automation groups.
4. The Cat and Mouse Game
At first, everything works. The site grows:
1 user. 5. 10. 50…
10 tests solved. 100. 1,000. 100,000…
And of course, when you're one of the only services on the market, problems arise…
Castle adds protections, forcing me to modify my script almost every day.
So, how was I getting detected? Due to a lack of rigor.
Unfortunately, when you move quickly, you make mistakes. Many algorithms were poorly transposed, rendering some data invalid, impossible, or inconsistent.
Another detection vector was the reuse of the same fingerprint. Castle added a usage limit per device: if the same fingerprint is used too many times in a short period, it gets blocked.
Each detection forced me to understand what I had done wrong, correct it, and then wait for the next counterattack. A real game of cat and mouse, except I never really knew if I was the cat or the mouse.
5. The Beginning of the End
Everything was going well until early December. Castle then decided to make a major update:
- Better obfuscation
- Better detection
In short, everything was better.
Overnight, nothing passed anymore. Not a small correction to make as usual: the entire script had to be reviewed. It was no longer just another counterattack; it was a level change.
At that moment, I thought it was just another step. That I would find a way, like the other times. I was wrong.
6. Three Months
What followed were three months during which I tested pretty much everything, reviewed everything, and rebuilt everything.
I worked from morning to night. At home, in class, on vacation. Whenever I had a moment, I went back to the project. In fact, my life revolved around it, or almost.
The cycle was always the same:
- A new idea, a new technique
- Hours (sometimes days) to implement it
- An encouraging first test
- Then detection. Again.
I collected thousands of real fingerprints, so I wouldn't have to invent them and only modify what was strictly necessary. I rebuilt entire parts of the generator. I rechecked every algorithm, every value, every detail I might have overlooked in the first months.
And in the end, nothing worked.
The hardest part wasn't the failure itself: it was not knowing. Against an anti-bot, you don't get an error message, no logs, just a "no." Impossible to know if you're on the brink of success or completely off track.
7. Closing Up Shop
After these three months, I finally accepted what I had been refusing to see for a while: it wouldn't work anymore.
So I stopped. I gave up and closed the project.
With a heavy heart, of course. You don't invest so much time and energy into something without getting attached to it. But in hindsight, I didn't walk away empty-handed, far from it.
8. What I Take Away from It
Technically
Rigor before speed. The vast majority of my detections came from silly mistakes made because I wanted to go fast. An approximate algorithm, an inconsistent value, a forgotten case… and everything else is useless. Today, I check before moving forward, not after being blocked.
Consistency rather than perfection. A piece of data doesn't need to be perfect; it needs to be consistent with all the others. This is a lesson that goes far beyond the realm of bots.
Methods and tools. Over the months, I learned to structure my work: tools to compare, test, and validate automatically rather than manually, and methods to approach a complex problem without getting lost.
Handling the load. Over 400 users and more than 14 million tests solved: when a service operates at this scale, every bug, every slowdown, every outage is immediately noticeable. I learned to build something reliable, to monitor, to react quickly, and to manage users who rely on you.
Personally
Knowing when to stop. This is probably the most important lesson. For three months, I continued partly because I had already invested so much. But the time spent doesn't make a project more viable. Knowing when to let go is a skill in itself.
Maintaining balance. When a project becomes your whole life, it ends up taking the place of everything else: classes, loved ones, rest. No project deserves that.
Not underestimating the other side. At first, Castle had the reputation of being an incompetent anti-bot. The following months showed me exactly the opposite. Behind every update, there was a team learning, adapting, and ultimately winning.
Reflecting on what you build. Initially, it was a game. But a service used by hundreds of people is no longer really a game. Even if the project was initially quite simple, I had to change everything because it wasn't ready for the scale it would take.
9. Closing the Chapter
For months, the project lingered in the back of my mind, like a door left ajar.
Then, in mid-August, I received a message from the research director at Castle. A friendly message, with no hard feelings, from the one who had spent months trying to stop me, and who had succeeded.
It was at that moment that I truly closed this chapter. In a way, this exchange transformed a defeat into a page that one turns peacefully: on the other side, there wasn't an enemy, just someone passionate about the same subject as me, simply on the right side of the barrier.
A few weeks later, I heard him mention my name in a video from Underscore. The loop is complete.
Conclusion
CastleSolver no longer exists, and that's just fine.
This project took a lot from me, probably too much, but it also gave me a lot: rigor, methods, the experience of a service that can handle the load, and above all, a few lessons I wouldn't have learned otherwise.
If I had to take away one thing: you don't always have to win to come out stronger from a fight.
Thank you for reading this far 👋