KeePassDX icon indicating copy to clipboard operation
KeePassDX copied to clipboard

Attachments broken

Open tisp00n opened this issue 2 years ago • 10 comments

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

tisp00n avatar May 31 '22 12:05 tisp00n

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

J-Jamet avatar May 31 '22 12:05 J-Jamet

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

tisp00n avatar Jun 21 '22 09:06 tisp00n

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.

J-Jamet avatar Jun 21 '22 13:06 J-Jamet

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 avatar Jul 07 '22 16:07 Chouffy

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:

  • Using my Nextcloud setup

    • Everything works well in this scenario

      1. create a manual new entry on KeePass desktop
      2. attach a picture (still on desktop)
      3. edit the entry from KeePassDX
      4. Check the picture
    • But if the entry contain a KPRPC header (used in Kee), it doesn't:

      1. create a manual new entry on KeePass desktop
      2. attach a picture (still on desktop)
      3. add a KPRPC String field
      • Name: KPRPC JSON
      • "Protect value in memory" is checked
      • Value: {"version":1,"formFieldList":[{"name":"","displayName":"KeePass password","value":"{PASSWORD}","type":"FFTpassword","id":"mydkt-defaut-Password","page":-1,"placeholderHandling":"Default"},{"name":"searchedText","displayName":"searchedText","value":"","type":"FFTtext","id":"menuSearchInput","page":-1,"placeholderHandling":"Default"},{"name":"","displayName":"KeePass username","value":"{USERNAME}","type":"FFTusername","id":"mydkt-defaut-Email","page":-1,"placeholderHandling":"Default"},{"name":"","displayName":"","value":"KEEFOX_CHECKED_FLAG_TRUE","type":"FFTcheckbox","id":"gwt-uid-1","page":-1,"placeholderHandling":"Default"}],"alwaysAutoFill":false,"neverAutoFill":false,"alwaysAutoSubmit":false,"neverAutoSubmit":false,"priority":0,"altURLs":["example.com"],"hide":false,"blockedURLs":[],"regExBlockedURLs":[],"regExURLs":[],"blockHostnameOnlyMatch":false,"blockDomainOnlyMatch":false}

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

Chouffy avatar Jul 07 '22 17:07 Chouffy

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

  • Created with: Windows KeePass 64-bit on Windows 10
  • Version: 2.51.1
  • Location: Remote file retrieved with Nextcloud
  • File provider (content:// URI): content://org.nextcloud.documents/...
  • Size: 952 kb
  • Contains attachment: Yes

KeePassDX:

  • Version: 3.4.5
  • Build: Libre
  • Language: English

Android:

  • Device: OnePlus 6
  • Version: LineageOS 19, running Android 12

Additional context

Add any other context about the problem here.

  • Browser for Autofill: Firefox 102.0 with Kee 3.9.5

Chouffy avatar Jul 07 '22 17:07 Chouffy

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 avatar Jul 10 '22 10:07 J-Jamet

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.

J-Jamet avatar Aug 17 '22 21:08 J-Jamet

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
  3. Key transformation of 70000000 (~ 1sec delay on my local machine)
  4. Other settings as default: Compression = Gzip, recycle bin = true
  5. Create some entries from KeePass (by using duplicate)
  6. Create some entries from Kee using https://www.w3schools.com/Tags/tryit.asp?filename=tryhtml5_input_type_password
  7. Attach some images to the Kee entries
  8. Attach a 10 mb zip file
  9. Close the database
  10. 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 😕🤔

Chouffy avatar Aug 21 '22 15:08 Chouffy

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.

J-Jamet avatar Aug 23 '22 08:08 J-Jamet