maybe it has something to do with this: https://github.com/hashcat/hashcat/commi...4ee0620076
The validation check is only searching for some specific pattern... we would need to know what your decrypted file starts with, currently supported patterns are (see https://github.com/hashcat/hashcat/issue...-469038973):
- "guid"
- "tx_no
- "share
- "addre
- "doubl
- "keys"
I'm pretty sure this huge number of possibilities comes from the fact that for json it doesn't really matter which keys come first (as long as they are in the json object)... so it is somehow shuffle.... the problem is that if some pattern is completely missing in the cracker/hashcat, it doesn't validate correctly.
We would need that pattern, if it's really missing... or come up with a better strategy alltogether (but it's not easy to come up with a good plan... maybe a entropy check or a search for specific character sets (e.g. non-binary data. should contain : and " etc) would be also enough, but could lead to false positives
)
The validation check is only searching for some specific pattern... we would need to know what your decrypted file starts with, currently supported patterns are (see https://github.com/hashcat/hashcat/issue...-469038973):
- "guid"
- "tx_no
- "share
- "addre
- "doubl
- "keys"
I'm pretty sure this huge number of possibilities comes from the fact that for json it doesn't really matter which keys come first (as long as they are in the json object)... so it is somehow shuffle.... the problem is that if some pattern is completely missing in the cracker/hashcat, it doesn't validate correctly.
We would need that pattern, if it's really missing... or come up with a better strategy alltogether (but it's not easy to come up with a good plan... maybe a entropy check or a search for specific character sets (e.g. non-binary data. should contain : and " etc) would be also enough, but could lead to false positives
)