Hacking An IoT Camera Reveals Hard-Coded Root Password

July 24, 2024 by Dan Maloney 24 Comments

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

Continue reading “Hacking An IoT Camera Reveals Hard-Coded Root Password” →

Smartwatch Snitches On Itself And Enables Reverse Engineering

July 4, 2024 by Dan Maloney 10 Comments

If something has a “smart” in its name, you know that it’s talking to someone else, and the topic of conversation is probably you. You may or may not like that, but that’s part of the deal when you buy these things. But with some smarts of your own, you might be able to make that widget talk to you rather than about you.

Such an opportunity presented itself to [Benjamen Lim] when a bunch of brand X smartwatches came his way. Without any documentation to guide him, [Benjamen] started with an inspection, which revealed a screen of debug info that included a mysterious IP address and port. Tearing one of the watches apart — a significant advantage to having multiple units to work with — revealed little other than an nRF52832 microcontroller along with WiFi and cellular chips. But the luckiest find was JTAG pins connected to pads on the watch face that mate with its charging cradle. That meant talking to the chip was only a spliced USB cable away.

Once he could connect to the watch, [Benjamen] was able to dump the firmware and fire up Ghidra. He decided to focus on the IP address the watch seemed fixated on, reasoning that it might be the address of an update server, and that patching the firmware with a different address could be handy. He couldn’t find the IP as a string in the firmware, but he did manage to find a sprintf-like format string for IP addresses, which led him to a likely memory location. Sure enough, the IP and port were right there, so he wrote a script to change the address to a server he had the keys for and flashed the watch.

So the score stands at [Benjamen] 1, smartwatch 0. It’s not clear what the goal of all this was, but we’d love to see if he comes up with something cool for these widgets. Even if there’s nothing else, it was a cool lesson in reverse engineering.

the Logitech receiver in question next to the mouse it's paired to

Uncovering Secrets Of Logitech M185’s Dongle

June 15, 2024 by Arya Voronova 14 Comments

[endes0] has been hacking with USB HID recently, and a Logitech M185 mouse’s USB receiver has fallen into their hands. Unlike many Logitech mice, this one doesn’t include a Unifying receiver, though it’s capable of pairing to one. Instead, it comes with a pre-paired CU0019 receiver that, it turns out, is based on a fairly obscure TC32 chipset by Telink, the kind we’ve seen in cheap smart wristbands. If you’re dealing with a similarly obscure MCU, how do you even proceed?

In this case, GitHub had a good few tools developed by other hackers earlier — a Ghidra integration, and a tool for working with the MCU using a USB-UART and a single resistor. Unfortunately, dumping memory through the MCU’s interface was unreliable and frustrating. So it was time to celebrate when fuzzing the HID endpoints uncovered a memory dump exploit, with the memory dumper code helpfully shared in the blog post.

From a memory dump, the exploration truly began — [endes0] uncovers a fair bit of dongle’s inner workings, including a guess on which project it was based on, and even a command putting the dongle into a debug mode where a TC32-compatible debugger puts this dongle fully under your control.

Yet another hands-on course on Ghidra, and a wonderful primer on mouse dongle hacking – after all, if you treat your mouse’s dongle as a development platform, you can easily do things like controlling a small quadcopter, or pair the dongle with a SNES gamepad, or build a nifty wearable.

We thank [adistuder] for sharing this with us!

A picture of the camera in question, successfully uploading a pic thanks to the fix found

Fixing A Camera’s WiFi Connectivity With Ghidra

May 30, 2024 by Arya Voronova 4 Comments

If your old camera’s WiFi picture upload feature breaks, what do you do? Begrudgingly get a new one? Well, if you’re like [Ge0rg], you break out Ghidra and find the culprit. He’s been hacking on Samsung’s connected cameras for a fair bit now, and we’ve covered his adventures hacking on Samsung’s Linux-powered camera series throughout the last decade, from getting root on them for fun, to deep dives into the series. Now, it was time to try and fix a problem with one particular camera, Samsung WB850F, which had its picture upload feature break at some point.

