Reverse-Engineering The Web-@nywhere Watch For 2001-Era Smartwatch Action

January 21, 2024 by Maya Posch 10 Comments

Although smartwatches seem to be just a recent fad, people have been strapping wristwatches to their wrists with all kinds of functionality. Whether a miniscule calculator, a remote control, an organizer or as in the case of the Web-@nywhere Watch a web browser. In the last case only sort of, naturally, as it was released in 2001 and this little early 2000s marvel cost only $85 (or $150 in 2024 USD), so what could it really be capable of? This is the million dollar question that [Cameron Kaiser] sought to find out as he found a new-in-box unit for sale.

The Web-@nywhere watch in action. (Credit: Cameron Kaiser)

Beforehand he knew already that the unit required interaction with a PC-based application to sync the 93 kB of on-watch data, with the required software and remote servers now being very much outdated and/or gone. This required some reverse-engineering to once more bring this watch widget back to life. Along the way it became also quite clear that this watch was designed as a cheap rip-off of the much better 1998 Seiko Ruputer – which later got sold also as the onHand PC – using the same joystick-driven interface.

After some poking around with the Windows-based software that came with the watch [Cameron] quickly realized that while it could establish a serial link with the watch in its cradle, it fully relied on a now defunct FTP server formerly run by the manufacturer, Kinger, along with any games and content on it. Since FTP servers were never archived like HTTP sites, this content is likely gone forever.

Fortunately, the protocol between the PC and the watch is a standard serial link (with parity), so [Cameron] was able to sniff the serial traffic and figure out the protocol, the results of which he has made available on GitHub in the form of a Perl script for transforming text and a C-based application to do the uploading. Now once again Web-@nywhere users can proudly roam the streets with 2024-era website content on their wrists.

Reverse-Engineering A Russian Tornado-S Guidance Circuit Board

January 16, 2024 by Maya Posch 21 Comments

With Russian military hardware quite literally raining down onto the ground in Ukraine, it’s little wonder that a sizeable part of PCBs and more from these end up being sold on EBay. This was thus where [msylvain] got a guidance board from a 300 mm Tornado-S 9M542 GLONASS-guided projectile from, for some exploration and reverse-engineering. The first interesting surprise was that the board was produced in February of 2023, with the Tornado-S system having begun production in 2016.

Presumed location of the PCB under investigation in the Tornado-S rocket.

The 9M542 and similar rocket projectiles are designed to reach their designated area with as much precision as possible, which where the guidance system comes into play. Using both GLONASS and inertial navigation, the rocket’s stack of PCBs (pictured) are supposed to process the sensor information and direct the control system, which for the 9M542 consists out of four canards. The board that [msylvain] is looking at appears to be one of the primary PCBs, containing some DC-DC and logic components, as well as three beefy gate arrays (ULAs). While somewhat similar to FPGAs, these are far less configurable, which is why the logic ICs around it are needed to tie everything together. For this reason, gate array technology was phased out globally by the 1990s due to the competition of FPGAs, which makes this dual-sided PCB both very modern and instantly vintage.

This is where a distinct 1980s Soviet electronics vibe begins, as along the way of noting the function of each identified IC, it’s clear that these are produced by the same Soviet-era factories, just with date stamps ranging from 2018 to more recent and surface-mount DIP-sized packages rather than through-hole.

Continue reading “Reverse-Engineering A Russian Tornado-S Guidance Circuit Board” →

Reverse-Engineering The ESP32’s WiFi Binary Blob With A Faraday Cage

January 15, 2024 by Maya Posch 36 Comments

The Faraday cage constructed by Jasper Devreker.

As part of a team reverse-engineering the binary blob driver for the ESP32’s WiFi feature at Ghent University, [Jasper Devreker] saw himself faced with the need to better isolate the network packets coming from the ESP32-under-test. This is a tough call in today’s WiFi and 2.4 GHz flooded airwaves. To eliminate all this noise, [Jasper] had to build a Faraday cage, but ideally without racking up a massive invoice and/or relying on second-hand parts scavenged from eBay.

