[ANN] vuke - Bitcoin Vulnerable Key Research Tool (Rust, Open Source)

[Redni]

Repository: https://github.com/oritwoen/vuke  
License: MIT  
Language: Rust

What is vuke?
vuke is a security research tool for reproducing and analyzing historically vulnerable Bitcoin key generation methods. If you're into wallet vulnerability archaeology, verifying your own keys for weak generation patterns, or academic cryptographic research - this tool is for you.

Key Features

🔄 Key Generation (forward)
- Transforms: SHA256, double SHA256, MD5, Milksad, MT19937-64, LCG, Xorshift, SHA256 chains, Electrum, Armory, MultiBit HD, Bitimage
- Input sources: numeric ranges, wordlists, timestamps, stdin, binary files
- Parallel processing via Rayon - full CPU utilization

🔍 Key Analysis (reverse)
- Brute-force 2^32 seeds (Milksad, LCG, SHA256 chain)
- Brute-force 2^64 with cascade filter (MT19937-64, Xorshift)
- Pattern detection (small seeds, ASCII strings)
- Heuristic analysis (entropy, hamming weight)

🎯 Target Scanning
- Match generated keys against known address lists
- Provider integration (boha:b1000 puzzles)
- Cascade filter for false positive reduction

💾 Storage & Cloud
- Parquet format for TB-scale analysis
- SQL queries via DuckDB
- S3/R2/MinIO upload
- Apache Iceberg catalog registration

⚡ Optional GPU (WebGPU)
- SHA256 and MT19937 acceleration
- Feature-gated: --features gpu

Disclaimer
⚠️ This tool is for educational and security research purposes only. Do not use it to access wallets you do not own. The authors are not responsible for any misuse.


Links
- 📦 GitHub: https://github.com/oritwoen/vuke
- 📖 Documentation: https://deepwiki.com/oritwoen/vuke
- 🦀 crates.io: https://crates.io/crates/vuke

Feedback, issues and PRs welcome! 🙏

[BattleDog]

This is the kind of project I like seeing on here, done as an actual engineering tool instead of a shoddy pastebin script.

Also, tiny suggestion: even with the disclaimer, tools like this attract the kinds of people that think they're good because they watched two hacking movies or something like that... So anything you can do to keep the sharp edges behind explicit flags and make the default behavior research-friendly. No bundled target lists, no network fetching, noisy logging when someone tries to run it like a wallet vacuum goes a long way.

Bonus points if you add a mode that only reports statistical findings or hit counts for owned datasets, 'cause plenty of people just want to validate historical keygen screwups without ever printing sensitive material to a terminal.

Either way, nice work. 💀

[JackMazzoni]

I'm waiting for projects like this for ages. Thanks

[Redni]

This is the kind of project I like seeing on here, done as an actual engineering tool instead of a shoddy pastebin script.

Also, tiny suggestion: even with the disclaimer, tools like this attract the kinds of people that think they're good because they watched two hacking movies or something like that... So anything you can do to keep the sharp edges behind explicit flags and make the default behavior research-friendly. No bundled target lists, no network fetching, noisy logging when someone tries to run it like a wallet vacuum goes a long way.

Bonus points if you add a mode that only reports statistical findings or hit counts for owned datasets, 'cause plenty of people just want to validate historical keygen screwups without ever printing sensitive material to a terminal.

Either way, nice work. 💀

Thanks for the thoughtful feedback.

Current state:
 - Offline-only core - no network fetching in main functionality (cloud storage is opt-in feature)
 - No bundled address lists - data providers (like boha:) are external crates, feature-gated
 - All targets user-provided - either files or explicit provider references

Your suggestions I'm considering:
- Stats-only mode - --stats-only flag that reports hit counts without printing keys/addresses. Good for validating research without sensitive output.
- Verbose audit logging - noisy output when scanning large target sets, so it's obvious what's happening

The data providers are intentional - they're for researchers working on known historical vulnerabilities (Bitcoin puzzles, documented CVEs). They require explicit syntax (boha:collection:filter) and understanding of what you're doing. Not hiding them, but keeping them explicit.

Appreciate the engineering perspective