The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.
[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.
He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.
This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.
At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.
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.
Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.
While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leo Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, [Leo] ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.
All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.
We’re not sure what to make of this one. With the variety of smartwatches and fitness trackers out there, we can’t be surprised by what sort of hardware ends up strapped to wrists these days. So a watch with an RPN calculator isn’t too much of a stretch. But adding a hex editor? And a disassembler? Oh, and while you’re at it, a transceiver for the 70cm ham band? Now that’s something you don’t see every day.
The mind boggles at not only the technical prowess needed to pull off what [Travis Goodspeed (KK4VCZ)] calls the GoodWatch, but at the thought process that led to all these features being packed into the case of a Casio calculator watch. But a lot of hacking is more about the “Why not?” than the “Why?”, and when you start looking at the feature set of the CC430F6137 microcontroller [Travis] chose, things start to make sense. The chip has a built-in RF subsystem, intended no doubt to enable wireless sensor designs. The GoodWatch20 puts the transceiver to work in the 430-MHz band, implementing a simple low-power (QRP) beacon. But the real story here is in the hacks [Travis] used to pull this off, like using flecks of Post-It notes to probe the LCD connections, and that he managed to stay within the confines of the original case.
There’s some real skill here, and it makes for an interesting read. And since the GoodWatch is powered by a coin cell, we think it’d be a great entry for our Coin Cell Challenge contest.
What do you do when a ten-year-old video game has a bug in it? If you are [ExileLord] you fix it, even if you don’t have the source code. Want to know how? Luckily, he produced a video showing all the details of how he tracked the bug down and fixed it. You can see the video below. You may or may not care about Guitar Hero, but the exercise of reverse engineering and patching the game is a great example of the tools and logic required to reverse engineer any binary software, especially a Windows binary.
The tool of choice is IDA, an interactive debugger and disassembler. The crash thows an exception and since [ExileLord] has done some work on the game before, he was able to find a function that was creating a screen element that eventually led to the crash.
Continue reading “Reverse Engineering Guitar Hero”
If you really want to hack software, you are going to face a time when you have to take apart someone’s machine code. If you aren’t very organized, it might even be your own — source code does get lost. If you want to impress everyone, you’ll just read through the hex code (well, the really tough old birds will read it in binary). That was hard to do even when CPUs only had a handful of instructions.
A more practical approach is to use a tool called a disassembler. This is nothing more than a program that converts numeric machine code into symbolic instructions. The devil, of course, is in the details. Real programs are messy. The disassembler can’t always figure out the difference between code and data, for example. The transition points between data and code can also be tricky.
When Not to Use
If you are coding your own program in assembly, a disassembler isn’t usually necessary. The disassembly can’t recover things like variable names, some function names, and — of course — comments. If you use a high-level language and you want to check your compiler output, you can easily have the compiler provide assembly language output (see below).
The real value of a disassembler is when you don’t have the source code. But it isn’t easy, especially for anything nontrivial. Be prepared to do a lot of detective work in most cases.
Continue reading “Disassembly Required”