Mask Attack with a "blank" value?

[solace]

Hi all, trying to get this to happen:

RIGHT SIDE:

Password?d?s

Password
Password1
Password2
...
Password!
Password@
...
Password1!
...
Password!1

In addition, how can I repeat the same process on the left? Resulting in

11Password1!
1@Password
Password!1
1Password1

Any help is insanely appreciated, this is the last step I need in my crackerr

[philsmd]

Well, the best strategy depends on a couple of things like:
1. is it a slow or fast hashing algorithm (which hash type is used, -m ?) ?
2. how large is the number of constant strings. Is there only one candidate "Password" string or several? how many? dozens, hundreds, thousands, millions?
3. how many characters need to be tested on the left and how many characters need to be tested on the right ?
... etc. etc. etc

There are also a couple of strategies:
1. use -a 0 and a couple of append/prepend rules (see https://hashcat.net/wiki/doku.php?id=rule_based_attack)
2. use a .hcmask file if the number of constant strings is small and the mask is large enough such that full speed is possible (see https://hashcat.net/wiki/doku.php?id=mas...mask_files and https://hashcat.net/wiki/doku.php?id=fre..._mask_file)
3. prepare a (in best case: mid-sized, not too large, not too small) dictionary for the left side and use attack mode -a 6, preparation can be done with maskprocessor (mp64) or hashcat's --stdout mode
4. prepare a (in best case: mid-sized, not too large, not too small) dictionary for the right side and use attack mode -a 7, preparation can be done with maskprocessor (mp64) or hashcat's --stdout mode
5. prepare a (in best case: mid-sized, not too large, not too small) dictionary and run it with -a 0 (with or without rules... but dict shouldn't be too large... forget about generating a couple of GB dict)

[solace]

Thanks for the reply, Hascat is still pretty overwhelming. Trying to crack my Ethereum pre-sale wallet, which is looking hopeless. 250 Eth, $300k USD. Anyone want a bounty?

hashcat32.exe -m 16300 -a 0 -w 2 -D 2 hash.txt dict.txt -r SUPER_RULES.txt

I'm trying this so far, with a couple of the example ruleset. Here's my attempt at a password mask:

hashcat32.exe -m 16300 -a 3 -w 2 -D 2 hash.txt -1 0123456789!@#$%^&*()_+-= -2 passwords.txt ?1?1?1?1-2?1?1?1?1

I've now resorted to building a password list with EthCracker, file is about 1 gig and takes about an hour to process. I buggered this good. FML.

[philsmd]

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).

[solace]

Thank you for such a well thought out and detailed reply! With respect, I appreciate your assistance.

You are right that we should acknowledge the users who have stated it's broken, only to find their password. Clearly, they were wrong.

I simply have no choice now but to reproduce the bug. I had been thinking that was the next step, and your opinion solidifies it. Why brute force something that's bugged? It makes sense. If we can reproduce it, we will know how to make a n algorithm to crack it correct.

I'm going to copy and paste your post and reference it over on the GitHub issue, I think many users and devs will appreciate your neutral, calm and deep understanding of this particular circumstance.

[solace]

Ah I figured out what to do, for anyone in the future looking at this.

Here's my ruleset to run with 'blanks'

0123456789!@#$%^&*()_+-=[]{};':",Password?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1?1

So as you can see, it adds more and more to the end, it seems to run quite nicely on Hashcat. Cheers,

[solace]

Hey @Philsmd thanks for your input on this issue.

Some users have reported a character such as ^ on a Mac gets shifted to ˆ which I guess is different. How would one put this in a characterset as my previous Mask Attack?

Is there a resource where I can find all the similar characters? ˆ^/\ etc?

Thanks again for your input, I think you're a real value to us poor souls dealing with this password issue in Ethereum.

[oldmate89]

Ah I figured out what to do, for anyone in the future looking at this.

Here's my ruleset to run with 'blanks'

0123456789!@#$%^&*()_+-=[]{};':",Password?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1?1

So as you can see, it adds more and more to the end, it seems to run quite nicely on Hashcat. Cheers,

Thanks Solace 

That's really helpful as I am attempting to run Hashcat on my presale wallet aswell. I am still learning Hashcat and reading the FAQ and wiki, however it would be helpful if you could provide clarification: 
1) Does the above ruleset include all characters (i.e. letters, numbers and special characters)?
2) Do I copy and paste the above into a .rule file, replace the known elements of password where you have "Password" and run a mask attack with the ruleset? 
3) That will subsequent test against more and more iterations to the right side of "Password" (e.g. Password% etc etc)

[solace]

Hey Oldmate, that SUCKS you're stuck with me But at least we have each other.

Hashcat is complex, but in order to run this, it's pretty easy.

1) Make sure you've got your Hashed wallet file

2) Run this command: hashcat32.exe -m 16300 -a 3 -w 2 -D 2 hash.txt ETHEREUM.mask

3) ETHEREUM.mask is as I've posted above:

0123456789!@#$%^&*()_+-=[]{};':",Password?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1
0123456789!@#$%^&*()_+-=[]{};':",Password?1?1?1?1

0123456789!@#$%^&*()_+-=[]{};':",?1Password
0123456789!@#$%^&*()_+-=[]{};':",?1Password?1
0123456789!@#$%^&*()_+-=[]{};':",?1?1Password?1?1
0123456789!@#$%^&*()_+-=[]{};':",?1?1?1Password?1?1?1
0123456789!@#$%^&*()_+-=[]{};':",?1?1?1?1Password?1?1?1?1

As you can see, this adds a lot before and after. Good luck

[oldmate89]

Thanks Solace - thats really helpful. I have it running now!