Screenshot of KiCad 7 feature that lets you overlay a PCB bitmap image and draw traces over it, being used for board reverse-engineering purposes

KiCad 7.0.0 Is Here, Brings Trove Of Improvements

February 13, 2023 by Arya Voronova 109 Comments

Yesterday, the KiCad team has released KiCad 7.0.0 – a surprise for those of us who have only gotten used to the wonders of KiCad 6, and it’s undoubtedly a welcome one! Some of these features, you might’ve seen mentioned in the KiCad 2022 end-of-year recap, and now, we get to play with them in a more stable configuration. There’s a trove of features and fixes for all levels of KiCad users, beginners, hobbyists and professionals alike – let’s start with some that everyone can appreciate! Continue reading “KiCad 7.0.0 Is Here, Brings Trove Of Improvements” →

High-contrast pictures described on the article, put onto a wall beside a crib

High-Contrast Images For Hacker Family Harmonics

February 13, 2023 by Arya Voronova 12 Comments

There’s a new addition to the Adafruit family, and it’s not a microcontroller board as you’d expect – however, we will still find plenty to learn from. On the Adafruit blog, [Phillip Torrone] shares a set of high-contrast images with us; the idea for such images is that they’re more appealing for a child during the first few months of its life, and not just that – they can support a kid’s development, too. The idea behind high-contrast images is twofold. During the first few months of life, a baby’s visual systems are only taking shape, and are nowhere near being advanced – so, sources of easily discernible and varied visual input can help it develop, as well as, perhaps, aid in holding attention.

The second part is – they look nice in their own way, and one would hope that a baby can appreciate them in the same way parents do. The images are quite varied, with some being somewhat electronics-themed (including an Adafruit logo, of course) and many being fairly neutral, which has to be an upside for us hackers when it comes to the spouse acceptance factor. For any of us interested, there are downloadable PDFs and

In a way, these are just like AprilTags – aiming to be helpful in development of visual algorithms. With such a family, we can’t wait to see what comes next – computer engineering books? Baby monitors with machine learning? Sleep-data-driven knit blankets? No matter what’s in store for us, we hope that for the Adafruit family, this journey will be smooth sailing.

Picture of a DualShock 4 controller PCB, with two joysticks on the sides

Challenging A Broken DualShock 4 Controller To A Duel

February 12, 2023 by Arya Voronova 2 Comments

A broken PlayStation controller would normally be a bummer, and if the issue is losing calibration that’s stored in a non-documented format, you might as well bin it. For [Al] of [Al’s blog], however, it’s a challenge, turning into a four-part story – so far. The first installment was published January 1st this year, and seeing the pure enthusiasm [Al] has reverse-engineering the DualShock 4 controller, you might guess that this is a New Year’s gift from someone who knows [Al] very well. The list of problems with the joystick is numerous, to begin with – it’s easier to list all the things that work properly, and it isn’t many of them. Perhaps, the firmware problem is is the most interesting one to start with. Continue reading “Challenging A Broken DualShock 4 Controller To A Duel” →

Screenshot of Wireshark, showing that source and destination port for ArtNet packets are the same

ArtNet Not Going Through? Your Switch Might Be Protecting You

February 12, 2023 by Arya Voronova 12 Comments

Cool technology often comes at a cost, and it’s not always that this cost is justified. For instance, [Rainfay] tells us about how the the ArtNet protocol’s odd design choices are causing incompatibility with certain Ethernet switches. ArtNet is a protocol for lighting control over DMX-512 – simply put, it allows you to blink a whole ton of LEDs, even literally. Unlike DMX-512 which can use different physical mediums, ArtNet uses Ethernet, taking form of the usual kind of network packets – and it does seem to do a great job about that, if it weren’t for this one thing.

For some reason, ArtNet connections are required to use the same destination and source port – unlike the usual network traffic, where the destination port is protocol-dependent and the source port is randomized. This behaviour violates RFCs, and not just in an abstract manner – such behaviour is indicative of certain kinds of attacks, that switches on the smart side are able and are supposed to prevent. As a result, ArtNet traffic actually triggers some protections on switches at the fancier end, specifically, so-called BLAT protection.

