cryptocurrency

30 Articles

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.

An earlier version of the FPGA cracker

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.

For those unfamiliar with the term, a “Bitcoin Faucet” is usually used as an incentive in software that wants your attention. Complete a captcha or look at and advertisement and you get one millionth of a BTC, that sort of thing. You’re never going to get rich off of one of them, but most people aren’t going to turn down free money either. The latest project from [TJ Bruno] follows that same concept and brings it into the physical world. But you still aren’t going to get rich off of it.

The hardware used for this corporeal Bitcoin Faucet is pretty simple. All you need is a Raspberry Pi, a camera module, and a 2.8″ touch LCD. Naturally you could use a larger screen if you wanted, but then it wouldn’t fit inside of the very slick 3D printed stand that [TJ] developed. We might consider upgrading to a slightly speedier Pi though, in the demonstration video it looks like the Zero is struggling pretty hard to handle the GUI.

Using the Faucet is straightforward enough. You tap the screen and place a QR code representing your Bitcoin wallet on the device’s tray, where it’s scanned by the camera. In a few seconds the Faucet shows a QR code on its own screen that will point your phone’s browser to the transaction details so you can verify your digital coinage is on the way.

You might be wondering why you’d want to have a device that sits there waiting to pay out fractions of a BTC to anyone who’s willing to flash their wallet at it. We’re not entirely sure, though it might make for an interesting way to raise awareness about cryptocurrency. In this particular case though, [TJ] says he was just looking for a project that would give him an excuse to hone his Python skills. Nothing wrong with that around these parts.

Blockchain has existed as a concept since the early 1990s, but keeping a distributed ledger for IoT transactions wasn’t widely implemented until IOTA developed Tangle. The blockchain company was initially founded as a hardware startup and pivoted to work on transactional settlement for IoT. The Tangle, their distributed ledger architecture based on a directed acyclic graph (DAG) works as a “blockchain without the blocks and the chain”.

As its name implies, the Tangle is a web of transactions that references its past two transactions and a subsection of other transactions. Rather than miners and stakers being responsible for overall consensus, all active participants are involved in the approval of transactions. The transaction process requires the client to sign with their private keys, select two random unconfirmed transactions to be referenced, and perform proof-of-work.

The proof-of-work has an unfortunately high difficulty as you might expect. The process is similar to finding a nonce in Bitcoin mining, although the difficulty is set at a lower threshold due to the transactions running on lower-power nodes. Even so, since IOTA transactions commonly occur on small embedded platforms this can take several minutes to complete, a relatively long time considering these are mere transactions.

Since Curl-P81 hashes should be computed in parallel, they can’t be computed efficiently on general purpose CPUs. The PiDiver 1.3, [Thomas Pototschnig]’s port of the IOTA Reference Implementation (IRI) PearlDiver, performs searches for nonces. Because it runs on FPGAs, it is able to speed up the proof-of-work by a factor of more than 140 when compared to a Raspberry Pi. The FPGA is able to calculate one round of the hash in a single clock cycle, and a complete hash in 85 cycles (as well as testing for a valid nonce). Seven parallel hashes can be calculated at once, giving 15.8MHash/s at a frequency of 188MHz. The proof-of-work takes ~300ms on the FPGA when compared to 90s on a Raspberry Pi, so this is a significant improvement in speed.

Since the project is open source, the core can be used by IRI for creating a modified version of their PearlDiver. The board can be used as a Raspberry Pi HAT, although it can also be connected via USB to work without the Pi.

While this doesn’t address the security concerns of using IOTA with personal IoT devices, it is certainly a significant improvement on the speed of their proof-of-work process, and the software speedup is incredibly satisfying to watch.

What’s in your crypto wallet? The simple answer should be fat stacks of Bitcoin or Ethereum and little more. But if you use a hardware cryptocurrency wallet, you may be carrying around a bit fat vulnerability, too.

At the 35C3 conference last year, [Thomas Roth], [Josh Datko], and [Dmitry Nedospasov] presented a side-channel attack on a hardware crypto wallet. The wallet in question is a Ledger Blue, a smartphone-sized device which seems to be discontinued by the manufacturer but is still available in the secondary market. The wallet sports a touch-screen interface for managing your crypto empire, and therein lies the weakness that these researchers exploited.

