+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: 9-10 char slow-hash brute-forcing (wallet.dat) (/thread-11523.html)
Pages:
1
2
9-10 char slow-hash brute-forcing (wallet.dat) - Nir Yung - 07-26-2023
Greetings!
A week ago I recovered my old wallet.dat file from 2014 which is not empty.
I've decided to try to recover the passphrase, but the ones that could be it does not work.
The thing is this pass is semi-random. Meaning it was generated by hand. No words etc.
Mathematically speaking it makes no sense to say that this idea seems at least naive.
If we're talking 9 chars it's 10^16 variants and 10^18 when we talk about 10 chars.
I have access to 3x4090 RTX rig. So, looking at the benchmarks I assume that my best case is 150 kH/s with 130k iterations. (Correct me if I'm wrong). Which is a drop in a bucket when we talk about 11300 mode with 9-10 chars.
Therefore there're several hints that may help lower this number:
1. Phrase is made of keys a-z, A-Z, 0-9
2. There are 3-5 numbers in Phrase
3. No neighbouring keys in a keyboard row, this means "s" can not be near "d" or "a" etc
4. No more then 4 uppercase letters
5. The phrase is 9-10 characters long
Example goes like this: h4Le8y0wR9
The supposed password is sort of a mutation from this one.
I've tried to compose the mask but it does not seem to be the optimal solution
Code:
^[^qwertyuiopasdfghjklzxcvbnm]*(?:[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z]|[^a-z])*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[^A-Z]*[A-Z]?[^A-Z]*[A-Z]?[^A-Z]*[A-Z]?[^A-Z]*$I would greatly appreciate help, if maybe someone has done something like this.
Therefore I have couple of questions:
1. Is it even reasonable to try to make such a mask? Would it optimise possible output?
2. Is there any technic of mutating the password? Like changing several letters etc?
I've spent enough time researching this task and seeng the math I'm tempted to abandon it, but I want to get response from the community before I do it.
Thank you in advance!
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Snoopy - 07-26-2023
double post see below
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Snoopy - 07-26-2023
first of all, forget the idea of one mask, you cannot tell hashcat all the things you mentioned in one mask (a mask is not a regex)
next thing is you can only combine 4 custom charsets (when you try to reflect your rule with your not near keys) you could take a look at https://github.com/hashcat/kwprocessor maybe it is possbile to use this for reflecting non near keys
never the less, lets do some math here, i used your example, for generating a plain, not modified mask like this
mask = ?l?d?u?l?d?l?d?l?u?d
combinations = 3.089.157.760.000, given 130kh/s -> 275 days ETA
trying to reflect non near keys very simple like skipping one vertical line (german keyboardlayyout) so: qay edc tgb ujm
or just imagine splitting the 26 chars 50/50 lets say ?l ?u are not 26 each but just 13 each, this will result in
combinations = 48.268.090.000 -> ETA 4.3 days
but this is just one mask, you have to generate all possbile masks for this kind of approach and the 13 chars instead of 26 is thought very simple
lets take a look at char "q", chars near are "was" so possible chars are still 22 and how do you specify "near" when taking a closer look at your keyboard
d -> ersfxc is w near or not?
f -> ertdgcv is e near or not?
mutating your given pass could be done with rules, but same problem, you will have to gerate huge amounts of rules to reflect all your mentioned possiblities
so yeah, my opinion: forget this and enjoy your life
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Nir Yung - 07-26-2023
(07-26-2023, 04:19 PM)Snoopy Wrote: lets take a look at char "q", chars near are "was" so possible chars are still 22 and how do you specify "near" when taking a closer look at your keyboard
d -> ersfxc is w near or not?
f -> ertdgcv is e near or not?
When I say near I mean "near in a row", so for "s", "w" and "x" are not considered to be "near", while "a" and "d" are
Sure, but at this point it's more about how am I able to stretch the math in such case, we're talking 10^8 difference and I'd just like to see creative solutions for such a task.
I'm adequate to consider numbers etc, but it seems to me there's always a "good enough to try" solution. That's what I'm looking for
The problem with pregenerated wordlist is time and memory, so I mainly look for runtime options
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - lapsikmees - 07-27-2023
There is dedicated password recovery for wallets. Look up btc recover: https://btcrecover.readthedocs.io/en/latest/
I hope you find all the help you need there.
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - marc1n - 07-27-2023
(07-27-2023, 07:44 AM)aikiuslik Wrote: There is dedicated password recovery for wallets. Look up btc recover: https://btcrecover.readthedocs.io/en/latest/Hashcat is much better than this outdated program. The problem is the complexity of the password and its length, not the password cracking program.
I hope you find all the help you need there.
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Nir Yung - 07-27-2023
(07-27-2023, 07:44 AM)aikiuslik Wrote: There is dedicated password recovery for wallets. Look up btc recover: https://btcrecover.readthedocs.io/en/latest/
I hope you find all the help you need there.
The program is worth taking a look, but it lacks such tools as masking and rules. Therefore I found a service that provides GPUs for good price, in case I need scale.
But I think I stick with hashcat. I have more trust in it and its community.
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Cmd2002 - 07-28-2023
(07-26-2023, 01:46 PM)Nir Yung Wrote: Greetings!
A week ago I recovered my old wallet.dat file from 2014 which is not empty.
I've decided to try to recover the passphrase, but the ones that could be it does not work.
The thing is this pass is semi-random. Meaning it was generated by hand. No words etc.
Mathematically speaking it makes no sense to say that this idea seems at least naive.
If we're talking 9 chars it's 10^16 variants and 10^18 when we talk about 10 chars.
I have access to 3x4090 RTX rig. So, looking at the benchmarks I assume that my best case is 150 kH/s with 130k iterations. (Correct me if I'm wrong). Which is a drop in a bucket when we talk about 11300 mode with 9-10 chars.
Therefore there're several hints that may help lower this number:
1. Phrase is made of keys a-z, A-Z, 0-9
2. There are 3-5 numbers in Phrase
3. No neighbouring keys in a keyboard row, this means "s" can not be near "d" or "a" etc
4. No more then 4 uppercase letters
5. The phrase is 9-10 characters long
Example goes like this: h4Le8y0wR9
The supposed password is sort of a mutation from this one.
I've tried to compose the mask but it does not seem to be the optimal solution
Code:^[^qwertyuiopasdfghjklzxcvbnm]*(?:[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z][^qwertyuiop]*[a-z]|[^a-z])*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[0-9][^0-9]*[^A-Z]*[A-Z]?[^A-Z]*[A-Z]?[^A-Z]*[A-Z]?[^A-Z]*$
I would greatly appreciate help, if maybe someone has done something like this.
Therefore I have couple of questions:
1. Is it even reasonable to try to make such a mask? Would it optimise possible output?
2. Is there any technic of mutating the password? Like changing several letters etc?
I've spent enough time researching this task and seeng the math I'm tempted to abandon it, but I want to get response from the community before I do it.
Thank you in advance!
One thing I found when I was learning about masks is that itll try like xxxxxxxx1 xxxxxxxxx2 xxxxxxxx3... etc, So to stop a char repeating or set a max occurance of it to like 2/3 times youll have to use maskprocessor and | pipe the output to hashcat. This could help save you alot of time or get your target keyspace down
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Nir Yung - 07-29-2023
Hello everyone!
Quick update. I wrote a program for exactly what suggested Cmd2002
Please, take a look:
https://github.com/Number16BusShelter/BitBrutal
Soon I'm going to try it soon. I hope that there'll be no issue with 9-10 characters to test with hashcat. Also, please, suggest me the best way to work with big (32GB) wordlists.
RE: 9-10 char slow-hash brute-forcing (wallet.dat) - Cmd2002 - 07-30-2023
(07-29-2023, 03:52 PM)Nir Yung Wrote: Hello everyone!
Quick update. I wrote a program for exactly what suggested Cmd2002
Please, take a look:
https://github.com/Number16BusShelter/BitBrutal
Soon I'm going to try it soon. I hope that there'll be no issue with 9-10 characters to test with hashcat. Also, please, suggest me the best way to work with big (32GB) wordlists.
Pretty awesome work that Nir! Ill check it out more after football, good job