Token length exception hashcat что это
No hashes loader and token length exception for wallet.dat #2489
Comments
Qalander commented Jul 11, 2020 •
So, I am a new bitcoin hashsing issue, the code i got after running bitcoin2john is but it is less in one decimal because the other hash got from different wallet has one digit longer and that one is loading in hashcat 6.0.0 but not this one.
I get error message that no hashes loader and token length exception, should I use SHA256 instead of bitcoin wallet here. while brut forcing, please help.
$bitcoin$64$9de529051d808b5d34c679c43020a233e6b5161de2e85070127009d61e4c24c8$16$09792b4786f368cb$49019$2$00$2$00 113 characters
this code is loading.
$bitcoin$64$50bb9ef9cad87bf2b865b060e80c72c52f5ff496dbefa0bcfc6c3b5e0b86050e$16$f63cb4696e604d94$128289$2$00$2$00 114 characters
The text was updated successfully, but these errors were encountered:
jsteube commented Jul 20, 2020
Both hashes work fine for me. What’s the password?
philsmd commented Jul 26, 2020 •
I’ve also tested to run these 2 hashes and they load perfectly fine for me: no error message, no problem loading them. nada.
Anyway, it doesn’t seem to be a problem / bug, but just an user error (pebcak). We also didn’t get any further response, so I would suggest that we close this issue as WORKSFORME / INVALID. Please close
philsmd commented Aug 26, 2020
Again I do not see any problem here. I tried it and everything is working correctly with the latest versions.
please close this issue @jsteube / @Qalander
Comments
freetom commented Oct 25, 2018
I am trying to crack a JWT token signing key (RS256) but I get:
The token’s length is 734 bytes. I believe you should allow such long tokens.
The text was updated successfully, but these errors were encountered:
jsteube commented Oct 31, 2018
Please provide example hash and password
freetom commented Oct 31, 2018 •
Alg: HS256
Key: qwertyuiopasdfghjklzxcvbnm123456
jsteube commented Oct 31, 2018
I can not reproduce this problem!!
I used the same site to generate a token and it works fine. My token is 1589 bytes.
jsteube commented Oct 31, 2018
Note: the original issue was about 734 bytes and we support 2k byte. Therefore there is no issue or it was not described correctly. Note that there has to be an upper limit since there’s no dynamic memory alloaction on GPU.
freetom commented Oct 31, 2018
mpgn commented Jan 17, 2019 •
Same with version 5 and the token used by @jsteube
vincentcox commented Feb 18, 2019
Did anyone from this thread got a solution?
jsteube commented Feb 18, 2019
All problems solved, everything works as it should.
vincentcox commented Feb 18, 2019
The 2 posts above my initial comment said otherwise. I also have the same issue, hence why I ask it.
aress31 commented Feb 19, 2019
Same issue for me with a RS256 JWT token, I keep getting the «Token length exception».
vincentcox commented Feb 19, 2019
For those having issues and need an alternative in the meantime: https://github.com/brendan-rius/c-jwt-cracker
c-nagy commented Aug 11, 2020
Same issue for me with a RS256 JWT token, I keep getting the «Token length exception».
Please correct me if I’m wrong, but looking at the source of the JWT Hashcat module (hashmode 16500) at src/modules/module_16500.c it appears that RSA/RS tokens are not supported and only HS/HMAC types are. I’m guessing this could be because it doesn’t make much sense to try to guess asymmetric RSA keys?
F-Masood commented Oct 15, 2020
Same issue for me with a RS256 JWT token, I keep getting the «Token length exception».
Please correct me if I’m wrong, but looking at the source of the JWT Hashcat module (hashmode 16500) at src/modules/module_16500.c it appears that RSA/RS tokens are not supported and only HS/HMAC types are. I’m guessing this could be because it doesn’t make much sense to try to guess asymmetric RSA keys?
Wow. I think you’re right.
As I also have a RS512 token and same error appears.
hashcat
advanced password recovery
Used 7z2hashcat, then loaded up hashcat and:
Hashfile ‘hashuni.txt’ on line 1 (▒▒$): Line-length exception
Parsing Hashes: 0/1 (0.00%). No hashes loaded
In unicode save format.
Saved in UTF8 in case it was an encoding problem and it just overruns the text area and returns no hashes loaded without me being able to see the error message.
Also the encrypted data following the header is very long, thousands of characters. Judging from the example hashes page this might not be right? It is just the output from 7z2hashcat, could the error be in that step? Could the original file be corrupted?
I also see on 7z2hashcat
1 means that the data must be decompressed using the LZMA1 decompressor
is there an additional intermediate step I am missing?
However I saw this:
«In addition to some bug fixes, they now also support decompressing LZMA1/LZMA data streams. The header decompression problem in 7z2hashcat.pl seems to be fixed too. Currently there are no further known problems» from the 7z2hashcat thread so I’m thinking it must be something else.
any help or thoughts much appreciated.
I think there is some special byte in there, like the windows BOM etc.
Hashcat doesn’t expect that there is any other bytes within the hash file except the bytes that are required («the hash»).
Please remove everything before and after the hash or just copy-paste the output (without the BOM etc).
(12-03-2017, 10:28 AM) philsmd Wrote: I think there is some special byte in there, like the windows BOM etc.
Hashcat doesn’t expect that there is any other bytes within the hash file except the bytes that are required («the hash»).
Please remove everything before and after the hash or just copy-paste the output (without the BOM etc).
Line Length Exception in hashcat
I’m very new to cracking a password so sorry if I sound stupid.
I am trying to get my admin password from my second PC (I lost it). I did find the SAM file with kali linux and with bkhive and samdump did get the hash. I think it’s a NTLM but I could be wrong (I don’t now if I’m allowed to post the hash so I won’t do that). I tried breaking the code with hashcat, but it gives a error (line length exception). This is the code I tried:
What is wrong with it?
EDIT i get this now but is says that 0/1 is recovered and in the cracked.txt file there is nothing—-> 
1 Answer 1
First, an answer to the original asker’s (now ancient) question.
Unlike some tools (like ophcrack), NTLM hashes need to be separated out into their LM and NTLM components for hashcat to attack them separately, either hashes only:
This post from Didier Stevens outlines how to use the LM cracks (case-insensitive) to then attack the case-sensitive NTLM hashes.
Second, since the number of views that this question has (3K at this writing!) is a testament to how often this error confuses people, here’s a more general answer.
hashcat throws the dreaded «line-length exception» error when hashcat receives something that it tried to interpret as a hash, but the data received is not the expected length for the requested hash type.
The common triggers include:
The hashes aren’t the type that you think they are, so the hash length doesn’t match the requested type. This is often the most common, and the first thing to check. The best way to verify is to try the same command against the corresponding example hash in the hashcat example hashes list.
The hashes have unexpected characters at the end (often whitespace).
(I saved the weirdest one for last): When you are passing a file containing a list of hashes on the command line, but the file doesn’t exist. This is because of a quirk in how hashcat processes the command line. The syntax for «hashcat [literal-hash-to-crack]» and «hashcat [file-containing-hashes-to-crack»] is exactly the same. This means that if you pass a file but it doesn’t exist, hashcat says to itself «hmm, that thing they asked to crack wasn’t a file, maybe they’re trying to specify a hash directly?». Since the filename is almost never the same length as the hashes of the target hash type, you’ll get the «this is the wrong length» error when what it really means is «the file doesn’t exist».
So as long as you interpret the error as «there is something wrong with my input», and you investigate each of these possibilities, you should be able to resolve any «line-length exception» errors.
hashcat
advanced password recovery
Used 7z2hashcat, then loaded up hashcat and:
Hashfile ‘hashuni.txt’ on line 1 (▒▒$): Line-length exception
Parsing Hashes: 0/1 (0.00%). No hashes loaded
In unicode save format.
Saved in UTF8 in case it was an encoding problem and it just overruns the text area and returns no hashes loaded without me being able to see the error message.
Also the encrypted data following the header is very long, thousands of characters. Judging from the example hashes page this might not be right? It is just the output from 7z2hashcat, could the error be in that step? Could the original file be corrupted?
I also see on 7z2hashcat
1 means that the data must be decompressed using the LZMA1 decompressor
is there an additional intermediate step I am missing?
However I saw this:
«In addition to some bug fixes, they now also support decompressing LZMA1/LZMA data streams. The header decompression problem in 7z2hashcat.pl seems to be fixed too. Currently there are no further known problems» from the 7z2hashcat thread so I’m thinking it must be something else.
any help or thoughts much appreciated.
I think there is some special byte in there, like the windows BOM etc.
Hashcat doesn’t expect that there is any other bytes within the hash file except the bytes that are required («the hash»).
Please remove everything before and after the hash or just copy-paste the output (without the BOM etc).
(12-03-2017, 10:28 AM) philsmd Wrote: I think there is some special byte in there, like the windows BOM etc.
Hashcat doesn’t expect that there is any other bytes within the hash file except the bytes that are required («the hash»).
Please remove everything before and after the hash or just copy-paste the output (without the BOM etc).