How to validate a Save file?

[rufwoof]

For a save file (file filesystem), each time you reboot even without saving, the content of that file changes. At least that is the case for Fatdog 800.

As part of bootup I validate the mbr (dd the first 512 bytes from the partition grub4dos is installed on, and compare that to a pre-recorded version), grldr, vmlinuz, menu.lst and fd64.sfs, using either comparisons to known versions md5sum's (for the larger files), or simple comparison to backup copies of those files (for the smaller files). That way any tampering (intrusion detection) gets flagged at bootup (I run the intrusion detection script in ~/Startup).

A changing save file however is more involved. Ultimately I'll be recording a md5sum for that however in the interim so far my code looks like ...

Code: Select all

# compare only partially, laR fields with a nineth value i.e. actual files
# excluding . and .. files (current directory and parent directory pointers)
# and we don't look at timestamp/date, only ownership, permissions, size and filenames
# We do pick up if files have been removed or added
mkdir /tmp/a /tmp/b
mount fd64save.ext3 /tmp/a
mount fd64save.ext3.bak /tmp/b
ls -laR /tmp/a | awk '{if(($9)&&($9!=".")&&($9!="..")){print $0}}' | awk '{print $1, $2, $3, $4, $5, $9}' | sort >/tmp/a.lst
ls -laR /tmp/b | awk '{if(($9)&&($9!=".")&&($9!="..")){print $0}}' | awk '{print $1, $2, $3, $4, $5, $9}' | sort >/tmp/b.lst
D=`diff /tmp/a.lst /tmp/b.lst`
if [ ! -z "$D" ]; then
	echo warning fd64save.ext3 suspect
	OK=0
fi
rm /tmp/a.lst /tmp/b.lst
umount /tmp/a /tmp/b
rmdir /tmp/a /tmp/b

i.e. I'm comparing mostly (not fully) as being comparable, comparing a backup copy of the fdsave.ext3 file (save area file filesystem) to the one being booted/loaded, in a manner such that the two reasonably extensive comparisons do fully compare.

My question is, is there another easier way that others might be using or might suggest? i.e. how to others go about validating a save file as having been unchanged/the-same, when the save file changes even if you don't save during a session.

TIA.

[s243a]

You could store the checksum of each file (e.g. sha256). This would take less space but would take longer. I would also compare the file size.

[rufwoof]

Thanks s243a. Something like mtree - checking each files checksum, is relatively slow. OK for small sized save file contents but much less so for larger saves.

ls -la and omitting the 6/7/8th fields does include a check against the permissions, owner, group. size and name for each file, and runs through checking all of the files in the save file, along with checking the mbr, grldr, menu.lst, vmlinuz and fd64.sfs in around 10 seconds total time, which is around the longest delay I would like before advising that the booted system looks OK (continuing). Better than nowt, not as extensive a test as it could be with respect to checking the fd64save.ext3 (savefile). Thinking along the lines of additionally including a checksum type test, perhaps separately/backgrounded, along the lines of mtree being set to run against all bin, sbin and lib folders (plus /etc) in the booted system. Combined that would equate to the save files content having been validated reasonably enough IMO.

More a case of thinking through possible alternatives - that might already be out-there. If for instance a remote cracker with root access to a session mounted the save-file and injected/changed things in that then their crack would remain persistent into future reboots that used the save file/folder layer. Encryption/lock of the save-file barrier (having to enter a password when booting) blocks that, but has the backdoor wide open (booted internet facing system/browser that could record changes in the ram based save area, that would get saved if a save were made during that session).

Frugal booting using HDD is a nice/simple way to go, however I guess the better practice is to usb boot (mbr, grldr, vmlinuz, fd64.sfs on usb) where that usb is removed once booted, only reattaching when a save is to be made and only saving after having booted a 'clean' session, making the changes and saving those (otherwise just shutting down without the usb and without saving changes), and where the HDD based save file is encrypted. Which mitigates the need for the above/earlier validations. More a case of looking for how similar protections might be applied when using different arrangements to that (such as booting when everything is on HDD (no usb being used)).

[musher0]

Why would one do this?

[rufwoof]

Why would one do this?

I now store my save files (multi-session) on the boot usb ... that I disconnect after booting. So no in session cracking of the mbr, grldr, vmlinuz ...etc. including the save files.

Otherwise (to reiterate) a cracked session ... mount a save file and insert/change as a cracker may desire and umount ... and the crack remains persistent across reboots.