Attachment 'key' value does not decrypt, and causes the current version V1.3 of BitwardenDecrypt to crash.

[chemputer]

This is an issue filed after going back and forth with GurpreetKang on Reddit a few times, and just documenting the issue and what we went through and discovered in the process.

With the (as of writing) currently available version, v1.3, setup with Python 3.9.7 (also tried it with 3.10 and 3.8), in a venv created specifically for this, after running pip install -r requirements.txt, then running the program in PowerShell or CMD with the venv active (to rule out any other installed packages or dependencies), it gives the following error:

❯ .\BitwardenDecrypt.py
Password:
Traceback (most recent call last):
  File "E:\Projects\Repos\BitwardenDecrypt\BitwardenDecrypt.py", line 325, in <module>
    main()
  File "E:\Projects\Repos\BitwardenDecrypt\BitwardenDecrypt.py", line 320, in main
    decryptedJSON = decryptBitwardenJSON(inputfile)
  File "E:\Projects\Repos\BitwardenDecrypt\BitwardenDecrypt.py", line 299, in decryptBitwardenJSON
    jsonEscapedString = json.JSONEncoder().encode(decryptCipherString(match, encKey, macKey))
  File "E:\Projects\Repos\BitwardenDecrypt\BitwardenDecrypt.py", line 216, in decryptCipherString
    return(cleartext.decode('utf-8'))
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 0: invalid start byte

Now, 0xa0 is a "non-returning space". I don't think this is relevant as even switching it to a different attachment by reordering the data.json file, regardless of what you do it still causes issues with various bytes that it considers invalid start bytes.

I made a minor modification to the code to print out the cleartext variable in the decryptCipherString function, to see what the last item was before it errored out, and it turned out to be the first instance of an attachment's key.
GurpreetKang then sent me a couple of versions to do some debugging with, and every instance of an attachments key was failing to decrypt. This indicates that it is almost certainly encrypted in a different way to the rest of the file.

[GurpreetKang]

Thanks for reporting this. It looks like each attachment has it's own Protected Symmetric Key, and BitwardenDecrypt is trying to decrypt it with the primary encryption key that's used for all other vault items. This fails, is not handled gracefully and the script aborts.

[GurpreetKang]

Commit 3559344 does not resolve the underlying issue (won't decrypt attachments/keys) but will no longer abort when it encounters them so BitwardenDecrypt can still be used to decrypt a backup data.json (though without attachments/keys).

[GurpreetKang]

Commit 4e95002 will decrypt the attachment/key value as a hex string.

[GurpreetKang]

Closed with Version 1.4.