Did you know you can get a “smart bed” that tracks your sleep, breathing, heart rate, and even regulates the temperature of the mattress? No? Well, you can get root access to one, too, as [Dillan] shows, and if you’re lucky, find a phone-home backdoor-like connection. The backstory to this hack is pretty interesting, too!

You see, a Sleep Number bed requires a network connection for its smart features, with no local option offered. Not to worry — [Dillan] wrote a Homebridge plugin that’d talk the cloud API, so you could at least meaningfully work with the bed data. However, the plugin got popular, Sleep Number didn’t expect the API to be that popular. When they discovered the plugin, they asked that it be shut down. Tech-inclined customers are not to be discouraged, of course.

Taking a closer look at the hardware, [Dillan] found a UART connection and dumped the flash, then wrote an extensive tutorial on how to tap into your bed’s controller, which runs Linux, and add a service you can use locally to query bed data and control the bed – just like it should have been from the beginning. Aside from that, he’s found a way to connect this hub to a network without using Sleep Number’s tools, enabling fully featured third-party use – something that the company doesn’t seem to like. Another thing he’s found is a reverse SSH tunnel back into the Sleep Number network.

Now, it can be reasonable to have a phone-home tunnel, but that doesn’t mean you want it in your personal network, and it does expose a threat surface that might be exploited in the future, which is why you might want to know about it. Perhaps you’d like to use Bluetooth instead of WiFi. Having this local option is good for several reasons. For example, having your smart devices rely on the manufacturer’s server is a practice that regularly results in perma-bricked smart devices, though we’ve been seeing some examples of dedicated hackers bringing devices back to life. Thanks to this hack, once Sleep Number shutters, is bought out, or just wants to move on, their customers won’t be left with a suddenly dumbed-down bed they can no longer control.

[Header image courtesy of Sleep Number]

Over the last few years, it’s been increasingly common for concertgoers to be handed a light-up bracelet from PixMob that synchronizes with the others in the crowd to turn the entire audience into a music visualizer. They’re a clever way of enhancing the concert experience, but unfortunately, they don’t do anything once you leave the show. Or at least, that used to be the case.

We’ve seen efforts to reverse engineer the IR (and occasionally radio) signals that drive these PixMob devices, but since we checked in last it seems like things have gotten a lot easier for the home gamer. [David Pride] has recently posted a brief write-up that shows how quickly and easily it is to get these devices fired up using nothing more exotic than an Arduino, an IR LED, and an audio sensor module.

With the audio sensor module connected to the Arduino’s digital input and the IR LED wired to digital out, all you need to do is flash firmware to the board and start playing some beats. The source code [David] has provided is a a remixed version of what’s previously been published by [Carlos Ganoza], which, in this case, has been tweaked to make the lighting patterns less random.

Presumably, this is to make the devices behave more like they do during an actual concert, but since nobody at Hackaday is cool enough to have seen a live musical performance in the last decade, we’re not really sure. All we can say is that the effect looks pretty sweet in the demo video.

Back in 2019, we saw a teardown of an early PixMob device, and by 2022, the efforts to reverse engineer their IR control protocol were well underway. We’re glad to see things have progressed to the point that you can piece together a transmitter from what’s in the parts bin, as it means at least some of these devices will have a lifespan longer than a single concert.

[Poking Technology] doesn’t think much of his new smartwatch. It is, by his admission, the cheapest possible smartwatch, coming in at about $3. It has very few useful features but he has figured out how to port MicroPython to it, so for a wrist-mounted development board with BLE, it might be useful. You can check it out in the video below.

The first step is a teardown, which reveals surprisingly little on the inside. There’s a tiny battery, a few connections, a display, and a tiny CPU board. There are, luckily, a few test pads that let you get into the CPU. What do you get? A 24 MHz Telink CPU with 512k of flash and 16k of RAM, along with all the other hardware.

