Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
HC error: No hashes loaded
#1
Trying to crack IKE PSK MD5 (-m 5300)
Client: python 0.3.0 version
OS: Windows 8.1

I got an error "HC error: No hashes loaded"

Here is the debug output:
Quote:[2018-11-07 10:43:25,641] [DEBUG] b'{"action":"getChunk","response":"SUCCESS","status":"OK","chunkId":3,"skip":0,"length":1}'
[2018-11-07 10:43:25,641] [INFO ] Start chunk...
[2018-11-07 10:43:25,643] [DEBUG] CALL: hashcat64.exe --machine-readable --quiet --status --remove --restore-disable --potfile-disable --session=hashtopolis --status-timer 5 --outfile-check-timer=5 --outfile-check-dir=..\..\hashlist_1 -o ..\..\hashlists\1.out --outfile-format=15 -p " " --remove-timer=5 -s 0 -l 1 -a 0 ..\..\hashlists\1 ..\..\files\mydict.dict  --hash-type=5300 
[2018-11-07 10:43:25,644] [DEBUG] started cracking
[2018-11-07 10:43:26,814] [ERROR] HC error: No hashes loaded.
[2018-11-07 10:43:26,815] [DEBUG] {'action': 'clientError', 'token': 'XXXXXXXXXX', 'taskId': 1, 'message': 'No hashes loaded.'}
[2018-11-07 10:43:28,269] [DEBUG] http://server-ip:80 "POST /hashtopolis/api/server.php HTTP/1.1" 200 45
[2018-11-07 10:43:29,350] [DEBUG] b'{"action":"clientError","response":"SUCCESS"}'
[2018-11-07 10:43:30,452] [INFO ] finished chunk

I think the problem is in -p option with chr(9) value. I tried to run hashcat in manual mode. And if I delete -p option all is OK. But I cant get good result with -p option at all even I changed it's value.

Thanx for any solution
Reply
#2
The chr(9) character should not be a problem on windows, I tested the client regularly on windows and -p was never an issue. We are using the tab character to avoid all these issues when having separators which are present in hashes.

Did you verify that on the client in the file hashlists/1 there is actually the correct hash? In case there was an error on the download it might be empty. 

I will do a test tomorrow and look if there might be a problem with this kind of binary hashes.
Reply
#3
(11-07-2018, 11:26 PM)s3in!c Wrote: The chr(9) character should not be a problem on windows, I tested the client regularly on windows and -p was never an issue. We are using the tab character to avoid all these issues when having separators which are present in hashes.

Did you verify that on the client in the file hashlists/1 there is actually the correct hash? In case there was an error on the download it might be empty. 

I will do a test tomorrow and look if there might be a problem with this kind of binary hashes.

I verified the hashlists/1 file first of all. And it had correct hash.
Then I tried to run the same command in command prompt. And until I deleted -p param hashcat had given me the same error 
Code:
Hashfile '..\..\hashlists\1' on line 1 (e957a6...19a3428d90eb5045363a58dc33f51941): Separator unmatched
No hashes loaded.

I added hash file, dict file and bat file to this post.

.zip   Files.zip (Size: 949 bytes / Downloads: 0)
Reply
#4
Thanks for the information. Indeed it's a separator issue, it's the same reason like for the hash parsing I fixed in this pull request: https://github.com/hashcat/hashcat/pull/1727
But as the hash was in a file, I didn't check it. I'll go over all algorithms again and fix the remaining ones and do again a pull request to hashcat.
Reply
#5
The fixed code is now in the hashcat repository: https://github.com/hashcat/hashcat/pull/1770
So either build hashcat from source there or wait until the next beta build or release. With the fix it will work within the hashtopolis agent and not throw anymore the separator unmatched error.
Reply
#6
Thx a lot. It works!
But I got another error: client doesn't sent cracked hash to his server.
Here is the debug log:
Quote:[2018-11-13 03:47:27,634] [DEBUG] CALL: hashcat64.exe --machine-readable --quiet --status --remove --restore-disable --potfile-disable --session=hashtopolis --status-timer 5 --outfile-check-timer=5 --outfile-check-dir=..\..\hashlist_1 -o ..\..\hashlists\1.out --outfile-format=15 -p " " --remove-timer=5 -s 0 -l 1 -a 0 ..\..\hashlists\1 ..\..\files\mydict.dict  --hash-type=5300 
[2018-11-13 03:47:28,288] [DEBUG] started cracking
[2018-11-13 03:47:30,204] [DEBUG] STATUS 6 SPEED 4475 1000 EXEC_RUNTIME 0.029760 CURKU 0 PROGRESS 1 1 RECHASH 1 1 RECSALT 1 1 REJECTED 0 UTIL -1
[2018-11-13 03:47:30,206] [DEBUG] Sending 0 cracks...

STATUS 6 means hashcat has cracked my hash, but the client sends nothing to the server.
Hash, dictionary file are the same.
Reply
#7
I think this is the special case that the hash get cracked so fast that the agent stopped to read the output file too fast. This was a bug in the 0.3.0 client version, if you run a normal task, this should not happen.

I assume that this above is from the test task as the keyspace is only length 1. Please test with a slightly larger task (e.g. taking a few minutes time) if this still happens then. If it works with longer tasks, it's definitely because of that known bug, in that case you could try with the `current-dev` branch of the client to make sure it is fixed.
Reply
#8
(11-13-2018, 12:38 PM)s3in!c Wrote: I think this is the special case that the hash get cracked so fast that the agent stopped to read the output file too fast. This was a bug in the 0.3.0 client version, if you run a normal task, this should not happen.

I assume that this above is from the test task as the keyspace is only length 1. Please test with a slightly larger task (e.g. taking a few minutes time) if this still happens then. If it works with longer tasks, it's definitely because of that known bug, in that case you could try with the `current-dev` branch of the client to make sure it is fixed.

I have tested it with 'current-dev' branch and all is ok.
Thank you.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)