Page 1 of 1

KDBX 4.1 recovered by PhotoRec opens with correct password but XML shows empty groups — raw strings contain real data

Posted: 23 Mar 2026, 05:24
by cyberfalcone
Hi everyone,
I'm trying to recover a KeePass 4.1 database that was accidentally overwritten on a Debian Linux system (single disk, no backup). I used PhotoRec to recover deleted files and got ~44 .kdbx files. Here's what I've found so far:
Setup:

OS: Debian Linux
KeePass version: KeePassXC (KDBX 4.1)
Recovery tool: PhotoRec (default options, only kdbx extension selected)
Python lib used for analysis: pykeepass 4.1.1

What works:

All recovered files open successfully with the correct password
Groups are intact: ['Raíz', 'Falcone', 'Factoria', 'Duo', 'Alligare']
The largest file (44MB) decrypts without errors

The problem:

pykeepass and keepassxc-cli both report 0 entries across all large files
Direct XML inspection via kp.tree.getroot().findall('.//Entry') also returns 0
The XML structure shows Meta and Root nodes, but Root contains only empty groups
The recovered files grow progressively in size (4KB → 44MB), suggesting each version captured more adjacent sectors from disk

Suspicious finding:
Running strings on the 44MB file reveals real URLs and data that belonged to the original database entries — including specific website URLs, Facebook Ads account IDs, and Google Analytics property IDs that I recognize as mine. This data is visible in the raw binary but not accessible through the decrypted XML.
What I have tried:

keepassxc-cli ls -R -f → shows empty groups
pykeepass direct XML parsing → 0 entries
Brute force password variations on 3 files with different credentials → no success yet
Checked Windows machine (same network) → identical files, no additional copies found
Checked cloud storage and mobile → not used

Question:
Is it possible that PhotoRec recovered a version of the file where the encrypted payload contains the correct data, but the XML index points to an empty state? Is there any known tool or technique to extract or reconstruct entry data from a KDBX 4.1 file where the XML shows empty groups but raw strings suggest the data exists in the binary?
Any guidance on low-level KDBX 4.1 structure, or tools that might help reconstruct the entries, would be greatly appreciated.
Thanks in advance.

Re: KDBX 4.1 recovered by PhotoRec opens with correct password but XML shows empty groups — raw strings contain real dat

Posted: 23 Mar 2026, 09:46
by recuperation
cyberfalcone wrote: Yesterday, 05:24 Hi everyone,
I'm trying to recover a KeePass 4.1 database that was accidentally overwritten on a Debian Linux system (single disk, no backup). I used PhotoRec to recover deleted files and got ~44 .kdbx files. Here's what I've found so far:
Fragmentation reduces the chance of file recovery when using PhotoRec. You were searching for one database and found 44 files. According to https://keepass.info/features.html#lnktrans a database only needs one file. That should ring a bell in case you are not using a copy-on-write file system.

Setup:

OS: Debian Linux
KeePass version: KeePassXC (KDBX 4.1)
Recovery tool: PhotoRec (default options, only kdbx extension selected)
Python lib used for analysis: pykeepass 4.1.1

What works:

All recovered files open successfully with the correct password
Groups are intact: ['Raíz', 'Falcone', 'Factoria', 'Duo', 'Alligare']
The largest file (44MB) decrypts without errors

The problem:

pykeepass and keepassxc-cli both report 0 entries across all large files
Thank you for your trust in TestDisk support! But pykeepass and keepassxc-cli is third party software. You should contact their support.
Direct XML inspection via kp.tree.getroot().findall('.//Entry') also returns 0
The XML structure shows Meta and Root nodes, but Root contains only empty groups
Without knowing anything about their software, these are signs that the recovery failed but decryption itself succeeded which contradicts my statement.
The recovered files grow progressively in size (4KB → 44MB), suggesting each version captured more adjacent sectors from disk
Rerun PhotoRec with the /log parameter to learn where the recovered files were recovered from:
https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
Suspicious finding:
Running strings on the 44MB file reveals real URLs and data that belonged to the original database entries — including specific website URLs, Facebook Ads account IDs, and Google Analytics property IDs that I recognize as mine. This data is visible in the raw binary but not accessible through the decrypted XML.
What I have tried:

keepassxc-cli ls -R -f → shows empty groups
pykeepass direct XML parsing → 0 entries
Brute force password variations on 3 files with different credentials → no success yet
Checked Windows machine (same network) → identical files, no additional copies found
Checked cloud storage and mobile → not used

Question:
Is it possible that PhotoRec recovered a version of the file where the encrypted payload contains the correct data, but the XML index points to an empty state? Is there any known tool or technique to extract or reconstruct entry data from a KDBX 4.1 file where the XML shows empty groups but raw strings suggest the data exists in the binary?
Any guidance on low-level KDBX 4.1 structure, or tools that might help reconstruct the entries, would be greatly appreciated.
Thanks in advance.
Sorry, obviously none of these are PhotoRec-related questions!

If decrypted data follows an XML scheme reverse engineering becomes much easier.
Start with a new Kepass database and let it grow by inserting entries. That way you learn how the structure is supposed to be. Then look at a bigger database und compare that to your findings.

Good luck!