eternal-flame-ad/java-hashcode-chosen-prefix

This project finds "collisions" in Java's hashCode function, meaning it generates different pieces of text that produce the exact same hash value. The demo shows it taking JSON like {"uid":0,"account_balance":0 and finding a modified version {"uid":0,"account_balance":99999,"_fixup":"l5555550000OVH|4830083526" that shares the same hash. The practical implication: if a system uses Java's hashCode to check whether data has been tampered with, an attacker could swap the original data for their modified version without the change being detected. At a high level, the tool uses a technique called "meet-in-the-middle." Instead of brute-forcing every possible text combination, it works from both ends, matching up pieces that produce the same intermediate hash value, which is dramatically faster. It's written in Rust and uses specialized CPU instructions (SIMD) to process many calculations simultaneously, bringing the search time down to milliseconds. The benchmarks show it testing hundreds of billions of hash candidates per second on modern hardware. The target audience is security researchers and engineers testing systems that rely on hashCode for integrity checks. A concrete example: if a service serializes objects to JSON and trusts hashCode to detect modifications, this tool demonstrates how an attacker could inject a field like "account_balance":99999 while keeping the hash identical. It's essentially a proof-of-concept for why hashCode should never be used as a security mechanism. The README is sparse beyond the benchmark and demo output, there's no detailed documentation on setup, configuration, or the full range of use cases. The project is notable for its speed: even on basic hardware it finds collisions in under 15 milliseconds, and with advanced CPU features like AVX-512, that drops to around 2.5 milliseconds.