https://mari.zip/blog strangely quiet here without you Thu, 16 Apr 2026 00:00:00 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en https://mari.zip/blog/call-for-rust-2020 call-for-rust-2020 Mon, 11 Nov 2019 00:00:00 GMT Mari (mellowagain) https://mari.zip/blog/great-things-of-2019 great-things-of-2019 Sun, 12 Jan 2020 00:00:00 GMT Mari (mellowagain) https://mari.zip/blog/great-things-of-2020 great-things-of-2020 Sun, 31 Jan 2021 00:00:00 GMT Mari (mellowagain) https://mari.zip/blog/isolated-dev-environments isolated-dev-environments Sun, 22 Mar 2026 00:00:00 GMT `) and nothing above it. It also features a special SSH agent, showing a GUI prompt every time a program wants to use your SSH key. See the appendix the end of the article for a screenshot of that. More importantly, it is **not a virtual machine**. This means that all programs still run on your original OS' kernel and your native Wayland server. This is especially bad because having access to the Wayland server means also having access to your global clipboard, a limitation that you sadly are not able to work around (for now, I hope). Of course if there is an exploit in the Linux kernel or anything that is exposed to the Litterbox (including Wayland and any devices you explicitly attached with `litterbox devices`), that can then also be exploited. But recent supply chain attacks have mostly been trying to get your credentials to stuff like Git, NPM, crates.io etc. so this provides a good shield against that. Read all about the limitations of Litterbox on its [README](https://github.com/Gerharddc/litterbox?tab=readme-ov-file#isolation-limitations). ## My development environment So let's get ready to set up a Litterbox. I have decided to have **one litterbox per project**. This gives the best isolation between projects but at the expense of disk space, as all runtimes, dependencies and IDE's need to be installed in every litterbox separately. That is a trade-off I am willing to make for the sake of security. You can choose to instead define a litterbox per-language or however you see fit. I'm going to set up a container for this very website, [mari.zip](https://github.com/mellowagain/website) so we need: * `nodejs`, as my project is a Next.js app * `pnpm`, the projects default package manager * `WebStorm`, the JetBrains IDE of choice for Node web development * A new ssh key for the litterbox This list is different per-project, for example for [GitArena](https://github.com/mellowagain/gitarena) I installed `cargo` and `RustRover` instead. ## Installing litterbox Installing it is as simple as running: ```bash curl -fsSL https://litterbox.work/install.sh | sh ``` This will install the latest litterbox version **for your local user**, in my case `litterbox 0.3.2`. Explicitly not system-wide, as it should be. Of course, you can critique the old curl and then pipe into bash, but if you're like that it seems that litterbox is easy to compile by yourself, being fully written in Rust. ## Creating the litterbox Creating the litterbox is a simple two-step progress, first defining it and then building the container. For the name I have chosen marizip to represent the project that is inside of it. ```bash litterbox define marizip ``` It will then ask you for a template, I picked `CachyOS` becaue my main system is Arch so the commands are similiar enough to not get mixed up between main system and container. There is an argument to be had to explicitly use a different distro for your container to always be sure you're running commands in the correct environment, but I decided against it. Next up we need to build the litterbox: ```bash litterbox build marizip ``` It will prompt you to set a user password. I have Bitwarden as my password manager, so I generate a new, unique password for all of my litterboxes. Afterwards it will ask you a lot of questions, these are **very important** to consider as after they have been defined you cannot change them and would have to rebuild your litterbox if you really wanted to. ## The questions ### Network mode ```text ? Choose the network mode for this Litterbox: > Pasta (isolated user-mode networking stack) Pasta with automatic port forwarding (host to container) Pasta with automatic port forwarding (container to host) Pasta with automatic port forwarding (bidirectional) Host networking (i.e. NO ISOLATION) ``` This should be self explaining. As mari.zip is a web app, I often use `pnpm run dev` to quickly spin up a dev server to see changes immediately, so I chose `Pasta with automatic port forwarding (container to host)`. Depending on your applications, you should choose differently. **Do not choose the last option, unless you have good reason to.** ### CAP_NET_RAW ```text ? Do you want to support `ping` inside this Litterbox? (y/N) [This will enable `CAP_NET_RAW`.] ``` If you're around the Kubernetes or devops world, you probably [already know of this](https://kyverno.io/policies/best-practices/require-drop-cap-net-raw/require-drop-cap-net-raw/). `CAP_NET_RAW` enables applications to craft and send arbitrary network packets, as used by tools like `ping` and `nmap` as well as binding to any network address regardless of ownership and intercepting traffic on the network interface. **Unless you have a specific need for it, do not enable it.** ### CAP_NET_ADMIN ```text ? Do you want to support TUN/TAP creation inside this Litterbox? (y/N) [This will enable `CAP_NET_ADMIN` and expose `/dev/net/tun`.] ``` `CAP_NET_ADMIN` is the equivalent of granting root access to network, allowing programs to bring interfaces up and down, assigning IP addresses, modifying the routing table, modifying iptables rules and creating and configuring network namespaces. This is mostly useful if you'd like to run an iptables firewall or a VPN daemon inside the litterbox. **Again, unless you have a specific need for it, do not enable it.** ### Packet forwarding ```text ? Do you want to enable packet forwarding inside this Litterbox? (y/N) ``` Packet forwarding allows programs within the litterbox to act as packet routers, routing packets from one interface to another. This is useful if you're running a VPN server or a proxy within the container. This is **not** however needed for my use case where I just want to visit the local dev server from my main machines browser outside the container. This is just for routing traffic _between_ network interfaces. **Again, unless you have a specific need for it, do not enable it.** ### User groups ```text ? Do you want to keep your user groups inside this Litterbox? (y/N) [This will preserve your host user's group memberships.] ``` In Linux a lot of access is managed through groups, for example `docker` (for rootless docker) or `root` (for running `sudo`). I found this to only really useful if you're passing in `litterbox devices` which are bound to a specific group. **It is most cleanly to not enable it but for your use case it might be required.** For my normal web development however, it isn't. ### seccomp confinement ```text ? Do you want to disable seccomp confinement? (y/N) $ [This enables 'dangerous' syscalls required by things like the Mojo debugger.] ``` Seccomp stands for Secure Computing Mode and is a kernel feature to filter syscalls programs can call. Confinement restricts them to be the normal syscalls most programs use, but for some special ones like debuggers which use `ptrace`, you would need to enable it. **Enable this if your programs need it.** ### Pipewire ```text ? Do you want to expose PipeWire inside this Litterbox? (y/N) [This will allow audio applications to work inside the Litterbox.] ``` This one is relatively simple. Do you need audio in your container like speaker output or microphone input? If yes, go ahead and enable it but for my use case I do not need it. ### SHM size ```text ? Shared memory size in GB (leave empty for default): () [Sets --shm-size for the container (e.g., 8 for 8G).] ``` Setting a big enough shared memory size is essential for programs using IPC, such as for example web browsers or in my case JetBrains IDE's such as WebStorm. I set it to 4 GB for mine, but depending on your setup you might want to choose a different size. ## Installing dependencies Now the litterbox should be successfully built we need to go ahead and install our projects required dependencies. First we need to attach to a terminal within the container: ```bash litterbox enter marizip ``` First we should update all packages in our system: ```bash paru -Syu ``` and then for the project itself we just need Node.js and pnpm, you should adjust for the dependencies required for your project: ```bash paru -S nodejs npm sudo npm install --global corepack@latest corepack enable pnpm ``` and for Webstorm we need to install some additional packages, as described in my [Installing JetBrains IDE in litterbox](https://github.com/Gerharddc/litterbox/discussions/63) post: ```bash paru -S webstorm webstorm-jre freetype2 ttf-dejavu fontconfig libxkbcommon libxkbcommon-x11 fc-cache -fv ``` If you want to render the Markdown preview in the JetBrains IDE additionally install: ```bash paru -S alsa-lib pango libxrandr libxdamage libxcomposite libcups at-spi2-core nss ``` Then we can launch WebStorm for the first time within the container with a forced override to use Wayland: ```bash _JAVA_OPTIONS="-Dawt.toolkit.name=WLToolkit" webstorm ``` Webstorm will warn us that we used the `_JAVA_OPTIONS` override, so we should persist the forced usage of Wayland the right way. We do this by clicking on the Settings cog and then `Edit Custom VM options` and adding the argument into the newly opened file/window: ```text -Dawt.toolkit.name=WLToolkit ``` From now on we can just start it within the container by typing `webstorm`, no need to set the `_JAVA_OPTIONS` env variable first. ## Setting up ssh keys As said, I like to have a separate SSH key for every litterbox. I chose `marizip` for the SSH key name, but you can choose whatever, it **doesn't** have to be the same as the container name. **The password it prompts for is for the SSH key storage, not the container**: ```bash litterbox keys generate marizip litterbox keys attach marizip marizip ``` You might have to restart your litterbox once or twice to have the new key be correctly attached to it. Litterbox stops the container automatically when all windows to it all closed. Now to allow cloning and pushing from GitHub, I add the SSH key as a **project specific** [deploy key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) so it's scoped to only the project that is actually running inside the Litterbox. First we need to get our public key: ```bash litterbox keys print marizip ``` and then we can add it to our GitHub project by going to the repo → Settings → Deploy Keys and then adding it as a read and write deploy key. Having keys attached means that everytime you `litterbox enter` to a litterbox, you will need to enter your SSH key storage password. ## Adding to launcher To be able to launch the IDE easier, I add it to my system launcher. As litterbox requests your SSH key store password, we need to have an interactive script to input it when required. I generated this quick Python script with Claude to do that, the only required dependency is `pexpect` (on Arch: `sudo pacman -S python-pexpect`). Be sure to adjust the path to your own username: ```python #!/usr/bin/env python3 import pexpect import sys import os name = sys.argv[1] ide = sys.argv[2] password = os.environ['LITTERBOX_PASSWORD'] child = pexpect.spawn(f'/home/mari/.local/bin/litterbox enter {name} {ide}', timeout=60) child.expect('password') child.sendline(password) child.expect(pexpect.EOF, timeout=None) ``` It takes the name of the container as the first argument and the launch command for the IDE as the second. The password gets pulled from the `LITTERBOX_PASSWORD` environment variable, which I set globally for my system. Then we can create a `.desktop` file in a folder our launcher looks for, in my example `~/.local/share/applications/` (find out with `printenv XDG_DATA_DIRS`): ```ini [Desktop Entry] Name=WebStorm (marizip) Comment=Webstorm for maridotzip Project Exec=/home/mari/.local/bin/litterbox-jb.py "marizip" "webstorm" Icon=webstorm Terminal=false Type=Application Categories=Development;IDE; StartupWMClass=jetbrains-webstorm ``` and to apply the changes we just need to refresh our desktop database: ```bash update-desktop-database ~/.local/share/applications ``` ## Conclusion We now have an isolated development environment setup. In case one of our dependencies do end up shipping malware: 1. It only affects the container we are in 2. The only secrets that can be stolen are the ones we store in our environment, which in the ideal case should be none or just development credentials with weak permissions. 3. Our SSH key cannot be used to further spread the malware as our SSH agent popup would make us suspicious. Finally, we can code in peace. Time for the exciting stuff. ## Appendix: Litterbox SSH request popup  ]]> Mari (mellowagain) https://mari.zip/blog/reverse-engineering-a-protocol-impossible-to-reverse-engineer reverse-engineering-a-protocol-impossible-to-reverse-engineer Sun, 21 Oct 2018 00:00:00 GMT ~~reverse engineering a protocol impossible to reverse engineer since always~~ > we are actually reverse engineering bancho successfully. for the third time. But how much truth is behind these sentences? In this article I will give a quick overview in how the osu! client and the osu!Bancho server communicate with each other and how I've gone ahead and figured these things out. ## Sniffing the traffic between client and server So let's start by opening up Wireshark and just capturing a few packets. You'll notice quickly that the communication between the osu! client and the osu!Bancho server happens using simple HTTP requests.  Normally, these would be sent over HTTPS, but I've gone ahead and patched my client to connect to osu!Bancho servers without HTTPS. If you want to decrypt the original HTTPS traffic, just search up ways to decrypt HTTPS traffic in Wireshark. ## So much traffic today! Immediately we notice that osu! seems to send a few checks to `/web/` routes, the first one seems to check if my client is up-to-date, as you can see from the parameters it sends. Next up osu! sends a request to `/web/bancho_connect.php`. Now this is interesting. This seems to be a pre-connection mechanism by osu! for eventual ban checking or something. It just seems to return the registration country if supplied with correct parameters. Because this query contains the md5sum of my password and my unique client hash, I've censored parts of it. We also see a few POST requests to `/web/osu_error.php`. osu! automatically sends the whole client information to that endpoint in case a error occurs, and because a few routes returned 404 (because I conveniently null-routed them) - that shows up a few times. ## Authentication But now lets get to the actual interesting part. osu! sends a POST request to the `/` endpoint. Looking at the body sent, it seems to be login and client information. This is the request that authenticates us with the osu!Bancho server. The body is in the following format: ```plaintext username md5sum of the password Version|UTC offset|Display full location|Colon seperated list of MAC addresses which are MD5 hashed|Block non-friend PMs ``` Funnily enough, because I'm running osu! on my Linux machine under Wine, the colon separated list of MAC addresses contained a string which wasn't md5 hashed, it's value was `runningunderwine`. Now let's take a look at what the server responded and...  What the hell? Until now everything was nice and plain text and now we got some garbage data with some strings between them? This doesn't seem right - well, actually, it does. We'll be taking a look at them in the next section. Let's first address the headers that we see because this is the first time the server set some headers on the response which seem interesting. | Header | Description | |----------------|------------------------------------------------------------------------------------------------------------------------------------| | `cho-protocol` | This is the version of the cho-protocol used in this response. The newest version known as of the writing of this article is `19`. | | `cho-token` | This is the authentication token used for future requests. Think of it like a session cookie. | | `cho-server` | **This is a non-standard header**. It was set by this 3rd party server implementation for identification of the software. | Now that this is out of the way, let's take a look at the seemingly random data mixed with strings between them. This data is actually a array of cho packets. But how exactly is the format of one cho packet? ## Disassembling one packet Let's take a look at one packet sent from the server to the client: ```hex 18 00 00 0F 00 00 00 0B 0D 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 ``` Looks pretty cryptic, doesn't it? But it isn't actually that hard. A cho packet has always a seven byte header and the actual packet data after it. It is in the following format: | Size | Description | Type | |---------|------------------|--------------------------------------------------------------------| | 2 bytes | Packet ID | LE 16-bit Integer | | 1 byte | Null byte | Backwards compatibility with the 2009 osu! client, no longer used. | | 4 bytes | Packet Data Size | LE 32-bit Integer | The remaining bytes after this header are all part of the actual packet body. Using Python's `struct` module, we can easily translate the bytes above into human readable data. ```python >>> struct.unpack(">> struct.unpack(">> b"\x0D\x48\x65\x6C\x6C\x6F\x2C\x20\x77\x6F\x72\x6C\x64\x21".decode("UTF-8") '\rHello, world!' ``` But what's this? The string at the beginning has a carriage return. Is this actually correct? Hint: it's not. But what is it then? After some search on the Internet I encounter the osu! wiki. To be more precise, I encounter the wiki page for the [`.osr` File Format][3]. A `.osr` file is a encoded osu! replay file containing all cursor movement and button clicks. Looking at their table of data types, we can see the following description: > **String** > Has three parts; a single byte which will be either 0x00, indicating that the next two parts are not present, or 0x0b (decimal 11), indicating that the next two parts are present. If it is 0x0b, there will then be a ULEB128, representing the byte length of the following string, and then the string itself, encoded in UTF-8. Could peppy have decided to use the same format for strings in cho packets as well? Let's try it out. Based on the description, the byte after the `0B`, which in our case is `0D`, represents the byte length of the following string. Let's convert this then. ```python >>> 0x0D 13 ``` Wow, what a coincidence! This is exactly the amount of the remaining bytes in our packet body. Converting the remaining bytes into a UTF-8 string and we get the correct string: ```python >>> b"\x48\x65\x6C\x6C\x6F\x2C\x20\x77\x6F\x72\x6C\x64\x21".decode("UTF-8") 'Hello, world!' ``` Success! We've successfully interpreted a cho packet containing a string as body. Let's try interpreting one which doesn't have a string body. ## Don't you reply to me The same HTTP body also contained another packet: ```hex 05 00 00 04 00 00 00 FF FF FF FF ``` Let's try parsing this. First we get again the packet ID and the packet data size. ```python >>> struct.unpack(">> struct.unpack(">> struct.unpack(" Mari (mellowagain)