>> -------------------------------
>> XOR File Destroyer
>> VERSION 2 (WinXP+ Edition)
>> File corruption made easy
>> June 2011
>> -------------------------------

 _______________
[ WHAT IS THIS? ]
#################
 XOR-FD is a utility for XOR-encrypting your files. XOR encryption is quite weak despite the cool-sounding name. Actually it is only as weak as the encryption key. If the key is as big as the file-to-be-encrypted, a phenomena called "one-time padding" will occur. One-time padding is unbreakable, because there's nothing to break. If you don't have the key there's no way you can un-pad the original data. (Remember: the key must be totally "unguessable" for OTP to happen.)

 _____________
[ THE LICENSE ]
###############
 See the file `copying.txt' which should be in the same directory as this file, for the license of this Software (which is the source-code, documentation, and other related data including the executables).

 _______________________
[ HOW CAN I COMPILE IT? ]
#########################
 This is the Windows XP/Vista/7 x86 (32-bit) version. It was tested to build with latest (2011) edition of MinGW. You will most likely download a small web installer, from Sourceforge. When you install it make sure you choose to install the MSYS component too (if available). MSYS will provide you with a Unix-like workspace so that you can run the Make utility as you would under Linux.
 A pre-built executable can be found in the `build' directory, if you're the archetypal short-fused teenage Windows user. And no, it won't work if you double-click on it, because it doesn't have a GUI -- so you need to launch it from the Command Prompt. Hello, you still there?

 To build it follow these steps (obviously after installing MinGW):
1. Copy the extracted folder to C:\MinGW\msys\1.x\home\YourUsername\
2. Start the MinGW Shell.
3. Type "cd xorcorrupt" without the quotes, and press Tab (it will autocomplete the filename) then Enter
4. Type "./build.sh" without the quotes, and it'll build a new executable in the "build" directory

 You can ignore the warning messages about redefining some MSVCRT things.

 ________________________
[ A CASE AGAINST WINDOWS ]
##########################
 I went through this "port" to save other people the hassle. I just knew there had to be small bugs and incompatibilities, and goody goody, there were. Microsoft doesn't like to abide by standards lest it would hurt their profits. And that deliberate non-standard design is passed on to the ported compilers, such as in the MinGW suite (since the compiler developers' interest is that their own compiler can seamlessly replace the native compiler of the target OS). I've had to taint my code with the non-standard type `off64_t', use the non-standard `fseeko64()' function, and the non-standard "I64d" format specifier for `printf()' instead of the regular "lld". What does this mean to you as a user? Nothing really. But to a developer, it means tainting their code so that it needs "porting" and glitch fixing when switching the target OS, in the circumstance when your code isn't really broken at all! That's nasty, and Microsoft are doing it on purpose. Being broken helps keep the developers on their side.
 The Windows command console is also horrible. By design of course, so that people avoid using it.
 It's not my job to try to persuade you to migrate to a free ("free as in speech") Unix-like operating system. So I won't!

 _____________________________________________
