There are some excellent online resources describing how to put together basic malware analysis labs. I won’t rehash that content here.
One thing that seems to get breezed over or is missing entirely from a lot of the “How To Build A Malware Lab” articles, is how to safely get malware samples on to the ‘Victim’ VM without exposing the host to potential infection.
I want to walk through the options and look at the potential problems.
Since taking Joseph Opacki’s malware reversing course in the GMU Digital Forensics and Cyber Analysis program, and later FOR610 @ SANS with Lenny Zeltser - I’ve been fascinated with malware analysis and reverse engineering. Unfortunately, in the years since those classes, I have not had much professional opportunity to use the skills directly.
I have finally decided to take matters in to my own hands. I can get all the practice I need through efficient use of my home lab and library.
Hands-on keyboard, dissecting samples is where I want to be. So here is my plan.
We are now on Lockitall LockIT Pro, revision b.02
What changed in this edition?
“We have fixed issues with passwords which may be too long”
This is level 3 of the Micro Corruption CTF.
Note: This level highlighted an important lesson for me personally. I often make things too complicated and jump to the most sophisticated solution too quickly. I jump to conclusions. With a little more patience and just a little more time reviewing the big picture, this level would have been a much quicker solve. WORK SMART NOT HARD!!
The pop-up documentation for this new lock in Sydney - specifies that the firmware has been revised and will no longer contain the password in memory.
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.
This series will be my walk through of how I approached and hopefully solved each lock.
We’ll start with level one - New Orleans