2

This question is about the optional encryption of user data with the live Linux distribution KNOPPIX v6.2 (2009-11-18), which as I understand is based on Debian.

I do not use this old version anymore, but I am trying to retrieve years-old data from the persisted data file knoppix-data.aes created by KNOPPIX v6.2 in the startup prompts. The file is one byte less than 4 GiB.

I was hoping someone who knows about Linux encryption standards going back to the late 2000s might be able to provide some information about this file (as I shall explain below). I'm not very familiar with Linux encryption standards, and am a bit overwhelmed by the myriad of terms I see (like "LUKS", "dm-crypt", etc.) -- I'm not certain which, if any, applies to my situation with late 2000s Knoppix.

Obviously the ".aes" in the file name indicates AES encryption. At first I suspected I was typing the password incorrectly, but now I wonder if there might be another issue that would render my attempts to correctly type the password futile. I will explain:

When I view the file with a hex editor, it's surprising to see that the beginning of the file is a cleartext list of file names and hashes, e.g.:

f4374a5897aafd09a2439f6c3f4a961d5cc7c1a1 *autorun.bat
eaf953dce8de1442e4e32769260e22435a70f3bc *autorun.inf
(etc.)

(also included are hashes for many files that obviously relate to Knoppix, such as KNOPPIX/knoppix-logo-small.png, to give one example)

The beginning bytes seems to match exactly with the plaintext file /mnt-system/KNOPPIX/sha1sums (on the USB drive where Knoppix is installed, so it's apparently part of the Knoppix installation). After that there are expanses of null bytes (00), and then random gibberish. I was expecting the entire thing would be random gibberish; in the context of AES encryption, the cleartext at the beginning of the ".aes" file would seem to be incongruous.

As a test, I powered off, renamed the original AES file, and then rebooted and created another knoppix-data.aes that is 256 MiB, with password "123456789". This one does not contain the cleartext at the beginning, and I am able to write to it (and successfully decrypt it on subsequent boots).

But I don't know about this opaque file format (or where the documentation for it is), other than it (presumably) involves an AES algorithm (but I have no details about mode of operation, key derivation, header, etc.). In particular, is it normal to have this cleartext stuff (sha hashes and file names) at the beginning of the file, as some kind of header, perhaps? Or would it indicate that the file has somehow become corrupted (such as by being concatenated with the sha1sums file in some bizarre circumstances)?

If the answer is that it's normal for the cleartext sha1 sums to be there, does that mean I need to provide an offset to losetup to move past the cleartext? I'm currently using

echo "mypassword" | losetup -p 0 -e aes -k 256 /dev/loop2 knoppix-data.aes
mount /dev/loop2 /media/mydir/

to avoid having to reboot every time I want to attempt decryption. This works for the 256 MiB test version of knoppix-data.aes, with password "123456789" and with no cleartext at the beginning, but not for the original 4 GiB file that has the cleartext hashes (it complains about the file system not being specified, which presumably means that it cannot be automatically determined, which presumably means that the decryption produced gibberish rather than the desired data, possibly because the cleartext is not supposed to be there, or because losetup needs an offset to move past it).

0

Well, corruption seems like the only possible explanation (someone did a cp file /dev/loopX or similar). loop aes does not have metadata so the file should be random throughout (perhaps except for sectors that were never written to, i.e. "free space").

You don't want an odd offset, you need to use the original offset to have any chance of decrypting the parts that were not overwritten.

Unfortunately loop aes is not a very consistent standard, see also loop-aes observations from the cryptsetup FAQ.

The only case where a changed offset would be applicable is if the file was actually produced by cat cleartextfile aesfile > newaesfile or similar, i.e. if the data were whole but moved to a later offset in the file. But then you'd have an odd file size, not 4G sharp, so you can rule that one out.

it complains about the file system not being specified

Well, that's expected if the filesystem headers got overwritten - you have to look at the decrypted raw data to find out if there's anything non-gibberish in it. Whatever is cleartext in the aes file will be gibberish in the decrypted view, no matter which password you choose...

| improve this answer | |
  • It's weird, I don't remember doing something like cp file /dev/loopX (years ago I successfully mounted it and since then the USB stick has been collecting dust), and I can't imagine why I would have any interest in copying the "boring" sha1sums file from the installation; but as you say corruption seems the likely explanation. – Keith Jun 26 '19 at 11:48
  • I understand your point that loop aes does not have metadata, but I wonder, is it possible that the developers of Knoppix used an undocumented file format which included a header, and which relied on loop aes for the post-header part? But arguing against that hypothesis would be the fact that the 2nd knoppix-data.aes I created does not have the cleartext at the beginning. But your answer gave me the idea that I could search the raw decrypted data for the word "rescue", as I'm pretty sure I had saved a script that invoked either dd_rescue or ddrescue. – Keith Jun 26 '19 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.