Inkjet Printing On The Cheap With A Continuous Ink System

December 6, 2019 by Lewin Day 39 Comments

Inkjet printers are cheap to buy, but expensive to run. Replacement cartridges can easily cost double the price of the hardware itself, leading many to decry the technology entirely. However, the hackers of the world have the problem licked – enter the continuous ink system.

[cprossu] wanted an affordable color printing solution for the hackerspace. A cheap printer was sourced from a thrift store. The model chosen was selected for its lack of cartridge DRM and the availability of kits on eBay for conversion to a continuous ink system. This involves running large refillable tanks of ink instead of small individual cartridges which must be thrown away when empty.

[cprossu] discusses both the challenges you’ll likely face in a general build, as well as the specific work required to handle the conversion on an Epson Artisan 725. There’s also excessive label-maker abuse, which always brings a smile to our face. It’s a conversion well worth considering if you find yourself regularly purchasing expensive cartridges. We’ve even seen similar builds as far back as 2009, right from the ground up!

Swapping The ROMs In Mini Arcade Cabinets

December 6, 2019 by Tom Nardi 10 Comments

You’ve probably seen a few of these miniature arcade games online or in big box retailers: for $20 USD or so you get scaled-down version of a classic arcade cabinet, perfect for a desk toy or to throw up on a shelf as part of your gaming collection. Like any good Hackaday reader, you were probably curious about what makes them tick. Thanks to [wrongbaud], we don’t have to wonder anymore.

Over the course of several blog posts, [wrongbaud] walks readers through the hardware and software used in a few of these miniature games. For example, the Rampage cabinet is using a so-called “NES on a Chip” along with a SPI flash chip to hold the ROM, while Mortal Kombat is using a Genesis emulation solution and parallel flash. It wouldn’t be interesting if they didn’t throw you a few curves now and again, right?

But these are more than simple teardowns. Once [wrongbaud] gives an overview of the hardware, the next step is reading the respective flash storage and trying to make sense of the dumped data. These sort of games generally reuse the hardware among a number of titles, so by isolating where the game ROM is and replacing it, they can be made to play other games without hardware modification. Here, this capability is demonstrated by replacing the ROM data for Rampage with Yoshi’s Cookie. Naturally it’s one of those things that’s easier said than done, but it’s an interesting proof of concept.

The Mortal Kombat cabinet is a newer addition to the collection, so [wrongbaud] hasn’t progressed quite as far with that one. The parallel flash chip has been dumped with the help of an ESP32 and a MCP23017 I/O expander, and some Genesis ROM headers are identifiable in the data, but there’s still some sifting to be done before the firmware structure can be fully understood.

Even if you’re not in the market for a diminutive arcade experience, the information that [wrongbaud] has collected here is really phenomenal. From understanding protocols such as I2C and SPI to navigating firmware dumps with a hex editor, these posts are an invaluable resource for anyone looking to get started with reverse engineering.

David Williams Is “FPGA-Curious”

December 6, 2019 by Elliot Williams 17 Comments

If you hadn’t noticed, we had a bit of an FPGA theme running at this year’s Superconference. Why? Because the open-source FPGA toolchain is ripening, and because many of the problems that hackers (and academics) are tackling these days have become complex enough to warrant using them. A case in point: David Williams is a university professor who just wanted to build a quadruped robotics project. Each leg has a complex set of motors, motor drivers, sensors, and other feedback mechanisms. Centralizing all of this data put real strains on the robot’s network, and with so many devices the microcontrollers were running out of GPIOs. This lead him to become, in his words, “FPGA-curious”.

If you’re looking for a gentle introduction to the state of the art in open-source FPGAs, this is your talk. David covers everything, from a bird’s eye view of hardware description languages, through the entire Yosys-based open-source toolchain, and even through to embedding soft-CPUs into the FPGA fabric. And that’s just the first 18 minutes. (Slides for your enjoyment, and you can watch the talk embedded below the break.)
Continue reading “David Williams Is “FPGA-Curious”” →

