GurpreetKang / BitwardenDecrypt

Decrypts an encrypted Bitwarden data.json file.
GNU General Public License v3.0
245 stars 30 forks source link

KeyError: 'encrypted' #27

Open Siding3823 opened 8 months ago

Siding3823 commented 8 months ago

Hello. I bumped in the following error when executing BitwardenDecrypt

  File "/home/$USER/build/BitwardenDecrypt/BitwardenDecrypt.py", line 604, in <module>
    main(args)
  File "/home/$USER/build/BitwardenDecrypt/BitwardenDecrypt.py", line 585, in main
    decryptedJSON = decryptBitwardenJSON(options)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/$USER/build/BitwardenDecrypt/BitwardenDecrypt.py", line 394, in decryptBitwardenJSON
    email, kdfIterations, encKey, encPrivateKey = checkFileFormatVersion(options)
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/$USER/build/BitwardenDecrypt/BitwardenDecrypt.py", line 362, in checkFileFormatVersion
    encKey = datafile[options.account['UUID']]['keys']['cryptoSymmetricKey']['encrypted']
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
KeyError: 'encrypted'

I start application as python3 BitwardenDecrypt.py ./data.json My Bitwarden desktop app version: 2023.10.1 I run on linux

iirekm commented 7 months ago

I have the same, data.json comes from desktop app 2023.12.0

zackslash commented 6 months ago

It looks like in recent desktop app versions the value of encKey has moved location in the bitwarden data.json.

Potentially this repo/tool is no longer maintained but for anyone else looking for a quick fix; changing the BitwardenDecrypt.py script file in this repo from

encKey = datafile[options.account['UUID']]['keys']['cryptoSymmetricKey']['encrypted']

to

encKey = datafile[options.account['UUID']]['keys']['masterKeyEncryptedUserKey']

seems to resolve this error at the moment.

bvwpo commented 2 months ago

In addition to the replacement provided by zackslash, I had to replace the next line after that in the same manner as well to make it work:

encPrivateKey = datafile[options.account['UUID']]['keys']['privateKey']['encrypted']

to

encPrivateKey = datafile[options.account['UUID']]['keys']['masterKeyEncryptedUserKey']

However, the above only works for my backups up until March 2023. Which is probably when I had switched to Argon. Current released version (1.6) does not support this. There is an unreleased version that supports Argon here: https://github.com/GurpreetKang/BitwardenDecrypt/pull/23 That version works on my backups up until December 2023. After that I get the same error described by the OP. Doing the same replacements above (and another one in the same nature) fixes that, but then I get another error regarding organization keys (I don't have any organizations in my vault):

File BitwardenDecrypt.py, line 476, in decryptBitwardenJSON for uuid, value in organizationKeys.items(): ^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'str' object has no attribute 'items'

It looks like in recent desktop app versions the value of encKey has moved location in the bitwarden data.json.

Potentially this repo/tool is no longer maintained but for anyone else looking for a quick fix; changing the BitwardenDecrypt.py script file in this repo from

encKey = datafile[options.account['UUID']]['keys']['cryptoSymmetricKey']['encrypted']

to

encKey = datafile[options.account['UUID']]['keys']['masterKeyEncryptedUserKey']

seems to resolve this error at the moment.

Davek145 commented 2 months ago

Hi to all. I have reviewed changes done by Bitwarden in recent releases. They are doing quite significant changes, which are not documented and not even mentioned in release notes.

I have made small updates to the script to support structure of the data.json file up to version 2024.1.0. #30 2024.1.0 is the last version, which is not introducing larger breaking changes I have noticed in later releases. What is worse, the format changes with every release they have made from Jan till now. It does not make sense to follow them until the format stabilizes. I hope, they will revert some of these format changes as they do not make much sense to me. They are breaking the whole logic of json objects hierarchy, which is not what I would expect to be intended. Let's see, how the format stabilizes in few months. I will than look at it again.

At this moment I suggest you use version 2024.1.0 of CLI to obtain the data.json file for decryption. You can have newer version of the desktop app or server and still use 2024.1.0 CLI version. Format of the data.json created by the CLI is driven by version of the CLI executable.

bvwpo commented 1 month ago

Thanks for your work on this @Davek145. And thanks for the suggestion on using the CLI to make new backups. What I was trying to do is to decrypt some old backups that I already have. Your latest commit #30 allowed me to decrypt by backups until January 2024, as you said it supports version up to 2024.1.0. However, it also works for my backups unitl March 2024, but with an error saying: ERROR: MAC did not match. Protected Symmetric Key was not decrypted. (Password may be wrong) My password is not wrong, it's the same password. Could the structural changes in the json file you mentioned be the cause of this password error?

Davek145 commented 1 month ago

Yes, it is caused by changes in the json file format. They are moving keys for encrypted key as well as parameters of the hashing algorithm that the script needs for decryption.Look inside your json file and you will see it your self.They seem to move step by step everything to flat structure with uuid prefix in the key. Which is nonsense from json format point of view.Anyway, as said, it has simple solution. Use older version of CLI and it will produce correct format of json file for you, but with current data.If you need to decrypt some prior offline backup, you can try to edit the json file and put back all encryption parameters to the original location. If you do not use organizations, it shall be easy copy paste from file prior Jan 24.

bvwpo commented 3 weeks ago

Thanks again @Davek145. I did the copy paste trick and it worked. I also agree that their earlier json format was much more sensible than these later ones. Interesting that they keep chaining it.