1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
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" fucked (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). 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
libevent might be useful to slam everything together for async IO that I don't need to real with, but that also sounds like it would
be a lot of work that I might not need to do. I'm going to do threadpooling first and then make a branch that uses libevent to see
if there's any appreciable improvement in performance
============== 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: ^
|
