Recreating The Quadrophonic Sound Of The 70s

For plenty of media center PCs, home theaters, and people with a simple TV and a decent audio system, the standard speaker setup now is 5.1 surround sound. Left and right speakers in the front and back, with a center speaker and a subwoofer. But the 5.1 setup wasn’t always the standard (and still isn’t the only standard); after stereo was adopted mid-century, audio engineers wanted more than just two channels and briefly attempted a four-channel system called quadrophonic sound. There’s still some media from the 70s that can be found that is built for this system, such as [Alan]’s collection of 8-track tapes. These tapes are getting along in years, so he built a quadrophonic 8-track replica to keep the experience alive.

The first thing needed for a replica system like this is digital quadrophonic audio files themselves. Since the format died in the late 70s, there’s not a lot available in modern times so [Alan] has a dedicated 8-track player connected to a four-channel audio-to-USB device to digitize his own collection of quadrophonic 8-track tapes. This process is destructive for the decades-old tapes so it is very much necessary.

With the audio files captured, he now needs something to play them back with. A Raspberry Pi is put to the task, but it needs a special sound card in order to play back the four channels simultaneously. To preserve the feel of an antique 8-track player he’s cannibalized parts from three broken players to keep the cassette loading mechanism and track indicator display along with four VU meters for each of the channels. A QR code reader inside the device reads a QR code on the replica 8-track cassettes when they are inserted which prompts the Pi to play the correct audio file, and a series of buttons along with a screen on the front can be used to fast forward, rewind and pause. A solenoid inside the device preserves the “clunk” sound typical of real 8-track players.

As a replica, this player goes to great lengths to preserve the essence of not only the 8-track era, but the brief quadrophonic frenzy of the early and mid 70s. There’s not a lot of activity around quadrophonic sound anymore, but 8-tracks are popular targets for builds and restorations, and a few that go beyond audio including this project that uses one for computer memory instead.

Continue reading “Recreating The Quadrophonic Sound Of The 70s”

Evidence For Graphite As A Room Temperature Superconductor

Magnetization M(H) hysteresis loops measured for the HOPG sample, before and after 800 K annealing to remove ferromagnetic influences. (Credit: Kopelevich et al., 2023)
Magnetization M(H) hysteresis loops measured for the HOPG sample, before and after 800 K annealing to remove ferromagnetic influences. (Credit: Kopelevich et al., 2023)

Little has to be said about why superconducting materials are so tantalizing, or what the benefits of an ambient pressure, room temperature material with superconducting properties would be. The main problem here is not so much the ‘room temperature’ part, as metallic hydrogen is already capable of this feat, if at pressures far too high for reasonable use. Now a recent research article in Advanced Quantum Technologies by Yakov Kopelevich and colleagues provides evidence that superconducting properties can be found in cleaved highly oriented pyrolytic graphite (HOPG). The fact that this feat was reported as having been measured at ambient pressure and room temperature makes this quite noteworthy.

What is claimed is that the difference from plain HOPG is the presence of parallel linear defects that result from the cleaving process, a defect line in which the authors speculate that the strain gradient fluctuations result in the formation of superconducting islands, linked by the Josephson effect into Josephson junctions. In the article, resistance and magnetization measurements on the sample are described, which provide results that provide evidence for the presence of these junctions that would link superconducting islands on the cleaved HOPG sample together.

As with any such claim, it is of course essential that it is independently reproduced, which we are likely to see the results of before long. An interesting part of the claim made is that this type of superconductivity in linear defects of stacked materials could apply more universally, beyond just graphite. Assuming this research data is reproduced successfully, the next step would likely be to find ways to turn this effect into practical applications over the coming years and decades.

Beating Bitlocker In 43 Seconds

How long does it take to steal your Bitlocker keys? Try 43 seconds, using less than $10 in hardware. Encrypting your hard drive is good security. If you’re running Windows, the most popular system is BitLocker, which has come with Windows since Vista. We’ve known for some time that Bitlocker could be defeated with direct access to the hardware. Microsoft claims that the process requires an attacker with skill and lengthy access to the hardware. [Stacksmashing] wanted to define lengthy, so he gave it a try. The result is a shockingly fast attack.

Anyone who uses Windows has probably run into Bitlocker. Your hard drive is encrypted, and Bitlocker runs silently in the background, decrypting data on demand.  The problem is key storage. In a simplified sense, encryption keys are stored in the Trusted Platform Module (TPM). When your computer boots, it reads the key from the TPM over the LPC (low pin count) bus, which is one of the last remnants of the original ISA bus.

Continue reading “Beating Bitlocker In 43 Seconds”

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

Retrotechtacular: The Master Hands Of The Early Automotive Industry

