enter image description hereI'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:

hashcat -m 1000 -a 0 -o cracked.txt --remove /root/Desktop/hashes.txt /usr/share/sqlmap/txt/wordlist.txt

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----> enter image description here

  • the wordlist file needs to only have hashes and not the shadow password formats – schroeder Jun 17 '15 at 17:15
  • @schroeder how can i delete those shadow password formats then and when i only run the hash after the : and i let it run i immediately stops and gives nothing am i alout to post the hash? – Jorrit Jun 17 '15 at 17:36
  • You need a proper hash table to use hashcat - this is a Google exercise now. – schroeder Jun 17 '15 at 22:19
  • @Jorrit, yes you can post the hash. It is your hash though, so you will want to change your password when you can. – amccormack Jun 18 '15 at 0:11
  • @schroeder how can i make a proper hash table? – Jorrit Jun 18 '15 at 14:53

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:

$ cat lm.hashes

$ cat ntlm.hashes

... or with users (which requires using the --username hashcat parameter):

$ cat lm-users.hashes

$ cat ntlm-users.hashes

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.

I phrase it in this specific way because it's important to understand that some natural activities might cause this in surprising ways. When you're working with hashcat command line, it's easy to accidentally pass it something that hashcat is expecting to be a hash, but isn't -- so much so that there is a hashcat FAQ entry for the error.

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

  • The supplied hashes include users or salts when they aren't expected (or they don't contain those, and they are expected). For example, you might supply hashes in a "username:hash" or similar format, but hashcat can't tell if "string:string" is really "hash:salt" or something else instead (use --username if you need to work on "username:hash" hashes).

  • Because of a typo or mis-ordering of command-line options, you accidentally pass a non-hashes file as the first "unflagged" parameter to hashcat. This is also quite common. For example, if you accidentally forget to put -r in front of a rules file, and you haven't specified a hash file yet, hashcat will think that that first "unflagged" parameter is your target hashfile, and will try to "crack" it. (Corollary: it's a good idea to place your hashfile relatively early in your command line, before anything else that takes a file as a parameter, to reduce the chances of this)

  • (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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.