GPU-Accelerated Password Cracking: Harnessing Your Graphics Card for Brute-Force Attacks

EDPR

You’ve probably come across Elcomsoft products before. I remember testing their first password crackers for Microsoft Office documents and various archive formats back in the early 2000s, wondering when they’d release a universal tool. We didn’t have to wait long. At first, Elcomsoft Distributed Password Recovery (EDPR) simply consolidated their earlier work, but from 2008 onward it started evolving on its own. That’s when they added GPGPU support and gradually integrated new plugins optimized for GPU-based brute forcing. The latest version at the time of this review, 3.23.1059, comes with 36 plugins, supports about seventy encrypted file formats, and runs on virtually any version of Windows.

EDPR runs on both desktop and server editions of Windows—from 32-bit XP through 64-bit Windows 10. That said, its most popular capability—GPU-accelerated password cracking on Nvidia GPUs—requires Windows 7, 8, 8.1, or 10, or Windows Server 2003, 2008, or 2012.

In theory, EDPR can brute-force passwords not only on Nvidia GPUs but on any graphics chips with a unified shader architecture released in the past seven years. That includes Nvidia gaming cards starting with the GeForce GTX 4xx series and newer; AMD Radeon HD 5000 through HD 8000; and the more recent AMD R9 and RX lines. It also supports professional cards (all Nvidia Quadro and AMD FirePro series) and specialized solutions from both vendors. The latter, in particular, deliver higher brute-force throughput per watt. Standouts for power efficiency relative to their process nodes include the Nvidia GeForce GTX Titan, Tesla K10 and newer, as well as the AMD Radeon Pro Duo, R9 Nano, and R9 Fury X.

However, many password recovery algorithms are optimized for CUDA rather than OpenCL. As a result, EDPR can speed up certain formats only when using Nvidia GPUs. These include ZIP and RAR archives, PDF documents, macOS Keychain stores, Windows account passwords, MD5 hashes, and several others.

Hardware

To see EDPR’s versatility and speed for ourselves, we ran a series of experiments. The first surprise hit us while we were assembling the testbed. Fast GPUs were nowhere to be found at retail, and ordering from abroad would take too long. We reached out to vendors, but they couldn’t help either. There simply weren’t any spare graphics cards available—not even at Nvidia’s local office. Only Inno3D stepped in and tracked down the card we needed.

We originally wanted to use the GTX 1070 for our tests, for several reasons.

First off, it’s a very well-balanced choice—a near-flagship model with all the bells and whistles of the high-end segment. Nothing’s been cut down: you get a full cache and a 256-bit memory bus. At the same time, the GTX 1070 is quite frugal (its TDP is just 150 W) and relatively compact. Thanks to its modest dimensions, it will fit easily into most mid-tower cases.

The graphics card runs just fine with basic 400 W power supplies, but for sustained 100% load it’s better to choose a 500 W unit with any level of 80 Plus certification. The GTX 1070’s relatively modest power draw means you don’t need to chase pricier PSUs—which are also hard to find right now. Crypto miners have snapped everything up!

We tested an iChill GeForce GTX 1070 X4 alongside the reference GeForce GTX 1070 Founders Edition. Both use the GP104 GPU built on a 16 nm FinFET process, with 1,920 CUDA cores arranged in three clusters. The iChill’s base clock is raised to 1620 MHz (up from the 1506 MHz reference) and it auto-boosts as long as it stays within its thermal envelope. Jumping ahead: in our tests the GPU boosted up to 2012 MHz (vs. the 1822 MHz reference boost limit) and remained rock-solid even under sustained 100% load.

Beyond the GPU specs, VRAM also has a noticeable impact on password‑cracking speed. The iChill is solid here too, with 8 GB of Micron GDDR5 running at 2 GHz.

Even the cheapest graphics cards can handle the short-lived performance spikes you see in games, but password brute‑forcing keeps every streaming processor busy for long stretches. So we looked for a card with robust, but strictly air-based, cooling. Liquid cooling adds hassle and isn’t exactly cheap overall. At first, the iChill GeForce GTX 1070 X4’s cooler struck me as a windmill—four fans, after all—but they all turned out to be impressively quiet.

The mention of four fans on the iChill X4 threw me at first. The photos clearly showed three—so why the “X4” in the name? The answer is simple: Inno3D’s engineers added an extra fan mounted perpendicular to the three main ones. It’s smaller (50 mm versus 92 mm) and primarily cools the VRM power circuitry—the most critical part of a modern graphics card.

Without additional cooling, the power-delivery components on new graphics cards can reach 120°C or more, so a dedicated fan is anything but redundant. Remember how EVGA’s first GTX 1070 and 1080 were burning up? Better to learn from others’ mistakes.

