Raspberry Pi clusters are a common enough project, but a lot of the builds we see focus on the hardware side of the cluster. Once it’s up and running, though, what comes next? Raspberry Pis aren’t very powerful devices, but they can still be a great project for learning how to interact with a cluster of computers or for experimental test setups. In this project from [Dino], four Pis are networked together and then loaded with a basic set of software for cluster computing.
The first thing to set up, after the hardware and OS, is the network configuration. Each Pi needs a static IP in order to communicate properly. In this case, [Dino] makes extensive use of SSH. From there, he gets to work installing Prometheus and Grafana to use as monitoring software which can track system resources and operating temperature. After that, the final step is to install Ansible which is monitoring software specifically meant for clusters, which allows all of the computers to be administered more as a unit than as four separate devices.
This was only part 1 of [Dino]’s dive into cluster computing, and we hope there’s more to come. There’s a lot to do with a computer cluster, and once you learn the ropes with a Raspberry Pi setup like this it will be a lot easier to move on to a more powerful (and expensive) setup that can power through some serious work.
You may sometimes see the Crosley name today on cheap record players, but from what we can tell that company isn’t connected with the Crosley Radio company that was a powerhouse in the field from 1921 to 1956. [Uniservo] looks at two of the very early entries from Crosley: the model VIII and the XJ. You can see the video of both radios, below.
The company started by making car parts but grew rapidly and entered the radio business very successfully in 1921. We can only imagine what a non-technical person thought of these radios with all the knobs and switches, for some it must have been very intimidating.
Continue reading “Odd Crosley Radios From The 1920s”
Another week, another exploit against an air-gapped computer. And this time, the attack is particularly clever and pernicious: turning a GPU into a radio transmitter.
The first part of [Mikhail Davidov] and [Baron Oldenburg]’s article is a review of some of the basics of exploring the RF emissions of computers using software-defined radio (SDR) dongles. Most readers can safely skip ahead a bit to section 9, which gets into the process they used to sniff for potentially compromising RF leaks from an air-gapped test computer. After finding a few weak signals in the gigahertz range and dismissing them as attack vectors due to their limited penetration potential, they settled in on the GPU card, a Radeon Pro WX3100, and specifically on the power management features of its ATI chipset.
With a GPU benchmarking program running, they switched the graphics card shader clock between its two lowest power settings, which produced a strong signal on the SDR waterfall at 428 MHz. They were able to receive this signal up to 50 feet (15 meters) away, perhaps to the annoyance of nearby hams as this is plunk in the middle of the 70-cm band. This is theoretically enough to exfiltrate data, but at a painfully low bitrate. So they improved the exploit by forcing the CPU driver to vary the shader clock frequency in one megahertz steps, allowing them to implement higher throughput encoding schemes. You can hear the change in signal caused by different graphics being displayed in the video below; one doesn’t need much imagination to see how malware could leverage this to exfiltrate pretty much anything on the computer.
It’s a fascinating hack, and hats off to [Davidov] and [Oldenburg] for revealing this weakness. We’ll have to throw this on the pile with all the other side-channel attacks [Samy Kamkar] covered in his 2019 Supercon talk.
Continue reading “GPU Turned Into Radio Transmitter To Defeat Air-Gapped PC”
Back when batteries were expensive and low-capacity, it was common to buy a “battery eliminator” that could substitute for common battery configurations. [David Watts] must remember those, because he decided to make an eliminator for all the CR2032 battery-driven gear he has. He got some brass blanks about the size of the battery, and you can see the results on the video below.
His first attempt seemed to work fairly well, a sandwich of two brass disks, each with a Velcro spacer and wires soldered on to connect to a power supply. The fake battery looks as though it might be a little thick, but it did work once the battery holder was persuaded to accept it.
Continue reading “A CR2032 Battery Eliminator”
Besides a few stalwart holdouts, most of us have have switched over listening to music in digital form, often via an online stream. As long as no data caps stand in your way, it’s a quick and easy way to listen to your favorite artists or discover new ones. But there’s something visceral about act of loading a piece of physical media into a player that can’t be replicated by just clicking or tapping on a screen.
Which is why [InfiniteVideo] put together this RFID playlist launcher peripheral. There’s an important distinction to be made here, as this device isn’t actually playing or even storing audio. A nearby Raspberry running Volumio handles the actual playback. This device is just an RFID reader with some clever tokens that the listener can use to select their favorite artists and albums with physical tokens. It’s certainly not a new concept, but we think the nuances of this particular build warrant a closer look.
The “player” consists of a ESP8266 with a MFRC522 RFID reader wired directly to the GPIO pins. The pair are housed in a rather large 3D printed enclosure, which at first might seem a bit excessive. But it turns out that [InfiniteVideo] is actually trying to replicate a crowd sourced project called Qleek which is based around a similarly chunky reader.
Likewise, the hexagon tiles are also lifted from the Qleek concept. But rather than being made out of wood as in the original, [InfiniteVideo] is printing those as well. Halfway during the process, the print is paused and an RFID sticker is placed in the middle of the hexagon. Once resumed, the RFID tag becomes permanently embedded in the tile with no visible seams to reveal how the trick was pulled off. With the addition of a suitable label, each printed hexagon gets associated with the desired album or artist in software.
This project is notable for its convenience and visual flair, but using RFID tags for media identification can also be a practical choice. It can be used as an assistive technology, or as a way for young children to easily interact with devices.
Saying that it was finally time for the community to bid a “fond but firm farewell to Python 2”, core developer Benjamin Peterson marked the release of Python 2.7.18 on April 20th; officially ending support for the 2.x branch of the popular programming language. It was hardly a snap decision. Python 3.0 was released all the way back in December 2008, and it was never a secret that the newer branch was not only incompatible with the earlier version, but that it would eventually superseded it to become the standard.
But migrating the incredible amount of Python code in the wild over to the latest and greatest was easier said than done. Millions upon millions of lines of code used in everything from Linux distributions to virtually every major web service needed to be reviewed and migrated over to Python 3. In many cases the changes were relatively minor, but when code is being used in mission critical applications, even the smallest of changes are often avoided unless it’s absolutely necessary. The voluntary migration took far longer than expected, and the end-of-life (EOL) for Python 2 was pushed back by years to accommodate developers who hadn’t made the necessary changes yet.
Given the somewhat fluid nature of the Python 2 EOL date, it seems fitting that this last final release would come several months after the “official” January 2020 deadline. The intention was for it to coincide with PyCon 2020, but just like so many of the events planned for the first half of the year, the in-person conference had to be canceled in favor of a virtual one due to the COVID-19 epidemic. That might have stymied the celebration somewhat, but the release of Python 2.7.18 will still be looked on as a special moment for everyone involved.
Continue reading “Core Devs Say A Fond But Firm Farewell To Python 2”
Hackaday editors Elliot Williams and Mike Szczys pan for gold in a week packed with technological treasure. The big news is Apple/Google are working on contact tracing using BTLE. From adoption, to privacy, to efficacy, there’s a lot to unpack here and many of the details have yet to take shape. Of course the episode also overflows with great hacks like broken-inductor bike chain sensors, parabolic basketball backboards, bizarre hose clamp tools, iron-on eTextile trials, and hot AM radio towers. We finish up discussing the greatest typing device that wasn’t, and the coming and going of the COBOL crisis.
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)
Places to follow Hackaday podcasts:
Continue reading “Hackaday Podcast 064: The COBOL Cabal, The Demoscene Bytes, And The BTLE Cure”