A picture showing acupuncture needles wedged into the inside of the payment terminal

Aaron Christophel Brings DOOM To Payment Terminal

Payment terminals might feel intimidating — they’re generally manufactured with security in mind, with all manner of anti-tamper protections in place to prevent you from poking around in the hardware too much. But [Aaron Christophel] thinks that level of security isn’t aren’t always in practice however, and on his journey towards repurposing devices of all kinds, has stumbled upon just the terminal that will give up its secrets easily. The device in question is Sumup Solo terminal, a small handheld with a battery, LTE connection and a payment card slot – helping you accept card payments even if you’re on the go.

Now, this terminal has security features like the anti-tamper shield over the crucial parts of the device, leading to payment processing-related keys being erased when lifted. However, acupuncture needles, a tool firmly in [Aaron]’s arsenal, helped him reach two UART testpoints that were meant to be located under that shield, and they turned out to be all that a hacker needed to access the Linux system powering this terminal. Not just that, but the UART drops you right into the root shell, which [Aaron] dutifully explored — and after some cross–compilation and Linux tinkering, he got the terminal to, naturally, run Doom.

The video shows you even more, including the responsible disclosure process that he went through with Sumup, resulting in some patches and, we hope, even hardware improvements down the line. Now, the payment processing keys aren’t accessible from the Linux environment — however, [Aaron] notes that this doesn’t exclude attacks like changing the amount of money displayed while the customer is using such a terminal to pay.

If you’d like to take a closer look at some of the hardware tricks used in these secure devices, we did a teardown on one back in 2019 that should prove interesting.

Continue reading “Aaron Christophel Brings DOOM To Payment Terminal”

Reverse Engineering The Apple Lightning Connector

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”

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

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”

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

Challenging A Broken DualShock 4 Controller To A Duel

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”

PCB mounted on 3D-printed holder, debug pins attached to Pi Pico on a breadboard. The battery is in the background, disconnected

Reverse Engineering E-Ink Price Tags

E-ink displays are great, but working with them can still be a bit tricky if you aren’t an OEM. [Jasper Devreker] got his hands on three e-ink shelf displays to reverse engineer.

After cracking the tag open, [Devreker] found a CC2510 microcontroller running the show. While the spec sheet shows a debug mode, this particular device has been debug locked making reading the device’s code problematic. Undaunted, he removed the decoupling capacitor from the DCOUPL pin and placed a MOSFET between it and the ground pin to perform a voltage glitch attack.

A Pi Pico was used to operate the MOSFET over PIO with the chip overclocked to 250 MHz to increase the precision and duration of the glitch. After some testing, a successful glitch pathway was found, but with only a 5% success rate. With two successive glitches in a row needed to read out a byte from the device, the process is not a fast one. Data pulled so far has shown to be valid code when fed into Ghidra, and this project page is being updated as progress continues.

If you want to delve further into hacking e-ink price tags, checkout this deep dive on the topic or this Universal E-paper Sniffer.

Reverse Engineering British Rail Tickets

There was a time when to take a British rail journey was to receive a ticket barely changed since Victorian times — a small cardboard rectangle printed with the destination through which the inspector on the train would punch a hole. In recent decades these were replaced by credit-card-sized thin card, and now increasingly with scanable 2D codes from an app. These caught the attention of [eta], and she set about reverse engineering their operation.

The codes themselves are Aztec barcodes, similar to a QR code but with a single central fiducial mark. At first glance they resemble the codes used by non-UK ticketing systems, but she soon found out that they don’t follow the same standard. There followed a lengthy but fascinating trail of investigation, involving app decompilation of a dodgy copy of the ticket inspector app to find public keys, and then some work with a more reputably sourced app from another ticketing company.

Along the way it revealed a surprising amount of traveler data that maybe shouldn’t be in the public domain, and raises the question as to why the ticketing standard remains proprietary. It’s well worth a read.

If you’d like more UK rail ticket hacking, it formed the subject of a talk at EMF 2022.

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.