When we compare the content of your .sqlite file with the normal parsing of the .js file (see https://github.com/philsmd/1password_agi...hashcat.pl ), we see:
- we only need the "data" and "iterations" part when parsing .js files
- if salt is being used, the base64 decoded data part starts with Salted__ (8 chars), 8 binary salt (16 hexadecimal characters) and the remaining part is the data part (about 1040 binary chars, or 2080 hex chars)
- the level, identifier and validation string can simply be ignored (we do not need them to crack the hashes)
The format for hashcat is:
[iteration_count]:[salt]:[data] (without the brackets)
note: there is no "sha1" etc (see https://hashcat.net/wiki/doku.php?id=example_hashes and search for 6600)
so I think the Salted__ part is a good start, the first 8 bytes (16 hexadecimal chars) should be the salt indeed, but now you need the 1040 binary chars (or 2080 hex chars) for the data too
with .js this "Salted__" splitting looks like this: https://github.com/philsmd/1password_agi...#L140-L144
So I think there must be a longer "data" string somewhere with exactly 1040 bytes (or 2080 hex chars)
---
It could also be that 1password 3.7.2 did use a different format/algorithm, it would not suprise me because this version is quite old and the web is full of tutorials how to upgrade starting with version 3.7.2.
It would also make sense to at least mention the password that the fields found in the sample database correspond to. Without the password it is very difficult to understand anything.
- we only need the "data" and "iterations" part when parsing .js files
- if salt is being used, the base64 decoded data part starts with Salted__ (8 chars), 8 binary salt (16 hexadecimal characters) and the remaining part is the data part (about 1040 binary chars, or 2080 hex chars)
- the level, identifier and validation string can simply be ignored (we do not need them to crack the hashes)
The format for hashcat is:
[iteration_count]:[salt]:[data] (without the brackets)
note: there is no "sha1" etc (see https://hashcat.net/wiki/doku.php?id=example_hashes and search for 6600)
so I think the Salted__ part is a good start, the first 8 bytes (16 hexadecimal chars) should be the salt indeed, but now you need the 1040 binary chars (or 2080 hex chars) for the data too
with .js this "Salted__" splitting looks like this: https://github.com/philsmd/1password_agi...#L140-L144
So I think there must be a longer "data" string somewhere with exactly 1040 bytes (or 2080 hex chars)
---
It could also be that 1password 3.7.2 did use a different format/algorithm, it would not suprise me because this version is quite old and the web is full of tutorials how to upgrade starting with version 3.7.2.
It would also make sense to at least mention the password that the fields found in the sample database correspond to. Without the password it is very difficult to understand anything.