Sometimes it’s the little touches and details that make a project. That’s certainly the case with [Franklinstein]’s Super Nintendo (SNES) Cartridge Hard Drive. It might only be an enclosure for a solid-state hard drive with a USB interface, but the attention to detail is what really makes it worth checking out.
A SNES cartridge has a pretty standard clamshell-ish construction, but fitting the solid-state drive plus cable adapter turned out to be a bit of a challenge.
Since [Franklinstein] wanted the cartridge to look as original as possible, careful measuring and cutting was needed to securely fit the drive and provide an unobtrusive USB-C port tucked discreetly into the cartridge’s opening. We like the technique of using a 3D printed fixture to take up the slack on the cable by exactly the right amount, resulting in a 100% rattle-free end product. A custom Minecraft sticker label provides the finishing touch.
Being able to plug it into a computer and actually play Minecraft is a neat gimmick, but it really shows that some careful construction and assembly can be what makes something look like a clean build instead of a hack job. Take a look at additional build detail and pictures, and check out the video of the build, embedded below.
Hey, if sneaky cartridge mod tricks intrigue you, then you’ll absolutely want to check out how it was possible to play DOOM on a NES from a cartridge. Maybe that’s the next evolution for a cartridge with a Minecraft label on it?
[Evan] realized that Apple’s ARM-based Macs feature a high-quality x86 emulator, used via the Rosetta binary translation system. It only supports 64-bit x86-64 binaries, also known as x64, and thus he had initially discounted it for running older 32-bit x86 software. However, as it turns out, x64 features a special compatibility mode for running 32-bit code. [Evan] was able to leverage this to run 32-bit Windows executables rather neatly via the high-performance Rosetta emulator.
To run a 32-bit executable on a 64-bit processor in this way, one creates a 64-bit program that is tasked with loading the 32-bit executable. It’s a little fussy, involving some tricks to handle memory management between the 32-bit code and the 64-bit wrapper, and how to interface with the OS, but [Evan] explains deftly how it’s all done.
[Evan] notes that this hack may not work forever, especially if Apple changes or deprecates Rosetta’s remaining x86-64 emulation in the future. Regardless, Apple’s “Game Porting Toolkit” relies on similar techniques used by Wine. If you find yourself dancing across platforms, you might learn some nifty tricks from [Evan]’s example!
Generally when you crack open a cheap car-to-USB charger unit that came with some widget, you do not expect to find anything amazing inside. That’s why it was such a surprise to [Big Clive] when said car USB charger revealed a blast from the past in the form of an MC34063. This is a switching regulator that supports buck, boost and inverting topologies, but perhaps it most notable feature is that it was first produced by Motorola in the early 1980s.
This particular IC is marked as having been produced by ON Semiconductor which means that it’s technically still manufactured by Motorola – with ON Semiconductor being the Phoenix division that was spun off in 1999 – but it’s somewhat remarkable that this particular chip isn’t only produced by ON Semi today, but also by Texas Instruments. Much like the venerable NE555 timer IC and Intel’s 8051 MCU architecture, it would seem that certain chips and designs are simply made to become commodities in the future.
This appears to be the case for the MC34063 as well, which may lack some niceties of more modern ICs, such as built-in thermal protection, and it switches at only up to 100 kHz, but it can be bought for peanuts, has a wide input voltage range of 3 to 40 V, can switch up to 1.5 A and supports multiple common topologies. Often a 100 kHz switching regulator is all you need, in which case it’s handy to have a stack of such commodity chips lying around, plus the MC34063 comes in PDIP packaging as well, which is a boon for prototyping.
Segways stunned the world when they first hit the market in 2001. Hoverboards then terrified the world with nasty accidents and surprise fires. [James Bruton] loves hoverboards regardless, and set out on a mighty upgrade regime turning the ride-on toy into a giant omniwheeled bicycle.
The build relies on two giant omniwheels of [James’s] own creation, using lasercut and 3D-printed parts. The wheels are mounted perpendicularly on either end of a boxy plywood “bike frame” built in two sections, with a split in the middle. The two halves can rotate relative to each other, much like the two halves of a stock hoverboard.
Amazingly, the build relies on the stock hoverboard motors and electronics. The hoverboard wheel motors are responsible for driving the omniwheels at either end via a toothed belt drive. The gear ratio of the belt reduction is set up to cancel out the greater diameter of the omniwheels, such that the hoverboard’s tuning isn’t disrupted. Wisely, [James] also fitted a safety power cutout, too.
The result is a self-balancing “bike” the likes of which you’ve never seen before. At present, it can balance upright and rotate relatively well. However, control is difficult, requiring the use of the rider’s body weight and the twisting of the bike’s sections. [James] has instead contemplated using servos to tilt the hoverboard sensors instead for an easier control method than the current setup.
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.
Today, I’d like to highlight a tool that brings your hacking skills to a whole new level, and does that without breaking the bank – in fact, given just how much debugging time you can save, how many fun pursuits you can unlock, and the numerous features you can add, this might be one of the cheapest tools you will get. Whether it’s debugging weird problems, optimizing your code, probing around a gadget you’re reverse-engineering, or maybe trying to understand someone’s open-source library, you are likely missing out a lot if you don’t have a logic analyzer on hand!
It’s heartbreaking to me that some hackers still don’t know the value that a logic analyzer brings. Over and over again, tactical application of a logic analyzer has helped me see an entirely different perspective on something I was hacking on, and that’s just the thing I’d like to demonstrate today.
A logic analyzer has a number of digital inputs, and it continuously reads the state of these digital inputs, sending them to your computer or showing them on a screen – it’s like a logic-level-only oscilloscope. If you have an I2C bus with one MCU controlling a sensor, connect a logic analyzer to the clock and data pins, wire up the ground, launch the logic analyzer software on your computer, and see what’s actually happening.
The venerable MOS Technology 6502 turned up in all kinds of computers and other digital equipment over the years. Typically, it was clocked fairly slow and had limited resources, but that was just how things used to be. Today, the 6502 can run at an altogether quicker pace, and the Neo6502 was the board built to take it there.
The Neo6502 from [Olimex] is a credit-card sized retro computer built around the W65C02. If you’re unfamiliar with that chip, it’s essentially a 6502 that can go fast. How fast? It can be readily overclocked to a blazing 16 MHz, if you’re so inclined!
Unlike some 6502 retro builds, the Neo6502 doesn’t live so firmly in the past. It’s outfitted with an HDMI video interface to make it easy to hook up to modern monitors, so you needn’t fuss around with old displays. Similarly, it has a USB host port to accept input from a keyboard, and audio out via a 3.5 mm jack. There’s also a tiny PCB-mount speaker, as well as I2C, SPI, and UART interfaces. Finally, there’s 2 MB of flash onboard, and a 40-pin connector hosting all the 6502 signals that you know and love. Which is all of them. Much of this lavish equipment comes courtesy of an RP2040 microcontroller onboard that handles all the bits and bobs that aren’t fit for the CPU itself.
It’s still a new project, with things like a BASIC interpreter currently in development and boards not yet openly available. But, if you’ve always wanted to play with a hotshot 6502, this could be the board for you. Try out the emulator and see how you go.