We previously reported on this reverse-engineering project, which has since seen an update. Although progress has been made, filtering out just the packets they were interested in was a big challenge. The solution was a Faraday cage, but on a tight budget.

Rather than relying on exotic power filters, [Jasper] put a battery inside a Faraday cage he constructed out of wood and conductive fabric. To get Ethernet data in and out, a fiber link was used inside a copper tube. Initial testing was done using a Raspberry Pi running usbip and a WiFi dongle. The Faraday cage provided enough attenuation that the dongle couldn’t pick up any external WiFi signals in listening mode.

The total cost of this build came down to a hair over €291, which makes it feasible for a lot of RF experiments by hobbyists and others. We wish [Jasper] and the rest of the team a lot of luck in figuring out the remaining secrets of Espressif’s binary WiFi blob using this new tool.

Reverse Engineering Smart Meters, Now With More Fuming Nitric Acid

January 13, 2024 by Dan Maloney 14 Comments

If you’re lucky, reverse engineering can be a messy business. Sure, there’s something to be said for attacking and characterizing an unknown system and leaving no trace of having been there, but there’s something viscerally satisfying about destroying something to understand it. Especially when homemade fuming nitric acid is involved.

The recipient of such physical and chemical rough love in the video below is a residential electric smart meter, a topic that seems to be endlessly fascinating to [Hash]; this is far from the first time we’ve seen him take a deep dive into these devices. His efforts are usually a little less destructive, though, and his write-ups tend to concentrate more on snooping into the radio signals these meters are using to talk back to the utility company.

This time around, [Hash] has decided to share some of his methods for getting at these secrets, including decapping the ICs inside. His method for making fuming nitric acid from stump remover and battery acid is pretty interesting; although the laboratory glassware needed to condense the FNA approaches the cost of just buying the stuff outright, it’s always nice to have the knowledge and the tools to make your own. Just make sure to be careful about it — the fumes are incredibly toxic. Also detailed is a 3D-printable micropositioner, used for examining and photographing acid-decapped ICs under the microscope, which we’d bet would be handy for plenty of other microscopy jobs.

In addition to the decapping stuff, and a little gratuitous destruction with nitric acid, [Hash] takes a look at the comparative anatomy of smart meters. The tamper-proofing features are particularly interesting; who knew these meters have what amounts to the same thing as a pinball machine’s tilt switch onboard?

Continue reading “Reverse Engineering Smart Meters, Now With More Fuming Nitric Acid” →

This Week In Security: Bitwarden, Reverse RDP, And Snake

January 5, 2024 by Jonathan Bennett 10 Comments

This week, we finally get the inside scoops on some old stories, starting with the Bitwarden Windows Hello problem from last year. You may remember, Bitwarden has an option to use Windows Hello as a vault unlock option. Unfortunately, the Windows credential API doesn’t actually encrypt credentials in a way that requires an additional Windows Hello verification to unlock. So a derived key gets stored to the credential manager, and can be retrieved through a simple API call. No additional biometrics needed. Even with the Bitwarden vault locked and application closed.

There’s another danger, that doesn’t even require access to the the logged-in machine. On a machine that is joined to a domain, Windows backs up those encryption keys to the Domain Controller. The encrypted vault itself is available on a domain machine over SMB by default. A compromised domain controller could snag a bitwarden vault without ever even running code on the target machine. The good news is that this particular problem with Bitwarden and Windows Hello is now fixed, and has been since version 2023.10.1.

Reverse RDP Exploitation

We normally think about the Remote Desktop Protocol as dangerous to expose to the internet. And it is. Don’t put your RDP service online. But reverse RDP is the idea that it might also be dangerous to connect an RDP client to a malicious server. And of course, multiple RDP implementations have this problem. There’s rdesktop, FreeRDP, and Microsoft’s own mstsc that all have vulnerabilities relating to reverse RDP.