[Ge0rg] grabbed a firmware update .zip, and got greeted by a bunch of compile-time debug data as a bonus, making the reverse-engineering journey all that more tempting. After figuring out the update file partition mapping, loading the code into Ghidra, and feeding the debug data into it to get functions to properly parse, he got to the offending segment, and eventually figured out the bug. Turned out, a particularly blunt line of code checking the HTTP server response was confused by s in https, and a simple spoof server running on a device of your choice with a replacement hosts file is enough to have the feature work again, well, paired with a service that spoofs the long-shutdown Samsung’s picture upload server.

Turned out, a bunch more cameras from Samsung had the same check misfire for them, which made this reverse-engineering journey all that more fruitful. Once again, Ghidra skills save the day.

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

February 6, 2024 by Dan Maloney 10 Comments

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

Decompiling Sonic Runners

August 22, 2023 by Matthew Carlson 7 Comments

Usually, when you hear about games being decompiled and rebuilt, the games are often decades-old relics, loving and saved from the ravages of time. [MattKC] recently set out to decompile the 2015 game Sonic Runners.

The game was a 2D endless runner released on mobile platforms. Despite getting praise for the gameplay, it received mixed reviews for the pop-up ads and pay-to-play elements. A little over a year later, the game was discontinued. However, the game required a constant online connection, so once the servers were offline, it rendered the over five million downloads unplayable.

A team of developers worked to reverse engineer the server, and with a little bit of binary hacking, the client could be patched to connect to a community-hosted server instead. However, as phones with notched displays came out and suggestions for improvements stacked up, the community realized a new client would bring immense benefits. Compared to many decompilation projects, Sonic Runners was pretty easy as it uses Unity, which means most of the code is in C#. Unfortunately, the build of Unity used by the game is from 2012, meaning many of the tools designed for much later versions of Unity were inoperable.

However, one native code library called UnmanagedProcess was designed to confuse reverse engineering efforts. The library handled AES encryption and communication with the server. Luckily, the library was a later addition, and earlier versions of its functions still lingered in the C# code. Since an open source server already existed, it was trivial to validate the changes. Additionally, all the shaders were in OpenGL Shading Language (GLSL), which meant rewriting them in High-Level Shading Language (HLSL) and checking that they matched the original GLSL when building for Android.

Now the client has new game modes, no ads, and a proper offline mode. The community continues adding new features and refining the game, which is very satisfying. If you’re curious about reverse engineering, [Matthew Alt] can help you get started.

Continue reading “Decompiling Sonic Runners“ →

Screenshot of the code decompiled after these patches are applied, showing that all the register writes are nicely decompiled and appropriate register names are shown in the code

Making Ghidra Play Nice With RP2040

March 1, 2023 by Arya Voronova 1 Comment

Developing firmware for RP2040 is undeniably fun, what’s with all these PIOs. However, sometimes you will want to switch it around and reverse-engineer some RP2040 firmware instead. If you’ve ever tried using Ghidra for that, your experience might have been seriously lackluster due to the decompiled output not making sense when it comes to addresses – thankfully, [Wejn] has now released patches for Ghidra’s companion, SVD-Loader, that turn it all around, and there’s a blog post to go with these.

SVD-Loader, while an indispensable tool for ARM work, didn’t work at all with the RP2040 due to a bug – fixed foremost. Then, [Wejn] turned to a pecularity of the RP2040 – Atomic Register Access, that changes addressing in a way where the usual decompile flow will result in nonsense addresses. Having brought a ton of memory map data into the equation, [Wejn] rewrote the decoding and got it to a point where peripheral accesses now map to nicely readable register writes in decompiled code – an entirely different picture!

You can already apply the patches yourself if you desire. As usual, there’s still things left in TODO for proper quality of life during your Ghidra dive, but the decompiled code makes way more sense now than it did before. Now, if you ever encounter a RP2040-powered water cooler or an air quality meter, you are ready to take a stab at its flash contents. Not yet familiar with the Ghidra life? Well, our own HackadayU has just the learning course for you!