hashcat normally runs a hash kernel through its CUDA, HIP, OpenCL or Metal backend. An assimilation bridge lets a hash-mode replace or supplement part of that pipeline with a shared library, so the work can go to CPU reference code, an embedded language runtime, remote hardware, or a compute system that does not fit the backend interface at all.
A bridge is chosen by the hash-mode. A mode that declares no bridge uses the normal backend path, so other modes incur no extra cost.
| mode | what the bridge does |
|---|---|
| 70000 | Argon2id through the reference implementation |
| 70100 | scrypt, with the memory-heavy smix() stage on the bridge and PBKDF2 left on the backend |
| 70200 | yescrypt in scrypt-emulation mode |
| 73000 | a generic hash written in Python, one interpreter process per CPU thread |
| 74000 | the same generic model in Rust |
| 75000 | bcrypt on an FPGA, see FPGA support |
| 79000 | the same bcrypt bridge against a simulated fleet, for testing without boards |
Mode 70100 illustrates how a backend and a bridge can handle different stages of a single hash. The split is per stage rather than per mode.
--help marks each of these [Bridged: ...]. They put more of the work on the host than an ordinary mode does, which is why CPU use is higher and why a benchmark reads differently.
All of them ship in the release folder under docs/.