Chandrayaan-2 Found By Citizen Scientist; Reminds Us Of Pluto Discovery

December 6, 2019 by Al Williams 40 Comments

What does Pluto — not the dog, but the non-Planet — have in common with the Vikram lunar lander launched by India? Both were found by making very tiny comparisons to photographs. You’d think landing something on the moon would be old hat by now, but it turns out only three countries have managed to do it. The Chandrayaan-2 mission would have made India the fourth country. But two miles above the surface, the craft left its planned trajectory and went radio silent.

India claimed it knew where the lander crashed but never revealed any pictures or actual coordinates. NASA’s Lunar Reconnaissance Orbiter took pictures several times of the landing area but didn’t see the expected scar like the one left by the doomed Israeli lander when it crashed in April. A lot of people started looking at the NASA pictures and one Indian computer programmer and mechanical engineer, Shanmuga Subramanian, seems to have been successful.

Continue reading “Chandrayaan-2 Found By Citizen Scientist; Reminds Us Of Pluto Discovery” →

Hackaday Podcast 045: Raspberry Pi Bug, Rapidly Aging Vodka, Raining On The Cloud, And This Wasn’t A Supercon Episode

December 6, 2019 by Mike Szczys 5 Comments

Hackaday editors Mike Szczys and Elliot Williams talk over the last three weeks full of hacks. Our first “back to normal” podcast after Supercon turns out to still have a lot of Supercon references in it. We discuss Raspberry Pi 4’s HDMI interfering with its WiFi, learn the differences between CoreXY/Delta/Cartesian printers, sip on Whiskey aged in an ultrasonic jewelry cleaner, and set up cloud printing that’s already scheduled for the chopping block. Along the way, you’ll hear hints of what happened at Supercon, from the definitive guide to designing LEDs for iron-clad performance to the projects people hauled along with them.

Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 045: Raspberry Pi Bug, Rapidly Aging Vodka, Raining On The Cloud, And This Wasn’t A Supercon Episode” →

Tuning Up The ThinkGeek Star Trek Intercom Panel

December 6, 2019 by Tom Nardi 8 Comments

On Star Trek, all Kirk and friends had to do was snap the button on the always conveniently located intercom panel, start talking, and the intended recipient would immediately respond no matter where they were in the ship. How did it work? Who knows. In spite of, or perhaps even because of, the lightly-explained nature of the technology, the cherry-red wall intercoms still hold a certain charm for fans of the groundbreaking show.

A viewer sent [Fran Blanche] a scaled down replica of the intercom from ThinkGeek, and while it certainly looks fairly close to the original prop, it has a couple of annoying design elements. When triggered by the side-mounted motion sensors, the panel will play either the iconic swoosh of the automatic doors or the “Red Alert” sound effect. It’s a cute idea for a kid’s bedroom maybe, but not exactly ideal for somebody who regularly records YouTube videos.

So the first order of business was to cut the motion sensors out of the circuit and replace them with a push button. [Fran] draws up a quick diagram to explain how these sensors work, and shows that they can easily be bypassed with a momentary switch since they normally bring the line high when triggered. She then converted the indicator light on the right side of the panel into a button to enable the alert sound effect, which is more accurate to how it worked in the show anyway.

The other issue, and perhaps the most egregious to Star Trek fans, is that the “Red Alert” indicator on the top of the panel didn’t actually flash like it did in the show. To design and build this panel and not put a few LEDs behind that piece of frosted plastic seems a bit like producing a Matchbox car and forgetting to make the wheels spin. With a couple of red LEDs and a bit of new wiring, the oversight was quickly rectified.

While it might not be perfect, at least ThinkGeek actually produced a functional product this time. It could have ended up like one of their April Fool’s “products” that never get put into production, forcing a desperate Trekkie to begrudgingly build his own version.

Continue reading “Tuning Up The ThinkGeek Star Trek Intercom Panel” →

This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg

December 6, 2019 by Jonathan Bennett 9 Comments

CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.

On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg” →