Of course, even if you just want a display with some smarts, $3 might be in your price range. The whole thing wound up taped down to a PCB. But the usual debugger didn’t want to connect. Grabbing an oscilloscope revealed that the output from the board had some level problems. He eventually wrote his own debugger interface using a Pi Pico.

He was able to find the onboard CPU’s development tools. The CPU claims to be proprietary but looks suspiciously like a slightly modified ARM. A short investigation shows that the object code is extremely similar to the ARM Thumb instruction set but with a few extra bits set and different mnemonics. But once you put Python on board, who really cares?

The only downside is that it doesn’t appear that the BLE is practically usable because of memory limitations. But there are still places you might use the little watch in a project.

If you want a smartwatch, maybe build your own. While many DIY watches are simple, you can get pretty complicated if you like.

We’ve seen prolific firmware hacker [Aaron Christophel] tackle smart devices of all sorts, and he never fails to deliver. This time, he’s exploring a device that seems like it could have come from the pages of a Cyberpunk RPG manual — a shiny chrome Bluetooth Low Energy (BLE) smart ring that’s packed with sensors, is reasonably hacker friendly, and is currently selling for as little as $20.

The ring’s structure is simple — the outside is polished anodized metal, with the electronics and battery carefully laid out along the inside surface, complete with a magnetic charging port. It has a BLE-enabled MCU, a heartrate sensor, and an accelerometer. It’s not much, but you can do a lot with it, from the usual exercise and sleep tracking, to a tap-sensitive interface for anything you want to control from the palm of your hand. In the video’s comments, someone noted how a custom firmware for the ring could be used to detect seizures; a perfect example of how hacking such gadgets can bring someone a brighter future.

The ring manufacturer’s website provides firmware update images, and it turns out, you can upload your own firmware onto it over-the-air through BLE. There’s no signing, no encryption — this is a dream device for your purposes. Even better, the MCU is somewhat well-known. There’s an SDK, for a start, and a datasheet which describes all you would want to know, save for perhaps the tastiest features. It’s got 200 K of RAM, 512 K of flash, BLE library already in ROM, this ring gives you a lot to wield for how little space it all takes up. You can even get access to the chip’s Serial Wire Debug (SWD) pads, though you’ve got to scrape away some epoxy first.

As we’ve seen in the past, once [Aaron] starts hacking on these sort of devices, their popularity tends to skyrocket. We’d recommend ordering a couple now before sellers get wise and start raising prices. While we’ve seen hackers build their own smart rings before, it’s tricky business, and the end results usually have very limited capability. The potential for creating our own firmware for such an affordable and capable device is very exciting — watch this space!

We thank [linalinn] for sharing this with us!

