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.

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.

(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

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.

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.

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.

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