Reverse-engineering The Milwaukee M18 Redlink Protocol

September 15, 2023 by Maya Posch 19 Comments

In an ideal world, every single battery pack for power tools would use the same physical interface and speak a clearly documented protocol with chargers. Since we live in a decidedly less-than-ideal world, we get to enjoy the fun pastime of reverse-engineering the interfaces and protocols of said battery packs.

A recent video from the [Tool Scientist] goes over what is already known about the Milwaukee M18 Redlink protocol, used with the manufacturer’s M18-series of batteries, before diving into some prodding and poking of these packs’ sensitive parts to see what comes out of their interface.

Previously, [Buy It Fix It] shared their findings on Reddit, covering the basic protocol, including the checksum method, but without an in-depth analysis of the entire charging protocol. Meanwhile [Quagmire Repair] performed an in-depth teardown and reverse-engineering of the M18 hardware, including the circuitry of the BMS.

Putting these two things together, [Tool Scientist] was able to quickly get some of his M18 packs strapped down into the analysis chair for both passive analysis, as well as the effect of overvoltage, undervoltage, overheating and freezing the battery pack on the output reported by the battery’s BMS.

One of the lists of commands and response messages obtained by [Tool Scientist] on YouTube.

The result is a rather comprehensive list of instructions obtained under these various conditions, including a fault condition (05) returned by the BMS of one pack indicating its likely demise. Overall, it does not appear to be a particularly special (or well-designed) protocol, but it does make for a good reverse-engineering target, while adding to the body of collective knowledge on these widely available battery packs.

Hopefully the same inertia that prevents people from moving outside the designated power tool ecosystem due to the incompatible battery packs will also ensure that this level of knowledge will remain relevant for the foreseeable future, especially since the manufacturers of knock-off battery packs seem rather unwilling to share the results of their own reverse-engineering efforts.

Continue reading “Reverse-engineering The Milwaukee M18 Redlink Protocol” →

Logic Analyzers: Capabilities And Limitations

September 12, 2023 by Arya Voronova 12 Comments

Last time, we’ve used a logic analyzer to investigate the ID_SD and ID_SC pins on a Raspberry Pi, which turned out to be regular I2C, and then we hacked hotplug into the Raspberry Pi camera code with an external MCU. Such an exercise makes logic analyzers look easy, and that’s because they are! If you have a logic analyzer, you’ll find that a whole bunch of hacks become available to you.

In this article, let’s figure out places where you can use a logic analyzer, and places where you can’t. We’ll start with the first limitation of logic analyzers – capture speed. For instance, here’s a cool thing you can buy on Aliexpress – a wristband from TTGO that looks like a usual fitness tracker, but has an ESP32 in it, together with an IMU, an RTC, and an IPS screen! The seller also has an FFC-connectable devboard for programming this wristband over UART, plus vibromotor and heartrate sensor expansion modules.

You can run C, MicroPython, Rust, JavaScript, or whatever else – just remember to bring your own power saving, because the battery is super small. I intended to run MicroPython on it, however, and have stumbled upon a problem – the ST7735-controller display just wouldn’t work with the st7735.py library I found; my image would be misaligned and inverted.

The specifications didn’t provide much other than “ST7735, 80×160”. Recap – the original code uses an Arduino (C++) ST7735 library and works well, and we have a MicroPython ST7735 library that doesn’t. In addition to that, I was having trouble getting a generic Arduino ST7735 library to work, too. Usually, such a problem is caused by the initialization commands being slightly different, and the reason for that is simple – ST7735 is just the name of the controller IC used on the LCD panel.

Each display in existence has specifics that go beyond the controller – the pixels of the panel could be wired up to the controller in a bunch of different ways, with varying offsets and connection types, and the panel might need different LCD charge pump requirements – say, depending on the panel’s properties, you might need to write 0x10 into a certain register of the ST7735, or you will need 0x40. Get one or more of these registers wrong, and you’ll end up with a misaligned image on your display at best, or no output at worst. Continue reading “Logic Analyzers: Capabilities And Limitations” →

Logic Analyzers: Tapping Into Raspberry Pi Secrets

August 31, 2023 by Arya Voronova 45 Comments

