NTP server heated with Bitcoin mining dongles

Bitcoin Mining ASICs Repurposed To Keep NTP Server On Track

January 12, 2022 by Dan Maloney 27 Comments

They say time is money, but if that’s true, money must also be time. It’s all figurative, of course, but in the case of this NTP server heater powered by Bitcoin mining dongles, money actually does become time.

This is an example of the lengths to which Network Time Protocol aficionados will go in search of slightly better performance from their NTP servers. [Folkert van Heusden], having heard that thermal stability keeps NTP servers happy, used a picnic cooler as an environmental chamber for his Pi- and GPS-based NTP rig. Heat is added to the chamber thanks to seven Block Erupter ASIC miner dongles, which are turned on by a Python script when a microcontroller sends an MQTT message that the temperature has dropped below the setpoint.

Each dongle produces about 2.5 Watts of heat when it’s working, making them pretty effective heaters. Alas, heat is all they produce at the moment — [Folkert] just has them working on the same hash over and over. He does say that he has plans to let the miners do useful work at some point, not so much for profit but to at least help out the network a bit.

This seems like a bit of a long way around to solve this problem, but since the mining dongles are basically obsolete now — we talked about them way back in 2013 — it has a nice hacky feeling to it that we appreciate.

All Your Passwords Are Belong To FPGA

May 15, 2020 by Tom Nardi 26 Comments

When used for cracking passwords, a modern high-end graphics card will absolutely chew through “classic” hashing algorithms like SHA-1 and SHA-2. When a single desktop machine can run through 50+ billion password combinations per second, even decent passwords can be guessed in a worryingly short amount of time. Luckily, advanced password hashing functions such as bcrypt are designed specifically to make these sort of brute-force attacks impractically slow.

Cracking bcrypt on desktop hardware might be out of the question, but the folks over at [Scattered Secrets] had a hunch that an array of FPGAs might be up to the task. While the clock speed on these programmable chips might seem low compared to a modern CPUs and GPUs, they don’t have all that burdensome overhead to contend with. This makes the dedicated circuitry in the FPGA many times more efficient at performing the same task. Using a decade-old FPGA board intended for mining cryptocurrency, the team was able to demonstrate a four-fold performance improvement over the latest generation of GPUs.

After seeing what a single quad FPGA board was capable of, the [Scattered Secrets] team started scaling the concept up. The first version of the hardware crammed a dozen of the ZTEX FPGA boards and a master control computer computer into a standard 4U server case. For the second version, they bumped that up to 18 boards for a total of 72 FPGAs, and made incremental improvements to the power and connectivity systems.

Each 4U FPGA cracker is capable of 2.1 million bcrypt hashes per second, while consuming just 585 watts. To put that into perspective, [Scattered Secrets] says you’d need at least 75 Nvidia RTX-2080Ti graphics cards to match that performance. Such an array would not only take up a whole server rack, but would burn through a staggering 25 kilowatts. Now might be a good time to change your password to something longer, or finally get onboard with 2FA.

We’ve covered attempts to reverse engineer hardware designed for cryptocurrency mining, but those were based around application-specific integrated circuits (ASICs) which by definition are very difficult to repurpose. On the other hand, disused FPGA-based miners offer tantalizing possibilities; once you wrap your mind around how they work, anyway.

[Thanks to Piejoe for the tip.]

Name That Unknown RF Signal With A Little FFT Magic

February 11, 2020 by Dan Maloney 27 Comments

Time was once that the amateur radio bands were an aurally predictable place. Spinning the dial up and down the bands, one heard familiar sounds – the staccato of Morse, the [Donald Duck] of sideband voice transmissions, and the occasional flute-like warble of radioteletype signals. Now, the ham bands are full of exotic signals encoding all manner of digital signals, each one with a unique sound and unique demodulation needs. What’s a ham to do?