In short, if your ArtNet stream is mysteriously not going through and your switch is on the fancier side, [Rainfay] says you might need to disable some security mechanisms. Sadly, as she points out, this problem isn’t even a direct consequence of some inherent property of ArtNet, but merely a consequence of a bizarre design choice. Once you’re done disabling protections, however, do check out some ArtNet projects for inspiration – it’s a genuinely useful protocol supported in a ton of fancy software, and it might be that you want to use it in the firmware of your RGB strip controller board!

All About USB-C: Manufacturer Sins

February 7, 2023 by Arya Voronova 85 Comments

People experience a variety of problems with USB-C. I’ve asked people online about their negative experiences with USB-C, and got a wide variety of responses, both on Twitter and on Mastodon. In addition to that, communities like r/UsbCHardware keep a lore of things that make some people’s experience with USB-C subpar.

In engineering and hacking, there’s unspoken things we used to quietly consider as unviable. Having bidirectional power and high-speed data on a single port with thousands of peripherals, using nothing but a single data pin – if you’ve ever looked at a schematic for a proprietary docking connector attempting such a feat, you know that you’d find horrors beyond comprehension. For instance, MicroUSB’s ID pin quickly grew into a trove of incompatible resistor values for anything beyond “power or be powered”. Laptop makers had to routinely resort to resistor and one-wire schemes to make sure their chargers aren’t overloaded by a laptop assuming more juice than the charger can give, which introduced a ton of failure modes on its own.

When USB-C was being designed, the group looked through chargers, OTG adapters, display outputs, docking stations, docking stations with charging functions, and display outputs, and united them into a specification that can account for basically everything – over a single cable. What could go wrong?

Of course, device manufacturers found a number of ways to take everything that USB-C provides, and wipe the floor with it. Some of the USB-C sins are noticeable trends. Most of them, I’ve found, are manufacturers’ faults, whether by inattention or by malice; things like cable labelling are squarely in the USB-C standard domain, and there’s plenty of random wear and tear failures.

I don’t know if the USB-C standard could’ve been simpler. I can tell for sure that plenty of mistakes are due to device and cable manufacturers not paying attention. Let’s go through the notorious sins of USB-C, and see what we can learn. Continue reading “All About USB-C: Manufacturer Sins” →

Dumping script window, showing the bytes being dumped one by one from the STM chip

Need To Dump A Protected STM32F0x? Use Your Pico!

February 5, 2023 by Arya Voronova 21 Comments

Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.

Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.

You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.

[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.

To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.

Showing two MCP23017 expanders soldered onto a PCB

MCP23017 Went Through Shortage Hell, Lost Two Inputs

February 3, 2023 by Arya Voronova 68 Comments

The MCP23017, a 16-bit I2C GPIO expander, has always been a tasty chip. With 16 GPIOs addressable over I2C, proper push/pull outputs, software-enabled pull-ups, eight addresses, maskable interrupts for all pins, and reasonably low price, there’s a reason it’s so popular. No doubt due in part to that popularity, it’s been consistently out of stock during the past year and a half, as those of us unlucky enough to rely on it in our projects will testify.

Now, the chip is back in stock, with 23,000 of them to go around on Mouser alone, but there’s a catch. Apparently, the lengthy out-of-stock period has taken a heavy toll on the IC. Whether it’s the recession or perhaps the gas shortages, the gist is — the MCP23017 now a 14/16-bit expander, with two of the pins (GPA7 and GPB7) losing their input capabilities. The chips look the same, are called the same, and act mostly the same — if you don’t download the latest version of the datasheet (Revision D), you’d never know that there’s been a change. This kind of update is bound to cause a special kind of a debugging evening for a hobbyist, and makes the chip way less suitable for quite a few applications.

It’s baffling to think about such a change happening nearly 20 years after the chip was initially released, and we wonder what could have caused it. This applies to the I2C version specifically — the SPI counterpart, MCP23S17, stays unaffected. Perhaps, using a microcontroller or shift registers for your GPIO expansion isn’t as unattractive of an option after all. Microcontroller GPIO errata are at least expected to happen, and shift registers seem to have stayed the same since the dawn of time.

The reasons for MCP23017 silicon getting cut in such a way, we might never know. At least now, hopefully, this change will be less of a bitter surprise to those of us happy to just see the chip back in stock — and for hackers who have already restocked their MCP23017 hoards, may your shelved boards magically turn out to have a compatible pinout.