Today, I’d like to highlight a tool that brings your hacking skills to a whole new level, and does that without breaking the bank – in fact, given just how much debugging time you can save, how many fun pursuits you can unlock, and the numerous features you can add, this might be one of the cheapest tools you will get. Whether it’s debugging weird problems, optimizing your code, probing around a gadget you’re reverse-engineering, or maybe trying to understand someone’s open-source library, you are likely missing out a lot if you don’t have a logic analyzer on hand!

It’s heartbreaking to me that some hackers still don’t know the value that a logic analyzer brings. Over and over again, tactical application of a logic analyzer has helped me see an entirely different perspective on something I was hacking on, and that’s just the thing I’d like to demonstrate today.

Diving In

A logic analyzer has a number of digital inputs, and it continuously reads the state of these digital inputs, sending them to your computer or showing them on a screen – it’s like a logic-level-only oscilloscope. If you have an I2C bus with one MCU controlling a sensor, connect a logic analyzer to the clock and data pins, wire up the ground, launch the logic analyzer software on your computer, and see what’s actually happening.

For instance, have you ever noticed the ID_SC and ID_SD pins on the Raspberry Pi GPIO connector? Are you wondering what they’re for? Don’t you want to check what actually happens on these pins? Let’s do that right now! Continue reading “Logic Analyzers: Tapping Into Raspberry Pi Secrets” →

Op-Amp Challenge: Light Up Breadboard Shows Us The Signals

May 5, 2023 by Jenny List 5 Comments

Most Hackaday readers will no doubt at some point used a solderless breadboard for prototyping. They do the job, but sometimes their layout can be inflexible and keeping track of signals can be a pain. There’s a neat idea from [rasmusviil0] which might go some way to making the humble breadboard easier to use, it’s a breadboard in which each line is coupled via an op-amp buffer to an LED. In this way it can be seen at a glance some indication of the DC voltage present.

It’s an idea reminiscent of those simple logic probes which were popular years ago, but its implementation is not entirely easy. Each circuit is simple enough, but to replicate it across all the lines in a breadboard makes for a huge amount of quad op-amp chips stuffed onto one piece of stripboard as well as a veritable forest of wires beneath the board.

The effect is of a breadboard crossed with a set of blinkenlights, and we could see that for simple digital circuits it could have some utility if not so much for higher frequency or analogue signals. Certainly it’s an experiment worth doing, and indeed it’s not the first tricked out breadboard we’ve seen.

Reverse Engineering The Apple Lightning Connector

February 22, 2023 by Chris Lott 7 Comments

A frequent contributor to the hacker community, [stacksmashing] has prepared an excellent instructional video on reverse engineering Apple’s Lighting connector proprietary protocol. The video begins by showing how to gain physical access to the signals and hooking them up to a logic analyzer. He then notes that the handshaking uses only a single signal and proposes that Apple isn’t going to re-invent the wheel (perhaps a risky assumption). Using a ChatGPT search, obligatory these days, we learn that Dallas Semiconductor / Microchip 1-wire is probably the protocol employed.

Which embedded single-wire busses exist that encode bits with different lengths of low and high signals?

At the basic level, 1-wire and protocols like Texas Instruments SDQ operate in a similar manner. It turns out that [stacksmashing] already wrote a SDQ analyzer module for the Saleae logic analyzer. Aided by this tool, he digs deeper and learns more about the kinds of messages and their contents. For example, upon being plugged in, the host system queries the accessory’s serial number, manufacturer, model number, and product description. Finally, he introduces the CRC reverse engineering tool reveng to determine which CRC polynomial and algorithm the protocol uses to frame each packet.

Even if you have no interest in Lightning cables, this video is a great tutorial on the types of things you need to do in order to make sense of an unknown communications protocol. Gather what information you can, make some educated guesses, observe the signals, revise your guesses, and repeat. In part two, [stacksmashing] will show how to build a homemade iPhone JTAG cable.

We wrote in more detail about cracking the Lightning interface back in 2015. The Lightning interface may have been a good solution in its day, foreshadowing some of the features we now have in USB-C. But its proprietary and closed nature meant it wasn’t used outside of the Apple ecosystem. With the proliferation and capabilities of USB-C, not to mention various legislative edicts, Lightning’s days seem numbered. Is the industry finally settling on one interface? Let us know your thoughts in the comments below.