When motion pictures came along as a major medium in the 1920s or so, it didn’t take long for corporations to recognize their power and start producing promotional pieces. A lot of them are of the “march of progress” genre, featuring swarms of workers happy in their labors and creating the future with their bare hands. If we’re being honest, a lot of it is hard to watch, but “Master Hands,” which shows the creation of cars in the 1930s, is somehow more palatable, mostly because it’s mercifully free of the flowery narration that usually accompanies such flicks.

“Master Hands” was produced in 1936 and focuses on the incredibly labor-intensive process of turning out cars, which appear to be the Chevrolet Master Deluxe, likely the 1937 model year thanks to its independent front suspension. The film is set at General Motors’ Flint Assembly plant in Flint, Michigan, and shows the entire manufacturing process from start to finish. And by start, we mean start; the film begins with the meticulous work of master toolmakers creating the dies and molds needed for forging and casting every part of the car. The mold makers and foundrymen come next, lighting their massive furnaces and packing the countless sand molds needed for casting parts. Gigantic presses stamp out everything from wheels to frame rails to body panels, before everything comes together at the end of the line in a delicate ballet of steel and men.

Continue reading “Retrotechtacular: The Master Hands Of The Early Automotive Industry”

Human-Interfacing Devices: Packing For The Descriptor Heist

We started with figuring out HID descriptors a week ago, and I’ve shown you how to send raw HID packets using a MicroPython fork. We do still have the task in front of us – making a touchscreen device. For that, let’s give you the tools to capture an existing descriptor from a touchscreen, then show you how to tweak it and how it turns out in the end.

Packing For The Heist

When it comes to this kind of adventure, we can’t go without tools and weapons – it could be dangerous! Without them, you could even abandon your project halfway! Here’s enough high-precision tools and ammunition to last you through whatever obstacles you might encounter. Except for the web-based tools, these tools are for Linux, but please remember that you can always use a virtual machine or a Raspberry Pi. Nobody would use Windows for a heist anyway, what’s with all the telemetry and such.

The first tool is for reading descriptors – we need one to learn from, it’s just like a keycard you can flash to a security guard and scan at the vault entry. Of course, with RFID, you want to have enough examples, compare bits between a few cards and all. For now, HID descriptors don’t have authenticity checks, but it looks like that might just change in the future. Leave it to Apple and Microsoft to add them, as usual. On Linux, seeing descriptors is simple – as root, go into /sys/bus/usb/devices/, find your device by its lsusb device tree path, then follow the directory with the VID/PID in it. That directory will contain a report_descriptor file – hexdump it. The entire command could look like this:

sudo hexdump -v -e '/1 "%02X "' /sys/bus/usb/devices/3-6.2/3-6.2\:1.1/0003\:0C40\:8000.0022/report_descriptor

Again, you might need root to even find this path, so use sudo -i if you must. The format string in the hexdump command gives you parser-friendly output. Specifically, for parsing, I use this webpage – it’s wonderful, even adding tabs that delineate different sections of the descriptor, making its output all that more readable! You can also save this webpage locally, it’s a very neat tool. Other than that, you can try other local tools like this one!

Continue reading “Human-Interfacing Devices: Packing For The Descriptor Heist”

It Wasn’t DOOM That Killed The Amiga

If you were the type of person who might have read Hackaday had we been around in the late 1980s or early 1990s, it’s a reasonable guess that you would have had a 16-bit home computer on your desk, and furthermore that it might have been a Commodore Amiga. These machines gave the best bang for the buck in those days with their impressive multimedia capabilities, and they gained a fervent following which persists to this day. [Carl Svensson] was one of them, and he’s penned a retrospective on the demise of the platform with the benefit of much hindsight.

The heyday of the Amiga from its 1985 launch until the days of the A1200 in the early-to-mid 1990s saw Moore’s Law show perhaps its fastest effects for the consumer. In that decade the PC world jumped from the 8088 to the Pentium, and from a PC speaker and CGA if you were lucky, to a Sound Blaster 16 and accelerated SVGA. By comparison the Amiga didn’t change much except in model numbers and a few extra graphics modes, and when a faster processor came it was far to little too late.

Defender of the Crown, released in 1986

There’s a well-worn path with some justification of blaming Commodore-s notoriously awful management for the debacle, but the piece goes beyond that into the mid ’90s. His conclusion is that what really killed the Amiga was that the CPU price reductions which defined the x86 world at that time never came to 68k or PowerPC lines, and that along with the architecture zealotry of the fan base meant that there would never be the much-longed-for revival.

He also takes a look at the other home computer platforms of the era, including the “all its killer architecture managed to kill was, sadly, Atari itself” Atari Falcon, and the Acorn Archimedes, which also lives on for enthusiasts and is perhaps the most accessible survivor. From here having also the benefit of hindsight we can’t disagree with him on his assessment, so perhaps it’s best to look at the Amiga not as the platform we should rightfully still be using, but the great stepping stone which provided us a useful computer back in t he day without breaking the bank.