Kunzisoft / KeePassDX

Lightweight vault and password manager for Android, KeePassDX allows editing encrypted data in a single file in KeePass format and fill in the forms in a secure way.
https://www.keepassdx.com/
GNU General Public License v3.0
4.8k stars 276 forks source link

Attachments broken #1346

Closed tisp00n closed 1 year ago

tisp00n commented 2 years ago

Hi, I have been using KeepassDX for many years and, for the 2nd time, I realize that most of my attachments (text files, PNG with QR codes ...) are unreadable. I'm also using Keepass(.info) on my Windows PC and the KDBX is stored in my Google Drive account to be synced accross my devices: Android & Windows. Pretty bad for a tool where you are supposed to keep your access data safe. I mostly add entries on my Windows PC, but also sometimes on KeepassDX. Any idea what is going on? Thanks

J-Jamet commented 2 years ago

Any idea what is going on?

Yes, my first thought is that the synchronization simply went wrong. It is possible that the save file stream is interrupted during a transfer, the probability of this happening during a synchronization is higher simply because the database is bigger. And since it's up to the synchronization application to handle this problem, it can't be solved from KeePassDX.

Pretty bad for a tool where you are supposed to keep your access data safe.

I don't think Google drive had this goal in mind when they created their application. ;) If you think the problem is with KeePassDX, try to reproduce the problem with a database that exclusively uses the phone's default DocumentsUI application with a local file.

Bypass solution under study: https://github.com/Kunzisoft/FileSync

Edit : more explanation in the wiki page https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync

Please fill in the bug template correctly in order to have as much information as possible to understand where the problem comes from

tisp00n commented 2 years ago

Any idea what is going on?

Yes, my first thought is that the synchronization simply went wrong. It is possible that the save file stream is interrupted during a transfer, the probability of this happening during a synchronization is higher simply because the database is bigger. And since it's up to the synchronization application to handle this problem, it can't be solved from KeePassDX.

Hi, thanks for your feedback. In case of a file stream corruption on Google Drive layer, wouldn't this have broken the entire kdbx file making it unreadable? In all the cases this issue occurred, only the attachments were broken, never the remaining data.

Pretty bad for a tool where you are supposed to keep your access data safe.

I don't think Google drive had this goal in mind when they created their application. ;) If you think the problem is with KeePassDX, try to reproduce the problem with a database that exclusively uses the phone's default DocumentsUI application with a local file.

I have tried downloading the kdbx file on the phone (in local storage, not the Google Drive cache) and made some changes, but the attachments remained in place and in shape. I have not made tons of tests though...

I have attached the kdbx file and left one corrupted entry: ConnectionData.zip Password is "password". Maybe this can help to understand what happened?

Bypass solution under study: https://github.com/Kunzisoft/FileSync

Edit : more explanation in the wiki page https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync

Please fill in the bug template correctly in order to have as much information as possible to understand where the problem comes from

J-Jamet commented 2 years ago

Hi, thanks for your feedback. In case of a file stream corruption on Google Drive layer, wouldn't this have broken the entire kdbx file making it unreadable? In all the cases this issue occurred, only the attachments were broken, never the remaining data.

Good suggestion. For me it is possible that header file data is corrupted during a transfer, so only affects encrypted blobs (here data related to attachments). But I'm not sure of anything at all without having reproduced the problem.

I have attached the kdbx file and left one corrupted entry: ConnectionData.zip Password is "password". Maybe this can help to understand what happened?

Maybe, I will study the format of the data in this database.

Chouffy commented 2 years ago

I also experience this issue using Nextcloud as a sync provider. And just like @tisp00n says, only attachments are broken, all other data (passwords, notes, even KPRPC JSON) are fine. Also, my whole database is 942 KB so I would exclude a sync issue

Chouffy commented 2 years ago

There seems to be a correlation between the database and/or an item size and this bug occurring. I'm currently trying to reproduce the error but I cannot do that consistently:

And using the above provided database and adding a KPRPC JSON field, it just works 🤔

Chouffy commented 2 years ago

Also, you asked for the issue template to be filled so here is it:

Describe the bug

Every attachments are "broken" after saving an edited KeePass database using KeePassDX

To Reproduce

Steps to reproduce the behavior:

  1. Open KeePass on desktop
  2. Create a new Entry
  3. Attach a picture to this entry
  4. Save the database
  5. On mobile, open KeePassDX
  6. Open the database in edit mode
  7. Edit an Entry
  8. Save the entry / the database

Expected behavior

Save all attachments without modifications, so they can be opened later.

KeePass Database

KeePassDX:

Android:

Additional context

Add any other context about the problem here.

J-Jamet commented 2 years ago

Thank you @Chouffy for your detailed feedback, it is much appreciated and will allow to go much faster in the analysis of this issue. My first guess now: Maybe there is a conflict with the protected data in memory in the XML formatting.

J-Jamet commented 2 years ago

Sorry guys but I still can't reproduce the problem. I create the file well with KeePass (2.51.1), add an image, then send the file to KeePassDX (3.4.5), modify the entry and save but I have no error. I am able to reopen the image after opening the database again.

Can you try to reproduce the problem on your side by doing a manual file transfer from PC to Android to see if the problem is still reproducible?

Kee requires registration and endless reading of Terms of Service so I haven't tested it.

Chouffy commented 2 years ago

I've tried to reproduce the issue from a new database. Here's my test log, but unfortunately I wasn't able to reproduce it either... At the moment I implemented a "workaround": all previous attachments are now files somewhere else, and the KeePass database doesn't contains them anymore. So it'll be difficult for me to check if this bug reoccurs or not in the near future.

--- Test log below ---

KeePass 2.51.1 on Windows x64 KeePassDX 3.4.5 on Android Files that I've generated:

On PC:

  1. Create a new Keepass database with password "helloGithub"
  2. Define database settings
    1. Key transformation of 70000000 (~ 1sec delay on my local machine)
    2. Other settings as default: Compression = Gzip, recycle bin = true
  3. Create some entries from KeePass (by using duplicate)
  4. Create some entries from Kee using https://www.w3schools.com/Tags/tryit.asp?filename=tryhtml5_input_type_password
  5. Attach some images to the Kee entries
  6. Attach a 10 mb zip file
  7. Close the database
  8. Save a copy of the databse, name is "AttachementsBrokenDatabase_1.kdbx"

On Android:

  1. Copy the KDBX using ADB via USB
  2. Open the database in KeePassDX in read-write mode
  3. Check that an image can be shown in the "internet" group
  4. Edit one of the entry and press save

On PC:

  1. Retrieve the database, name is "AttachementsBrokenDatabase_2.kdbx"
  2. Open the databse on KeePass
  3. Check that one image can be opened as expected
  4. Change the MasterKey to add a Key File, attached "lorem.txt"
  5. Save the database

On Android:

  1. Copy the KDBX and the lorem.txt file using ADB via USB
  2. Open the database and save fingerprint
  3. Check if image works
  4. Close and reopen the database as read-write

... still working as expected 😕🤔

J-Jamet commented 2 years ago

Thanks for the feedback. I have improved the save routine in version 3.5.0, so if the problem was in an error in formatting attachments during save it will be implicitly solved in the next version.

I can't reproduce the problem, so I leave the issue open. You will tell me if it happens again in version 3.5.0, if I have no feedback on this version I will consider the issue solved.