image key file hmac mismatch on Android 12

[rebior]

Describe the bug
For a short time now (since mid of December 2021) I am not able to open my password database with key file any longer. To find the problem I cloned the repo, started debugging the app and found the following:

• When I open the database in an emulated device (Pixel 5 with API 30) it works as expected.
• I again copied the files (database and key file) to my Pixel 6 and tried it there - it doesn't work
• When I open the database in an emulated device (Pixel 6 with API 31) it also does not work.
• So I stepped through the process of opening the database and found that the hmac does not match.
• If the same database has no key file it loads as expected.

So it looks like it is an issue with the newest Android system with Android 12 (ABI x86_64 and API 31)

Expected behavior
The database should load.

KeePass Database

• Created with: Linux KeePassXC 2.6.6
• Version: 4.0
• Location: Copied to internal storage
• File provider (content:// URI): Where do I find this?
• Size: 187 kB
• Contains attachment: No

KeePassDX (please complete the following information):

• Version: 3.0.4
• Build: Free
• Language: German

Android (please complete the following information):

• Device: Pixel 6
• Version: 12

[J-Jamet]

I just tested on emulator and I have no problem.
Can you upload a test database file with its key file so that I can reproduce the issue?

content:// is visible when you go to the database history by clicking on the arrow next to a file name.

[rebior]

Ok, I can now give more precise instructions to reproduce the issue:
It happens with a .jpg image as key file that contains the GPSVersionID exif tag (e.g. GPSVersionID=2.3.0.0). It looks like Android somehow modifies the content of the file when KeePassDX reads it. When I change the extension to .bin everything works. When I remove the GPSVersionID it also works. I've attached such an image

.

[J-Jamet]

Indeed, the header hmac does not give the same result with the .jpg extension and without extension, which is very strange. If the new system starts to modify the data provided from files, it's a bad start. :D

I'll see if there are any new options to add in the stream requests for this problem.

[J-Jamet]

I've done several searches and haven't found a viable way, I think the data is modified by the file provider in the "Files" application of the device before being sent to the stream. So the only solution I see for now is to modify the extension.

[rebior]

I also tried to give the app location permissions, but that also didn't help. For me it looks like a bug in Android 12. Initially this worked on my Pixel 6, so it was introduced some time in December.
The only thing I can imagine is that this is a feature that should prevent circumventing the location permissions by scanning images to get the location. But this is rather useless if renaming the image can be used to circumvent this feature...

[rebior]

Will you report this as a bug in Android?

[J-Jamet]

It should be. Anyway, now that the bug is in production in the Google OS, I'll have to manage a warning message to warn the user, so I'll do that already.

[J-Jamet]

Issue open : https://issuetracker.google.com/issues/218668344 (previous https://issuetracker.google.com/issues/216592436)
Test app : https://github.com/Kunzisoft/SAFIntegrity