Cracking Brainwallets: How Custom Hashcat Modules Turn Passphrases into Private Keys

TLDR: This research demonstrates how to automate the brute-forcing of brainwallets by solving a series of cryptographic puzzles using custom Hashcat modules. By leveraging GPU-accelerated cloud instances, the author successfully derived a private key from a low-entropy passphrase to claim a Bitcoin bounty. This attack highlights the critical failure of using human-readable passphrases for key derivation and provides a blueprint for building custom cracking plugins for non-standard targets.

Brainwallets—cryptocurrency wallets where the private key is derived directly from a user-provided passphrase—have been a known security disaster for over a decade. The premise is simple: if you can remember the passphrase, you can regenerate the key anywhere. The reality is that human entropy is abysmal. When you combine a predictable passphrase with deterministic key derivation, you are essentially handing your funds to anyone with a decent GPU and a bit of patience.

The Anatomy of the Brainwallet Heist

The research presented at DEF CON 2025 centers on a specific challenge: a brainwallet containing one Bitcoin, protected by a series of 20 cryptographic puzzles. To claim the prize, a researcher had to solve these puzzles to reconstruct the passphrase, which then allowed for the derivation of the private key.

Mechanically, the process relies on the standard Bitcoin address generation flow:

1. Passphrase to Private Key: The passphrase is hashed (often using SHA-256) to create a private key.
2. Private Key to Public Key: The private key is mapped to a public key on the secp256k1 elliptic curve.
3. Public Key to Address: The public key is hashed using SHA-256 and RIPEMD-160 to generate the final wallet address.

The author realized that brute-forcing this entire chain on a CPU was computationally infeasible, given the search space. The solution was to move the heavy lifting to the GPU using Hashcat. However, standard Hashcat modules do not support the specific brainwallet derivation path out of the box. This required writing custom modules.

Building Custom Hashcat Plugins

Developing a Hashcat plugin is not for the faint of heart, but it is the only way to achieve the necessary throughput for this kind of attack. A Hashcat plugin consists of two primary components: the Module and the Kernel.

The Module, written in C, handles the high-level logic: input/output processing, result handling, and interfacing with the target hash format. It is compiled alongside Hashcat. The Kernel, written in OpenCL, is where the actual cryptographic operations occur on the GPU.

To reproduce this, you need to define the module_hash_decode and module_hash_encode functions to bridge your target format with Hashcat’s internal structure. The most critical part is the Kernel’s loop function, where the repeated hashing rounds occur. If your target algorithm involves multiple iterations, you must implement them here to keep the GPU threads synchronized and avoid the massive overhead of moving data back to the CPU.

For this specific heist, the author modified existing modules for SHA-256 and secp256k1. By stripping out unnecessary overhead and focusing on the specific derivation path, the author achieved a massive speedup compared to CPU-based tools like brainflayer.

Real-World Pentesting and Impact

In a professional engagement, you are unlikely to encounter a 20-part puzzle, but you will frequently encounter Identification and Authentication Failures involving weak key derivation. If you find an application that allows users to "recover" keys via a passphrase or a "security question" that acts as a seed, you are looking at a potential brainwallet-style vulnerability.

If you can identify the derivation algorithm, you can write a custom Hashcat module to test common password patterns against that seed. The impact is total account compromise. During an assessment, demonstrating this by cracking a test account with a weak passphrase is far more effective than simply reporting "weak password policy."

Defensive Realities

Defending against this is straightforward but often ignored: never derive cryptographic keys from user-provided passphrases. If you must use a passphrase, it must be passed through a slow, memory-hard key derivation function (KDF) like Argon2 or scrypt. These functions are specifically designed to make GPU-accelerated brute force prohibitively expensive by requiring significant memory per attempt.

If you are building a system that handles private keys, the key should be generated by a cryptographically secure random number generator (CSPRNG) and stored in a hardware security module (HSM) or a secure enclave. Passphrases should only ever be used to encrypt the stored key, not to generate it.

The author’s journey from manual brute-forcing to writing custom OpenCL kernels is a masterclass in persistence. When you hit a wall with standard tools, the ability to drop down to the kernel level and optimize the math is what separates a script kiddie from a researcher. If you find yourself stuck on a target, stop looking for a pre-made tool and start looking at the math. The solution is usually hidden in the derivation logic.