A red and blue Lytro camera with a serial port soldered onto one

Unlocking Hidden Features Of An Unusual Camera

January 25, 2023 by Robin Kearey 65 Comments

Back in 2012, technology websites were abuzz with news of the Lytro: a camera that was going to revolutionize photography thanks to its innovative light field technology. An array of microlenses in front of the sensor let it capture a 3D image of a scene from one point, allowing the user to extract depth information and to change the focus of an image even after capturing it.

The technology turned out to be a commercial failure however, and the company faded into obscurity. Lytro cameras can now be had for as little as $20 on the second-hand market, as [ea] found out when he started to investigate light field photography. They still work just as well as they ever did, but since the accompanying PC software is now definitely starting to show its age, [ea] decided to reverse-engineer the camera’s firmware so he could write his own application.

[ea] started by examining the camera’s hardware. The main CPU turned out to be a MIPS processor similar to those used in various cheap camera gadgets, next to what looked like an unpopulated socket for a serial port and a set of JTAG test points. The serial port was sending out a bootup sequence and a command prompt, but didn’t seem to respond to any inputs. Continue reading “Unlocking Hidden Features Of An Unusual Camera” →

A solar inverter that asks for a password on its display

Decompiling Software To Fix An Old Solar Inverter

October 20, 2022 by Robin Kearey 16 Comments

It’s a fact of life that electronic devices become obsolete after a few years. Sometimes this is because technology has moved on, but it can also happen that a perfectly functional device becomes near-useless simply because the original manufacturer no longer supports it. When [Buy It Fix It] found a pair of second-hand Power-One Aurora solar inverters, he ran into an issue for which he needed access to the service menu, which happened to be password-protected. The original manufacturer had ceased to exist, and the current owner of the brand name was unable to help, so [Buy It Fix It] had to resort to reverse engineering to find the password.

Thanks to the Wayback Machine over at the Internet Archive, [Buy It Fix It] was able to download the PC software bundle that originally came with the inverters. But in order to access all features, a password was required that could only be obtained by registering the unit with the manufacturer. That wasn’t going to happen, so [Buy It Fix It] fired up dnSpy, a decompiler and debugger for .NET programs. After a bit of searching he found the section that checked the password, and by simply copying that section into a new program he was able to make his own key generator.

With the service password now available, [Buy It Fix It] was able to set the inverter to the correct voltage setting and hook it up to his solar panels. Interestingly, the program code also had references to “PONG”, “Tetris” and “tiramisu” at various places; these turned out to be Easter eggs in the code, containing simple versions of those two games as well as a photo of the Italian dessert.

Inside the software archive was also another program that enabled the programming of low-level functions within the inverter, things that few users would ever need to touch. This program was not written in .NET but in C or something similar, so it required the use of x32dbg to look at the machine code. Again, this program was password-protected, but the master password was simply stored as the unencrypted string “91951” — the last five digits of the manufacturer’s old phone number.

The inverter was not actually working when [Buy It Fix It] first got it, and his repair video (also embedded below) is also well worth watching if you’re into power electronics repair. Hacking solar inverters to enable more features is often possible, but of course it’s much easier if the entire design is open source.

Continue reading “Decompiling Software To Fix An Old Solar Inverter” →

Solving The Final Part Of The IClicker Puzzle

May 21, 2019 by Tom Nardi 9 Comments

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.

Capture The Flag Challenge Is The Perfect Gift

January 18, 2018 by Sven Gregori 7 Comments

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.

Learn To Reverse Engineer X86_64 Binaries

January 6, 2018 by Sven Gregori 16 Comments

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, [Leonora 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, she 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.

A Watch Only A Ham Can Use

December 19, 2017 by Dan Maloney 17 Comments

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.

[via r/AmateurRadio]

Reverse Engineering Guitar Hero

September 25, 2017 by Al Williams 11 Comments

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” →