04-26-2021, 10:18 AM
the most important part of course is the "ct":"...." part... It would be intersting to know if this part is always of the same length.
there is another question that comes to my mind: we currently have no fully compatible JSON decoder within hashcat... but I think a new hash format wouldn't hurt in this case.... it might just be a little bit less convenient, but hashcat users are actually used to use the "xyz2hashcat.py" or similar tools.
Also in this case the JSON decoding wouldn't be much of a problem because we could just "search" for "ct", "iter" etc within the base64 decoded string. The only problem would be the reconstruction of the "cracked hash" (and in JSON the order doesn't really matter, but the output should be same as input, therefore this needs to be stored somehow.... except if we assume the order of the JSON attributes is always the same, which isn't normally the case).
there is another question that comes to my mind: we currently have no fully compatible JSON decoder within hashcat... but I think a new hash format wouldn't hurt in this case.... it might just be a little bit less convenient, but hashcat users are actually used to use the "xyz2hashcat.py" or similar tools.
Also in this case the JSON decoding wouldn't be much of a problem because we could just "search" for "ct", "iter" etc within the base64 decoded string. The only problem would be the reconstruction of the "cracked hash" (and in JSON the order doesn't really matter, but the output should be same as input, therefore this needs to be stored somehow.... except if we assume the order of the JSON attributes is always the same, which isn't normally the case).