[ WHAT ARE ALL THESE FILES AND FOLDERS ABOUT? ]
###############################################
 I decided to present them as a list, `+' (plus sign) marks directories, and `-' (minus sign) marks files. Additional text files (mostly "readme" files) could be found inside any given directories offering more detailed information on that specific folder's contents.

 + build = will contain executable program after compilation succeeded
 + docs = contains developer documentation
 + source = contains the actual source-code of the program
 + test = contains the tests used to ensure that components from `source' worked correctly
 - bugs.txt = lists found bugs and their fixes
 - build-nomake.sh = script which compiles the source code (`gcc' needed)
 - build.sh = script which automatically runs make utility (`gcc' and `make' needed)
 - clean.sh = script which cleans backup files, object files and executable files from `source', `build' and current directory
 - copying.txt = the license of this Software
 - readme.txt = TODO: figure it out yourself
 - ID file = allows for easy identification of the project through its name and version

 ______________________________________________
[ HOW CAN I GENERATE HUGE KEYS FOR HUGE FILES? ]
################################################
 Either with a customised version of CrazySumForPasswords, or by using another file as the key.
 CSFP is why I started this project. You may find other XOR encrypting programs out there, with a fancy User Interface, or written in a fancy bloated way. My version is an attempt to simplicity and robustness. And interoperability with CSFP.

 ________________
[ USAGE EXAMPLES ]
##################
 Synopsys is as follows (the order of the arguments must be respected):
 (NOTE: You're expected to run the program from the Command Prompt.)

 program_name [file_to_be_encrypted] <[resulting_file] [file_used_as_key]>

"stdin" Standard Input examples:
	echo "This text is the key" | xorcorrupt.exe file.txt file.txt.xorred
	echo "This text is the key" | xorcorrupt.exe file.txt

 IMPORTANT:
  In the second example above, the original file will be overwritten.
  Also, if you fail to provide standard input data, the program will jam.
  (Translation: don't start it with one or two arguments but without a pipe.)

Filename example:
	xorcorrupt.exe ABIGISOOFSOMETHING.ISO ABIGISOOFSOMETHING.ISO.x keyfile.txt

 ______________________________________________________
[ YOUR PROGRAM IS BLOATED AND YOUR STYLE IS UGLY. WHY? ]
########################################################
 We do not (yet) have perfect computers. And if hardware can't be perfect, neither can software. My program is bloated in order to compensate for the imperfections found in the real world. Hardware failures can occur, which could prevent accessing a file. Hardware is also slow. The perfect, flawless way of reading or writing files would be by the smallest amount possible per cycle, that amount being one byte. But if you do that, you'll notice your program is painfully slow, because of hardware. So you need to use buffers, thereby increasing the complexity of your code. Finally, there are users who will try to take advantage of the real world imperfections of hardware and software. This means you need to add input sanity checking and validation.
 That's why my program is bloated and my style is ugly; error checking, performance tuning and sanity checking had to be added. More modern programming languages (and their compilers) partially take care of this, automatically. Which is why I'm planning to switch to C++. Oldskool C is good for quick projects, but wastes your time when quality is desired. Not talking about driver and kernel programming where C remains an excellent choice, but about small utilities. Such as this one...

 ___________________________________________________________________________________
[ WHEN WILL YOU CODE A GRAPHICAL USER INTERFACE BECAUSE I'M TOO LAZY TO TYPE STUFF? ]
#####################################################################################
 I probably never will. Do-It-Yourself, that's what open-source is about!
 There are dangers in coding a GUI. Not only are you relying on others' sometimes poorly designed framework, you also taint your code so that users may not be able to run or even compile your program in their environment... at least not without having to install a myriad of extra libraries they don't even need for anything else. I prefer a "self-sufficient" model. A second line of developers can "improve" my program into a dependency monster if they so choose; my hands are clean.

 UPDATE: A project named "wxWidgets" stirred up my interest. I guess it would be fun but I'll have to split the versions.

 _______________________________
[ HOW DOES THE XOR METHOD WORK? ]
#################################
 XOR comes from "eXclusive OR", and it's the logical operator which returns a value of True (one) if and only if operands are unequal, and returns a value of False (zero) if the operands are equal. All possible bitwise operations are:

 OP1  OP2    RESULT
 ------------------
 0    ^ 0    = 0
 0    ^ 1    = 1
 1    ^ 0    = 1
 1    ^ 1    = 0

 Two properties are evident from the table above. First, the order of the Operands is irrelevant, and second, if you XOR one Operand with the Result you get the other Operand. In other words, the XOR encryption is symmetrical. In practical terms, encryption cancels itself when applied twice (or an even number of times).
 And as you probably already know, digital computers store all information as a sequence of 1's and 0's. So until quantum desktop computers come along, we can all happily use XOR.

 __________________________________________
[ WHY USE XOR INSTEAD OF... ANYTHING ELSE? ]
############################################
 The way I see it, the "real" ciphers out there are nothing more than glorified math tricks, adapted to a world in which genuine one-time padding is too cumbersome for practical applications... if you want to encrypt a CD image that way you'd have to store a padding information its size! Ciphers try to emulate the strength of one-time padding by using algorithmic padding. It's neat but fake, and sooner or later they will all be broken.
 I still have some reading to do on the subject, so who knows, maybe I'm just another ignoramus who's wrong.

-RF
