OS X Bug ? Or.. ?

A hash is cracked but no plain text !
Last version of ocl.

oclHashcat64.exe  --outfile-format=7 -o rs.txt -m 122  hash.txt dic.txt

hash.txt contains the hash (fa86cdace0a74fbb97dc7aa6d16cfbfcad80e679a4921655)

dic.txt contains only carriage return+line feed
[Image: 603007dic.png]

Result gives :
[Image: 121347res.png]

No special characters, no hex..
Is it a bug ?

the password for this hash is the empty string, ""
the double colon says this (nothing between the colons means empty string)
the LF is also correct at the end, otherwise the next cracked hash:password:hex pair would end up on the same line
the hex code for the empty string is ofc also empty/null (therefore we do not see anything), besides the trailing line feed

So everything seems kind of ok...

PS. It doesn't really help posting hashes.... if you just say "the -m 122 hash of CRLF starts w/ fa86" we could very quickly double-check and proove that this is not the case
PSS. also checking for blank passworts makes sense most of the times... and in those specific cases (small dict) it is also sort of a performance measurement e.g. *hashcat loads words (from dicts) in huge blocks (most of the time)... if the block is not filled (at the end of the wordlist/run etc) -> check empty password ...

well - little bit off-topic - , there is an open trac ticket https://hashcat.net/trac/ticket/165 that also deals w/ blank passwords... maybe someone could help/discuss there when it currently does not work and how it should be implemented
Thanks, but the empty hash is 3E8ED8FC0C6AC6C17CB6EFCBE43BF31E765F8F456B2A6500
this thread http://hashcat.net/forum/thread-1360-post-7493.html said that.
i am confused Confused

atom Wrote:Yes, its an empty pass:
remember, we talk about salted hashes (that's why different salt - but same pass - => different hash)

The first 8 characters is the salt string of those OSX hashes
Humm right I got it. I forgot the salt.

Is there a way to know when a hash is the empty string or not ?

Thank you.