Reviving An SD Card With Shorted Capacitors

Tiny capacitors in an SD card package. (Credit: Aeson Labs)
Tiny capacitors in an SD card package. (Credit: Aeson Labs)

A nice thing about SD cards is that even in their non-micro format they are conveniently small. This is however a bit of a problem when an SD card stops working, as they are not exactly designed to be easy to service, or to recover data from. There is however a very good chance that the Flash memory and controller are still fine, and it’s actually one of the passives on the tiny PCB that failed, as with the 32 GB SD card that [Yevgeniy Kapishon] recently diagnosed and recovered data from for a customer.

A big hint during initial diagnostics was a clear short between the supply rail and ground, but as became clear when taking the SD card apart, this one was built as a monolithic package, without exposed components on a PCB as in older SD cards. Correspondingly an X-ray machine and thermal camera were used to figure out what was inside the package, and where the short was located.

By combining the hot spot image with the X-ray it was determined that the problem was with some passives near the edge of the package. Some careful material removal later two miniscule capacitors were found to be the culprit and gently removed. With this the short on the power rail vanished, and the SD card started working again.

Having a shorted MLCC or similar passive component is a very common failure mode in general which can cripple even the most expensive device. Even if SD cards still aren’t really repairable, it’s at least reassuring to know that in many cases the data is fairly easy to recover once you have identified and removed the offending part.

DOOM Played On Series Of 555 Timers

It’s technically true that any piece of software can be reproduced in hardware, although modern software’s size and complexity generally makes this a non-starter. But if we go far enough back in time, older software becomes easier and easier to implement in hardware. The original DOOM from 1993 might one day be recreated in full this way, but that day is not today. Instead, [Nick] has recreated the original music from that game, playing the opening track in nothing but 555 timers.

The circuit starts with a 555 timer that acts as a system clock with a rate of just over 7 Hz. These pulses feed a binary counter which in turn feeds a decoder, giving the circuit 15 positions. Each output of the decoder feeds to a diode matrix which stores information about what pitch the circuit should play. The circuit only needs to play six pitches so the diodes effectively connect each moment in time to one of these six notes. From there the circuit feeds into a set of switches which select different resistor networks of another 555 which is actually responsible for producing sound. The resistor networks have different values to adjust the timing of the 555 to produce different pitches.

Of course this entire exercise is largely academic as almost any microcontroller would be able to be programmed to play this chiptune quite easily, but it’s not a bad idea to get down into the weeds of digital logic from time to time in order to refine one’s skills and knowledge about what’s really going on in the inner workings of circuits. Or, go even deeper than that and build the logic gates themselves from first principles.

Continue reading “DOOM Played On Series Of 555 Timers”

Casting Engine Parts From 3D Prints

After building a couple of internal combustion engines by milling billet aluminium stock and cringing at the absolute waste of material this created, [Camden Bowen] figured he’d give casting metal parts a shot. Of course, the key here is to create the molds for said casting, which is where you got a few options available.

Since DIY is really his thing, he also made his own kiln using cement and perlite, plus a propane burner. For the aluminium material to melt, he bought a stack of aluminium alloy wheels, as these are made of an alloy that’s actually suitable for casting. These were turned into ingots as a first step towards casting the engine parts, which among other things helps to purify the metal.

For the actual casting method he picked lost PLA, meaning the intended shape is 3D printed in PLA, then put into plaster before it’s melted out of the newly minted mold in an oven and subsequently burned out in the kiln. For the plaster [Camden] used regular Plaster of Paris, mixed with sand to give it suitable heat-resistant properties.

After some trial and error, as well as a lot of trouble burning out all the PLA, he got a usable mold and managed to eventually cast an engine cylinder with only a few imperfections. Considering just how convoluted it would have been to mill that part out of billet aluminium, it’s easy to see why commercial manufacturers are casting such parts as well.

Continue reading “Casting Engine Parts From 3D Prints”

Hackaday Podcast Episode 384: OCR MOD Records, Magical PCBs, And The Gravity Of Space Stations

What did Hackaday editors Elliot Williams and Al Williams read in Hackaday last week? Probably everything, but you can tune in and hear about their favorites on this week’s podcast. They heard from lots of listeners this week, and also saw DIY projects running from a 3D-printed Stirling engine, to clogs, to LEDs.

There are some over-the-top hacks like a refit for a decades-old watch to do tap-to-pay and a — for lack of a better word — a record player that optically reads MOD files. Want to emulate an iPod? Talk to Eliza? Print a hand-operated rail car? Hackaday is the place to read about it all.

The can’t miss articles included a talk from Hackaday Europe about making magical PCBs and a not-so-brief history of space stations starting in the 1800s.

