Closed marksee closed 6 years ago
The important part is mostly mentioned here: https://github.com/s3inlc/hashtopolis/issues/323#issuecomment-361897078
You need to use set a different separator when importing these hashes, as hashtopolis otherwise wrongly parses the hashes on import and when trying to find the cracked one, it does not match.
So you need to reimport the hashlist, then use ]
for example as the separator (basically just a char which is not present in the hash). And the hash should NOT be imported as salted one.
With the newly imported hashlist the crack should then be successfully submitted and saved.
I changed the separator in the Server configs, reimported, and cracked successfully. Thanks for the quick help!
Is this considered a bug worth fixing for future releases?
The main issue here is the one size fits all problem. hashtopolis has to support a wide range of configurations, hash types, attacks, etc.
So i believe instead of chasing down one particular issue with compatibility. Its best to come up with a solution that can be reused with other future "problems" and giving the end user the ability to choose whatever separator character they wish is one of those 'general' solutions. Is it the easiest way for the end user... No. Is it the best way... probably not. but, it does allow the end user more flexibility in what they can do with Hashtopolis. especially when dealing with the odd and the stranger algorithms.
Now, this particular issue with hashes containing the same character most people use as a separator ( the colon) is not a new thing. A lot of software struggles to figure out what is considered a separator and what is considered part of the "data". Unfortunately, in my opinion, the best way to handle this problem is changing to another separator that is not found in the algorithm output (hash). This is not the most user-friendly way to handle this but, its the best way to handle it.
So i guess to answer your question I believe this is not a bug. Hashtopolis already supports user-defined separator characters and in the end, that's the best way to handle this problem on a "universal" level.
Completely agree, thanks the for detailed reply. My only suggestion would to publicly document the edge cases in NetNTLM and other algorithms which may prevent future issue tickets such as mine.
Yeah, I agree. It's already mentioned shortly in the Frequent Problems section on the wiki: https://github.com/s3inlc/hashtopolis/wiki/Frequent-Problems#hashes-containing-colons-are-not-handled-correctly
RTFM it is for me then :), I'll close the issue now. Thanks for all the help.
Your current Server version located at the bottom of any Hashtopolis webpage.
Hashtopolis: commit 410898e branch master 0.5.1
Current Client version
python 0.1.3
Your current Hashcat version
4.1.0
The exact task command you are trying to run.
Hashlist: NetNTLMv2
Task: #HL# -r best64.rule crackstation-human-only.txt
Debug output from the client by running "hashtopolis.exe -d" or with debug flag set on the python client.
Describe your problem in as much detail as possible " It's broke " is not a description.
When cracking a NetNTLMv2 hash, debug output shows the task running and successfully cracking. The UI doesn't now show the cracked password but shows as the task is completed. I've read #323 and saw it was fixed in a previous version of the python client, figured I would create a new one instead of reopening.