hashcat Forum

I'm trying to recover a 10-digit PIN for an old bitcoin-based altcoin (dogecoin) wallet. From what I found reading btcrecover code this is different from a regular encrypted wallet in that regular bitcoin-based wallets use a SHA512-derived key for AES-256 CBC while this "PIN-lock" uses a Scrypt-derived key instead for the same AES-256 CBC.
Hashcat --help mentions mode 15700 for Ethereum Wallets using SCRYPT while code for AES-256 CBC is in base implementation of mode 11300 for recovering encrypted Bitcoin wallet passwords.
My questions are: 

1. Am I right to consider hashcat for this purpose?
   
2. What does it usually take to get a new mode introduced into hashcat in terms of votes, wait time in the requested modes queue, beers bought?
   
3. Where do I start in the process of learning to add such PIN recovery mode to hashcat myself, knowing that both Scrypt and AES-256 CBC are already in the repo and could possibly be reused? 
   

If I need to attach some sort of benchmark: btcrecover manages to hit 1100 P/s on a i9-10900x using 8 cores - it has 20 logical on 10 physical cores, so I suppose it can be pushed more but I'm not considering turning my main and only PC into a full-time cracker. At this speed it will take 105 days to exhaust the 10-digit PIN pool and while I'm pretty sure the PIN was 10-digits, I would like to prepare for a scenario where I need to try 11-digit combinations as well.
I don't remember enough about the PIN to consider anything else than bruteforcing it.
I did run a test creating an empty, new wallet, setting a PIN for it and managed to recover that PIN using btcrecover.

The wallet in question and the test wallet were generated with: https://github.com/langerhans/dogecoin-wallet-new
which is a fork of: https://github.com/bitcoin-wallet/bitcoin-wallet
bitcoin2john I tried using before I figured out the difference in how the keys are derived during regular wallet encryption and a PIN-lock: https://github.com/openwall/john/blob/bl...in2john.py

1. in general, yes. but you will need a new module
2. I wouldn't put too much hope into a feature request. Some things never get implemented and I haven't seen a sign of life from atom on any public channel in the past months.
3. If you're lucky all you need to do is some copy-paste stuff to combine modes 15700 and 11300. Other than that, there's a development overview here: hashcat plugin development guide, and commits in the git history might be helpful, too.

(02-05-2021, 05:56 PM)undeath Wrote: [ -> ]1. in general, yes. but you will need a new module
2. I wouldn't put too much hope into a feature request. Some things never get implemented and I haven't seen a sign of life from atom on any public channel in the past months.
3. If you're lucky all you need to do is some copy-paste stuff to combine modes 15700 and 11300. Other than that, there's a development overview here: hashcat plugin development guide, and commits in the git history might be helpful, too.

Thanks for responding. Does this entire Scrypt+AES-256-CBC sound to you like something worth delegating to GPU, or is this combination among the ones with no GPU advantage, or even a significant penalty? Should I expect a big difference between the process of implementing the module for CPU compared to making it for GPU or is the usage of either handled by core hashcat?

Depends on the scrypt parameters. Especially combinations with high memory usage are a poor match for GPUs. Development-wise it doesn't make a difference. Modules are written in OpenCL and device-independent.

Thx for post