Mist Wallet 08.10 bruteforce

[jonask]

Hi everyone,

after half a day researching this issue, I'm still having trouble figuring out if there have been any advancements in the past couple of years.

Personally I did some ethereum mining in 2016, found out that I couldn't make any transactions with my mining account in 2017, even went as far as sending my private key to a wallet recovery service (desperate, I know), and basically nothing has changed other than the price.

Unfortunately I didn't remember *exactly* what I was doing in 2016.
All I know:
- I was running Ethereum Wallet 0.5.1 on Ubuntu (according to the files that I still have)
- I still have the supposed password in my password manager, and the timestamps of the account as well as the password match.
- I didn't copy the password as far as I remember, but entered it by hand. But that was 2016, and memory can be tricky.
- The mining account was not my main one in that software. The main one works though.
- The password in my password manager does only use alphanumeric characters.

I read through issue 3513, and as far as I can see the activity has fizzled out over time, and if I see correctly, mist has been gone since 2019. There's still no consensus on whether the bug even exists because it has never been properly reproduced. Other bugs have been found, but nothing that could be definitely connected to the issue.

Question 1 - Is there some active community of people working on this, or is this thread now it? I'm a bit surprised - everyone with this problem surely would donate 20% of their lost ETH to someone who could find the bug and a way to recover the passwords and by now that would probably turn that person into an instant millionaire. Although it's a bit like solo mining - you're not guaranteed that your search will result in finding the solution. In any case, has everyone just given up by now or are we still talking?

Question 2 - I'm new to hashcat. I have an RTX 2080, but I'm trying to figure out the risk/reward on brute-forcing this. How likely do you think there's some typo that the wallet recovery people missed? Did anyone actually recover their password with hashcat and find out it was garbled in a way that was unlikely to stem from typing it wrong?

[philsmd]

answer 1: I guess that many users already tried to reproduce problems with certain specific versions of mist+geth, but realized that when installing the software versions freshly (even on a new PC etc), they didn't see any wrong or strange behaviour and everything was working as expected. (no automatic account creation, no locked up accounts, password was working etc etc etc).
So I guess many affected users tried to reproduce a bug (I don't have any exact number or stats, you could even ask the mist team, they even collected some "affected users" anonymized data on google forms back then), but always failed to make any clear conclusion about what could have gone wrong or at least weren't able to proof that there is/was some obvious bug. Could just be many users that don't remember the password (and some even don't remember that they had to insert a password ! ) . Again, all this can also turn out to be a wrong conclusion or a false statement, but only when a software bug was detected and the facts about the bug are sorted out.

answer 2: you stated above that you gave the private key to somebody. My guess/hope is that you only gave the encrypted keystore to a professional and trusted wallet recovery service... So please make sure first that your ethereum address still has some funds in it etc... otherwise all your work you put in to unlock the account is wasted if there are no more funds.
We have already stated a couple of times here, that it depends a lot on the wallet version and hash type, whether the GPU cracking should be done or if it would be better to crack the hashes with CPU only (scrypt based algorithms are better suited for CPU cracking, no GPU needed, because the scrypt algorithm itself is GPU-resistent). Just try to convince yourself by testing the speeds of different device/hardware types with --opencl-device-types (short -D, uppercase D).

I can't really remember if there were users that were able to unlock the account after some rule-based attacks (or in general mangled passwords) against an scrypt-based ethereum wallet, but I'm pretty sure these cases exist (not everybody posts their success story after a successful cracking attack). In general, rule-based attacks are very efficient and crack a lot of hashes... but of course this hash algorithm is very heavy compared to other (non-slow i.e. *fast*) hash types that hashcat supports and therefore it's much more difficult to run a huge amount of rules against a large dictionary file.
That said, the rule-based attack (or any non-brute-force attack or any non-mask attack), as you probably already guessed, could still be much more efficient and with a much better success rate than other attacks. This of course depends on the randomness of the password itself, but in general even if for some fast hash types mask attacks are much faster, the efficiency and success rate of rule-based attacks (or combinator, hybrid attacks etc) is often much better and the only clever approach.