[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.

One exciting feature of hardware development involving MCUs and FPGAs is that you all too often need specific tools to program them, with [Doug Brown] suffering a price tag aneurysm after checking the cost of an official Altera/Intel USB Blaster (yours for $300) to program a MAX 10 FPGA device with. This led him naturally down the path of exploring alternatives, with the $69 Terasic version rejected for ‘being too expensive’ and opting instead for the Waveshare USB Blaster V2, at a regretful $34. The amazing feature of this USB Blaster clone is that while it works perfectly fine under Windows, it works at most intermittently under Linux.

This led [Doug] down the path of reverse-engineering and diagnosing the problem, ultimately throwing in the towel and downclocking the Altera CPLD inside the adapter after finding that it was running a smidge faster than the usual 6 MHz. This was accomplished initially by wiring in an external MCU as a crude (and inaccurate) clock source, but will be replaced with a 12 MHz oscillator later on. Exactly why the problem only exists on Linux and not on Windows will remain a mystery, with Waveshare support also being clueless.

Undeterred, [Doug] then gambled on a $9 USB Blaster clone (pictured above), which turned out to be not only completely non-functional, but also caused an instant BSOD on Windows, presumably due to the faked FTDI USB functionality tripping up the Windows FTDI driver. This got fixed by flashing custom firmware by [Vladimir Duan] to the WCH CH552G-based board after some modifications shared in a project fork. This variety of clone adapters can have a range of MCUs inside, ranging from this WCH one to STM32 and PIC MCUs, with very similar labels on the case. While cracking one open we had lying around, we found a PIC18 inside, but if you end up with a CH552G-based one, this would appear to fully fix it. Which isn’t bad for the merest fraction of the official adapter.

Thanks to [mip] for the tip.

With all the EV hype in the air, you’d be forgiven for thinking electric vehicles are something new. But of course, EVs go way, way back, to the early 19th century by some reckonings. More recently but still pretty old-school were Ford’s Think line of NEVs, or neighborhood electric vehicles. These were commercially available in the early 2000s, and something like 7,200 of the slightly souped-up golf carts made it into retirement communities and gated neighborhoods.

But as Think aficionado [Hagan Walker] relates, the Achille’s heel of these quirky EVs was its instrument cluster, which had a nasty habit of going bad and taking the whole vehicle down with it, sometimes in flames. So he undertook the effort of completely reverse engineering the original cluster, with the goal of building a plug-in replacement.

The reverse engineering effort itself is pretty interesting, and worth a watch. The microcontroller seems to be the primary point of failure on the cluster, probably getting fried by some stray transients. Luckily, the microcontroller is still available, and swapping it out is pretty easy thanks to chunky early-2000s SMD components. Programming the MCU, however, is a little tricky. [Hagan] extracted the code from a working cluster and created a hex file, making it easy to flash the new MCU. He has a bunch of other videos, too, covering everything from basic diagnostics to lithium battery swaps for the original golf cart batteries that powered the vehicle.

True, there weren’t many of these EVs made, and fewer still are on the road today. But they’re not without their charm, and keeping the ones that are still around from becoming lawn ornaments — or worse — seems like a noble effort.

If there’s one thing we like better around here than old, obscure displays, it’s old, obscure displays with no documentation that need a healthy dose of reverse engineering before they can be put to use. These Plessey dot-matrix displays are a perfect example of that.

We’re not sure where [Michael] scored these displays, but they look fantastic. Each 8-pin DIP has two 5×7-matrix, high-visibility LED displays. They bear date codes from the late 80s under the part number, GPD340, but sadly, precious little data about them could be dredged up from the Interwebz. With 70 pixels and only six pins after accounting for power and ground, [Michael] figured there would be a serial protocol involved, but which pins?

He decided to brute-force the process of locating them, using a Pico to sequentially drive every combination while monitoring the current used with a current sensor. This paid off after only a few minutes, revealing that each character of the display has its own clock and data pins. The protocol is simple: pull the clock and data pins high then send 35 bits, which the display sorts out and lights the corresponding pixels. The video below shows a 12-character scrolling display in action.

Plessey made a lot of displays for military hardware, and these chunky little modules certainly have a martial air about them. Given that and the date code, these might have come from a Cold War-era bit of military hardware, like this Howitzer data display which sports another Plessey-made display.

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.

Although much of the software that runs on the ESP32 microcontroller is open source, the Wi-Fi driver is not. Instead, it uses a proprietary binary blob. This was no problem for [Jasper Devreker]’s reverse-engineering of the ESP32’s Wi-Fi stack so far until he came face to face with reverse-engineering the initialization of the Wi-Fi peripheral. As it turns out, there is a lot of work involved after you call esp_phy_enable in the Espressif binary blob, with the team logging 53,286 peripheral accesses during the initialization phase. In comparison, sending a Wi-Fi packet takes about ten calls.

Currently, the way that the initialization step is handled is by having the initialization routine in the binary blob do its thing by configuring the radio and other elements before killing the FreeRTOS task and replacing it with their own version. The team is actively looking for a clean approach for moving forward that will avoid simply writing everything from scratch. For the Wi-Fi MAC, existing code (e.g., FreeBSD’s stack) could be used, but the radio code is much more of a headache. Clearly, there’s still a lot more work to be done in order to get a fully open-source Wi-Fi MAC and stack for the ESP32, but having the community (that’s you) pitch in might speed things up if there’s demand for an open-source driver.

[Jasper’s] been working on this for a while. He’s even built a Faraday cage to make the task easier.

Some of us may have recently stumbled over these mysterious ‘Mini 560’ synchronous buck converter modules at various e-shopping websites. These little modules claim to take in 7-20 VDC and output whatever voltage they’re configured for (e.g., 5 VDC). What IC is used on these modules? Since the IC on these modules has had its markings laser-etched away, answering that particular question is a tedious sleuthing job. Fortunately, [MisterHW] has done the legwork for us already, with a detailed write-up.

Details like the nominal input rating, measured currents, and resulting efficiency values provide clues. Looking at the 0603 SMD resistor values for given output voltages provides the programming resistances, combined with the footprint of the QFN-20 package. After desoldering the IC on a sample board, the footprint was reminiscent of certain Texas Instruments (Ti) packages, leading to a perusal of the Ti parametric database and a couple of candidate matches.

The other provided parameters for the Mini 560, such as the 500 kHz frequency, narrows things down to two Ti parts: the TPS51397A and TPS56C230. The latter only accepts up to 18 VDC unless you look at the absolute maximum ratings, which matches the 20 VDC. The pin-out of the TPS56C230 also matches the Mini560 IC, but looking deeper, there’s no good match.

Catching a lucky break, [MisterHW] got pointed to the JoulWatt JW5069A, which, as it turns out, is a good match, including the odd footprint with bridged pads. Googling for this part number even led to images of the Mini 560 module without the laser-etching. It looks like JoulWatt may have been founded in China in 2013 to provide drop-in alternatives for Western parts like those from Ti (with the JW5068A also very interesting), but it still doesn’t really explain the laser-etched markings unless these parts aren’t designed for the export market? Some mysteries may never truly be solved, it seems.

Of course, we’ve seen other buck converter modules that are less mysterious. Want to know the theory behind it? We got you.

Over the past few years a number of teams have been putting a lot of effort into taking beloved Nintendo 64 games, decompiling them, and lovingly crafting them into highly portable C code. This allows for these games to not only run natively on PCs, but also for improvements to be made to the rendering engine and other components.

Yet this artisan approach to porting these games means a massive time investment, something which static binary translation (static recompilation) may conceivably speed up. Enter the N64: Recompiled project, which provides a binary translation tool to ease the translation of the N64’s binaries into C code.

This is effectively quite similar to what an emulator does in real-time, just with the goal of creating a permanent copy of the translated instructions. After this static binary translation, the C code can be compiled again, but as noted by the project’s documentation, a suitable runtime is needed to get a functional game. An example of this is the Zelda 64: Recompiled project, which uses the N64: Recompiled project at its core, while providing the necessary scaffolding and wrappers to create a working copy of The Legend of Zelda: Majora’s Mask as output.

In the video below, [Modern Vintage Gamer] takes the software for a test drive and comes away very excited about the potential it has to completely change the state of N64 emulation. To be clear, this isn’t a one-button-press solution — it still requires capable developers to roll up their sleeves and get the plumbing in. It’s going to take some time before you favorite game is supported, but the idea of breathing new life into some of the best games from the 1990s and early 2000s certainly has us eager to see where this technology goes

Thanks to [Keith Olson] for the tip.

[Matthew “wrongbaud” Alt] is well known around these parts for his hardware hacking and reverse-engineering lessons, and today he’s bringing us a JTAG hacking primer that demoes some cool new hardware — the PiFEX (Pi Interface Explorer). Ever wondered about those testpoint arrays on mSATA and M.2 SSDs? This write-up lays bare the secrets of such an SSD, using a Pi 4, PiFEX, OpenOCD and a good few open-source tools for JTAG probing that you can easily use yourself.

The PiFEX hat gives you level-shifted bidirectional GPIO connectors for UART, SPI, I2C, JTAG, SWD and potentially way more, an OLED screen to show any debugging information you might need, and even a logic analyzer header so that you can check up on your reverse-engineering progress.

The suggested software workflow pulls no punches either, proposing ease-of-use features like USB-Ethernet gadget mode and Jupyter notebooks. [wrongbaud] shows us how to find JTAG among the dozen testpads left on the SSD, get the SSD single-stepping through code, and dump some of its memory space as a test. Full of tricks of the trade like reverse-engineering devices on a sheet of paper you can leave markings on, this write-up gives you a solid background in JTAG hacking, even if you only have a Pi and an old SSD.

So how can you get your hands on one? [wrongbaud] says the plan is to open source both the PiFEX hardware and software in the near future. Until until then, it looks like at least the hardware it wouldn’t be too hard to re-implement it yourself if you wanted to get the hang of reverse engineering with the Raspberry Pi.

[Matthew “wrongbaud” Alt] is a good friend of Hackaday community. He’s stopped by to host a reverse engineering Hack Chat, and ran a HackadayU class on Ghidra. His reverse-engineering journeys are always an informative read, from using arcade machines as a Linux hacking primer, to hacking a cryptocurrency wallet through glitching attacks.

Augmented reality (AR) tech is getting more and more powerful, the glasses themselves are getting sleeker and prettier, and at some point, hackers have to conquer this frontier and extract as much as possible. [Void Computing] is writing an open source SDK for making use of AR glasses, and, along the way, they’ve brought us two wonderful blog posts filled with technical information laid out in a fun to read way. The first article is titled “AR glasses USB protocols: the Good, the Bad and the Ugly”, and the second one follows as “the Worse, the Better and the Prettier”.

Have you ever wanted to learn how AR glasses and similar devices work, what’s their internal structure, which ones are designed well and which ones maybe not so much? These two posts have concise explanations, more than plenty of diagrams, six case studies of different pairs of AR glasses on the market, each pair demonstrated by our hacker’s canine assistant.

[Void Computing] goes in-depth on this tech — you will witness MCU firmware reverse-engineering, HID packet captures, a quick refresher on the USB-C DisplayPort altmode, hexdumps aplenty, and a reminder on often forgotten tools of the trade like Cunningham’s law.

If reverse-engineering lights your fire, these high-level retrospectives will teach you viable ways to reverse-engineer devices in your own life, and they certainly set a high bar for posts as far as write-ups go. Having read through these posts, one can’t help but think that some sort of AR glasses protocol standard is called for here, but fortunately, it appears like [Void Computing]’s SDK is the next best thing, and their mission to seize the good aspects of a tentative cyberpunk future is looking to be a success. We’ve started talking about AR glasses over a decade ago, and it’s reassuring to see hackers catching up on this technology’s advancements.

We thank [adistuder] for sharing this with us on the Hackaday Discord server!

Sometimes, you will want to power a device in a way it wasn’t designed for, and you might find that the device in question is way too tailored to the original power source. Today, [Oleg Kutkov] is here to give us a master class on excising unnecessary power conversion out of your devices, with the Starlink terminal as an example. This device can only be officially powered from 48V PoE, but can technically work from about 12V – and, turns out, many people want to mount a Starlink terminal to their cars.

[Oleg] shows us the power circuit of the Starlink terminal, explaining which component is responsible for what, and gives us a block diagram. Then, he shows you the 12V rail that all internal components actually draw power from, and where to feed power into it. Plus, he warns you about possible caveats, like having to disable the builtin 12V regulator to prevent it from backfeeding-induced damage. If you’re looking to modify a similar device, this tutorial gives you heaps of insight on what you might need on your foray.

Thinking to modify your own Starlink terminal, perhaps, and wondering about the power consumption? [Oleg] has current consumption graphs for you, collected with a data logger for Uni-T UT800 of his own design, providing detailed figures on just how much energy you ought to supply to power the terminal from 12V, and where to (not) get it. After all, even a seemingly suitable power supply might not do.

If you ever wondered just what it takes to build a modern device like a phone, you should have come to last year’s Supercon and talked with [Jose Angel Torres]. He’s an engineer whose passion into investigating what makes modern devices tick is undeniable, and he tells us all about where his forays have led so far – discovering marvels that a Western hacker might not be aware of.

Six years ago, he has moved to China, having previously been responsible for making sure that their Chinese subcontractors would manufacture things in the right ways. Turns out, doing that while being separated by an ocean set up more than just the timezone barriers – they were communicating between different worlds.

[Jose] tells us of having learned Chinese on the spot, purely from communicating with people around him, and it’s no wonder he’s had the motivation! What he’s experienced is being at the heart of cycle of hardware life, where devices are manufactured, taken apart and rebuilt anew. Here’s how he tapped into that cycle, and where he’s heading now.

One day, he sat down with his phone, connected to a computer, ADB prompt open, and enabled a logging routine. He saw a myriad of debug messages scrolling past – despite the phone being, for all intents and purposes, turned off, it was still alive. That made him think – now, what makes a phone tick? Which parts of it are responsible for this activity? How much control do you have over this, and can you replace these parts?

To get to the core of these questions, he headed down into dark places, where phones are taken apart, their motherboards laid bare, people working away with hot air guns and tweezers in hand. Trays of freshly desoldered BGAs, to be put into bespoke testing jigs and verified, so that they can be repackaged into tapes anew and resold to customers unconcerned with an increased failure rate.

On the streets where blocks are entirely owned by different companies, in stores overflowing with parts you couldn’t imagine to have existed, he has met a handful of friendly faces, each introducing him to different facets of the hardware world – from Macbook repairs that are officially not supposed to happen, to full-board reverse-engineering services.

If you need a PCB taken apart layer by layer, component by component, carefully imaged, and turned into CAD files, here is where you can get this done. What about a phone? What if you wanted to rebuild a phone? Well, not only can you fully reverse-engineer its PCB here, but they have tons of custom tooling for all the even somewhat popular models.

He glanced at a Huawei phone he’s just recently had bought, and decided to use it as a case study. The Ifixit diagrams can tell you about every single component on it, but only here can you walk up to a table and see piles and bins full of all sorts of different components for this specific model. Need a specific BGA? Here’s where you get a strip of them for $10.

What if you want to recreate the entire manufacturing process for a specific phone, from schematic to test jig, complete with all the different little parts like custom antennas and shells? That’s where you refer to a reverse-engineering company. This kind of company will take an example board, desolder all components, sand off all layers to get to even the internal copper, put all that data into a digital format. All passives that are taken off? Measured with an LCR meter. All ICs? Carefully documented, and, again, you can get a strip of them for $10. After a few weeks of work, you get Gerber files and Altium sources you can modify to add any feature the board might be missing. A schematic usually not included, but you can pay for it to be rebuilt too. And, of course, you get a BOM. Now, this is most of what you need to get a batch of identical phones assembled, starting from just one.

Now, what about if you need some test fixtures for bringup? Here, you can even use a phone of the same model as a test fixture – extend the connectors with separate FPCs, and use that second phone to test any of the different components you might be working on. All of these practices tie into the smaller seller culture, where every part you buy is marked with a seller’s stamp, so you can try and bring it back for a refund if it’s faulty.

[Jose] ends by showing a small curiosity he’s found – an I2C-connected daughterboard for a certain phone lineup, that almost, just barely, fits the SAO standard, with proximity and ambient light sensors on it. If you ever wanted to build a secure phone, you want to understand it, and if you want to understand what makes a phone tick, China will give you insights from the place this phone was born.

If your thought repurposing DVB-T dongles for generic software defined radio (SDR) use was cool, wait until you see QCSuper, a project that re-purposes phones and modems to capture raw 2G/3G/4G/5G. You have to have a Qualcomm-based device, it has to either run rooted Android or be a USB modem, but once you find one in your drawers, you can get a steady stream of packets straight into your Wireshark window. No more expensive SDR requirement for getting into cellular sniffing – at least, not unless you are debugging some seriously low-level issues.

It appears there’s a Qualcomm specific diagnostic port you can access over USB, that this software can make use of. The 5G capture support is currently situational, but 2G/3G/4G capabilities seem to be pretty stable. And there’s a good few devices in the “successfully tested” list – given the way this software functions, chances are, your device will work! Remember to report whether it does or doesn’t, of course. Also, the project is seriously rich on instructions – whether you’re using Linux or Windows, it appears you won’t be left alone debugging any problems you might encounter.

This is a receive-only project, so, legally, you are most likely allowed to have fun — at least, it would be pretty complicated to detect that you are, unlike with transmit-capable setups. Qualcomm devices have pretty much permeated our lives, with Qualcomm chips nowadays used even in the ever-present SimCom modules, like the modems used in the PinePhone. Wondering what a sniffer could be useful for? Well, for one, if you ever need to debug a 4G base station you’ve just set up, completely legally, of course.

In the world of cheap amateur radio transceivers, the Quansheng UV-K5 can’t be beaten for hackability. But pretty much every hack we’ve seen so far focuses on the firmware. What about the hardware?

To answer that question, [mentalDetector] enlisted the help of a few compatriots and vivisected a UV-K5 to find out what makes it tick. The result is a (nearly) complete hardware description of the radio, including schematics, PCB design files, and 3D renders. The radio was a malfunctioning unit that was donated by collaborator [Manuel], who desoldered all the components and measured which ones he could to determine specific values. The parts that resisted his investigations got bundled up along with the stripped PCB to [mentalDetector], who used a NanoVNA to characterize them as well as possible. Documentation was up to collaborator [Ludwich], who also made tweaks to the schematic as it developed.

PCB reverse engineering was pretty intense. The front and back of the PCB — rev 1.4, for those playing along at home — were carefully photographed before getting the sandpaper treatment to reveal the inner two layers. The result was a series of high-resolution photos that were aligned to show which traces connected to which components or vias, which led to the finished schematics.

There are still a few unknown components, mostly capacitors by the look of it, but the bulk of the work has been done, and hats off to the team for that. This should make hardware hacks on the radio much easier, and we’re looking forward to what’ll come from this effort. If you want to check out some of the firmware exploits that have already been accomplished on this radio, check out the Trojan Pong upgrade, or the possibilities of band expansion. We’ve also seen a mixed hardware-firmware upgrade that really shines.

Most reverse engineering projects we see around here have some sort of practical endpoint in mind. Usually, but not always. Reverse-engineering a 40-year-old cable modem probably serves no practical end, except for the simple pleasure of understanding how 1980s tech worked.

You’ll be forgiven if the NABU Network, the source of the modem [Jared Boone] tears into, sounds unfamiliar; it only existed from 1982 to 1985 and primarily operated in Ottawa, Canada. It’s pretty interesting though, especially the Z80-based computer that was part of the package. The modem itself is a boxy affair bearing all the hallmarks of 1980s tech. [Jared]’s inspection revealed a power supply with a big transformer, a main logic board, and a mysterious shielded section with all the RF circuits, which is the focus of the video below.

Using a signal generator, a spectrum analyzer, and an oscilloscope, not to mention the PCB silkscreen and component markings, [Jared] built a block diagram of the circuit and determined the important frequencies for things like the local oscillator. He worked through the RF section, discovering what each compartment does, with the most interesting one probably being the quadrature demodulator. But things took a decidedly digital twist in the last compartment, where the modulated RF is turned into digital data with a couple of 7400-series chips, some comparators, and a crystal oscillator.

This tour of 80s tech and the methods [Jared] used to figure out what’s going on in this box were pretty impressive. There’s more to come on this project, including recreating the original signal with SDRs. In the mean time, if this put you in the mood for other videotext systems of the 80s, you might enjoy this Minitel terminal teardown.