hashcat Forum

Full Version: hashcat cracking special chars error
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
can the hashcat recognize special chars?

my password is encrypted as pattern SHA1($password.$salt)

the salt is about 5 bytes and some salts contains special chars like 0xFFFFFF00 or 0xFF000105.

error occurs while cracking hashes.Sad..the application seems not to recognize the special chars???Huh
in addition , my hash is about 40 bytes and seperate char is ':'.

how can i crack hashes effectively?..Dodgy
hashcat format is hashConfusedalt, not salt:hash
(05-27-2010, 04:00 PM)atom Wrote: [ -> ]hashcat format is hashConfusedalt, not salt:hash

the hashes file's format is hashConfusedalt.

but the application seems not to recognize salt that contains special chars..Dodgy
[attachment=13]
no. hashcat is complaining about an -unmatched seperator-

this mean either your hash is not exactly 40 bytes or on pos 40 + 1 is not the expected seperator char or you have wrong -m mode.

but, if i counted correctly from your screenshot, your hash has only 39 bytes. then this is the problem.
(05-27-2010, 05:18 PM)atom Wrote: [ -> ]no. hashcat is complaining about an -unmatched seperator-

this mean either your hash is not exactly 40 bytes or on pos 40 + 1 is not the expected seperator char or you have wrong -m mode.

but, if i counted correctly from your screenshot, your hash has only 39 bytes. then this is the problem.

do you mean that the program take the first 40 bytes to be the hash and 41th byte to the seperator char?then program reads the 42th byte to the end of line("\r\n"??) to be the salt? do the salt store in bytes array and can i use a option to define the length of salt?

by the way , can seperator be two or more chars using -p option?

thanks , dear Atom.Blush
it reads 40 chars of the line to be the hash, yes, regardless of the position of the seperator. the reason therefore is the problematic hashConfusedalt format. it is possible that the seperator char itself is part of the salt. so i could add -p option but this would not solve the main problem. a better solution would be the user manually setting a fixed length of the salt. this is possible but would require a new option. if user uses this option all salts of all hashes must have exactly that length. this is problematic if you have a hashlist with multiple salts. so i think this is a bit to confusing. you see, the only real solution would be to change the format to maybe xml or something like that. but telling users to put their hashes into xml format would be a overkill.
(05-29-2010, 06:38 AM)atom Wrote: [ -> ]it reads 40 chars of the line to be the hash, yes, regardless of the position of the seperator. the reason therefore is the problematic hashConfusedalt format. it is possible that the seperator char itself is part of the salt. so i could add -p option but this would not solve the main problem. a better solution would be the user manually setting a fixed length of the salt. this is possible but would require a new option. if user uses this option all salts of all hashes must have exactly that length. this is problematic if you have a hashlist with multiple salts. so i think this is a bit to confusing. you see, the only real solution would be to change the format to maybe xml or something like that. but telling users to put their hashes into xml format would be a overkill.


i see. thank you very much. atom.

but i think add a option to define the salt length is necessary in your next version.because usually the salt in some web applications is fixed length....xml is not a good idea , in my thoughtBlush

but however , hashcat and oclHashcat are very excellent .Big Grin
hex-salt and hex-charset comes soon in oclHashcat v0.26