01-09-2018, 06:43 PM
your syntax is not correct, --custom-charset2 (or short -2) is used to define a charset. You can't specify a dictionary file with -2, it only accepts a set of different chars at the first line of the file (see https://hashcat.net/wiki/doku.php?id=mas...m_charsets)
I'm also convinced that it is a bad idea to start a brute-force (or use a huge mask for) for ethereum hashes. That will take kind of forever and in general brute-force should be the last thing you should try (the last desperate attempt). In general, there are much better and clever ways to attack a hash.
BTW: I had a short glance at the comments on the mist github: https://github.com/ethereum/mist/issues/2411 and https://github.com/ethereum/mist/issues/3513 because people are also desperately trying to get help on a completely unrelated issue of hashcat: https://github.com/hashcat/hashcat/issue...-356054866 (I was wondering about his wordings "the Ethereum bug", because I didn't understand how one could claim that something is "the Ethereum bug", as if there was only a single bug per software)
First of all, I'm very sorry that you (and others) have to deal with this "problem". My thoughts about it are however two-fold since a couple of people first claimed that the password used for the encryption is not the one they provided (and even insulted the devs) and that they are 100% sure they typed it correctly ... and reported in a new comment later on that they were able to get access to the private key/keystore (with the correct password) again because someone helped them to crack the password (and they found out *they set* a password that was not *exactly* the same password that they were "100% sure" about, for instance the person that thought it way their day of marriage and at the end it was "married"+day etc).
From a technical perspective the only solution for this problem is to make the problem reproducible. If you claims are correct and you are convinced that the software that encrypts the keystore is missbehaving, you just need to be able to (reliably?) reproduce it.... e.g. start a new setup (without any old keys etc) and with an environment that you know (or think) leads to this problem (e.g. a system with operating system x, geth version y, mist version z, operating system language k, n keyboard languages i, j, ... etc). The best approach would be to even capture the whole process starting from how you set up the whole system, ... copy-paste (or type?) the password from a text file etc, ..., and finally how geth fails to unlock the keystore with the exact same password that you used to generate the "account".
What I'm trying to say is, it makes no sense to try to brute-force a password if you are convinced that the software missbehaves (and you didn't proof it yet with a full step-by-step guide or capture of your screen). The strategy on mixing all those different cases into one single github issue is also debatable (my guess is that a couple of those reporters could have just forgotten the password they have set, unfortunately this is what happens millions of times a day for different services. a lot of password recovery mails etc are sent each and every day. I'm not saying that all commenters have forgotten there password, but for sure some of the reporters are not affected by any bug, but only a forgotten password or a misstyped password are causing the problems for some of the reporters)...
I'm not trying to start pointing fingers at who is the culprit and who should have done better. In my humble opinion it just would make much more sense to solve this problem by trying to reproduce it (if, as someone said in the comments within the before mentioned issues, there are houndreds/thousands of affected users, it should statistically be very easy to reproduce it!). Proof it to the devs that given this and that input and this and that environment and this and that password the encryption is done incorrectly etc...
Of course you could say that it is not your duty/task to proof that the software misbehaves... and I agree.... but helping the devs to find out what the problem(s) could be with some reproducible steps and ideally some captures of the whole process would make much more sense than trying the impossible (using very huge masks to "brute-force" the password) or commenting on very unrelated issues or insulting open source developers etc (it wasn't you, but what I read over there was just shocking for me)...
I also understand that some "wallets" that are affected are worth a couple of USD, but again this fact alone doesn't help to solve the problem... it just makes the problem much more problematic (because people get annoyed and greedy to access there account even more).
Other strategies and most importantly some facts might help much more... I would suggest that starting with a reproducible problem (e.g. a keyboard layout -> encoding issue that has to do with electronjs... this is just an example) would help a lot and the problem could be fixed very soon... If the problem was identified the "cracking" or recovering of the password could be doable/possible (or in best case very, very easy and straight forward).
also note: I'm not trying to start a debate over here... I suggest that you and other people affected try to help the devs by making these problem(s) understandable and reproducible and only contribute to the github issue either with the emojis (e.g. if you want to let the devs know that you are affected too) or by posting new *facts* on how to reproduce the problem (with exact version numbers, operating system version/name, languages installed etc).
I'm also convinced that it is a bad idea to start a brute-force (or use a huge mask for) for ethereum hashes. That will take kind of forever and in general brute-force should be the last thing you should try (the last desperate attempt). In general, there are much better and clever ways to attack a hash.
BTW: I had a short glance at the comments on the mist github: https://github.com/ethereum/mist/issues/2411 and https://github.com/ethereum/mist/issues/3513 because people are also desperately trying to get help on a completely unrelated issue of hashcat: https://github.com/hashcat/hashcat/issue...-356054866 (I was wondering about his wordings "the Ethereum bug", because I didn't understand how one could claim that something is "the Ethereum bug", as if there was only a single bug per software)
First of all, I'm very sorry that you (and others) have to deal with this "problem". My thoughts about it are however two-fold since a couple of people first claimed that the password used for the encryption is not the one they provided (and even insulted the devs) and that they are 100% sure they typed it correctly ... and reported in a new comment later on that they were able to get access to the private key/keystore (with the correct password) again because someone helped them to crack the password (and they found out *they set* a password that was not *exactly* the same password that they were "100% sure" about, for instance the person that thought it way their day of marriage and at the end it was "married"+day etc).
From a technical perspective the only solution for this problem is to make the problem reproducible. If you claims are correct and you are convinced that the software that encrypts the keystore is missbehaving, you just need to be able to (reliably?) reproduce it.... e.g. start a new setup (without any old keys etc) and with an environment that you know (or think) leads to this problem (e.g. a system with operating system x, geth version y, mist version z, operating system language k, n keyboard languages i, j, ... etc). The best approach would be to even capture the whole process starting from how you set up the whole system, ... copy-paste (or type?) the password from a text file etc, ..., and finally how geth fails to unlock the keystore with the exact same password that you used to generate the "account".
What I'm trying to say is, it makes no sense to try to brute-force a password if you are convinced that the software missbehaves (and you didn't proof it yet with a full step-by-step guide or capture of your screen). The strategy on mixing all those different cases into one single github issue is also debatable (my guess is that a couple of those reporters could have just forgotten the password they have set, unfortunately this is what happens millions of times a day for different services. a lot of password recovery mails etc are sent each and every day. I'm not saying that all commenters have forgotten there password, but for sure some of the reporters are not affected by any bug, but only a forgotten password or a misstyped password are causing the problems for some of the reporters)...
I'm not trying to start pointing fingers at who is the culprit and who should have done better. In my humble opinion it just would make much more sense to solve this problem by trying to reproduce it (if, as someone said in the comments within the before mentioned issues, there are houndreds/thousands of affected users, it should statistically be very easy to reproduce it!). Proof it to the devs that given this and that input and this and that environment and this and that password the encryption is done incorrectly etc...
Of course you could say that it is not your duty/task to proof that the software misbehaves... and I agree.... but helping the devs to find out what the problem(s) could be with some reproducible steps and ideally some captures of the whole process would make much more sense than trying the impossible (using very huge masks to "brute-force" the password) or commenting on very unrelated issues or insulting open source developers etc (it wasn't you, but what I read over there was just shocking for me)...
I also understand that some "wallets" that are affected are worth a couple of USD, but again this fact alone doesn't help to solve the problem... it just makes the problem much more problematic (because people get annoyed and greedy to access there account even more).
Other strategies and most importantly some facts might help much more... I would suggest that starting with a reproducible problem (e.g. a keyboard layout -> encoding issue that has to do with electronjs... this is just an example) would help a lot and the problem could be fixed very soon... If the problem was identified the "cracking" or recovering of the password could be doable/possible (or in best case very, very easy and straight forward).
also note: I'm not trying to start a debate over here... I suggest that you and other people affected try to help the devs by making these problem(s) understandable and reproducible and only contribute to the github issue either with the emojis (e.g. if you want to let the devs know that you are affected too) or by posting new *facts* on how to reproduce the problem (with exact version numbers, operating system version/name, languages installed etc).