Polish Train Manufacturer Threatens Hackers Who Unbricked Their Trains

December 14, 2023 by Jenny List 63 Comments

A week ago we covered the story of a Polish train manufacturer who was caught using software to brick their products after they had been repaired by in independent railway workshop. Now 404 Media has a follow-up story with more information, including the news that the hackers responsible for the discovery are now being threatened by the manufacturer.

The more we learn about this story the more interesting it becomes, as the Newag trains in question began failing after service as far back as 2021. In desperation after services were affected by the number of non-functional units, an employee searched online for Polish hackers and found a group called Dragon Sector. The group was able to find the issue, and are now being threatened with legal action by the manufacturer, who are citing possible safety issues.

It’s clear from where we are standing that Newag have been caught red-handed in some extremely dubious practices, and seem to have little sense of how their actions might not be the best in terms of protecting their reputation. We are guessing that the European regulators will become very interested in this case, and that meanwhile the order books of a company which puts DRM in its trains will start to look very empty indeed. You can catch our original coverage as the story broke, here.

Thanks [JohnU] for the tip.

Oddball LCDs Reverse Engineered Thanks To Good Detective Work

December 12, 2023 by Dan Maloney 5 Comments

Is there anything more discouraging to the reverse engineer than to see a black blob of epoxy applied directly to a PCB? We think not, because that formless shape provides no clue as to what chip lies beneath, and that means a lot of detective work if you’re going to figure out how to use this thing.

[Sudhir Chandra]’s detective story starts with a bunch of oddball LCDs, slim 1×32 character units rather than the more familiar 2×16 displays. Each bore the dreaded black COB blob on the back, as well as a handful of SMD components and not much else. Googling revealed no useful documentation, and the manufacturer wasn’t interested in fielding calls from a hobbyist. Reasoning that most manufacturers wouldn’t spin up a custom chip for every display, [Sudhir] assumed there was an ST7066, a common LCD driver chip, underneath the blob, especially given the arrangement of external components. But a jumper set was bodged together under this assumption didn’t get the display going.

Next up were more destructive methods, to decap the COB and see what kind of numbers might be on the chip. Sandpaper worked at first, but [Sudhir] eventually turned to the “Chips a la [Antoine]” method of decapping, which uses heat and brute force to get at the goods. This got down to the chip, but [Sudhir]’s microscope wasn’t up to the task of reading the die markings.

What eventually cracked the case was tracing out the voltages across the various external resistors and matching them up to other chips in the same family as the ST7066, plus the realization that the long, narrow epoxy blob probably covered a similarly shaped chip, which led to the culprit: an ST7070. This allowed [Sudhir] to build an adapter PCB for the displays, with plans for a custom Arduino library to talk to the displays.

This was a great piece of reverse engineering and a good detective story to boot. Hats off to [Sudhir] for sticking with it.

The Deere Disease Spreads To Trains

December 6, 2023 by Jenny List 37 Comments

If the right-to-repair movement has a famous story, it’s the familiar green and yellow John Deere tractor. Farmers and mechanics have done their own repairs as long as there have been tractors, but more recent Deeres have been locked down such that only Deere-authorised agents can fix them. It’s a trend that has hurt the value of a second-had Deere, but despite that it appears to be spreading within the machinery world. Now there’s a parallel on Polish railways, as Polish-made Newag electric passenger trains have been found to give errors when serviced by non-Newag workshops.

At the heart of the problem are the PLCs which control all aspects of a modern rail traction system, which thanks to a trio of Poland and Germany based researchers have been found to play a range of nasty tricks. They’ll return bogus error codes after a set date which would presumably be reset by the official service, if the train has been laid up for a while, or even if they are detected via GPS to have visited a third-party workshop. Their work will be the subject of a talk at 37C3 which should be worth watching out for.

It will be especially interesting to juxtapose the reaction to this revelation with cases such as the Deere tractors, because of course Poland is part of the European Union. We’re not specialist EU competition lawyers, but we know enough to know that the EU takes a dim view of these types of practices and has been strong on the right to repair. Who knows, Polish trains may contribute further to the rights of all Europeans.

Big Red Button Puts Toddler In Command Of Chromecast

November 3, 2023 by Dan Maloney 12 Comments

Controversial position: the world needs more buttons. We’ve gotten so far away from physical interfaces like buttons, knobs, and switches in favor of sleek but sterile touch-screen “controls” that when we see something like this big red button so toddlers can start a TV show, we just have to latch onto the story and see what it’s all about.