Continue reading “Reverse Engineering The Apple Lightning Connector” →

Dishwasher Repair Nightmare: Chasing Down 3 Faults

February 5, 2023 by Donald Papp 42 Comments

It all started with a vague error code (shown in the image above) on [nophead]’s Bosch SMS88TW01G/01 dishwasher, and it touched off a months-long repair nightmare that even involved a logic analyzer. [nophead] is normally able to handily diagnose and repair electronic appliances, but this time he had no idea what he was in for.

Not many dishwashers require breaking out a logic analyzer and 3D-printed custom adapters, but this one did.

Not only were three separate and unrelated faults at play (one of them misrepresented as a communications error that caused a lot of head-scratching) but to top it all off, the machine is just not very repair-friendly. The Bosch device utilized components which are not easily accessible. In the end [nophead] prevailed, but it truly was a nightmare repair of the highest order. So what went wrong?

One error appears to have been due to a manufacturing problem. While reverse-engineering the electronics in the appliance, [nophead] noticed a surface-mounted transistor that looked crooked. It was loose to the touch and fell into pieces when he attempted to desolder it. This part was responsible for switching an optical sensor, so that was one problem solved.

Another issue was a “communications error”. This actually came down to ground leakage due to a corroded and faulty heater, and to say that it was a pain to access is an understatement. Accessing this part requires the machine to be turned upside down, because the only way to get to it is by removing the base of the dishwasher, which itself requires a bizarre series of awkward and unintuitive steps to remove. Oh, and prior to turning the machine upside down, one has to purge the sump pump, which required a 3D-printed adapter… and the list goes on.

And the E02 error code, the thing that started it all? This was solved early in troubleshooting by changing a resistor value by a tiny amount. [nophead] is perfectly aware that this fix makes no sense, but perhaps it was in fact related to the ground leakage problem caused by the corroded heater. It may return to haunt the future, but in the meantime, the machine seems happy.

It goes to show that even though every fault has a cause and a reason, sometimes they are far from clear or accessible, and the road to repair is just a long slog. Heck, even phones these days can be bricked by accidentally swapping a 1.3 mm screw for a 1.2 mm screw.

Mis-captured signal transitions shown on the screen of the LA104, with problematic parts circled in red.

When Your Logic Analyzer Can’t Tell Good And Bad Signals Apart

July 9, 2022 by Arya Voronova 17 Comments

[Avian] has picked up a Miniware LA104 – a small battery-powered logic analyzer with builtin protocol decoders. Such analyzers are handy tools for when you quickly need to see what really is happening with a certain signal, and they’re cheap enough to be sacrificial when it comes to risky repairs. Sadly, he stumbled upon a peculiar problem – the analyzer would show the signal glitching every now and then, even at very low bitrates. Even more surprisingly, the glitches didn’t occur in the signal traces when exported and viewed on a laptop.

He dug into the problem, as [Avian] does. Going through the problem-ridden capture files helped him realize that the glitch would always happen when one of the signal edges would be delayed by a few microseconds relative to other signal edges — a regular occurrence when it comes to digital logic. This seems to stem from compression being used by the FPGA-powered “capture samples and send them” part of the analyzer. This bug only relates to the signal as it’s being displayed on the analyzer’s screen, and turned out that while most of this analyzer’s interface is drawn by the STM32 CPU, the trace drawing part specifically was done by the FPGA using a separate LCD interface.

It would appear Miniware didn’t do enough testing, and it’s impossible to distinguish a good signal from a faulty one when using a LA104 – arguably, the primary function of a logic analyzer. In the best of Miniware traditions, going as far as being hostile to open-source firmware at times, the FPGA bistream source code is proprietary. Thus, this bug is not something we can easily fix ourselves, unless Miniware steps up and releases a gateware update. Until then, if you bought a LA104, you can’t rely on the signal it shows on the screen.

When it comes to Miniware problems, we’ve recently covered a Miniware tweezer repair, requiring a redesign of the shell originally held together with copious amount of glue. At times, it feels like there’s something in common between glue-filled unrepairable gadgets and faulty proprietary firmware. If this bug ruins the LA104 for you, hey, at least you can reflash it to work as an electronics interfacing multitool.