June 23, 2024 ❖ Tags: writeup, reverse-engineering, linux, operating-systems, hardware
This blog post is about a GNU/Linux rabbit hole I fell down in the belief I was chasing a mighty adventure. It was not nearly as adventurous as I had hoped, but I am nonetheless posting about it in case this information is helpful to someone else. My story begins with a purchase of four wireless gamepads from 8BitDo. I had done little research outside of scrolling past a few positive comments about their products on the Fediverse and viewing enough of their marketing materials to see that the controller I was interested in was supported by SteamOS. That was enough to encourage me to put in an order, so I did, and patiently awaited their arrival. When they were finally in my hands, I plugged two of them into my media center, hoping to play some Mario Kart with Oli. They were clearly working in some capacity because RetroArch pops up a toast when it detects that a controller has been plugged in, but something was wrong. I twiddled the analog sticks and I mashed the buttons. Nothing seemed to happen.
January 22, 2020 ❖ Tags: writeup, reverse-engineering, linux, security
It's typical for the younger sibling to look up to and mimic the older sibling, which is apparently what happened while I was away at school. I'm self-hosting a few services off of a Raspberry Pi B+ back at my parents' house, and when my brother got a Pi of his own, he decided that he also wanted to use it for self-hosting. Unfortunately, he doesn't know much about security, and unintentionally did me the favor of setting up a honeypot.
July 13, 2019 ↻ Crosspost ❖ Tags: writeup, programming, functional-programming, linux, guix, lisp, scheme, guile
Hey, there! I'm Jakob, a Google Summer of Code intern and new contributor to Guix. Since May, I've been working on a DevOps automation tool for the Guix System, which we've been calling guix deploy.
May 28, 2018 ❖ Tags: opinion, linux, gentoo
It seems that the general consensus on "distro hopping," the act of constantly switching between distributions of GNU/Linux, is that it's a bad habit that should be consciously avoided. If you do a search for the term, you'll get articles with titles along the lines of "How I Stopped Distro Hopping." But it's also a term that gets thrown around loosely, and I think that that "distro hopping" is an acceptable practice in a lot of the contexts where the phrase is used. Needless to say, I've "hopped" distributions in the past month, and this blog post is going to describe the highs and lows of that experience.
March 01, 2018 ❖ Tags: tutorial, reverse-engineering, x86, c, linux
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.
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.
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.
June 18, 2017 ↻ Crosspost ❖ Tags: tutorial, reverse-engineering, linux, video-games, game-hacking
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.