sorry to hear about your loss.
I think something like this explains the format pretty well: https://apple.stackexchange.com/question...863#220863
if you have the .xml format, it's easy to see the different "items" that you need to extract to build the hash:
$ml$<iterations>$<salt>$<entropy>
sometimes hashes (the entropy) are longer than the example hash from https://hashcat.net/wiki/example_hashes , if hashcat doesn't accept it, you could just "truncate" it to the same entropy length that the example hash uses (this is basically the pbkdf2 hash output length and doesn't really matter if it's longer, hashcat will only check the first 16 bytes = 128 bits of the digest anyways)
I would highly suggest to try the same thing with a different account or notebook for which you know the password, just to make sure that you are doing everything correctly (before wasting the time on uncrackable data etc, if you do something wrong).
I also suggest using dictionary attack (-a 0) with rules (-r) for a start. Yeah, brute-force (or mask attack, -a 3) is not always the most clever idea for starting with a new target hash (even if it is often faster, but speed isn't everything... often more clever and more target-specific password candidates get your passwords/data back sooner, just saying).
btw: looking at that example from stackexchange, if your xml file says something like this:
... it's clear that the data *after* the "entropy" xml element, is the data we need for the <entropy> in the hash. The only problem is that it's base64 encoded and you need to base64 decode it and hex encode it.
In linux you would do something like this:
the output therefore is:
(this of course matches with the <entropy> part of the stackexchange $ml$... hash)
I think also on macOS you can use base64 decoding with "base64", xxd for hex conversion and tr for removing the new lines (brew is your friend on macOS !), but I also suggest not cracking with hashcat on a notebook (throttling and cooling issues)
I think something like this explains the format pretty well: https://apple.stackexchange.com/question...863#220863
if you have the .xml format, it's easy to see the different "items" that you need to extract to build the hash:
$ml$<iterations>$<salt>$<entropy>
sometimes hashes (the entropy) are longer than the example hash from https://hashcat.net/wiki/example_hashes , if hashcat doesn't accept it, you could just "truncate" it to the same entropy length that the example hash uses (this is basically the pbkdf2 hash output length and doesn't really matter if it's longer, hashcat will only check the first 16 bytes = 128 bits of the digest anyways)
I would highly suggest to try the same thing with a different account or notebook for which you know the password, just to make sure that you are doing everything correctly (before wasting the time on uncrackable data etc, if you do something wrong).
I also suggest using dictionary attack (-a 0) with rules (-r) for a start. Yeah, brute-force (or mask attack, -a 3) is not always the most clever idea for starting with a new target hash (even if it is often faster, but speed isn't everything... often more clever and more target-specific password candidates get your passwords/data back sooner, just saying).
btw: looking at that example from stackexchange, if your xml file says something like this:
Code:
<key>entropy</key>
<data>
xfGYY5kVoQHJmvMm3/4T6PFEVr6P0jEqOad3uSF4gE4gTKT+4SqGZ4cUQO/0
KI6BHYbXRsbZamDJGcNBjf67pC8yn11zwDctY21h1d/aGt1hrzbHDkrNdxJ2
EHIJ5kOukqD0PpWkUnROUPtFQNm99OC3AXJdfbSI++GMGrdzfGs=
</data>... it's clear that the data *after* the "entropy" xml element, is the data we need for the <entropy> in the hash. The only problem is that it's base64 encoded and you need to base64 decode it and hex encode it.
In linux you would do something like this:
Code:
echo xfGYY5kVoQHJmvMm3/4T6PFEVr6P0jEqOad3uSF4gE4gTKT+4SqGZ4cUQO/0KI6BHYbXRsbZamDJGcNBjf67pC8yn11zwDctY21h1d/aGt1hrzbHDkrNdxJ2EHIJ5kOukqD0PpWkUnROUPtFQNm99OC3AXJdfbSI++GMGrdzfGs= | base64 -d | xxd -p | tr -d '\n'; echothe output therefore is:
Code:
c5f198639915a101c99af326dffe13e8f14456be8fd2312a39a777b92178804e204ca4fee12a8667871440eff4288e811d86d746c6d96a60c919c3418dfebba42f329f5d73c0372d636d61d5dfda1add61af36c70e4acd771276107209e643ae92a0f43e95a452744e50fb4540d9bdf4e0b701725d7db488fbe18c1ab7737c6b(this of course matches with the <entropy> part of the stackexchange $ml$... hash)
I think also on macOS you can use base64 decoding with "base64", xxd for hex conversion and tr for removing the new lines (brew is your friend on macOS !), but I also suggest not cracking with hashcat on a notebook (throttling and cooling issues)