Mark El-Khoury ports Hashcat to a Game Boy Advance, and it is 30 million times slower

Mark El-Khoury, a security engineer, ported Hashcat to the Game Boy Advance. He built a project called GBA-Hashcat, and his headline performance claim is brutally specific: the 16.78 MHz ARM7TDMI in the GBA does 727 SHA256 hashes per second. El-Khoury frames that as about thirty million times slower than a modern cracking rig, adding that “350 days of continuous cracking on this bad boy could be done in about 1 second with a modern GPU-accelerated cracking rig.”

So why does any of this matter if the hardware is that slow? Because the core point is not speed, it is portability. El-Khoury’s “not really” Hashcat is still a functioning password-recovery pipeline for a tightly constrained use case: it checks one fixed word list against SHA-256 and, when a hash matches, can reveal the plaintext password. The GBA becomes a proof that serious offensive ideas can be transplanted into unexpected devices, even if the economics are all wrong.

To make the port possible, El-Khoury used the Butano engine, which lets developers code software for the GBA using C++. But this is where the “port” stops being “full Hashcat.” Hashcat in its usual form supports a variety of attack methods and over 300 hash algorithms. GBA-Hashcat is confined to one algorithm and one approach: it generates the SHA256 hash of each line in the fixed word list and compares it to a hardcoded target hash to see if there is a match. That is enough to demonstrate the workflow, but it also highlights a key reality for security teams: constraints change performance and capability, not the existence of risk.

If you are a decision-maker, the interesting part is what this says about attacker creativity. The story explicitly frames the developer’s motivation as part technical curiosity, part joke, writing on his GitHub page that it is both “The greatest password cracking of all time” and his “dumbest app of all time.” On LinkedIn, he followed up with another update: after porting hashcat to the GBA, he realized it is slow and expects speed gains by implementing in Lua, specifically the subset used in World of Warcraft addons. The follow-on claim is that this could enable “crack hashes in-game,” which again reinforces the same theme. It might be inefficient on purpose, but it demonstrates that offensive techniques can be re-skinned to run in new environments.

There is also a broader “why not” pattern in the source that is worth treating as more than nerd entertainment. In recent weeks, multiple developers have been building security-adjacent and emulation projects for old handhelds. Back in April, a modder shrunk down the Game Boy Color into a smart watch form factor with what the article calls a cursed control scheme. Last month, another lone developer built an E-Ink Game Boy emulator with an “actually playable” refresh rate for Pokémon Blue. The thread connecting these is not just retro hardware. It is a culture of taking tools meant for one context and repackaging them for another. Boards should care because that same instinct is the substrate attackers exploit, even when the initial project is playful.

For executives thinking about governance and risk management, the headline numbers here are actually useful. A GBA doing 727 SHA256 hashes per second, even at thirty million times slower than a modern GPU rig, is still capable of doing meaningful work under the right conditions. The article states that 350 days of continuous cracking on the GBA could be reduced to about 1 second with a modern GPU-accelerated cracking rig. That contrast is a clear reminder that threat models cannot rely on “we do not have the budget for attacks.” Attackers often leverage performance where it matters, but they also experiment with workarounds and portability where it gets them access to new surfaces.

Regulatory and compliance angles typically focus on protecting authentication and limiting credential exposure. This kind of demonstration strengthens the case that password protection needs to be designed for worst-case attacker capability, not average-case scenarios. Even if this specific device is too slow to be a practical attack tool against well-protected systems, it reinforces the need for strong password hashing practices, monitoring, rate limiting, and systems that do not treat weak passwords as an acceptable gamble.

The second-order stakes for peers in similar roles: if you assume attackers only run tools on commodity servers, you are underestimating how quickly “tech plumbing” gets moved around. The GBA-Hashcat port is an existence proof. It says that with the right mapping, the shape of an attack can travel across platforms. Speed can be throttled by hardware, but the logic still travels. For security leadership, that means focusing on controls that survive both high-performance rigs and weird, custom implementations.