Help is on the way. [José Carlos Rueda] has made progress toward automatically classifying unknown signals by modifying a Shazam-like app. Shazam is a popular smartphone app that listens to a few seconds of a song, creates an audio fingerprint of it, and searches a massive database of songs for a match. [Rueda] used a homebrew version of the app to search a SQL-lite database of audio fingerprints populated not with a playlist of popular music, but with samples from every known signal type in the Signal Identification Wiki. The database contains hashes for an FFT of each sample, which can be easily searched. With a five to ten second sample of a signal, captured either live over a microphone or from a recording, he is able to identify the signal automatically.

Whether it be the weird, dissonant wail of PSK-31 or the angry buzzing of PACTOR, the goings-on across the bands no longer have to remain a mystery. We really like the idea here, and wonder if it can be expanded upon to visually decode signals based on their waterfall signatures using TensorFlow. There are some waterfall examples in [Danie Conradie]’s excellent article on RF modulation that could get you started.

[via RTL-SDR.com]

Using Lookup Tables To Make The Impossible Possible

January 10, 2020 by Dan Maloney 60 Comments

Embarrassing confession time: I never learned my multiplication tables in grade school. Sure, I had the easy tables like the twos and the fives down, but if asked what 4 x 7 or 8 x 6 was, I’d draw a blank. As you can imagine, that made me a less than stellar math student, and I was especially handicapped on time-limited tests with lots of long multiplication problems. The standard algorithm is much faster when you’ve committed those tables to memory, as I discovered to my great woe.

I was reminded of this painful memory as I watched Charles Lohr’s 2019 Supercon talk on the usefulness and flexibility of lookup tables, or LUTs, and their ability to ease or even completely avoid computationally intensive operations. Of course most LUT implementations address problems somewhat more complex than multiplication tables, but they don’t have to. As Charles points out, even the tables of sines and logarithms that used to populate page after page in reference books have been ported to silicon, where looking up the correct answer based on user input is far easier than deriving the answer computationally.

Yes, this is a Minecraft server all thanks to LUTs.

One of the most interesting examples of how LUTs can achieve the seemingly impossible lies in an old project where Charles attempted to build a Minecraft server on an ATMega168. Sending chunks (the data representations of a portion of the game world) to clients is the essential job of a Minecraft server, and on normal machines that involves using data compression. Rather than trying to implement zlib on an 8-bit microcontroller, he turned to a LUT that just feeds the raw bytes to the client, without the server having the slightest idea what any of it means. A similar technique is used by some power inverters, which synthesize sine wave output by feeding one full cycle of values to a DAC from a byte array. It’s brute force, but it works.

Another fascinating and unexpected realization is that LUTs don’t necessarily have to be software. Some can be implemented in completely mechanical systems. Charles used the example of cams on a shaft; in a car’s engine, these represent the code needed to open and close valves at the right time for each cylinder. More complicated examples are the cams and gears once found in fire control computers for naval guns, or the programming cards used for Jacquard looms. He even tips his hat to the Wintergatan marble machine, with its large programming drum and pegs acting as a hardware LUT.

I found Charles’ talk wide-ranging and fascinating. Originally I thought it would be an FPGA-heavy talk, but he didn’t actually get to the FPGA-specific stuff until the very end. That worked out fine, though — just hearing about all the cool problems a LUT can solve was worth the price of admission.

And for the curious, yes, I did eventually end up memorizing the multiplication tables. Oddly, it only clicked for me after I started playing with numbers and seeing their relationships using my first calculator, which ironically enough probably used LUTs to calculate results.

Continue reading “Using Lookup Tables To Make The Impossible Possible” →

Space Age Bitcoin Mining On An Apollo AGC

July 9, 2019 by Dan Maloney 6 Comments

Imagine you’ve got an Apollo Guidance Computer, the machine that took men to the Moon 50 years ago. You’ve spent ages restoring it, and now it’s the only working AGC on the planet. It’s not as though you’re going to fly to the Moon with it, so what do you do with it? Easy – turn it into a perfectly awful Bitcoin mining rig.

The AGC that [Ken Shirriff] and others have been restoring barely resembles a modern computer. The AGC could only do about 40,000 operations per second, but raw speed was far less important than overall reliability and the abundant IO needed to run a crewed spacecraft. It was a spectacular success on the Apollo missions, but [Ken] wanted to know if turning it into a Bitcoin mining rig was possible.

