Hunting For Part Numbers: Analyzing The Buck Converter On Mini 560 Modules

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.

Continue reading “Hunting For Part Numbers: Analyzing The Buck Converter On Mini 560 Modules”

Static Recompilation Brings New Life To N64 Games

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

Continue reading “Static Recompilation Brings New Life To N64 Games”

Pi with the PiFEX shield on the right, the SSD under test on the left with testpoints held by a jumper clip, jumper wires connecting the two together

JTAG Hacking An SSD With A Pi: A Primer

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

Continue reading “JTAG Hacking An SSD With A Pi: A Primer”

Two pictures of the same black dog, wearing two separate pairs of the AR glasses reviewed in these two articles

A Master-Class On Reverse-Engineering Six AR Glasses

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!

Starlink terminal being injected with 12V from an external PSU

Bypass PoE And Power Your Starlink Terminal Directly

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.

Wireshark screenshot with QCSuper-produced packets streaming into it; QCSuper script running in an adjacent terminal

Turn Your Qualcomm Phone Or Modem Into Cellular Sniffer

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.

Reverse Engineering A Fancy Disposable Vape

Many readers will be aware of the trend for disposable vapes, and how harvesting them for lithium-ion batteries has become a popular pastime in our community. We’re all used to the slim ones about the size of a marker pen, but it’s a surprise to find that they also come in larger sizes equipped with colour LCD screens. [Jason Gin] received one of this type of vape, and set about reverse engineering it.

What he found inside alongside the lithium-ion cell (we love his use of the term ” street lithium” by the way) was an ARM Cortex M0 microcontroller, 1 MB of flash, and that 80×160 display. Some investigation revealed this last part to have an ST7735S controller with an SPI interface. He turned his attention to the flash, which was filled with the bitmaps for the display. Seeing an opportunity there, this lead to the creation of a Windows 95 theme for the device.

Finally, the microcontroller turned out to be accessible with programming tools, with an unprotected firmware. The reverse engineering effort is ongoing, but we hope the result is a small dev board that will at least save some of the from being e-waste. If you’re curious, all the tools used are in a GitHub repository.

Meanwhile, we’ve looked at street lithium harvesting before.

Thanks [DeadFishOnTheLanding] for the tip!