I decided to upgrade from 4.2 to 4.3. I backed up all my vms to an encrypted drive. The password is stored in a keepassxc database. I copied the database file locally to a flash drive, as well as to an encrypted cloud provider.
After wiping the drive and doing a clean install of 4.3, I attempted to open the keepassxc database. When doing so, I get the error "Invalid inner header length: field 3: expected nnnnnnn read nnnnnn.
I thought maybe it was a compabitlity issue between versions, so installed (what I believe to be, I’m not certain) the same version of keepassxc used in 4.2, but received the same issue.
Question 1: How could both files become simultaneously corrupted? I’ve done this process before when finishing projects and working for a different client to ensure no cross contamination of proprietary and sensitive data and never had an issue.
I have an old mac from ~4 years that has copy of the original kdbx file. Its the exame same file as the corrupted one, just missing alot of data. I copied it to the qubes laptop, and it opened without issue. I then tried to merge the databases, but receive the error “Error while reading the database: Not a keepass database”.
Question 2: Is there a way to use the working, old database to extract the data from the corrupted one so I can recover the password of the encrypted drive storing my data?
Question 3: The generated password for the encrypted drive follows a custom algorithm. I know most of the password with the exception of n characters which are sequential and only alphanumeric. Are there tools I could use to brute force it?
I believe this shows that the database is corrupt.
Unlikely. More likely is that the database was corrupt (for whatever
reason) and you took copies of the corrupted database.
I doubt that.
Yes, and this is likely your best bet.
You havent said what sort of encryption is involved, or whether
the cloud provider will allow you to brute force it. On the provider
is the whole content encrypted, or is each individual file encrypted
separately?
Whatever you do I would make sure that you have a full copy of the
remote drive - your provider may help you to do this. If they enable you
to make a local copy of the remote drive, that would make it easier
for you to bruteforce it.
Do you not have any backups of the data from your 4.2 install?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Unlikely. More likely is that the database was corrupt (for whatever
reason) and you took copies of the corrupted database.
I locked the db, closed keepassxc, then copied the db file mere seconds later. I guess it’s possible.
You havent said what sort of encryption is involved, or whether
the cloud provider will allow you to brute force it. On the provider
is the whole content encrypted, or is each individual file encrypted
separately?
I don’t remember exactly which encryption method(s) were used when creating the keepassxc database. And it’s a local file, not one created by the cloud provider. If their claims of e2e encryption are true, they’re not even aware what kind of file it is. But removing the copy stored in the cloud, the local copy I backed up would have none of the issues that brings.
Whatever you do I would make sure that you have a full copy of the
remote drive
The encrypted drive is local, not remote. The password to the encrypted local drive is stored in the corrupted db file, which was backed up both locally on a usb drive and to the cloud provider.
Do you not have any backups of the data from your 4.2 install?
All my backups of the 4.2 install are on the local encrypted drive.
I understand this - but you said " I copied the database file locally to
a flash drive, as well as to an encrypted cloud provider".
And you said “The generated password for the encrypted drive follows a
custom algorithm”. I misheard these two completely.
So, take a backup of the encrypted drive. Use cryptsetup luksDump to
get basic information about the encryption.
Your options are pretty limited for LUKS 2 - you can use john to generate
wordlists using your custom algorithm. (WRITE IT DOWN NOW YOU REMEMBER
IT), but for more recent LUKS you could try bruteforce-luks, packaged
for Debian (maybe Fedora too). It’s designed for exactly this sort of
situation and has the capability to build off the section of
password you remember. Take a full image copy of the drive first
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.