Yeah, think about the possible password candidates and patterns, create a middle to huge password list of several megabytes of candidates.... try to learn rule-based attacks (and other non-brute-force attack, https://hashcat.net/wiki/#core_attack_modes) and create your own specific rule file and run your CPU-based rig against the scrypt-based ethereum hash. Good luck

[fb2039]

answer 1: I guess that many users already tried to reproduce problems with certain specific versions of mist+geth, but realized that when installing the software versions freshly (even on a new PC etc), they didn't see any wrong or strange behaviour and everything was working as expected. (no automatic account creation, no locked up accounts, password was working etc etc etc).
So I guess many affected users tried to reproduce a bug (I don't have any exact number or stats, you could even ask the mist team, they even collected some "affected users" anonymized data on google forms back then), but always failed to make any clear conclusion about what could have gone wrong or at least weren't able to proof that there is/was some obvious bug. Could just be many users that don't remember the password (and some even don't remember that they had to insert a password ! ) . Again, all this can also turn out to be a wrong conclusion or a false statement, but only when a software bug was detected and the facts about the bug are sorted out.

answer 2: you stated above that you gave the private key to somebody. My guess/hope is that you only gave the encrypted keystore to a professional and trusted wallet recovery service... So please make sure first that your ethereum address still has some funds in it etc... otherwise all your work you put in to unlock the account is wasted if there are no more funds.
We have already stated a couple of times here, that it depends a lot on the wallet version and hash type, whether the GPU cracking should be done or if it would be better to crack the hashes with CPU only (scrypt based algorithms are better suited for CPU cracking, no GPU needed, because the scrypt algorithm itself is GPU-resistent). Just try to convince yourself by testing the speeds of different device/hardware types with --opencl-device-types (short -D, uppercase D).
I can't really remember if there was an user that has able to unlock the account after some rule-based attacks (or in general mangled passwords) against an scrypt-based ethereum wallet, but I'm pretty sure these cases exist (not everybody posts their success story after a successful cracking attack). In general, rule-based attacks are very efficient and crack a lot of hashes... but of course this hash algorithm is very heavy compared to other fast hash types that hashcat supports and therefore it's much more difficult to run a huge amount of rules against a large dictionary file.
That said, the rule-based attack (or any non-brute-force attack or any non-mask attack), as you probably already guessed, could still be much more efficient and with a much better success rate than other attacks. This of course depends on the randomness of the password itself, but in general even if for some fast hash types mask attacks are much faster, the efficiency and success rate of rule-based attacks (or combinator, hybrid attacks etc) is often much better and the only clever approach.

Yeah, think about the possible password candidates and patterns, create a middle to huge password list of several megabytes of candidates.... try to learn rule-based attacks (and other non-brute-force attack, https://hashcat.net/wiki/#core_attack_modes) and create your own specific rule file and run your CPU-based rig against the scrypt-based ethereum hash. Good luck

I have investigated this issue further and I am 100 % sure that i did not create an account in the wallet. Also in the topic there are lots of users reporting the same problem exactly in the month juni / july 2017.
I found old pictures in my database where i have taken pictures from the wallet , from the site where i bought ethereums , everything !! No password or so .. 

What i have also discovered is that my wallet was active also in 2019 and on etherscan i found that tokens were sent to this address ? Could it be that i was on the solo network when sendig funds to this address ? I didnt want to “mine” or something , and i have never opened my wallet after transferring the funds.. how is it then possible that transactions were made for this specific address ?

[philsmd]

I'm not a cryptocurrency expert unfortunately... but receiving some random very small amounts of eth and btc is/was a known strategy to try to deanonymize users, as far as I remember. A so-called known deanonymization attack.
What amounts are we talking about here ? only very few dollars worth of ether back at that specific time of the transaction ?

It could be anything, in general... maybe even a friend of you that you gave your address to play around with or some tests that you performed yourself or a withdrawal from an cryptocurrency exchange/platform/website etc.

The other problem is, that several user situations are quite different ... for instance you are stating that you had a wallet on a website... I guess it also depends on whether you "imported" this wallet or if you just sent your funds from that website wallet directly to your very independent wallet created with Mist etc etc etc

I think you shouldn't worry about small incoming transactions... it's much more important that there are no outgoing transactions (that would be horrible because it would mean that somebody has unlocked your account somehow and has access to the private key, the decrypted/unlocked keystore file). Again, this would be only true if you can see some outgoing transactions, the other way around i.e. receiving some funds could be done by anybody... and you might not even be "targetted', it could just be some folks trying to sent some small amount to some random and old accounts and try to see if the users somehow are still able to unlock their account and "use" this new funds and this old account etc...

again, I'm not a cryptocurrency expert and not sure if this attempt for a de-anonymization "attack" is even possible or meaningful within the ethereum network.... I just remember that some similar attempts of deanonymization were tried back then and this type of dusting attack was actually quite an obvious and wide-spread attempt and some users only made some transactions after they received some (even very very small) funds because of this trigger (a new incoming transaction).

[jonask]

answer 1: I guess that many users already tried to reproduce problems with certain specific versions of mist+geth, but realized that when installing the software versions freshly (even on a new PC etc), they didn't see any wrong or strange behaviour and everything was working as expected. (no automatic account creation, no locked up accounts, password was working etc etc etc).
So I guess many affected users tried to reproduce a bug (I don't have any exact number or stats, you could even ask the mist team, they even collected some "affected users" anonymized data on google forms back then), but always failed to make any clear conclusion about what could have gone wrong or at least weren't able to proof that there is/was some obvious bug. Could just be many users that don't remember the password (and some even don't remember that they had to insert a password ! ) . Again, all this can also turn out to be a wrong conclusion or a false statement, but only when a software bug was detected and the facts about the bug are sorted out.

answer 2: you stated above that you gave the private key to somebody. My guess/hope is that you only gave the encrypted keystore to a professional and trusted wallet recovery service... So please make sure first that your ethereum address still has some funds in it etc... otherwise all your work you put in to unlock the account is wasted if there are no more funds.
We have already stated a couple of times here, that it depends a lot on the wallet version and hash type, whether the GPU cracking should be done or if it would be better to crack the hashes with CPU only (scrypt based algorithms are better suited for CPU cracking, no GPU needed, because the scrypt algorithm itself is GPU-resistent). Just try to convince yourself by testing the speeds of different device/hardware types with --opencl-device-types (short -D, uppercase D).

I can't really remember if there were users that were able to unlock the account after some rule-based attacks (or in general mangled passwords) against an scrypt-based ethereum wallet, but I'm pretty sure these cases exist (not everybody posts their success story after a successful cracking attack). In general, rule-based attacks are very efficient and crack a lot of hashes... but of course this hash algorithm is very heavy compared to other (non-slow i.e. *fast*) hash types that hashcat supports and therefore it's much more difficult to run a huge amount of rules against a large dictionary file.
That said, the rule-based attack (or any non-brute-force attack or any non-mask attack), as you probably already guessed, could still be much more efficient and with a much better success rate than other attacks. This of course depends on the randomness of the password itself, but in general even if for some fast hash types mask attacks are much faster, the efficiency and success rate of rule-based attacks (or combinator, hybrid attacks etc) is often much better and the only clever approach.

Yeah, think about the possible password candidates and patterns, create a middle to huge password list of several megabytes of candidates.... try to learn rule-based attacks (and other non-brute-force attack, https://hashcat.net/wiki/#core_attack_modes) and create your own specific rule file and run your CPU-based rig against the scrypt-based ethereum hash. Good luck

I think what's missing is some sort of wiki dedicated to the issue. As it stands, you have to wade through many pages of heated arguments to extract some information. Would anyone be interested in contributing to something like that? Gather evidence, contact original developers, describe various theories and their pros/cons, maybe even set up some bounty scheme...

The service has both the key and the password, and the funds are still there. The password is 20 chars random upper/lowercase and digits and I think I didn't provide them with other passwords, so I think they gave up rather quickly. Their website still exists and looking around they seem to have a good reputation.

I think it was scrypt, so maybe they just don't have a lot of CPU resources, and cases where users provide a lot of password fragments + the wallet is GPU-friendly are probably more profitable. Which I'm hoping, because that means I can take your advice and then try some attacks and run it for longer.

[jonask]

I have investigated this issue further and I am 100 % sure that i did not create an account in the wallet. Also in the topic there are lots of users reporting the same problem exactly in the month juni / july 2017.
I found old pictures in my database where i have taken pictures from the wallet , from the site where i bought ethereums , everything !! No password or so ..

May/June of 2017 was the first seriously big rally for Ethereum, so I'm not surprised. I was one of those people - I made the account a year before, and the end of May looked like a good time to sell, which is how I found out that my biggest account didn't work. The most recent version at the time was 0.8.10.

[fb2039]

I have investigated this issue further and I am 100 % sure that i did not create an account in the wallet. Also in the topic there are lots of users reporting the same problem exactly in the month juni / july 2017.
I found old pictures in my database where i have taken pictures from the wallet , from the site where i bought ethereums , everything !! No password or so ..

May/June of 2017 was the first seriously big rally for Ethereum, so I'm not surprised. I was one of those people - I made the account a year before, and the end of May looked like a good time to sell, which is how I found out that my biggest account didn't work. The most recent version at the time was 0.8.10.

Exactly my wallet was also version 08.10 and i foumd more people reporting problems with this specific version , whats the name of that wallet recovery company ? I am interested to give it a try. Because i usually do not make passwords longer than 13-14 characters

[JuanPelota]

Because i usually do not make passwords longer than 13-14 characters

Why don’t you try to build password candidates wordlist and run it through hashcat and then try some variations around it with rules ? It’s not that complicated. I am completely new in this world and even if I didn’t get (yet ) my password of my Ethereum wallet back I already have tested nearly a million of candidates on my very old cpu (4 H/s)

As rough guidelines I always run hashcat —stdout and send the result to a txt file before actually running hashcat.
Then I run hashcat
Before running a new session I run the utility rli to check duplicates with the already exhausted candidates to save time.

Even if I don’t succeed I will know I have tried hard before giving up.

[philsmd]

I have investigated this issue further and I am 100 % sure that i did not create an account in the wallet.

My question to you @fb2039 is that I'm not understanding why some people say they are 100% sure. In my opinion, we can only be 100% sure about a problem when you really see the software starting on a fresh installation with an already created account which is locked (and doesn't unlock with the empty password).

Did any of you (affected people) try to reproduce this problem of an already available account on first startup (of course any old keystore files from older installations must be moved/backed up on another disk before the fresh installation is tested, or just use a new/different PC).

---

JuanPelota : I really like your willingness to learn about these advanced attacks on this rather slow (scrypt) algorithm and how you are dealing with this "problem". I wish you (and also to all others struggling with any sort of a similar problem) best of luck to unlock your keystore file

[jimby]

Maybe you can make some further tests and mention your results here or on the mist github issue. good luck

(snip)


But with my 2017 wallet, it’s very complicated since I am the kind of person who sets very long passwords. Somewhat like passphrase. So if I have done a typo somewhere it might be horrible to find since in my estimations the password length range is min 27 max 65 😱. 



What do you think are the best strategies with long passwords like this ? My next step is to try to use Prince to combine words I use in my password/pass phrase. The main issue is that I sometimes interspersed numbers or special characters between words.

Thanks

Have a look at comboleetor.pl.   It may be able to help you create your password list.

https://www.jimby.name/techbits/recent/comboleetor/

See the training pdf at https://www.jimby.name/techbits/recent/c...tation.pdf  for more info.

Enjoy!