A built‑in RGB LED indicator helps you monitor the graphics card’s temperature. As it heats up, the indicator shifts from blue to green, then to yellow and red.

The size was a pleasant surprise. I’m used to each new GPU being bigger than the last, but this time it was the other way around. Despite similar length (305 mm for the old card and 302 mm for the new one), the previous card took up three slots because of its massive heatsink. Back then it seemed justified—more metal, higher heat capacity. How else do you dissipate 200 W of heat?

By contrast, the previous card’s fans struggled to push air through the large heatsink at low RPM, and became noticeably loud at higher speeds. The iChill X4 cooler takes a different approach. It occupies two slots (about two and a half if you include the shroud and branded lighting), and with a 150 W TDP that’s more than sufficient. Thanks to its sensible size, the aluminum heatsink remains quite effective even at low fan speeds—helped by uniform airflow and a heatpipe setup: two 8 mm pipes and three 6 mm ones.

In the past, compact ATX mid‑tower cases could barely accommodate even a single triple-slot Fermi-era graphics card. Now they can easily fit two Pascal-based cards, which are faster and more power-efficient. That said, you still need additional cooling—at minimum, another front-mounted case fan.

By default, the GPU is tuned for maximum performance. However, EDPR puts a highly unusual load on it, and without TDP tweaks it would periodically spike past 140%, pushing the cooling system to its limits. As soon as I launched the Inno3D TuneIT utility and set sensible caps, everything snapped into place: the fans spun up to about 1300 RPM, and TDP returned to normal.

The manufacturer states that the iChill X4 cooling system uses HerculeZ fans with dust-protected bearings, certified for continuous 24/7 operation. I didn’t have enough usage data to draw broad conclusions, but after about a month of running at high RPM, the system’s acoustics remained excellent.

The Universal Unlocker

The EDPR package includes a server component, a local agent, and a management console. The main password recovery workflow starts by launching the EDPR Console. In this console, you can select the encrypted files and choose the password attack type.

• Dictionary attack
• Mask attack
• Exhaustive brute-force attack

For dictionary attacks, you can enable rule-based mutations: adding digits, punctuation, changing case, and so on. As a result, EDPR can detect not only straight dictionary passwords like password, but also various mutations such as password123 or PaSSw0rd.

You can use any dictionary or create your own, but EDPR already includes a solid set of dictionaries: five for English, four for Russian, and one for German.

Additionally, for encryption algorithms with known weaknesses, EDPR offers an option to recover the key directly instead of brute-forcing passwords. This is several times faster.

A mask attack is straightforward: if you know any characters of the password—for example, you saw it starts with a—just put a in place of the first mask character (the question mark). Know other characters? Great—fill those in too.

Brute forcing in EDPR is highly streamlined. All characters are divided into five primary groups (lowercase letters, uppercase letters, digits, punctuation, and space), and common combinations (for example, lowercase letters plus digits) can be defined as separate groups and selected from presets. For the password search, you can specify both maximum and minimum length. This is useful when you know for sure that passwords shorter than N can’t be used in the system you’re analyzing.

On the Comments tab, you can view all details about the encrypted file. For example, for a test archive in the legacy RAR format, it shows the version (RAR 3-4), the encryption algorithm (AES), the key length (128-bit), and the version of the plugin that actually performs the password brute-force (espr_rar.dll v.3.22.109). You can also see the date and time when the audit task was created.

Synchronization between the EDPR agent and server takes some time (from a few seconds to a couple of minutes, depending on the complexity of the most recent task). As a result, even if you remove the only job in the EDPR console, the server will continue to stress the GPU and CPU until it finishes processing the current batch of passwords.

Recovering Microsoft Office Documents

Different versions of MS Office use fundamentally different encryption algorithms. Moreover, Microsoft Office documents come in two formats—Open XML and Office 97–compatible—plus two types of passwords and a variety of security settings.

A document can have a password to open it (in newer versions of Office this is fairly robust) and a separate password to modify it (which is always weaker). In the latter case, especially with older Office versions, you don’t have to crack the password—you can simply view or remove it. The document’s content isn’t encrypted when it’s only protected against edits. Just save it as XML, open it in Notepad, and search for the line containing unprotectPassword=". You can delete that line entirely or read the stored password in cleartext.

Old versions of Office 97 and 2000 handled “password to open” poorly as well. They used the RC4 cipher, which wasn’t particularly robust, and users in Russia got an even weaker variant—only 40-bit keys plus additional simplifications in the key-generation process. Brute-forcing the open password on such documents can reach tens of millions of attempts per second even without a GPU. Worse, the space of possible keys is smaller than the space of possible passwords (a collision effect typical of weak hash functions), so many passwords map to the same key. As a result, these files can be opened very quickly regardless of how complex the original password was.

