All About USB-C: Manufacturer Sins

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!

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

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.

Picture of the dumper board, with a ROM chip and a Pi Pico inserted

A Disposable Dumper For ROM Chips With A Pi Pico

ROM dumping is vital for preserving old hardware, and we’ve seen many hacks dedicated to letting someone dump a ROM and send its contents to some hacker stuck with a piece of technology that lost its firmware. However, that requires ROM dumping tools of some kind, and it’s often that the lucky ROM-equipped hacker doesn’t own such tools. Now, you could mail the chip to someone else, but postal services in many countries are known to be UDP-like — lossy and without delivery guarantees. The risk of leaving both hackers without a ROM chip is quite real, so, instead of mailing ROM chips or expensive devices around, [Amen] proposes a cheap and disposable flash dumping tool that you could mail instead.

The ROMs in question are 24-pin 2332 and 2364 chips, which run at 5 V and can easily be read with any microcontroller. Thus, his concept is a very simple board, with a Pi Pico and flash chip socket on it, as well as some resistors. Those are used to provide rudimentary GPIO over-voltage protection, since the RP2040 runs its GPIOs at 3.3 V. All the magic is in the software – the tool can both write the chip contents in the RP2040’s internal memory, as well as dump it over USB to the computer. Everything is open-source – if you ever need to dump a rare chip on the other side of the world, modify the design to your liking, order a few copies and then mail them to the hacker involved – losing such a package is way less significant than losing a ROM chip with last-of-its-kind firmware on it.

Old ROM chips are dying out, causing whole generations of hardware, like synths, to fade away – with tools like this one, you can lend a hand in preserving the legacy of many an industry and hobby, and many hackers do. Looking to learn about the basics of parallel flash dumping? This post from 2012 will be a good start, and then check out a more recent venture to learn how things are done with more recent parts.

Building An All-in-One Desktop Out Of Framework Parts

The Framework laptop prides itself on having reusable parts, and hackers all around routinely challenge the claims by building projects reusing them. Yet again, [whatthefilament] puts the Framework hardware to the test, by taking all the laptop internals and building an AiO (All-in-One) desktop computer with it. Hot on the heels of his Framework tablet project we covered a few months ago, this desktop reuses as much as possible – the mainboard, the display and the expansion cards in particular, and even one of the hinges is reused for adjusting the monitor’s angle.

Of course, this build required a custom case – and [whatthefilament]’s design is fully 3D-printed, with STLs and assembly instructions available for anyone interested. Parts of the desktop are held by magnets for ease of assembly and maintenance, with a few parts requiring screws held in by heat-set inserts. Complete with a webcam, speakers and even a WiFi card, all it needs for completeness is an external keyboard&mouse combo, making for a sleek desktop that anyone in possession of a few Framework parts can build.

Laptop-to-desktop builds are nice – take the X-PC project, starting with a pile of school laptops and rebuilding them into colourful and sturdy desktops for classroom use. We’ve seen quite a few fancy Framework projects already, and that’s because they provided motherboards to hackers for specifically project purposes, kickstarting a fair few creations to grace our pages. Other hacker-friendly laptops didn’t lag behind, either – for instance, here’s the hacker favourite, Novena, getting the desktop treatment.

Screenshot of a terminal showing the HELP command in action - outputting descriptions of other commands

Let’s Make SCPI More Helpful

The SCPI (Standards Command for Programmable Instruments) protocol is exceptionally popular in lab and workspace tools, letting you configure and fetch data from oscilloscopes and lab scales alike in a standardized way. However, when interfacing with a SCPI device, you need to use a programming guide document if you want to know the commands for any of the inevitably extended features; essentially, SCPI isn’t as human-friendly as you might want. [MisterHW] argues that SCPI could use more discoverability by proposing a HELP? command.

This proposal is so intuitive, it makes you wonder why it isn’t in the base spec. It adds a built-in command that provides information on other commands. Internally, the description is just an extra string parameter that you add to your command definition code, and you can use it to describe the parameter types and ranges it takes. The output is both human-readable and machine-parseable, and as it’s stored within your code, it’s way quicker to update the description string than it is to re-release programming guides. Which are themselves prone to being outdated as-is, so decreasing reliance on them is a win-win.

The proposal makes a lot of sense, and [MisterHW] is willing to back it up with a pull request to the most popular SCPI library, libscpi. Whenever the pull request finally goes through, you will have the option to easily add the HELP? command support to whatever SCPI-connected device you might have brewing.

While the old devices will eventually fade, SCPI is not about to die out – hackers keep building devices with SCPI as the communication protocol, as the spec is quite powerful. For instance, here’s this fancy temperature logger, or this Source Measurement Unit – both of them use SCPI for hacker-to-device data transfer, and it’s likely to be libscpi under the hood. Ever wondered what SCPI is all about? Check out our overview!

The Chipwhisperer adapter plugged into a ChipWhisperer, with the STM chip mentiuoned soldered on

ChipWhisperer Adapter Helps Reverse-Engineer A Controversial Game Cartridge

The ChipWhisperer has been a breakthrough in hobbyist use of power analysis and glitching attacks on embedded hardware. If you own one, you surely have seen the IDC and SMA sockets on it – usable for connecting custom breakouts housing a chip you’re currently probing. Today, [MAVProxyUser] brings us a ChipWhisperer adapter for STM32F446ZEJx, which comes in a UFBGA144 package – and the adapter has quite a backstory to it.

In retro gaming world, a crowdfunding campaign for a game called PAPRIUM has seen a huge success getting funded in 2017. However, the campaign has grossly underdelivered throughout the last five years, and out of those rare cartridges delivered to backers, quite a few have faulty hardware. Getting replacements isn’t realistic at this point, so the repair attempts and game preservation efforts have been ongoing. Trouble is – there are protection mechanisms against dumping the cartridges, and one of the protection mechanisms is the built-in flash read protection of the aforementioned STM32 found on the cartridge. This board adapts the chip to a ChipWhisperer interface for protection bypass exploration, and has quite a few configuration jumpers anyone facing a similar chip is able to use – Eagle files are out there as well, in case your chip needs a slightly different approach.

With reverse-engineering underway, are we likely to see this cartridge’s defenses fall? Our assessment is ‘yes’ – it’s not like there’s a shortage of mechanisms for bypassing security ; from modchips to EMP attacks to blasting the die with a laser, hardware-reliant security is, still, quite bypassable. All in all, despite the drama around the project, this is one more reference design for the ChipWhisperer, and a fun journey to look forward to.