As it turns out, the big red button itself is probably the least interesting part of [Mads Chr. Olesen] build. The real meat of the project is the reverse engineering effort needed to get Chromecast to start the show. As [Mads] explains, once upon a time a simple GET request to a URL was all it took to do so, but no more; Google has repeatedly nerfed the Chromecast API over the years, enough that [Mads] had some digging to do.

Luckily, pyChromecast is a thing, but using it for DRTV, a streaming service of the Danish Broadcasting Corporation, required figuring out the AppID of the DRTV app. It looks like [Mads] used Wireshark to sniff traffic to and from the Chromecast, and netlog-viewer to analyze the capture. That and a little Developer Tools action in Chrome led to all the information needed to modify pyChromecast to support DRTV. The rest of the project consisted of building a box for the huge red arcade button and wiring it up to a Wemos D1. A Raspberry Pi actually talks to the Chromecast, and now the toddler is able to call up his favorite show and pause and restart it at will, no parent required.

We appreciate the reverse engineering heroics [Mads] displays here, which provide good general lessons for other purposes. It’s been a while since we’ve seen a Chromecast physical interface build, too, so we appreciate the refresher.

DIY Repair Brings An X-Ray Microscope Back Into Focus

September 22, 2023 by Dan Maloney 6 Comments

Aside from idle curiosity, very few of us need to see inside chips and components to diagnose a circuit. But reverse engineering is another story; being able to see what lies beneath the inscrutable epoxy blobs that protect the silicon within is a vital capability, one that might justify the expense involved in procuring an X-ray imager. But what’s to be done when such an exotic and expensive — not to mention potentially deadly — machine breaks down? Obviously, you fix it yourself!

To be fair, [Shahriar]’s Faxitron MX-20 digital X-ray microscope was only a little wonky. It still generally worked, but just took a while to snap into the kind of sharp focus that he needs to really delve into the guts of a chip. This one problem was more than enough to justify tearing into the machine, but not without first reviewing the essentials of X-ray production — a subject that we’ve given a detailed look, too — to better understand the potential hazards of a DIY repair.

With that out of the way and with the machine completely powered down, [Shahriar] got down to the repair. The engineering of the instrument is pretty impressive, as it should be for something dealing with high voltage, heavy thermal loads, and ionizing radiation. The power supply board was an obvious place to start, since electrostatically focusing an X-ray beam depends on controlling the high voltage on the cathode cup. After confirming the high-voltage module was still working, [Shahriar] homed in on a potential culprit — a DIP reed relay.

Replacing that did the trick, enough so that he was able to image the bad component with the X-ray imager. The images are amazing; you can clearly see the dual magnetic reed switches, and the focus is so sharp you can make out the wire of the coil. There are a couple of other X-ray treats, so make sure you check them out in the video below.

Continue reading “DIY Repair Brings An X-Ray Microscope Back Into Focus” →

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” →

Diving Into Starlink’s User Terminal Firmware

August 31, 2023 by Maya Posch 7 Comments

The average Starlink user probably doesn’t spend a lot of time thinking about their hardware after getting the dish aligned and wiring run. To security researchers, however, it’s another fascinating device to tinker with as they reverse-engineer the firmware and try to both find out what makes it tick, as well as how to break it. This is essentially the subject of [Carlo Ramponi]’s article over at Quarkslab as he digs into the firmware architecture and potential weaknesses in its internal communication.

The user terminal hardware itself is a quite standard AArch64 ARM-based SoC, along with the proprietary communication interface, all of which is controlled by the Linux-based firmware. Dumping the firmware itself was made easy thanks to existing work by researchers at the KU Leuven, involving dumping the contents of the onboard eMMC storage. After this the firmware architecture could be analyzed, which turned out to consist out of mostly C++-based binaries, but with a single big binary for the user front-end written in Go.

Communication between these processes is handled through a custom inter-process protocol called ‘Slate Sharing’, all of which is coordinated via the core User Terminal Control process. It are these Slate IPC messages which form the most likely attack surface for a fuzzing attack, with the SoftwareUpdateRequest command being an interesting target as it would seem to not require authentication since it doesn’t address a specific user. This work is part of [Carlo]’s master’s thesis, and should form the basis of further research on the Starlink User Terminal firmware.