Documents created in MS Office XP or 2003 are slightly harder to crack because RC4 key generation uses a stronger hash—SHA‑1 (160-bit) instead of MD5. Office 2007 documents are harder still: they use AES‑128 and multiple rounds of hashing.

Encryption didn’t become truly robust until Office 2010. That release added the ability to use third‑party algorithms from the system’s Cryptographic Service Providers via CryptoAPI. As a result, encrypted documents from Office 2010 and newer, saved in Open XML formats (docx, xlsx, etc.), are a much tougher target. The one saving grace is that almost nobody customizes the encryption settings—most people leave the defaults: AES‑128.

Without a GPU, cracking Office 2013 and newer documents is practically impossible. Even five-character passwords would take about six months on a CPU at roughly 57 guesses per second.

Once we add our GTX 1070 GPU, the speed jumps by two orders of magnitude—to 6,550 passwords per second. Instead of six months, brute-forcing the same file takes about a day and a half.

Cracking Archive Passwords

There’s a huge gap between the password protection strength of ZIP and RAR archives. ZIP passwords are cracked extremely fast—so fast that using a GPU to brute-force short passwords isn’t even worth it. In our test, the password AfLpX5 was recovered in just a few seconds, and not by pure brute force but via a dictionary attack with mutations. EDPR didn’t even have time to display the elapsed time or report the cracking speed.

Therefore, if you expect the password to be relatively simple, it’s better to stick with the CPU. By the time the GPU’s execution units spin up and receive their workload, the CPU will have already tried all candidates. CUDA-accelerated brute forcing only makes sense for reasonably long passwords (eight characters or more), and even then mainly when the CPU is busy with other tasks.

In straight brute force, EDPR can’t keep all CUDA cores busy—the GPU load stays under 15%. That’s why, for attacking ZIP archives specifically, you should prioritize a CPU with the highest clock speed. For other formats, GPU performance matters more.

The RAR format is designed to resist high-speed brute‑force attacks. Extracting such an archive requires a series of computationally intensive mathematical operations. In normal use this only adds a barely noticeable fraction‑of‑a‑second delay, but during brute force it significantly slows the attack rate.

Even short, digits-only passwords on RAR archives can take several days to brute-force—at a snail’s pace of about 263 guesses per second.

Add a GPU and everything changes. Throughput jumps 74×—to 19,400 passwords per second. The same job now takes just over an hour instead of a full workweek.

Brute-forcing passwords for older RAR versions (v3.0–v4.x) is easier thanks to their use of a 128-bit AES key. In the new (fifth) RAR version, the key length was increased to 256 bits. However, EDPR was optimized with the new RAR format in mind. As a result, for version 5 archives the GPU cracking speed is even higher—26,500 passwords per second.

Cracking Wi‑Fi Access Point Passwords

EDPR can recover Wi‑Fi passwords from captured handshakes in all popular formats: cap, pcap, hccap, hccapx, ncf, wkp, and wph.

We’ll start with a dictionary attack. On a CPU, it runs at about 12,300 guesses per second. Running through all English wordlists with common password mutations will take over two hours.

Adding a single GTX 1070 GPU to the compute pool boosts throughput to about 391,000 passwords per second—nearly 32× faster. Solving the task will take less than five minutes.

Brute-forcing the shortest allowed password made up of digits only means testing 100 million combinations. EDPR completes this on a GTX 1070 in under six minutes.

If we add lowercase letters to digits, the number of possible combinations jumps by four orders of magnitude. Instead of 10^8, it becomes (10 + 26)^8 = 2,821,109,907,456. Our test rig could brute-force almost three trillion passwords in about four months.

The recommended WPA password pattern (minimum eight characters, with at least one uppercase and one lowercase letter) yields (10 + 26 + 26)^8 = 218,340,105,584,896 combinations. A single GPU would need about 23 years to brute-force that many passwords, which makes this approach practically futile.

What makes EDPR interesting is that it enables distributed brute‑forcing across a local network or over the internet, pooling as many as ten thousand nodes. And if that pool includes not just ordinary PCs but also servers with Nvidia Tesla GPUs or the mining “farms” popular with crypto miners, you could crack 218 trillion WPA passwords in just a day.

In other words, password‑cracking speed is purely a scaling problem, and Elcomsoft Distributed Password Recovery (EDPR) makes pooling nodes easy. Just add more on the “Workers” tab in Elcomsoft Password Recovery Agent.

At first glance, building such a network might seem prohibitively expensive. But you don’t have to buy racks of GPUs and set up all the hardware yourself. Modern distributed computing networks already include millions of nodes, and the main incentive to join them is the opportunity to earn cryptocurrency rewards. In theory, you could launch a new altcoin where “mining” doesn’t just compute hashes but generates rainbow tables (hash–password pairs) in a blockchain format. In practice, someone has almost certainly done this already — we just don’t know about it.