From 03c5fce0220d3e5d02d320f925a3b9401a397729 Mon Sep 17 00:00:00 2001 From: "@syxhe" Date: Thu, 26 Dec 2024 21:42:53 -0600 Subject: Put some notes down --- notes.txt | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 notes.txt (limited to 'notes.txt') diff --git a/notes.txt b/notes.txt new file mode 100644 index 0000000..fb6f283 --- /dev/null +++ b/notes.txt @@ -0,0 +1,46 @@ +This is a file of ramblings and notes for what I'm doing + +vxgg originally only encrypted the /home directory and its subdirectories. As of now, I believe it should +also encrypt the /root dir as well. Running as a daemon and setting things up in the background may be +a good idea as well + +vxgg was not atomic in its encryption, in that if the encryption was in progress and interrupted for whatever reason, the original +file would be "irrecoverably" (as in vxgg had no error checking and couldn't tell the difference between an encrypted and +unencrypted file other than through filename. You could manually unfuck the file yourself if you had the key, but it would be a +long and tedious process) fucked. I can't possibly make the entire operation of reading and writing to a file atomic, but I can +make the action of "encrpytion" atomic; or, at least, I can make the encryption seem atomic through a cheat: hard linking. Turns out +that you can make a file in /tmp, fill it with a whole bunch of shit, then hardlink it to somewhere else on the drive, and the +file's contents will persist after a reboot. The idea here is to open a file in /tmp, write the encrypted contents to it, and then +hardlink the encrypted file to the same location as the original, and then delete the original. This way, if the process is +interrupted, there is no chance of file loss. The hardlink isn't atomic in terms of being uninterruptable and instant, but the +specific order of "encrypt in tmp, hardlink, delete real file" will, at very least, minimize the chances of irrecoverable data loss. +I'm trying to encrypt people's drives for fun, not for malicious purposes. The least I can do is make sure I don't lose their data + +The only issue I see with hardlinking is that it's possible that, for some reason (linux pedants), the /home and /tmp folders are +not in the same partition/drive. The simple solution I see for now is creating a hidden, root owned, chmod u=rwx,go= folder in +/home to store files as they are being encrypted + +Nevermind, another problem I see is that permisions and filetypes may be different. Not that I ever tried vxgg on a symlink, but I +wouldn't be surprised if it worked fine (given that all vxgg does is rewrite the contents of a file), but this solution would break +those links. If this is a problem, it'll be interesting to see how I should make exact copies of files before encrypting them + +I really need to figure out how to determine if a filesystem is a Large File System (LFS) so I can know whether to use the standard +or 64 bit versions of functions + +Ok so supposedly stat and its variants will work with 64 bit systems using LFS fine because of some macro "_FILE_OFFSET_BITS", but +I'm not certain if I need to figure this out or what. Also, it's a compile-time thing, and preferably I don't need to compile this +on each system I infect, so I still need something else + +mkstemp might be quite a useful function for doing the encrypting thing, but having a template name might be problematic. I may just +have to rename everything before linking. Maybe linkat() would work + +============== LIST OF POTENTIALLY USEFUL GNU C FUNCTIONS ============== + scandir() - Gets a list of files in a directory: https://www.gnu.org/software/libc/manual/html_node/Scanning-Directory-Content.html + link() - Hardlinks one file to another location: https://www.gnu.org/software/libc/manual/html_node/Hard-Links.html + canonicalize_file_name() - Get the canonical filename of some path (removes symlinks, /'s, .'s, and ..'s): https://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html + realpath() - canonicalize_file_name(), but you can put the result directly into a user-allocated string: ^ + remove() - Deletes a file or directory according to unlink() and rmdir() respectively: https://www.gnu.org/software/libc/manual/html_node/Deleting-Files.html + rename() - Renames a file or directory, atomically: https://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html + All of the file attribute related functions: https://www.gnu.org/software/libc/manual/html_node/File-Attributes.html + tmpfile() - Creates a temp binary file as if you used fopen: https://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html + mkstemp() - Creates a temp file using a name template and opens it for you: ^ -- cgit v1.2.3