Blog Gaming Microcorruption

Posted on July 16, 2018 by Kevin Romano

The cornerstone of my early interest in technology was gaming. I needed to learn to make the computer work, so I could play games like Battle Chess, Ascendency, Sim Tower, and later Warcraft. My desire for better performance, better graphics, better gaming drove my interest in building better computing rigs. This fostered a deep love for technology and a curiousity about how it all worked. What I didn’t realize as a 10-year-old was aside from the hours of entertainment, I was actually developing skills that would later be priceless in my career as a Security Engineer. Of course, at the time, I didn’t know or care about my career, I was just having fun playing the games. 30 years later — surprise, surprise…games are still fun!

Gaming provides a fundamental benefit over traditional study methods. Motivation! Motivation to reach the final boss fight; acheive the high score; find all the easter eggs. When this motivation is paired with a specific learning objective, it can make the learning process far more effective and engaging than a simple lecture. The Information Security community, probably made up of many early gamers, has embraced this gaming framework for skill development and testing.

Capture The Flag (CTF) events, found at most security conferences and now increasingly available online, provide a game-based testing and learning platform. There are various flavors of CTF events, but they all have the fundamental motivation that gaming provides.

Blue Mantle Technology encourages and supports every employee in continued education and skill development in any area of interest – from system administration and hardening to forensics and reverse engineering. In addition to the more traditional university coursework, boot camps, and seminars, we encourage staff to participate in Capture The Flag events. We will occasionally host our own internal events, but there are many CTF challenges available online.

The following is a walkthrough of the first level of a publicly available challenge based on embedded device security. If it looks interesting, I encourage you to sign up and continue the challenges at https://microcorruption.com/login. Gaming is the best way to learn!

Micro Corruption is an Embedded Security CTF found here. The basic narrative behind the CTF is that a series of warehouses spread around the world are protected by a Bluetooth-enabled deadbolt lock. These deadbolts can only be unlocked with the correct credentials supplied via the manufacturer’s mobile app. Our team wants to steal things from the warehouses and we were rightly left off the authorized access list. Our goal is to find some input (it might even be the password) that unlocks the lock and allows our team entry.

The challenge in the CTF:

Using the debugger, you’ll be able to single step the lock code, set breakpoints, and examine memory on your own test instance of the lock. You’ll use the debugger to find an input that unlocks the test lock, and then replay it to a real lock.

The lock is built on the MSP430 microcontroller and a lock manual is provided.

New Orleans

Each level in Micro Corruption begins with a pop-up showing the release notes of the latest version of the lock. These notes can provide helpful hints on the types of security the developers may have included. Here are the release notes for Level 1:

The debugger window consists of six sections – a Disassembly window, a set of registers, the current instruction, a Live Memory Dump, and I/O Display and a debugger console.

In the Micro Corruption tutorial, the password for the test lock was stored clearly visible in memory. So for level one, as a starting point, I begin by scrolling through the Live Memory dump window to see if there is anything obvious.

I see strings “Access Granted”, “Invalid Password”, and other terminal output – but nothing that is obviously a password.

Next, I scroll through the Disassembly window looking for the <main> function. I will scan through <main> and look for all of the ‘call’ instructions to get a general sense of the program flow.

The first few calls are:

call #0x447e <create_password>
call #0x4594 <puts>
call #0x44b2 <get_password>
call #0x44bc <check_password>


create_password seems interesting! I scroll further through the Disassembly window looking for the create_password function.

The first instruction moves the literal value #0x2400 to r15. The subsequent instructions (mov.b) move literal byte values to some offset of the value stored in r15 (0x2400).

Because these byte values are clearly visible in the disassembled instructions we could copy them down and convert them manually from the [ASCII chart](http://www.asciitable.com).

0x2f -> "/"
0x3d -> "="
0x3a -> ":"
0x6c -> "l"
0x70 -> "p"
0x2e -> "."
0x2e -> "."
0x0 -> NULL Terminator


The converted string: /=:lp..

For a string 7 bytes long (8 with the null terminator) the manual work isn’t a big deal. If this password were longer or there were some sort of decryption loop, a better approach would be to let the debugger do the work. Work smart, not hard!

I will place a break-point at the end of this function (#0x44b0 ret) and allow the program to run up to the break-point.

Once the break point is hit, I will check the Live Memory Dump to see if there is anything like a password at memory address 0x2400.

The break-point is hit and, at the memory location 0x2400, ascii characters are found. ASCII strings are terminated by a null character \x00 – so I will copy all the bytes leading up to the first \x00 starting at #0x2400:

/=:lp..

I will let the program continue running and use this string when prompted for the password.

And voila!