My long-lived hiatus from capture-the-flag has come to an end, as I got off my ass this weekend to play in PlaidCTF 2019. Being a one-man team is pretty lonely, but my old team wasn't playing, and even if they were, I don't know if I would've wanted to make the commute just to play with them.
My capture-the-flag team played in the Insomni'hack teaser this year. During the competition, I worked on a single challenge titled "sapeloshop." It was labeled as "Medium-Hard," and it was in the binary exploitation category. The source code for the server wasn't provided, so reverse engineering was necessary. I don't think that having to reverse the binary was supposed to be the hard part, as most of the behavior could have been inferred through some high-level analysis, yet I spent nearly five hours fruitlessly trying to reverse it, and the subsequent burnout was bad enough that I went home early. This wasn't the first time a reversing task had gotten the best of me; there had been a few competitions last year where I felt a similar loss in motivation. Noticing this recurring pattern frustrated me, and that frustration drove me to think about ways to improve myself as a reverse engineer.
It seems that static linking is back in style, or at least popular among all the hip new programming languages of today. I don't have anything against statically linked binaries, nor do I have a problem with larger executables, but I've noticed that the acceptable size for an executable is a lot larger now than it was a few years ago; that is, the new kids on the block have significantly more leeway than their predecessors. For example - a C program that spits out "hello world" is 7 KB when statically linked to musl. It's 12 KB when dynamically linked to glibc. The same program in D, where the reference compiler doesn't allow dynamic linking to the standard library, is 896 KB. A blog post I read recently about certificate chain verification in Go made a point of praising the toolchain for being able to spit out a binary that was "less than 6 MB!" I'm being more facetious than with my D example, as this was statically linked to an SSL-capable web server, but 6 MB is a little over half the size of a fully-functioning operating system. I'm not so interested in why we settle binaries the size of a few videos, but instead I'd like to look at why they're that large to begin with. To peer in and see what wealth of information is stored inside, and how certain programming languages make use of that information.
To start off, I'd like to say that I know very little about audio programming and digital audio in general. I've never formally studied signal processing, and hell, I haven't even started high school physics yet. This post merely documents what I've learned while trying to get sound working in my game, because there aren't really any other learning resources about this out there.
About two months have passed since the first release of Nekopack - a tool I wrote for extracting game data from Nekopara's XP3 archives. While the process wasn't an amazing reverse-engineering war story that will keep you on the edge of your seat, I feel it deserves a small blog post explaining how I did it. Additionally, there's no real documentation on the XP3 format as far as I'm aware, so hopefully this post will serve as an informal specification.
SDL2 is my favorite graphics library right now. It might not be as powerful as something like raw OpenGL, but it's simple. Simple enough that you can just pick it up and start using it. There's a glaring issue with it, though. The documentation is horrible. Absolutely horrible. A lot of it is unfinished, and it doesn't look like it's getting attention any time soon. The SDL1.2 documentation wasn't as bad, but that version of the library is vastly outdated by today's standards. So here's my take on a tutorial for SDL - part 0x00 of a I-don't-know-how-long-I'm-going-to-drag-this-on series. My examples are going to be written in C, because the constructs I show here can still be used verbatim in C++ (and probably SDL's other language bindings as well). This tutorial will be covering the little boilerplate that SDL requires, as well as the basics of windowing and rendering. Let's get into it.