picoCTF 2017 was happening over the last two weeks, and while I didn’t have time to play it, a friend messaged me asking for help on one of the “master” level problems. The problem was a fun cryptography problem related to RSA, and I heard that some people ended up solving the problem using brute force, so I decided to writeup my solution which doesn’t require brute force. Note that there’s nothing wrong with the brute force solution, and you probably would have solved the problem faster, but it’s good practice to be able to do it with just number theory.
This weekend was TUM CTF 2016, and while I didn’t have much time to play, I did want to solve at least one problem. I ended up choosing
l1br4ry, a 300 point pwnable problem that had zero solves at the time. I really enjoyed working on the challenge, and I ended up being the third person to solve the problem, so I decided to do a writeup on it.
I’ve been going through how2heap problems recently, and I really enjoyed solving search-engine from 9447 CTF 2015. This was a pretty complicated problem, but it was also a lot of fun so I’ll be sharing a writeup of my solution below. I’d highly recommend going over sploitfun’s glibc malloc article and the fastbin_dup_into_stack.c example from how2heap before going through this writeup.
While I was working on my ggp-rs project last week, I was having some trouble tracking down a strange bug that was happening. The relevant code was related to the unification, substitution, and general statement proving algorithms, which is a non-trivial piece of code to write, read, and debug. I started to put
println! statements in various functions, sometimes just to see if the function was entered, and sometimes to see the value of some variables. After spending about half an hour on this bug, I got fed up with the code, took a step back, and started thinking of an easier, more structured approach to debugging the code. I realized that putting print statements in the code to trace execution is a common debugging practice used by myself and other developers all the time, and it might be possible to make this more convenient with the help of Rust’s syntax extensions/compiler plugins.
Whenever I come across some topic of piece or software I don’t completely understand, I always want to try writing it. When I was in high school, operating systems and compilers were two concepts that I tried to understand but couldn’t completely get a grasp of just from reading books or articles online. That’s why I ended up writing both of them. I’ve been curious about how display/login managers and window managers work in Linux now for a while now. There are some tutorials on how to write a window manager online, but when it comes to display managers there’s absolutely nothing. That’s why I tried to write my own display manager and wrote this tutorial so you can write your own as well.
I’ll be writing this in C, but the concepts apply to any language as long as the language you’re using has all the necessary libraries. You can find my final code on Github (this is the tutorial branch, which follows this tutorial more closely), and you might also find the SLiM display manager a useful reference as well. The SLiM website (which hosted the code) went down recently as the project is no longer maintained, so I’ve linked my mirror of the project above.
I’ve noticed that when it comes to Git tutorials, there’s only the “Intro to Git” or the “Here’s how you do X with Git”, but there aren’t any tutorials that take you from a Git beginner to a Git master. This post is supposed to be a starting point for that. It will provide some useful tips and concepts that I use everyday, which allows me to use Git to the fullest extent. For anyone who’s interested in learning more, definitely check out the Pro Git that’s freely available online. I’ve read that book from beginning to end and I’ve found it very interesting and educational.
Note that this tutorial requires basic knowledge of Git. That is, you should know what Git is, how to add, commit, and push changes, and the very basics of branches and merging.
Over the years I’ve accumulated a lot of useful aliases for my Bash shell. I rarely see others using many aliases, so I thought I’d share mine. This list can get somewhat long, so I recommend putting these in a
.bash_aliases file and sourcing it from your
Any content surrounded by angled brackets (
<>) are machine/user specific, so don’t forget to replace them with the correct values.