A great place to get your feet wet with the data-network-wonderland that is modern-day automobiles is the Car Hacking Village at DEF CON. I stopped by on Saturday afternoon to see what it was all about and the place was packed. From Ducati motorcycles to junkyard instrument clusters, and from mobility scooters to autonomous RC test tracks, this feels like one of the most interactive villages in the whole con.
Nothing says friendship like a reverse engineering challenge on unknown terrain as a birthday present. When [Rikaard] turned 25 earlier this year, his friend [Veydh] put together a Capture the Flag challenge on an ESP8266 for him. As a software guy with no electronics background, [Rikaard] had no idea what he was presented with, but was eager to find out and to document his journey.
Left without guidance or instructions, [Rikaard] went on to learn more about the ESP8266, with the goal to dump its flash content, hoping to find some clues in it. Discovering the board is running NodeMCU and contains some compiled Lua files, he stepped foot in yet another unknown territory that led him down the Lua bytecode rabbit hole. After a detour describing his adjustments for the ESP’s eLua implementation to the decompiler he uses, his quest to capture the flag began for real.
While this wasn’t [Rikaard]’s first reverse engineering challenge, it was his first in an completely unknown environment outside his comfort zone — the endurance he demonstrated is admirable. There is of course still a long way down the road before one opens up chips or counts transistors in a slightly more complex system.
[q3k] got tipped off to a very cool problem in the ongoing Pwn2Win capture-the-flag, and he blew it out of the water by decoding the metal interconnect layers that encode a password in a VLSI IC. And not one to rent someone else’s netlist extraction code, he did it by writing his own.
The problem in the Pwn2Win CTF came in the form of the design files for a hypothetical rocket launch code. The custom IC takes an ASCII string as input, and flips a pin high if it matches. Probably the simplest way to do this in logic is to implement a shift register that’s long enough for the code string’s bits, and then hard-wire some combinatorial logic that only reads true when all of the individual bits are correct.
(No, you don’t want to implement a password-checker this way — it means that you could simply brute-force the password far too easily — but such implementations have been seen in the wild.)
Anyway, back to our story. After reversing the netlist, [q3k] located 320 flip-flops in a chain, suggesting a 40-byte ASCII code string. Working backward in the circuit from the “unlocked” pin to the flip-flops, he found a network of NOR and NAND gates, which were converted into a logic notation and then tossed into Z3 to solve. Some cycles later, he had pulled the password straight out of the silicon!
This looks like a really fun challenge if you’re into logic design or hardware reverse engineering. You don’t have to write your own tools to do this, of course, but [q3k] would say that it was worth it.
Thanks [Victor] for the great tip!
Featured image by David Carron, via Wikipedia.
If you want to learn how to defeat computer security, nothing beats hands-on experience. Of course, if you get your hands on someone’s system without their permission, you may end up having a very short training that ends with a jail term. And that’s where capture-the-flag (CTF) events come in.
A CTF is a system of increasingly-difficult challenges that can’t be too easy or too hard. A well-designed CTF teaches all of the participants stuff that they didn’t know, no matter how far they get and what skills they came in with. Designing a good CTF is difficult.
But since it’s also a competition, running one also involves a lot of horrible bookkeeping for the folks running it. Registering teams and providing login pages is the dirty work that you have to do in the background, that takes away time from building the systems which others are going to take apart.
Which is why it’s great that Facebook is opening up their CTF-hosting platform, along with a few starter challenges, for us all to play along. We love CTFs and related hacking challenges. If this spurs the creation of more, we’re all for it. You can find the whole setup on GitHub.
If you’re new to CTFs, here’s an awesome collection of CTF-related material on GitHub to get you started. And if your tastes run more toward hardware hacking, we’ve covered previous firmware CTFs, but frankly there’s a lot more material out there. We feel a feature post coming on…
Thanks [ag4ve] for the unintentional tip!
There’s a great game of capture-the-flag that takes place every year at HITCON. This isn’t your childhood neighborhood’s capture-the-flag in the woods with real flags, though. In this game the flags are on secured servers and it’s the other team’s mission to break into the servers in whatever way they can to capture the flag. This year, though, the creators of the game devised a new scoreboard for keeping track of the game: a lightsaber.
In this particular game, each team has a server that they have to defend. At the same time, each team attempts to gain access to the other’s server. This project uses a lightsaber stand that turns the lightsabers into scoreboards for the competition at the 2015 Hacks In Taiwan Conference. It uses a cheap OpenWRT Linux Wi-Fi/Ethernet development board, LinkIt Smart 7688 which communicates with a server. Whenever a point is scored, the lightsaber illuminates and a sound effect is played. The lightsabers themselves are sourced from a Taiwanese lightsabersmith and are impressive pieces of technology on their own. As a bonus the teams will get to take them home with them.
While we doubt that this is more forced product integration advertisement from Disney, it certainly fits in with the theme of the game. Capture-the-flag contests like this are great ways to learn about cyber security and how to defend your own equipment from real-world attacks. There are other games going on all around the world if you’re looking to get in on the action.
If you’ve ever been to a capture the flag hacking competition (CTF), you’ve probably seen some steganography challenges. Steganography is the art of concealing data in plain sight. Tools including secret inks that are only visible under certain light have been used for this purpose in the past. A modern steganography challenge will typically require you to find a “flag” hidden within an image or file.
[Anfractuosus] came up with a method of hiding packets within a stream of network traffic. ‘Timeshifter’ encodes data as delays between packets. Depending on the length of the delay, each packet is interpreted as a one or zero.
To do this, a C program uses libnetfilter_queue to get access to packets. The user sets up a network rule using iptables, which forwards traffic to the Timeshifter program. This is then used to send and receive data.
All the code is provided, and it makes for a good example if you’ve ever wanted to play around with low-level networking on Linux. If you’re interested in steganography, or CTFs in general, check out this great resource.
Hacking conferences often feature a Capture the Flag, or CTF event. Typically, this is a software hacking challenge that involves breaking into targets which have been set up for the event, and capturing them. It’s good, legal, hacking fun.
However, some people are starting to build CTFs that involve hardware hacking as well. [Balda]’s most recent hardware hacking challenge was built for the Insomni’hack 2014 CTF. It uses an MSP430 as the target device, and users are allowed to enter commands to the device over UART via a Bus Pirate. Pull off the exploit, and the wheel rotates to display a flag.
For the first challenge, contestants had to decompile the firmware and find an obfuscated password. The second challenge was a bit more complicated. The password check function used memcpy, which made it vulnerable to a buffer overflow attack. By overwriting the program counter, it was possible to take over control of the program and make the flag turn.
The risk of memcpy reminds us of this set of posters. Only abstaining from memcpy can 100% protect you from overflows and memory disclosures!