The technical details here aren’t terribly interesting. It’s all variations on the theme of not properly checking remote data from the server, and hence either reading or writing past internal buffers. This results in various forms of information leaks and code executions problems. What’s interesting is the different responses to the findings, and then [Eyal Itkin]’s takeaway about how security researchers should approach vulnerability disclosure.

So first up, Microsoft dismissed a vulnerability as unworthy of servicing. And then proceeded to research it internally, and present it as a novel attack without properly attributing [Eyal] for the original find. rdesktop contained quite a few of these issues, but were able to fix the problem in a handful of months. FreeRDP fixed some issues right away, in what could be described as a whack-a-mole style process, but a patch was cooked up that would actually address the problem at a deeper level: changing an API value from the unsigned size_t to a signed ssize_t. That change took a whopping 2 years to actually make it out to the world in a release. Why so long? Continue reading “This Week In Security: Bitwarden, Reverse RDP, And Snake” →

Reverse-Engineering The Stadia Controller Bluetooth Switching Procedure

December 19, 2023 by Maya Posch 10 Comments

Ever since the demise of Google’s Stadia game streaming service, the associated Stadia controllers have found themselves in limbo, with the only way to switch them from the proprietary WiFi mode to Bluetooth by connecting to a special Google website. Yet as [Gary] found out, all this website does is flash a firmware file via WebUSB and WebHID over the original Stadia firmware with a generic Bluetooth controller firmware image. This is the reason why it’s a one-way process, but this wasn’t to [Gary]’s liking, so he figured out how to flash the controller himself, with the option to flash the original Stadia firmware or something else on it later, too.

[Gary]’s stadiatool follows the same procedure as the Google Stadia website, just implemented in Python and outside the control of Google. Although Google has recently announced that it will keep the Bluetooth switching website online one year longer – until December 31st 2024 – at some point this service will go away and only projects like [Gary]’s together with squirreled away firmware images can still save any stray Stadia controllers that will inevitably discovered in the back of a warehouse in the future.

Although we reported on the demise of Stadia when it happened in January of 2023, as Ars Technica notes it was common in 2022 to buy into Stadia and get a controller manufactured in the 2019 launch year, suggesting massive overproduction.

Oddball LCDs Reverse Engineered Thanks To Good Detective Work

December 12, 2023 by Dan Maloney 5 Comments

Is there anything more discouraging to the reverse engineer than to see a black blob of epoxy applied directly to a PCB? We think not, because that formless shape provides no clue as to what chip lies beneath, and that means a lot of detective work if you’re going to figure out how to use this thing.

[Sudhir Chandra]’s detective story starts with a bunch of oddball LCDs, slim 1×32 character units rather than the more familiar 2×16 displays. Each bore the dreaded black COB blob on the back, as well as a handful of SMD components and not much else. Googling revealed no useful documentation, and the manufacturer wasn’t interested in fielding calls from a hobbyist. Reasoning that most manufacturers wouldn’t spin up a custom chip for every display, [Sudhir] assumed there was an ST7066, a common LCD driver chip, underneath the blob, especially given the arrangement of external components. But a jumper set was bodged together under this assumption didn’t get the display going.

Next up were more destructive methods, to decap the COB and see what kind of numbers might be on the chip. Sandpaper worked at first, but [Sudhir] eventually turned to the “Chips a la [Antoine]” method of decapping, which uses heat and brute force to get at the goods. This got down to the chip, but [Sudhir]’s microscope wasn’t up to the task of reading the die markings.

What eventually cracked the case was tracing out the voltages across the various external resistors and matching them up to other chips in the same family as the ST7066, plus the realization that the long, narrow epoxy blob probably covered a similarly shaped chip, which led to the culprit: an ST7070. This allowed [Sudhir] to build an adapter PCB for the displays, with plans for a custom Arduino library to talk to the displays.

This was a great piece of reverse engineering and a good detective story to boot. Hats off to [Sudhir] for sticking with it.