nesfit / fitcrack

A hashcat-based distributed password cracking system
https://fitcrack.fit.vutbr.cz/
Other
140 stars 30 forks source link

Fix for issue #108 #109

Closed alpatron closed 6 months ago

alpatron commented 10 months ago

Fixes issue #108.

The problem was some quite distressing sharing of data inside a function. The hash validation function was doing some horrible tricks:

#'h' stands for hash; 's' stands for status
for h, s in hash_validity.items():
    hashes.append("{} {}".format(h, s))

just to immediately then parse the data back:

hashArr = hash.rsplit(' ', 1)

Except 's' in the is a status message acquired from hashcat, which can contain spaces. So something like 66093185230c5faa235d03c9a9dfaad9 Token length exception got turned into (66093185230c5faa235d03c9a9dfaad9 Token length, exception). The front-end then took 66093185230c5faa235d03c9a9dfaad9 Token length returned from the verification endpoint and forwarded it to the job-creation endpoint when later creating the job, causing the odd behaviour.

This seems to have been done like this when changing the hash validator from some special validator tool to hashcat (32e71f1); the changed code was bolted on and made to use the same interchange format as the old one.

So I just changed the code to share the data directly using tuples rather than building and immediately deconstructing a string.

This also means there was another bug present in the code for a few years; the hash error pop-up was showing a truncated error message:

obrazek

It now correctly display the entire message.

obrazek