By using a HackRF SDR and a simple whip antenna, they found that the wallet radiated a distinctive and relatively strong signal at 169 MHz every time a virtual key was pressed to enter a PIN. Each burst started with a distinctive 11-bit data pattern; with the help of a logic analyzer, they determined that each packet contained the location of the key icon on the screen.

Next step: put together a training set. They rigged up a simple automatic button-masher using a servo and some 3D-printed parts, and captured signals from the SDR for 100 presses of each key. The raw data was massaged a bit to prepare it for TensorFlow, and the trained network proved accurate enough to give any hardware wallet user pause – especially since they captured the data from two meters away with relatively simple and concealable gear.

Every lock contains the information needed to defeat it, requiring only a motivated attacker with the right tools and knowledge. We’ve covered other side-channel attacks before; sadly, they’ll probably only get easier as technologies like SDR and machine learning rapidly advance.

For a long time it seemed like e-ink displays were outside the reach of us lowly hackers, as beyond the handful of repurposed Kindles that graced these pages, we saw precious few projects utilizing this relatively exotic display. But that’s changed over the last couple of years, and we’re thrilled to start seeing hackers bend this incredible technology to their will.

A perfect example is PaperLedger, an entry into the 2019 Hackaday Prize by [AIFanatic]. This wireless device is designed to display the current price of various cryptocurrencies on its 2.9-inch e-ink screen and provide audible price alerts with its built-in speaker. It even has a web portal where users can configure the hardware or view more in-depth price information.

The PaperLedger is based on the TTGO T5 V2.2 ESP32, but it looks like [AIFanatic] is in the process of spinning up a new board for the MIT licensed project to address some nagging issues for this particular application. Unfortunately, it doesn’t look like there are any pictures of the new board yet, but a description of the changes on the Hackaday.IO page shows that most of the work seems to be going into improving support for running on batteries.

Even if you’re not interested in cryptocurrency, the PaperLedger looks like a fantastic little e-ink monitor for pretty much anything else you’d like to keep a close eye on. The GPLv3 licensed firmware is available on the project’s GitHub page, so expanding or completely changing the device’s functionality shouldn’t be too tricky for anyone with a desire to do so and a working knowledge of C++.

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.

It looks like Al was right, we should all be using Emacs. On the 4th of June, [Armin Razmjou] announced a flaw in Vim that allowed a malicious text file to trigger arbitrary code execution. It’s not every day we come across a malicious text file, and the proof of concept makes use of a clever technique — escape sequences hide the actual payload. Printing the file with cat returns “Nothing here.” Cat has a “-v” flag, and that flag spills the secrets of our malicious text file. For simplicity, we’ll look at the PoC that doesn’t include the control characters. The vulnerability is Vim’s modeline function. This is the ability to include editor options in a text file. If a text file only works with 80 character columns, a modeline might set “textwidth=80”. Modeline already makes use of a sandbox to prevent the most obvious exploits, but [Armin] realized that the “:source!” command could run the contents of a file outside that sandbox. “:source! %” runs the contents of the current file — the malicious text file.

Taking this apart one element at a time, the “:!” is the normal mode command to run something in the shell, so the rest of the line is what gets run. “uname -a” is the arbitrary command, benign in this case. Up next is the OR operator, “||” which fully evaluates the first term first, and only evaluates what comes after the operator if the first term returns false. In this case, it’s a simple way to get the payload to run even though the rest of the line is garbage, as far as bash is concerned. “vi:” informs Vim that we have a modeline string. “:fen” enables folding, and “:fdm=expr” sets the folding method to use an expression. This feature is usually used to automatically hide lines matching a regular expression. “:fde=” is the command to set the folding expression. Here’s the exploit, the folding expression can be a function like “execute()” or “assert_fails()”, which allows calling the :source! command. This pops execution out of the sandbox, and begins executing the text file inside vim, just as if a user were typing it in from the keyboard. Continue reading “This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist”→