We often take for granted how easy it is to get information in today’s modern, Internet-connected world. Especially around electronics projects, datasheets are generally a few clicks away, as are instructions for building almost anything. Not so in the late 80s where ordering physical catalogs of chips and their datasheets was generally required.
There’s a train vulnerability making the rounds this week. The research comes from [midwestneil], who first discovered an issue way back in 2012, and tried to raise the alarm.
Turns out you can just hack any train in the USA and take control over the brakes. This is CVE-2025-1727 and it took me 12 years to get this published. This vulnerability is still not patched. Here's the story: https://t.co/MKRFSOa3XY
To understand the problem, we have to first talk about the caboose. The caboose was the last car in the train, served as an office for the conductor, and station for train workers to work out of while tending to the train and watching for problems. Two more important details about the caboose, is that it carried the lighted markers to indicate the end of the train, and was part of the train’s breaking system. In the US, in the 1980s, the caboose was phased out, and replaced with automated End Of Train (EOT) devices.
These devices were used to wirelessly monitor the train’s air brake system, control the Flashing Rear End Device (FRED), and even trigger the brakes in an emergency. Now here’s the security element. How did the cryptography on that wireless signal work in the 1980s? And has it been updated since then?
The only “cryptography” at play in the FRED system is a BCH checksum, which is not an encryption or authentication tool, but an error correction algorithm. And even though another researcher discovered this issue and reported it as far back as 2005, the systems are still using 1980s era wireless systems. Now that CISA and various news outlets have picked on the vulnerability, the Association of American Railroads are finally acknowledging it and beginning to work on upgrading.
Laravel provides the encrypt() and decrypt() functions to make that process easy. The decrypt() function even does the deserialization automatically. … You may be able to see where this is going. If an attacker has the APP_KEY, and can convince a Laravel site to decrypt arbitrary data, there is likely a way to trigger remote code execution through a deserialization attack, particularly if the backend isn’t fully up to date.
So how bad is the issue? By pulling from their records of GitHub, GitGuardian found 10,000 APP_KEYs. 1,300 of which also included URLs, and 400 of those could actually be validated as still in use. The lesson here is once again, when you accidentally push a secret to Github (or anywhere on the public Internet), you must rotate that secret. Just force pushing over your mistake is not enough.
Fake Homebrew
There’s a case to be made that browsers should be blocking advertisements simply for mitigating the security risk that comes along with ads on the web. Case in point is the fake Homebrew install malware. This write-up comes from the security team at Deriv, where a MacOS device triggered the security alarms. The investigation revealed that an employee was trying to install Homebrew, searched for the instructions, and clicked on a sponsored result in the search engine. This led to a legitimate looking GitHub project containing only a readme with a single command to automatically install Homebrew.
The command downloads and runs a script that does indeed install Homebrew. It also prompts for and saves the user’s password, and drops a malware loader. This story has a happy ending, with the company’s security software catching the malware right away. This is yet another example of why it’s foolhardy to run commands from the Internet without knowing exactly what they do. Not to mention, this is exactly the scenario that led to the creation of Workbrew.
SQL Injection
Yes, it’s 2025, and we’re still covering SQL injections. This vulnerability in Fortinet’s Fortiweb Fabric Connector was discovered independently by [0x_shaq] and the folks at WatchTowr. The flaw here is the get_fabric_user_by_token() function, which regrettably appends the given token directly to a SQL query. Hence the Proof of Concept:
GET /api/fabric/device/status HTTP/1.1
Host: 192.168.10.144
Authorization: Bearer 123'//or//'x'='x
And if the simple injection wasn’t enough, the watchTowr write-up manages a direct Remote Code Execution (RCE) from an unauthenticated user, via a SQL query containing an os.system() call. And since MySQL runs as root on these systems, that’s pretty much everything one could ask for.
AI guided AI attacks
The most intriguing story from this week is from [Golan Yosef], describing a vibe-researching session with the Claude LLM. The setup is a Gmail account and the Gmail MCP server to feed spammy emails into Claude desktop, and the Shell MCP server installed on that machine. The goal is to convince Claude to take some malicious action in response to an incoming, unsolicited email. The first attempt failed, and in fact the local Claude install warned [Golan] that the email may be a phishing attack. Where this mildly interesting research takes a really interesting turn, is when he asked Claude if such an attack could ever work.
Claude gave some scenarios where such an attack might succeed, and [Golan] pointed out that each new conversation with Claude is a blank slate. This led to a bizarre exchange where the running instance of Claude would play security researcher, and write emails intended to trick another instance of Claude into doing something it shouldn’t. [Golan] would send the emails to himself, collect the result, and then come back and tell Researcher Claude what happened. It’s quite the bizarre scenario. And it did eventually work. After multiple tries, Claude did write an email that was able to coerce the fresh instance of Claude to manipulate the file system and run calc.exe. This is almost the AI-guided fuzzing that is inevitably going to change security research. It would be interesting to automate the process, so [Golan] didn’t have to do the busywork of shuffling the messages between the two iterations of Claude. I’m confident we’ll cover many more stories in this vein in the future.
Cryptojacking is the technique where a malicious website embeds a crypto miner in the site. And while it was particularly popular in 2017-2019, browser safeguards against blatant cryptojacking put an end to the practice. What c/side researchers discovered is that cryptojacking is still happening, just very quietly.
ZDI has the story of Firefox and a JavaScript Math confusion attack. By manipulating the indexes of arrays and abusing the behavior when integer values wrap-around their max value, malicious code could read and write to memory outside of the allocated array. This was used at Pwn2Own Berlin earlier in the year, and Firefox patched the bug on the very next day. Enjoy!
If you ever look at projects in an old magazine and compare them to today’s electronic projects, there’s at least one thing that will stand out. Most projects in “the old days” looked like something you built in your garage. Today, if you want to make something that rivals a commercial product, it isn’t nearly as big of a problem.
Dynamic diode tester from Popular Electronics (July 1970)
For example, consider the picture of this project from Popular Electronics in 1970. It actually looks pretty nice for a hobby project, but you’d never expect to see it on a store shelf.
Even worse, the amount of effort required to make it look even this good was probably more than you’d expect. The box was a standard case, and drilling holes in a panel would be about the same as it is today, but you were probably less likely to have a drill press in 1970.
But check out the lettering! This is a time before inkjet and laser printers. I’d guess these are probably “rub on” letters, although there are other options. Most projects that didn’t show up in magazines probably had Dymo embossed lettering tape or handwritten labels.
Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of the library was based on leaked information from Nintendo had been circulating for decades, but the more recent accusations that libogc included code from other open source projects without proper attribution brought the debate to a head — ultimately leading Wii Homebrew Channel developer Hector Martin to archive the popular project and use its README as a central point to collect evidence against libogc and its developers.
At the time, most of the claims had to do with code being taken from the Real-Time Executive for Multiprocessor Systems (RTEMS) project. Martin and others in the community had performed their own investigations, and found some striking similarities between the two codebases. A developer familiar with both projects went so far as to say that as much as half the code in libogc was actually lifted from RTEMS and obfuscated so as to appear as original work.
While some of these claims included compelling evidence, they were still nothing more than accusations. For their part, the libogc team denied any wrongdoing. Contributors to the project explained that any resemblance between libogc code and that of either leaked Nintendo libraries or other open source projects was merely superficial, and the unavoidable result of developing for a constrained system such as a game console.
But that all changed on May 6th, when the RTEMS team released an official statement on the subject. It turns out that they had been following the situation for some time, and had conducted their own audit of the libogc code. Their determination was that not only had RTEMS code been used without attribution, but that it appeared at least some code had also been copied verbatim from the Linux kernel — making the license dispute (and its solution) far more complex.
[James Sharman] designed and built his own 8-bit computer from scratch using TTL logic chips, including a VGA adapter, and you can watch it run a glorious rotating cube demo in the video below.
The rotating cube is the product of roughly 3,500 lines of custom assembly code and looks fantastic, running at 30 frames per second with shading effects from multiple light sources. Great results considering the computing power of his system is roughly on par with vintage 8-bit home computers, and the graphics capabilities are limited. [James]’s computer uses a tile map instead of a frame buffer, so getting 3D content rendered was a challenge.
The video is about 20 seconds of demo followed by a detailed technical discussion on how exactly one implements everything required for a 3D cube, from basic math to optimization. If a deep dive into that sort of thing is up your alley, give it a watch!
If you’ve ever bought a modchip that adds features to your game console, you might have noticed sanded-off IC markings, epoxy blobs, or just obscure chips with unknown source code. It’s ironic – these modchips are a shining example of hacking, and yet they don’t represent hacking culture one bit. Usually, they are more of a black box than the console they’re tapping into. This problem has plagued the original XBOX hacking community, having them rely on inconsistent suppliers of obscure boards that would regularly fall off the radar as each crucial part went to end of life. Now, a group of hackers have come up with a solution, and [Macho Nacho Productions] on YouTube tells us its story – it’s an open-source modchip with an open firmware, ModXO.
Like many modern modchips and adapters, ModXO is based on an RP2040, and it’s got a lot of potential – it already works for feeding a BIOS to your console, it’s quite easy to install, and it’s only going to get better. [Macho Nacho Productions] shows us the modchip install process in the video, tells us about the hackers involved, and gives us a sneak peek at the upcoming features, including, possibly, support for the Prometheos project that equips your Xbox with an entire service menu. Plus, with open-source firmware and hardware, you can add tons more flashy and useful stuff, like small LCD/OLED screens for status display and LED strips of all sorts!
If you’re looking to add a modchip to your OG XBOX, it looks like the proprietary options aren’t much worth considering anymore. XBOX hacking has a strong community behind it for historical reasons and has spawned entire projects like XBMC that outgrew the community. There’s even an amazing book about how its security got hacked. If you would like to read it, it’s free and worth your time. As for open-source modchips, they rule, and it’s not the first one we see [Macho Nacho Productions] tell us about – here’s an open GameCube modchip that shook the scene, also with a RP2040!
The EDUC-8, a DIY minicomputer design that came out in “Electronics Australia” magazine, was almost the world’s first in August 1974. And it would have been tied for the world’s first if inventor [Jamieson “Jim” Rowe] hadn’t held back from publishing to rework the design to expand the memory to a full 256 bytes. The price of perfectionism?
Flash forward 50 years, and [Gwyllym Suter] has taken on the job of recreating the EDUC-8 using modern PCBs, but otherwise staying true to the all-TTL design. He has all of his schematics up on the project’s GitHub, but has also sent us a number of beauty shots that we’re including below. Other than the progress of PCB tech and the very nice 3D-printed housing, they look identical. We have to admit that we love those wavy hand-drawn traces on the original, but we wouldn’t be sad about not having to solder in all those jumpers.
