TL;DR, I discovered a stack-smashing vulnerability in GZDoom's interpreter for
ACS. As a preface, there's a tendency for whitepapers like this in the security
community to be written with a somewhat condescending tone towards the product's
vendor. I do not mean for any portion of this writeup to come off as degrading
to the developers involved. Yes, the bug was obvious to me, but it was still
subtle enough that it went under the radar for nearly 23 years. Most developers
aren't actively thinking about this kind of attack while writing a bytecode
interpreter. I have an enormous amount of respect for the development teams of
both GZDoom and Zandronum, who were quick to issue a patch addressing the issue
and were respectful of my wishes to release this whitepaper to the public. I'd
also like to thank everyone I had the pleasure of working with during this
process; it warms my heart to know that the communities behind these open-source
software projects are this friendly.
read more →
"funsignals" was a 250 point binary exploitation challenge with 58 solves. The
challenge itself was a very trivial example of sigreturn-oriented programming.
read more →
At a first glance, it might seem that game cheats like AimTux are something that
could only be conjured by the most talented of reverse engineers. That was at
least my initial view on it, especially since I always saw these game hackers
using outlandish terms that I hadn't heard in over a year of playing in CTF's.
Don't be fooled; game hacking isn't nearly as complex as its community makes it
seem. In this post, I will explain the concepts in a way that is familiar to
people with experience in binary exploitation and reverse engineering, but it
shouldn't be too hard to understand if you lack that background.
read more →
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.
read more →
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.
read more →
Hey, this is a very brief tutorial on scanmem, a memory manipulation tool for
Linux that’s well suited to game hacking. I’ll be using GZDoom as an example,
but you should be able to follow along with any game you want.
read more →
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.
read more →
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.
read more →