Check out the links if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download in MP3 suitable for hand-decoding.

Continue reading “Hackaday Podcast Episode 384: OCR MOD Records, Magical PCBs, And The Gravity Of Space Stations”

Building A Headless Game Boy Emulator

[Artificial-Age] has built a rather unique way to play old Game Boy games. It’s an emulator, but it doesn’t work in quite the way you might think!

Since the Game Boy is a relatively simple 8-bit machine that runs at a leisurely 4 MHz or so, it is well within the capabilities of an ESP32 microcontroller to emulate. [Artificial-Age] got an ESP32-S3 and programmed it to do just that. However, there’s a twist—there is no screen hooked up to the microcontroller, nor any buttons. Instead, the board is accessed over a WiFi access point that it hosts itself.

One then opens a web browser, which streams the emulated video and audio from the console, while accepting button inputs from your keyboard or touchscreen, depending on the platform you’re viewing the web interface on. ROMs are stored on the ESP32’s flash storage, and can be uploaded via the web interface.

It’s an interesting setup, and one that perhaps doesn’t make obvious sense at first. After all, any modern smartphone can easily emulate a Game Boy, too. However, this setup makes it easy to share the emulator with other people, who can simply check out the WiFi AP and web interface without having to download or or install anything on their own device. We’ve featured some other fun emulation projects lately, too.

Continue reading “Building A Headless Game Boy Emulator”

This Week In Security: Android Malware, VOIP Hijack, Signal Contact Discovery, And TeamPCP Arrests

On GitHub, [AyaanB] details buying a cheap Android TV streaming device, looking for, and finding, baked-in malware.

Multiple warnings have been issued by the FBI and CISA regarding malware on media box Android devices. Many devices have been caught participating in botnets providing residential proxies, ad-click fraud, and DDOS services. [AyaanB] sets out to discover if a $30 set-top streaming box is pre-infected with malware, and extracting it – without ever letting the device talk to the Internet or access other devices on the local network.

Picking a device named in the advisories, [AyaanB] discovered that it was, indeed, preloaded with multiple app stores and applications that wouldn’t typically make sense on a set-top TV box. After identifying the serial port test pads and obtaining a low-voltage serial adapter, they were able to gain access to the bootloader and from there dump the contents of the MMC over TFTP.

With the entire filesystem accessible out-of-body, proving it was infected with malware at the factory becomes simple: the malware is signed as a system application, baked onto the system partition of the MMC, granted SELinux exceptions to mark it as a system binary with shell privileges, and has multiple launch scripts to make sure it is executed even if partially removed. With the malware identified, [AyaanB] continues to dig through to uncover the capabilities.

By installing hooks into the low-level Android process spawning system, the malware installs hooks into every application as it is launched: even if an application isn’t trojaned already, by the time it finishes executing, it’s definitely been subverted. The functions patched and the methods used match the Vo1d botnet, which is used for account takeovers, residential proxies, free “VPN” services, and other unfriendly behavior.

Further digging into the system showed hooks for ad-click fraud, where hidden browser windows are allowed to run unthrottled and display overlays are configured to obscure ads below where the user may click. Other included tools bid in real-time ad auctions, claiming to directly publish ads to the user which may or may not be visible. To cap it all off, a root level backdoor allows botnet operators to access the systems directly and install additional tools.

Be sure to check out [AyaanB]’s writeup for more details on exfiltration methods and other malware found on the devices. Continue reading “This Week In Security: Android Malware, VOIP Hijack, Signal Contact Discovery, And TeamPCP Arrests”

RAM And EMMC Prices Are So High, Pine64 Has Stopped Linux Device Production

We all know that the price of RAM and storage has shot up due to demand from the AI industry and other factors. In most cases that means we grumble about the price, but if we really need the part we can fork out for it. [CNX Software] are reporting that rather than continue to push up their prices, Pine64 are responding to the crisis by halting production of their Linux boards for the time being.

We’ve seen online comment over the now-exorbitant cost of other boards such as a fully-loaded Raspberry Pi, and this follows in that vein. If we had to guess we’d speculate that the high process have resulted in too little in the way of sales, which considering the knock-on impact on our community if other vendors follow suit, could be concerning.

If there’s one bright spot in the current situation, it’s that for many applications where a single-board computer might be used, a microcontroller might now be a better choice for the job than something running Linux. We’re in a very different situation from that we were in when cheap Linux boards appeared, the current generation of high-power microcontrollers have significantly closed the gap between the two. Given that microcontrollers have onboard memory and storage, their immunity from the price hikes makes them even more attractive. As to Pine64, we hope that sales of their other products make up for it.


Header image: BasilicumTree, CC0.