Matthew Ruffell

Double Trouble With Symmetric Encryption in TimeLock 1.5 Vulnerability Writeup

All right, I hope you liked the previous articles on TimeLock, because here is another one! This will be my fourth bug bounty now. As always, interesting reverse engineering followed by an awesome Bitcoin reward awaits!

A little while ago u/cryptocomicon posted a new announcement of TimeLock 1.5 to Reddit:

I can’t turn down a good challenge, so lets get started!

Beginning Kernel Crash Debugging on Ubuntu 18.10

If you have been reading this blog, you have probably noticed how all the debugging and analysis of applications have been on Windows executables, and although I did create my own Linux distribution, Dapper Linux, I haven’t written much about debugging on Linux.

Time to change that. Today, we are going to look into how debugging Linux kernel crash dumps works on Ubuntu 18.10 Cosmic Cuttlefish. Fire up a virtual machine, and follow along.

We will cover how to install and configure crash and kdump, a little on how each tool works, and finding the root cause of a basic panic.

Let’s get started.

Unleashing a Sybil Attack Against TimeLock 1.3 Vulnerability Writeup

Here we are, back again for my third bug bounty! It really is a good time trying to break an applications security, and especially so when there is some Bitcoin waiting as a reward.

As always, I was on Reddit and saw that u/cryptocomicon has made some changes to TimeLock, and is ready for them to be tested again.

u/cryptocomicon has acknowledged that writing secure software is extremely hard, and is absolutely correct in that statement. We also see that a new challenge is issued:

Designing an un-hackable TimeLock is challenging. This is my third version and the third challenge, with a 0.02 BTC reward.

Please give it a try.

Will do. Challenge accepted.

Looking at kmalloc() and the SLUB Memory Allocator

Recently I was asked to do some homework to prepare for an interview on Linux kernel internals, and I was given the following to analyse:

Specifically, we would like you to study and be able to discuss the code path that is exercised when a kernel caller allocates an object from the kernel memory allocator using a call of the form:

object = kmalloc(sizeof(*object), GFP_KERNEL);

For this discussion, assume that (a) sizeof(*object) is 128, (b) there is no process context associated with the allocation, and (c) we’re referencing an Ubuntu 4.4 series kernel, as found at

git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git

In addition, we will discuss the overall architecture of the SLUB allocator and memory management in the kernel, and the specifics of the slab_alloc_node() function in mm/slub.c.

I spent quite a lot of time, maybe 8-10 hours, studying how the SLUB memory allocator functions, and looking at the implementation of kmalloc(). It’s a pretty interesting process, and it is well worth writing up.

Let’s get started, and I will try to keep this simple.

Revisiting TimeLock 1.2 and Vulnerability Writeup

I’m back again for my second bug bounty! Searching for bugs is actually pretty fun, especially when it comes with a generous reward in my favourite cryptocurrency, Bitcoin!

I was scrolling Reddit like usual, and u/cryptocomicon has returned with a new version of TimeLock! That’s great news.

If we remember back to last week, I solved the original TimeLock challenge, and wrote a detailed writeup.

u/cryptocomicon issued a new challenge:

I’m so confident in this technology that I’ve created a challenge LockBox file which holds the private key to an address with 0.02 BTC.

Please give it a try.

NOTE: This is going to be much harder than last time.

Much harder than last time? Sounds interesting.

Challenge accepted.