Hello and thank you to any prospective helpers. Apologies if this is obvious, but I may have missed something in the mask documentation or have been looking in the wrong place.
I have been unable to decrypt an ethereum presale wallet despite thinking I used a familiar password ending in a special character.
I intend to attack via a different path.
I have 59 of 64 hex bytes that I think are a backup of the seed made during purchase. Probably in the correct order or in one of a small number of permutations of order (split across multiple post-it notes as an emergency backup.)
I suspect the additional bytes belong on the end but I would like to try all possibilities.
I am trying to crack a Keccak-256 hash of this hex(number) + 0x02 (hexadecimal two.)
Is there are an efficient way to crack this?
Thanks again for reading
The 5 missing bytes will still be 256 * 256 * 256 * 256 * 256 = 256 ^ 5 = 1099511627776 combinations.
That's a quite huge keyspace, even if the hashing algortihm (keccak) is quite fast.
of course with a huge prefix (the very long 59 "salt" because of the 59 known bytes) it would be better to have a more dedicated hash mode, like salted keccak e.g. by speficing the hash like
(i.e. salt:[59bytesPrefix])
(btw: salted keccak is not implemented yet )
The mask attack for -m 5000 would be -a 3 --hex-charset keccak_hash_file.txt [59bytesPrefix]?b?b?b?b?b02
of course the [59bytesPrefix] must be replaced by the known bytes (in hexadecimal)
but again, this might be infeasible (depending on your setup etc).
I think it would be still more clever to try to find the correct password (much less tries, possibilities ? no real bruteforce, but word list + rule attack ?).
In all cases, I would suggest that you generate some example hashes with the same version that you generated the old seed and try to crack them just to make sure that you are doing everything right and not wasting time (i.e. try examples of cracking with 16300 and also with -m 5000 with hashes/seeds generated by the presale wallet/seed generator etc).
BTW: I know that the pre-sale web page generated a much longer seed, because there where complains/rumours that the mouse movements for the entropy + timing etc was not that good of a random number/byte generator. The website used to generate up to 608 byte seeds as far as I know... but if you got your eth earlier you might have a shorter seed. I would double-check this too
Keccak is just a last step. Use -m 16300 to crack Ethreum Presale wallets (extract with ethereum2john.py).
phil: Sorry. I was being silly. I meant hex characters between 0 and F not full bytes, so (2^4)^5 =1048576. These could be at any one of C(64, 5) = 7624512, so a space of approximately 8*10^12.
I am travelling for July and August and am willing to devote my deep learning machine with 1080Ti to the task, which should be able to pull ~1.5*10^6 checks/second, which brings the number of seconds to less than I've spent trying every every possible permutation of errors on the password I could have sworn I used.
The 0X02 as part of the ethereum presale is numerically added to the seed prior to hashing.
Ideally, I'd like to be able to feed in 0123ABC[0-F]87A[0-F]... etc. for every possible insertion point.
atom: Thank you, but I am trying to crack the seed of the bkp component, having had no luck with encseed. I see a perl script here:
https://github.com/hashcat/hashcat/issues/1279 which appears to process the output of ethreum2john.py? I could modify said perl script to accept a candidate seed, add 0x02 to it and compare the KeccakSHA3 of the result, but wasn't certain sure whether it was possible to use custom rules like that.
As you can see, I'm fairly unfamiliar with the hashcating game. Thank you both for the info so far.
hashcat uses ?H for 0123456789ABCDEF
therefore you could specify the mask as -a 3 --hex-charset [someting]?H[somethingElse]?H?H02
the main problem now is that the hash mode -m 5000 only supports a password length of 55 bytes.
Again, I need to emphasize again that I wouldn't suggest running anything before you generated some test hashes and are able to crack those... but the password limit for -m 5000 (because only the optimized kernels exist) is a bummer, because it doesn't allow masks that are so long.
thinking about it, if you are willing to run this on CPU because the keyspace is "small enough" (well, it depends how certain you are about the order of bytes and where the bytes are missing) you could just try to modify the perl script or implement it in ANSI C or something like this
On the other hand, we already have the extended keccak code in -m 16300 (verification step of the decrypted seed), therefore it would be somehow managable within a few minutes/hours to add the OpenCL/m05000_a3-pure.cl kernel and also make the host code modifications.
(06-29-2018, 05:46 PM)philsmd Wrote: [ -> ]hashcat uses ?H for 0123456789ABCDEF
...
the main problem now is that the hash mode -m 5000 only supports a password length of 55 bytes.
...
This must be where I'm running into problems. I was hoping that, since the generated password to try would be only 32 bytes, the mask mode would work it out but that does not appear to be the case.
I'll mess around with with more when I get home this evening. CPU mode is definitely not an option! The GPU can exhaust the search space in a useful time frame but I'd be an old man ready to retire before I got my coins if relying on my CPU!
Thank you both very much for your input. I'll report if I make an progress. I guess I should learn some OpenCL anyway.
IIRC you can't separate the Keccak from the AES step in Presale format as it requires you to decrypt the full ciphertext and hash that with keccak to verify.
the ciphertext gets decrypted into the raw seed if you have the correct password/AES key/
see my perl code
https://github.com/hashcat/hashcat/issue...-351716733
Code:
my $hash = keccak_256 ($seed. "\x02");
the first 16 bytes of this "hash" are used for the so-called bkp.
As already mentioned, I'm just not sure why the seed for a presale wallet is just 64 bytes long and why it is known at all (because as far as I know the website, later on, generated a much longer seed because of randomness security weakness ... and the web page as far as I know didn't really offer to download the raw seed, only the json file).
As far as I know the seed is also hashed in hexadecimal, i.e. the seed isn't used "raw", but is in hex! (that is why I suggested a known charset attack/check in other presale threads whenever the user doesn't want to share the whole encseed)
The seed is 64 characters long? Now i'm confused. Ethereum Private Keys are 64 characters long, hex, seeds are typically the multi word phrases used to derive the private key. It's my understanding that Presale wallets hold private keys, not seeds. Maybe there is some terminology being confused here?
https://theethereum.wiki/w/index.php/Acc...rivate_Key
An ethpresale tool on github says this:
https://github.com/kholia/ethpresale/blo...ethtool.py
Quote:if not seed:
seed = random_key().decode('hex') # uses pybitcointools' 3-source random generator
encseed = aes.encryptData(pbkdf2(pw),seed)
ethpriv = sha3(seed)
btcpriv = sha3(seed + '\x01')
ethaddr = sha3(privtopub(ethpriv)[1:])[12:].encode('hex')
btcaddr = privtoaddr(btcpriv)
bkp = sha3(seed + '\x02').encode('hex')
return {
"encseed": encseed.encode('hex'),
"bkp": bkp,
"ethaddr": ethaddr,
"btcaddr": btcaddr,
"email": email
}
def genwallet(seed,pw,email):
The whole thing is crazy?