cgsecurity
Feature request: support for .journal files
Most common logs format on Linux. Starts with "LPKSHHRH" magic number.
https://systemd.io/JOURNAL_FILE_FORMAT/
A minimal support has been added in commit a3ad131c358c9622b97166159aab325e3cf6d62b Can you try it ?
I checked it out. I duplicated and deleted one 8.4 MB .journal file and ran recovery. 2 .journal files of rather abnormal for journald sizes were recovered: 5.2 MB and 41.9 MB.
Comparing the internal structure of their headers, including (offset 0x18-0x27) file_id, it does not seem like any one of them is the file I deleted earlier. Probably due to the fact that the deleted file was overwritten by some process in the meantime.
The smaller file lists (at 0x108-0x10F) tail_entry_offset as 0x643470, while file ends at 0x4E9FFF, that can indicate abrupted recovery (larger file had all nulls on it's tail entry place). Although, after, as I remember, successfully finishing the recovery (?) I switched to terminal again and saw the lines:
2 files saved in /run/media/user/.../recup_dir directory. Cannot write file, no space left.
With 951.9 MB still free on USB drive. Likely due to this glitch the files were broken. None of recovered files passed verification.
user@fedora:~/Documents/GitHub/testdisk$ journalctl --directory=/run/media/user/KINGSTON/backup-testing/recup_dir.1 --verify Journal file /run/media/user/KINGSTON/backup-testing/recup_dir.1/f5319080.journal is truncated, ignoring file. 000110: Invalid field hash table hash table item (238/333) tail_hash_offset: 30451004523a0039 000110: Invalid object contents: Bad message File corruption detected at /run/media/user/KINGSTON/backup-testing/recup_dir.1/f5237216.journal:272 (of 41914368 bytes, 0%). FAIL: /run/media/user/KINGSTON/backup-testing/recup_dir.1/f5237216.journal (Bad message)
I have published a new version that try to get the correct filesize and the date/time. You should get better results.