Bitcoin/altcoin wallet PIN recovery

[HetanAwke]

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

[undeath]

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.

[HetanAwke]

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?

[undeath]

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.

[gold333]

Thx for post