+- 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: ETH Salt-length exception No hashes loaded (/thread-9619.html)
ETH Salt-length exception No hashes loaded - lokojones - 11-05-2020
I'm trying to crack my wallet, but the hashcat returns the error:
Hash '$ethereum$s*262144*8*1*e2bef244cc8e484xxxxxxx1356cb33f91e0a4887b52ab36b301754fbe11c3eea*056f7a344594249a6d639cfd951c49eb4axxxxxxxxbb4c727fb590328c60c4*e1d1586d0b8f09a2fe73d5db5cd150f559c8237fa4440931b0xxxxxxx687eb1f': Salt-length exception
No hashes loaded.
ciphertext in this scenario has only 62 numbers where most wallets have 64, tested with other wallets, and worked just fine.
"ciphertext":"056f7a344594249a6d639cfd951c49eb4axxxxxxxxbb4c727fb590328c60c4"
also tried with --force function, same return.
hashcat64.exe -m15700 $ethereum$s*262144*8*1*e2bef244cc8e484xxxxxxx1356cb33f91e0a4887b52ab36b301754fbe11c3eea*056f7a344594249a6d639cfd951c49eb4axxxxxxxxbb4c727fb590328c60c4*e1d1586d0b8f09a2fe73d5db5cd150f559c8237fa4440931b0xxxxxxx687eb1f --force passwords1.txt
Any idea how to fix that?
many thanks
RE: ETH Salt-length exception No hashes loaded - philsmd - 11-06-2020
if the problem is the ciphertext length, hashcat would say "Token length exception".
please test the example hash from https://hashcat.net/wiki/example_hashes
maybe it's because you try with a wrong/manipulated salt (not hexadecimal chars).
The problem with shorter ciphertext was already explained a couple of times (but again you wouldn't get a "Salt-length exception" for the ciphertext problem, so you are definitely doing something wrong or you have another problem not related to the ciphertext): https://hashcat.net/forum/thread-7095-post-38010.html#pid38010 ( again a forum thread from you ) https://hashcat.net/forum/thread-9614-post-50647.html#pid50647 and https://github.com/hashcat/hashcat/issues/2017 and https://github.com/ethereum/go-ethereum/pull/3032 etc
RE: ETH Salt-length exception No hashes loaded - lokojones - 11-08-2020
(11-06-2020, 10:04 AM)philsmd Wrote: if the problem is the ciphertext length, hashcat would say "Token length exception".
please test the example hash from https://hashcat.net/wiki/example_hashes
maybe it's because you try with a wrong/manipulated salt (not hexadecimal chars).
The problem with shorter ciphertext was already explained a couple of times (but again you wouldn't get a "Salt-length exception" for the ciphertext problem, so you are definitely doing something wrong or you have another problem not related to the ciphertext): https://hashcat.net/forum/thread-7095-post-38010.html#pid38010 ( again a forum thread from you ) https://hashcat.net/forum/thread-9614-post-50647.html#pid50647 and https://github.com/hashcat/hashcat/issues/2017 and https://github.com/ethereum/go-ethereum/pull/3032 etc
As I said, I tested hashcat with test json and everything just worked. In the end I used john ripper which automatically recognized json format of the same hash. Cracking now
RE: ETH Salt-length exception No hashes loaded - philsmd - 11-08-2020
Are you sure hashcat gives this error: "Salt-length exception" ?
Did you try to use a hash file instead ? Use a file instead of specifying the hash in the command line itself.
The "Salt-length exception" problem shouldn't occur with too short ciphertext lengths.... salt length only has to do with the salt, not with the ciphertext.
RE: ETH Salt-length exception No hashes loaded - lokojones - 11-11-2020
Hi Phil, you are right - the error is different this time, probably I have been playing with different combinations
Hashfile 'testwallet.txt' on line 1 ('$ethereum$s*262144*8*1*e2bef244cc8e484xxxxxxx1356cb33f91e0a4887b52ab36b301754fbe11c3eea*056f7a344594249a6d639cfd951c49eb4axxxxxxxxbb4c727fb590328c60c4*e1d1586d0b8f09a2fe73d5db5cd150f559c8237fa4440931b0xxxxxxx687eb1f): Line-length exception
No hashes loaded.
On another thread, you posted a solution https://hashcat.net/forum/thread-9614.html to apply the patch.
now when I reach this line
base64 -d patch_ethereum_15700_github_2017_base64.diff > patch_ethereum_15700_github_2017.diff
its says: C:\AA\Hashcat\hashcat_15700_mod>base64 -d patch_ethereum_15700_github_2017_base64.diff > patch_ethereum_15700_github_2017.diff
'base64' is not recognized as an internal or external command,
operable program or batch file.
Regards
RE: ETH Salt-length exception No hashes loaded - philsmd - 11-11-2020
whether you have a base64 tool installed / available on the command line depends on your operating system, on macOS and linux we have a "base64" tool to decode base64 text.
for instance, on stackoverflow they suggest to use "certutil" as a workaround to base64 decode a text on windows (cmd), I didn't test it myself because I use linux:
https://stackoverflow.com/questions/16945780/decoding-base64-in-batch/16946681#16946681
Code:
certutil -decode patch_ethereum_15700_github_2017_base64.diff patch_ethereum_15700_github_2017.diff(note: so I suggest using the certuil command with windows cmd instead of the base64 command that can be used in linux or macOS)
I don't understand your other problem with "Line-length exception". This is again a different error message that shouldn't occur with too short ciphertext. What is your command line ? are you sure you use -m 15700 in your command ?
The hash file also only contains the hash no quotes (neither " , nor ' ) within the hash file. Please test to use a hash file with the example hash from https://hashcat.net/wiki/example_hashes . If I change the ciphertext length with the example to a shorter ciphertext I definitely only get a "Token length exception" (nothing else, neither salt-length, nor line-length) with the unpatched version. With the patched version instead everything is working
RE: ETH Salt-length exception No hashes loaded - lokojones - 11-11-2020
(11-11-2020, 03:59 PM)philsmd Wrote: whether you have a base64 tool installed / available on the command line depends on your operating system, on macOS and linux we have a "base64" tool to decode base64 text.
for instance, on stackoverflow they suggest to use "certutil" as a workaround to base64 decode a text on windows (cmd), I didn't test it myself because I use linux:
https://stackoverflow.com/questions/16945780/decoding-base64-in-batch/16946681#16946681
Code:certutil -decode patch_ethereum_15700_github_2017_base64.diff patch_ethereum_15700_github_2017.diff
(note: so I suggest using the certuil command with windows cmd instead of the base64 command that can be used in linux or macOS)
I don't understand your other problem with "Line-length exception". This is again a different error message that shouldn't occur with too short ciphertext. What is your command line ? are you sure you use -m 15700 in your command ?
The hash file also only contains the hash no quotes (neither " , nor ' ) within the hash file. Please test to use a hash file with the example hash from https://hashcat.net/wiki/example_hashes . If I change the ciphertext length with the example to a shorter ciphertext I definitely only get a "Token length exception" (nothing else, neither salt-length, nor line-length) with the unpatched version. With the patched version instead everything is working
Because I did a quick test this morning just to confirm the error I didn't pay attention to the format and run the command:
hashcat64.exe -m15600 wallet.txt passwords.txt - this gives me Line-length exception No hashes loaded.
another one below:
C:\AA\Hashcat>hashcat64.exe -m15700 wallet.txt passwords.txt
hashcat (v4.0.1) starting...
ADL_Overdrive_Caps(): -8
ADL_Overdrive_Caps(): -8
ADL_Overdrive_Caps(): -8
ADL_Overdrive_Caps(): -8
nvmlDeviceGetFanSpeed(): Not Supported
OpenCL Platform #1: Advanced Micro Devices, Inc.
================================================
* Device #1: gfx902, 2259/3170 MB allocatable, 6MCU
OpenCL Platform #2: NVIDIA Corporation
======================================
* Device #2: GeForce MX350, 512/2048 MB allocatable, 5MCU
Hashfile 'biblawallet.txt' on line 1 ($ethereum$s*262144*8*1*e2bef244cc8e484xxxxxxx1356cb33f91e0a4887b52ab36b301754fbe11c3eea*056f7a344594249a6d639cfd951c49eb4axxxxxxxxbb4c727fb590328c60c4*e1d1586d0b8f09a2fe73d5db5cd150f559c8237fa4440931b0xxxxxxx687eb1f): Salt-length exception
No hashes loaded.
Started: Wed Nov 11 18:25:34 2020
Stopped: Wed Nov 11 18:25:36 2020
RE: ETH Salt-length exception No hashes loaded - philsmd - 11-12-2020
that's often the problem with user problem reports: unfortunately you just can't rely at all at the output / results they post. They just make the most strange and noobish mistakes and this is just confusing / distracting a lot.
Again, I tested with a 32 byte salt and a < 32 byte ciphertext and I get a "Token length exception" with the unpatched version.
The hash above seems to have an invalid salt length, it's exactly 42 characters (with the x counted too as replacement chars).
I think this problem is now pebcak and the patch should fix the orginal problem. You are probably testing with your tampered / modified hash again, not with the hash that has an exactly 32 character long salt and a < 32 character long ciphertext.
Again, for me (and I tested now several, several times with different lengths) your problem doesn't make sense unless you are not using the output that comes directly from ethereum2john.py (with file names and colons removed).
You should get a "Token length exception" with the unpatched version and no more error message at all with the patched version. It works for me.... otherwise just make it more clear how long your salt length is, because with those xxx the hashes just look way too tampered (in length) and it doesn't make any sense at all why you are testing with those tampered hashes.
update: what makes it even much worse... you seem to test with hashcat v4.0.1 . Is this a joke !? I mean, I don't want to offend anybody here and you might have some excuse (no valid one of course) to use such an old version (see https://hashcat.net/hashcat for latest version), but at this point I actually get started to think I'm just wasting my time answering here. We need some careful and cautious testers to fix a potential problem or new feature to support shorter ciphertext length... but I'm not going to waste my time here to explain why you shouldn't use a many years old and deprecated hashcat version. gosh damnit (sorry for the rant)