OK, if you say so.
Now I've a question @ epixoip
I gues 5 ruonds means, that there is generated a SHA512 hash out of my pw and this string is passing the algorythm once again. This will be repeated for another 3 times and this hash will be encoded with base64 after this.
Now I looked up base64 at wikipedia and compared it with my linux string. There were some "." (dots) included in my hash but no "+", but in wikipedia was no ".", but a "+" for the value of "62". Am I right, when I think these two chars are both reprisented by the value of 62?
Beside that I tryed to convert a base64 saltto hex manually.
The bas64 strin contains of 13 chars, means 13 6bit-blocks means 78 bits. 78 ins't divisible by 8, so I think ther ware 2 zero bits more 0-bits at the end of the hex hash. But in this case 80 isn't divisible by 6 and to convert this string two 8bit-zero-blocks should had been added two the hash, because 96 is the next number which is divisble by 6. But in this case two "=" mus stand after the bas64-hash, which aren't there.
Is there something wrong in my calculation, or are they just droped out of the hash?
Now I've a question @ epixoip
Quote:Please understand sha512crypt, aka SHA512(Unix), is *not* simply salted sha512. The "hex string" generated by Cain's Hash Calculator is just a raw sha512 hash, and is completely different -- and in no way compatible with -- sha512crypt in libc. The "ASCII string" that crypt outputs is base64-encoded, and is the result of 5,000 rounds of the sha512 algorithm.
You can use -m 1800 in the cpu version of Hashcat to crack the sha512crypt hashes from your shadow file.
I gues 5 ruonds means, that there is generated a SHA512 hash out of my pw and this string is passing the algorythm once again. This will be repeated for another 3 times and this hash will be encoded with base64 after this.
Now I looked up base64 at wikipedia and compared it with my linux string. There were some "." (dots) included in my hash but no "+", but in wikipedia was no ".", but a "+" for the value of "62". Am I right, when I think these two chars are both reprisented by the value of 62?
Beside that I tryed to convert a base64 saltto hex manually.
The bas64 strin contains of 13 chars, means 13 6bit-blocks means 78 bits. 78 ins't divisible by 8, so I think ther ware 2 zero bits more 0-bits at the end of the hex hash. But in this case 80 isn't divisible by 6 and to convert this string two 8bit-zero-blocks should had been added two the hash, because 96 is the next number which is divisble by 6. But in this case two "=" mus stand after the bas64-hash, which aren't there.
Is there something wrong in my calculation, or are they just droped out of the hash?
