I’m delroth, or Pierre Bourdon. Originally from France, currently living in
Zürich, Switzerland. I’m an open source developer, mainly contributing to
NixOS these days. In the past, I was a core developer for
the Dolphin Emulator, and I was the main
infrastructure maintainer as well as treasurer for the project.
In my working life, I’ve worked for around 10 years as a Software Engineer at
Google. I’ve spent around 3 years each specializing in site reliability,
counter-abuse technologies, then infrastructure security. Along the way, I also
became privacy reviewer for new infrastructure projects, as well as
teacher/mentor for new C++ developers at the company.
I’m currently on a sabbatical leave, spending my free time learning more about
the country I’ve lived in for 10 years, and finally learning the local
language.
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.
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).
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.
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 🙂
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.
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.
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.
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.
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.
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.