Posts tagged with "writeup" — Page 2

Writeups for Dennis Yurichev's Reverse Engineering Challenges (#2-#11)

March 10, 2019 ❖ Tags: writeup, reverse-engineering, arm, x86

As mentioned in the (now deleted) post I wrote describing my plans for 2019, one of my goals this year is to get through at least 50 of the exercises on Dennis Yurichev's challenges.re. I've decided to document my progress in the form of writeups for the challenges I complete, batched in sets of ten exercises. For each challenge, I'll try to explain the intuitions that brought me closer to answering the recurring question from Yurichev, "[w]hat does this code do?"

read more →

Slime the World: A Postmortem

November 02, 2018 ❖ Tags: writeup, video-games, programming, game-development, lua, lisp, fennel

Slime the World was my entry to this year's Autumn Lisp Game Jam, and it managed to win second place. The theme was slime, so it’s a game about covering everything in sight with slime, and the dialect of Lisp I chose to use was Fennel, a simple and elegant Lisp that I feel perfectly matches the simplicity and elegance of Lua. It takes on a more "modern" style that I associate with Lisps such as Clojure. I had initially pushed Clojure to the side, feeling it was too different from Common Lisp, but now that I've had a positive firsthand experience with a Lisp where lists aren't the data structure you always reach for, I'm hoping to return to it with an open mind.

read more →

Duke on Fluidsynth

January 13, 2018 ❖ Tags: writeup, programming, video-games, audio, c++

My first experiences with Duke Nukem 3D were with EDuke32 ages ago. This was back when I was running Windows Vista, and while my memory is a bit lacking, I swear that I had working music then. Ever since I made the switch to Linux, I haven't had working music playback in EDuke. Frustrated at the fact that my past few years of Duke 3D have been devoid of all sound besides the screams of death and Duke's trash talking, I've finally decided to troubleshoot it.

read more →


January 04, 2018 ❖ Tags: writeup, security, binary-exploitation, video-games, x86, doom

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 →

BackdoorCTF 2017: FUNSIGNALS

September 24, 2017 ❖ Tags: writeup, security, capture-the-flag, binary-exploitation, x86, linux

"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 →

Analyzing Executable Size, part 0 - A Small Proof-of-Concept Loader

July 31, 2017 ❖ Tags: writeup, programming, operating-systems, c, linux

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 →

Reverse Engineering Babby's First Archive Format

March 02, 2017 ❖ Tags: writeup, programming, reverse-engineering, video-games, x86, c, python

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 →