05-27-2010, 02:53 PM (This post was last modified: 05-27-2010, 03:30 PM by xiaozhi.)
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...the application seems not to recognize the special chars???
in addition , my hash is about 40 bytes and seperate char is ':'.
05-28-2010, 01:48 AM (This post was last modified: 05-28-2010, 01:53 AM by xiaozhi.)
(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?
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 hashalt 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 hashalt 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 thought
but however , hashcat and oclHashcat are very excellent .
..the application seems not to recognize the special chars???
alt, not salt:hash
