![]() |
Bug: file not found reports as hash length exception - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Developer (https://hashcat.net/forum/forum-39.html) +--- Forum: Beta Tester (https://hashcat.net/forum/forum-31.html) +--- Thread: Bug: file not found reports as hash length exception (/thread-1357.html) |
Bug: file not found reports as hash length exception - Bitweasil - 07-04-2012 Log: ================= ./oclHashcat-plus64.bin -m0 -a3 -1 ?u?l?d?s example.dict.nothere ?1?1?1?1?1?1?1?1 ** Valid keyfile for beta usage: Bitweasil (expires 05.03.2013) WARNING: Hash 'example.dict.nothere': Line-length exception ERROR: No hashes loaded ================= To reproduce: Provide oclHashcat with a hash filename that is not present. Expected behavior: oclHashcat tells me that the file I have listed is not present on the filesystem - file not found, unable to open file, etc. Observed behavior: The ever-generic line length exception error. Importance: Minor. Just annoying if one has typoed their filename and is trying to debug why it cannot load hashes. RE: Bug: file not found reports as hash length exception - atom - 07-04-2012 Wait, thats a feature! ![]() I dont want to have two parameters where one defines a single-hash and onle defines a hash-file. I prefer to have that automatically checked. That means oclHashcat checks if example.dict.nothere exists as a file. If yes, it load its as hash-file. Otherwise it loads it as single-hash. RE: Bug: file not found reports as hash length exception - Bitweasil - 07-04-2012 Could you do a tiny bit of sanity checking re the hash type? -m0 (raw MD5) should never have anything other than [0-9a-fA-F] in it. If other characters are found, it's clearly not a MD5 hash on the command line. "Unable to open example.dict.nothere as a file, and does not appear to be a valid MD5 hash. Exiting." RE: Bug: file not found reports as hash length exception - atom - 07-05-2012 that might be correct for md5 but there are so many other hashes that allow all chars like the base64 ones. so that would require a special parser for each hash type. a lot of work... RE: Bug: file not found reports as hash length exception - Bitweasil - 07-08-2012 They're still a valid format. Up to you. It seems you already have all the code to test it for reading the hashfile - if the file doesn't exist, and you cannot read it is a valid hash, throw some sort of sane error. "Unable to open hash file %s, and cannot read as a valid type %s hash." RE: Bug: file not found reports as hash length exception - atom - 07-09-2012 OK, I can do that. Thank you. |