Large amount of false positives cracking apple keychain -m 23100 login.keychain
#1
Hey! hoping someone could help me with this

I have an apple keychain file i am trying to decrypt. i obtained the login.keychain hash by using chainbreakers --export-keychain-password-hash mode. this gave be the apple hash but with b* or *b at the beginning of every block of hash. i noticed this didnt work with hashcat so deleted all of the "b"'s after the * that were in the hash as this more closely resembled the test hash on the hashcat website. this left me with the hash thats posted below.
my issue is simple. i am getting a crap ton of false positives. i have appended the hashcat code with --keep-guessing but on average running hashcat for 24 hours leaves me with at least 20-30 extra potential passwords that are useless. is there a way to fix this? am i doing something wrong? i have used hashcat for cracking md5's in the past as well as a handful of other types and have never had this issue. i tried to do some research on this but other than the github request for keychain coverage and a select few other posts that are made on cracking keychains before the release of keychain for hashcat there really isnt much out there.

Below is the modified keychain hash. if someone can crack it ill cashapp you 15 bucks but im really hoping for a solid answer on why i am getting so many false positives so i can do it myself, as i do this in my spare time and forsee myself cracking more of these hash types in the future.

*****EDIT to abide by the rules parts of the hash have been blocked out. if any of you need the full hash please ask and i will post it.


$keychain$*6eefdb0f07c86248a76a80aeAAAAAAAf70ec0ed043*8ac5fbAAAAAA53ccae8*48800647d4c50fbe87bAAAAAA0111327c42067c867660cf825f98edf2d99e0532eAAAAAA83460a1f64ef6dfede
Reply
#2
The b' on your screen is an encoding/decoding-thing.

As for the false positives, this is extensively discussed here https://github.com/hashcat/hashcat/issue...-647462514
You'll read that there is a padding check of only 4 bytes (namely \x04\x04\x04\x04) in the decrypted output in order to see if the candidate is correct. This technique is susceptible to have a lot of false positives.
Since it is not documented anywhere on how to optimize this check (at my knowledge), one should be using --keep-guessing.

Finally, as also stated in the Github-issue, the login-pwd and the keychain-pwd have a high probability to be the same.
Reply