[Ken] gives a great overview of how Bitcoin mining works, with one of the best explanations of the hashing algorithm we’ve seen. Getting that to run on the AGC was no mean feat, especially with limits imposed by the memory addressing scheme and the lack of machine instructions for manipulating words. He eventually got it working, though, clocking in at a screaming 10.3 seconds per Bitcoin hash. [Ken] estimates that the first coin will be successfully mined in a mere 400 zettaseconds, which is about a billion times older than the universe. With about 13 quadrillion years to the first ka-ching, you have plenty of time to watch a block mined in the video below; alas, it was an old block, so no coins were awarded to compensate the team for their efforts.

This isn’t the first time [Ken] has implemented a useless Bitcoin mine. The Xerox Alto mine was actually fast compared to the AGC, but it sure beats the IBM mainframe and punchcards.

Continue reading “Space Age Bitcoin Mining On An Apollo AGC” →

Is My Password Safe? Practices For People Who Know Better

April 7, 2017 by Pedro Umbelino 75 Comments

A couple of weeks back a report came out where [Tavis Ormandy], a widely known security researcher for Google Project-Zero, showed how it was possible to abuse Lastpass RPC commands and steal user passwords. Irony is… Lastpass is a software designed to keep all your passwords safe and it’s designed in a way that even they can’t access your passwords, the passwords are stored locally using strong cryptography, only you can access them via a master-key. Storing all your passwords in only place has its downfalls. By the way, there is no proof or suggestion that this bug was abused by anyone, so if you use Lastpass don’t worry just yet.

But it got me thinking, how worried and how paranoid should a regular Internet user should be about his password? How many of us have their account details exposed somewhere online? If you’ve been around long enough, odds are you have at least a couple of accounts on some major Internet-based companies. Don’t go rushing into the Dark Web and try to find if your account details are being sold. The easiest way to get your paranoia started is to visit Have I Been Pwned. For those who never heard about it, it’s a website created by [Troy Hunt], a well-known security professional. It keeps track of all known public security breaches he can get his hands on and provides an answer to a simple question: “Was my account in any major data leak?” Let’s take a look.

Continue reading “Is My Password Safe? Practices For People Who Know Better” →

SHAttered — SHA-1 Is Broken In

February 23, 2017 by Pedro Umbelino 96 Comments

A team from Google and CWI Amsterdam just announced it: they produced the first SHA-1 hash collision. The attack required over 9,223,372,036,854,775,808 SHA-1 computations, the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations. While this may seem overwhelming, this is a practical attack if you are, lets say, a state-sponsored attacker. Or if you control a large enough botnet. Or if you are just able to spend some serious money on cloud computing. It’s doable. Make no mistake, this is not a brute-force attack, that would take around 12,000,000 single-GPU years to complete.

SHA-1 is a 160bit standard cryptographic hash function that is used for digital signatures and file integrity verification in a wide range of applications, such as digital certificates, PGP/GPG signatures, software updates, backup systems and so forth. It was, a long time ago, proposed as a safe alternative to MD5, known to be faulty since 1996. In 2004 it was shown that MD5 is not collision-resistant and not suitable for applications like SSL certificates or digital signatures. In 2008, a team of researchers demonstrated how to break SSL based on MD5, using 200 Playstations 3.

Early since 2005 theoretical attacks against SHA-1 were known. In 2015 an attack on full SHA-1 was demonstrated (baptized the SHAppening). While this did not directly translate into a collision on the full SHA-1 hash function due to some technical aspects, it undermined the security claims for SHA-1. With this new attack, dubbed SHAttered, the team demonstrated a practical attack on the SHA-1 algorithm, producing two different PDF files with the same checksum.

The full working code will be released in three months, following Google’s vulnerability disclosure policy, and it will allow anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images and some, not yet specified, pre-conditions.

For now, recommendations are to start using SHA-256 or SHA-3 on your software. Chrome browser already warns if a website has SHA-1 certificate, Firefox and the rest of the browsers will surely follow. Meanwhile, as always, tougher times are ahead for legacy systems and IoT like devices.