Page 1 of 1

Recover encrypted save.dat

Posted: 11 Jan 2013, 14:16
by maverick
Hello everyone,

I just had a hard reset which seems to have corrupted my save.dat file (several messages at boot and shutdown asking me to run xfs_repair). Unfortunately I was not able to perform the recovery neither from the Porteus save.dat utility nor manually with xfs_repair in Parted Magic because my save.dat file is encrypted. Any ideas on how I could repair this? I am running Porteus 1.2 Final.

Many thanks.

Re: Recover encrypted save.dat

Posted: 11 Jan 2013, 15:26
by brokenman
Try manually decrypting the file and then running your xfs_repair

Code: Select all

openssl aes-256-cbc -d -in /path/to/encrypted.dat -out /path/to/decrypted.dat
Make sure you swap /path/to/encrypted.dat for your encrypted .dat

Re: Recover encrypted save.dat

Posted: 12 Jan 2013, 06:34
by maverick
Thanks brokenman. Unfortunately this returned an error:
root@PartedMagic:/# openssl aes-256-cbc -d -in /media/sdb2/porteus/porteussave.dat -out /tmp/porteussave.dat
enter aes-256-cbc decryption password:
bad magic number

Re: Recover encrypted save.dat

Posted: 12 Jan 2013, 07:16
by fanthom
@maverick
please make a backup of your save.dat first.
you can try to mount corrupted .dat with 'mloop' utility (i have added support for encrypted containers some time ago) with:

Code: Select all

mloop /path_to/save.dat
after entering the password it will be mounted in /mnt/loop as normal.

now please run 'umount /mnt/loop' command and perform xfs_repair on /dev/mapper/mloop-crypt (this is where cryptsetup mapped your save.dat).
once finished please run:

Code: Select all

cryptsetup luksClose mloop-crypt
if xfs_repir wont help then you may have to mount save.dat again with 'mloop' and recover data manually (copy to another place) then create second encrypted container and copy recovered files back to it.

please let us know if any method worked for you.

Re: Recover encrypted save.dat

Posted: 12 Jan 2013, 13:07
by brokenman
It would be nice to get a copy of the corrupt changes file (only if you consent) so i can work on the recovery section. I found it difficult to purposely corrupt a changes file.

Re: Recover encrypted save.dat

Posted: 21 Jan 2013, 14:56
by maverick
@fanthom
Thank you so much! mloop then xfs_repair worked like a charm, and it only took a few seconds.

@brokenman
I really wish I could help but my save.dat contains some sensitive information. Sorry :(
This said, I can explain how the corruption happened in case you are interested in replicating it. I had Google Chrome open with quite a few tabs, and a KDE pop-up showed up asking me if it was OK to delete certain video and sound drivers which were no longer in use. The computer froze as soon as I clicked on OK and after a hard reset I discovered that the partition was corrupt.

Interestingly after the repair I noticed that I only had 20 MB of free space left in my 1.5 GB save.dat file (even after running Sweeper) which was very surprising. Upon further inspection using du I found out that /var/log/syslog and /var/log/messages were taking up 1.1 GB on their own (at least partially due to the file system corruption errors) so I truncated them and deleted /var/tmp/kdecache-guest from within LXDE which brought my used space down to just 375 MB. I propose one of the following 3 measures which could save beginner users a lot of headaches:
1- Limit the size of these log files
2- Automatically exclude them from save.dat
3- Develop a custom 'Porteus Sweeper' (or maybe there is already something similar out there) kind of utility which not only deletes browsing history and recent documents but also truncates log files, removes temporary files, resets settings and caches such as the PPM cache, etc.

On a related note, which directories are kept in save.dat? I am asking because my home directory is now 90 MB and my var and tmp folders are 110 MB but there are still 175 MB in use which I cannot explain. Are parts of /usr or /lib also stored in the savefile?

Re: Recover encrypted save.dat

Posted: 21 Jan 2013, 16:58
by fanthom
@maverick
1- Limit the size of these log files
this issue is already being addressed in porteus-2.0 which has 'logrotate' utility included by default.
which directories are kept in save.dat?
all dirs
Are parts of /usr or /lib also stored in the savefile?
yes - every file which is new or got updated (access time stamp changed, etc) is transferred to save.dat.

Porteus-2.0 got 'EXIT:' extension to the 'changes=' cheatcode which (among other features) let's you specify which dirs are saved in save.dat (dirs not listed in /etc/changes_exit.conf are skipped).
to find more about 'EXIT:' extension please have a look here:
http://forum.porteus.org/viewtopic.php?f=53&t=1778

Re: Recover encrypted save.dat

Posted: 21 Jan 2013, 17:16
by maverick
@fanthom
Porteus 2.0 sounds great! I am looking forward to the official release and will check out RC1 in the meantime.

Thanks for clarifying that all directories are part of save.dat. If I understand things correctly, save.dat contains only the files that are different from those in the xzm modules. Is there any easy way of distinguishing these files? For example by bolding their names in the file manager (as Puppy Linux does), or looking in a specific directory/mountpoint (I can't find /mnt/loop), or just running a command that lists the names of the files within a particular directory which come from save.dat.

Re: Recover encrypted save.dat

Posted: 21 Jan 2013, 21:58
by fanthom
save.dat contains only the files that are different from those in the xzm modules
correct
Is there any easy way of distinguishing these files?
proper way of cleaning up .dat container is to:
a) make a backup of your save.dat (just in case you wipe to much)
b) boot in 'Always Fresh' mode
c) mount container with 'mloop save.dat' command
d) delete unwanted files from /mnt/loop directory (this dir is created on the fly so it's always there)
e) reboot with 'changes=save.dat' and make sure nothing broke.

second (and less safe) way is to boot as normal and delete files from /mnt/live/memory/changes folder.
this method is not recommended as direct access to aufs rw branch may cause system instability.