The rise of inexpensive yet relatively powerful electronics has enabled a huge array of computing options that would have been unheard of even two decades ago. A handheld gaming PC with hours of battery life, for example, would have been impossible or extremely expensive until recently. But this revolution has also enabled a swath of inexpensive but low-quality knockoff consoles, often running unlicensed games, that might not even reach the low bar of quality set by their sellers. [Jorisclayton] was able to modify one of these to live up to its original promises.
This Ultimate Brick Game, as it is called, originally didn’t even boast the number of games, unlicensed or otherwise, that it claimed to. [Jorisclayton] removed almost all of the internals from this small handheld to help it live up to this original claim. It boasts a Raspberry Pi Zero 2W now as well as a TFT screen and has a number of other improvements including Bluetooth support for external controllers and upgraded audio. A second console was used for donor parts, and some case mods were made as well to accommodate a few extra buttons missing on the original console.
Right now the project is in a prototype phase, as [Jorisclayton] is hoping to use the donor case to build a more refined version of this handheld console in the future. Until then, this first edition upgrade of the original console can run RetroPie, which means it can run most games up through the Nintendo 64 era. RetroPie enables a ton of emulation for old video games including arcade games of the past. This small arcade cabinet uses that software to bring back a bit of nostalgia for the arcade era.
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!
The old saying that the best way to learn is by doing holds as true for penetration testing as for anything else, which is why intentionally vulnerable systems like the Damn Vulnerable Web Application are so useful. Until now, however, there hasn’t been a practice system for penetration testing with drones.
The Damn Vulnerable Drone (DVD, a slightly confusing acronym) simulates a drone which flies in a virtual environment under the command of of an Ardupilot flight controller. A companion computer on the drone gives directions to the flight controller and communicates with a simulated ground station over its own WiFi network using the Mavlink protocol. The companion computer, in addition to running WiFi, also streams video to the ground station, sends telemetry information, and manages autonomous navigation, all of which means that the penetration tester has a broad yet realistic attack surface.
The Damn Vulnerable Drone uses Docker for virtualization. The drone’s virtual environment relies on the Gazebo robotics simulation software, which provides a full 3D environment complete with a physics engine, but does make the system requirements fairly hefty. The system can simulate a full flight routine, from motor startup through a full flight, all the way to post-flight data analysis. The video below shows one such flight, without any interference by an attacker. The DVD currently provides 39 different hacking exercises categorized by type, from reconnaissance to firmware attacks. Each exercise has a detailed guide and walk-through available (hidden by default, so as not to spoil the challenge).
Homebrew bills itself as the package manager MacOS never had (conveniently ignoring MacPorts) but they leave the PPC crowd criminally under-served, to say nothing of the 68k gang. Enter [that-ben] with MR Browser, a simple utility to fetch software from Macintosh Repository for computers too old to hit up the website.
If you’re not familiar with Macintosh Repository, it is what it says on the tin: a repository of vintage Macintosh software, like Macintosh Garden but apparently less accessible to vintage machines.
MRBrowser sys6 runs nicely on the Macintosh Plus, as you can see.
There are two versions available, depending on the age of your machine. For machines running System 6, the appropriately-named MR Browser sys6 will run on any 68000 Mac in only 157 KB of and MacTCP networking. (So the 128K obviously isn’t going to cut it, but a Plus from ’86 would be fine.)
The other version, called MR Browser 68K, ironically won’t run on the 68000. It needs a newer processor (68020 or newer, up-to and including PPC) and TCP/IP networking. Anything starting from the Macintosh II or newer should be game; it’s looking for System 7.x upto the final release of Mac OS 9, 9.2.2. You’ll want to give it at least 3 MB of RAM, but can squeak by on 1.6 MB if you aren’t using pictures in the chat.
Chat? Yes, perhaps uniquely for a software store, there’s a chat function. That’s not so weird when you consider that this program is meant to be a stand-alone interface for the Macintosh Repository website, which does, indeed, have a chat feature. It beats an uncaring algorithm for software recommendations, that’s for sure. Check it out in action in the demo video below.
In the same way that it makes sense for you to learn to touch type if you’re going to be using a computer a lot, it makes sense for you to put some thought and effort into your KiCad keyboard shortcuts keys, too.
In this video [Pat] introduces the keymap that he has come up with for the KiCad programs (schematic capture and PCB layout) and explains the rules of thumb that he used to generate his recommended shortcut keys, being:
one handed operation; you should try to make sure that you can operate the keyboard with one hand so your other hand can stay on your mouse
proximity follows frequency; if you use it a lot it should be close to hand
same purpose, same place; across programs similar functions should share the same key
birds of a feather flock together; similar and related functionality kept in proximate clusters
typing trounces topography; if you have to use both hands for typing you have to take your hand off the mouse anyway so then it doesn’t really matter where on the keyboard the shortcut key is
What has 8 ARM cores, 8 GB of RAM, fits in a pocket, and runs NixOS? It’s no pi-clone SBC, but [MWLabs]’s smartphone– a OnePlus 6, to be precise.
The video embedded below, and the git link above, are [MWLabs]’s walk-through for loading the mobile version of Nix onto the cell phone, turning it into a tiny-screened Linux computer. He’s using the same flake on the phone as on his desktop, which means he gets all the same applications set up in the same way– talk about convergence. That’s an advantage to Nix in this application, compared to the usual Alpine-based PostMarketOS.
Of course some of the phone-like features of this pocket-computer are lacking: the SIM is detected, and he can text, but 4G is nonfunctional. The rear camera is also not there yet, but given that Mobile-NixOS builds on the work done by well-established PostMarketOS, and PostMarketOS’ testing version can run the camera, it’s only a matter of time before support comes downstream. Depending what you need a tiny Linux device for, the camera functionality may or may not be of particular interest. If you’re like us, the idea of a mobile device running Nix might just intrigue you,
In today’s high-speed information overload environment, we often find ourselves with too much data to take in at once, causing us to occasionally miss out on opportunities otherwise drowned out in noise. None of this is more evident in the realm of high-speed trading, whether it’s for stocks, commodities, or even crypto. Most of us won’t be able to build dedicated high speed connections directly to stock exchanges for that extra bit of edge over the other traders, but what we can do is build a system that keys us in to our cryptocurrency price of choice so we know exactly when to pull the trigger on a purchase or sale.
[rishab]’s project for doing this is based on an ESP32 paired with a 10″ touchscreen display. It gathers live data from Binance, a large cryptocurrency exchange that maintains various pieces of information about many digital currencies. [rishab]’s tool offers a quick, in-depth look at a custom array of coins, with data such as percentage change over a certain time and high and low values for that coin as well. The chart updates in real time, and [rishab] also built a feature in which scales coins up if they have been seeing large movements in price over short timeframes.
Although it’s not a direct fiber link into an exchange, it certainly has its advantages over keeping this information in a browser window on a computer where it could get missed, and since it’s dedicated hardware running custom firmware it can show you exactly what you need to see if you’re day trading crypto. Certainly projects like this are in the DIY spirit that crypto enthusiasts tout as ideals of the currency, and as people move away from mining and more into speculative trading we’d expect to see more projects like this.