YULL ENCRYPTION PRO


Odds and Ends

Check out 2600 Magazine: The Hacker Quarterly. There is a review of Yull in the Winter 2015/2016 issue, which is available on Amazon.

How to use Andromeda encryption in your C# program

It's quite easy:

Where data is a byte[] array of the data you want to encrypt/decrypt.
That's it.

Yull-Reg.exe

What it is and how to use it

Yull-Reg.exe is a console application that adds, modifies and deletes Yull-related entries in the Registry that support the Explorer Context menu.

You might want to make using Yull easier for the members of your group by adding Yull to the Explorer context menu.

With Yull added to your Explorer Context menu, when you right-click on a file you will get YullEncrypt and YullDecrypt as choices.


Running Yull from the Explorer Context menu is the same as running it from the command line or from the GUI except that you don't have to worry about the path to Yull or where the options file is. That's all handled by the Context Menu and Registry settings. And of course, they can be modified by Yull-Reg, running in Administrator mode, as needed.

What you need to run Yull from the Explorer Context Menu

1. The registry entries for Yull are YullEncrypt and YullDecrypt.

They are located in HKEY_CLASSES_ROOT\*\shell

They are handled by Yull-Reg.exe.

2. A key file.

Before you run Yull-Reg, you need to create or designate a Yull key file. Yull can use any file as a key, within the size range of 100-10,0000 bytes. Or you can instruct Yull to create a key file for you. If you already have a Key File and an options file, you are just about good to go.

3. An options file.

This is just a text file (which can be encrypted). It contains all the options Yull uses. See the documentation for YullG for more about the Options File. Yull-Reg is run from the command line, with these parameters (and these parameters are just examples):


yull-reg set c:\yullinstallation\yull.exe R:\yulloptions

This will instruct Yull-Reg to add (or update) YullEncrypt and YullDecrypt in the Registry so the command line, which Explorer will exec, will look like this:
c:\yullinstallation\yull.exe in=%1 @R:\yulloptions

If Yull.exe is on the path, you only need to specify with just yull.exe in=%1 @R:\yulloptions

Of course, the R:\yulloptions is just an example here.

From Explorer, when you right click on a file and select, say, YullEncrypt, Explorer will extract the command line from the Registry and run it as a Command, passing in the file you right-clicked on as the parameter (the %1).

If you have run YullG to create a default folder and default key, you can also run Yull-Reg like this:

yull-reg set c:\yullinstallation\yull.exe /usedefaultoptions

so when you right click on a file and want to encrypt it, it will run this as a command:

c:\yullinstallation\yull.exe in=%1 /usedefaultoptions

c:\yullinstallation\yull.exe and R:\yulloptions are just examples. They would be different on your computer(s).
To delete these Context Menu options just run:

yull-reg unset

You can also run:

Yull-Reg help

or just

Yull-Reg

to see more instructions on how to use it.

File Resizer

During development of Yull I had need of files of specific sizes as well as the ability to easily change those files with certain kinds of data (text or numerica). So I created this simple application, File Resizer.

File Resizer changes file sizes by appending data to the end of a file or by deleting data from the end of a file. It does not keep a record of what it does.

It is IMPORTANT TO NOTE THAT changing a file's size may have serious consequences if that file is relied upon by programs.

This application is available on the Downloads page.

Monobits.exe

All Monobits does is output to console how many 1 bits and how many 0 bits are in a file as well as their ratio. I wrote it because I thought purely random files will likely have a close ratio of 0s to 1s. Not sure if this is true (or obvious). But there it is.

Monobits. Very easy to run: Monobits filename<enter>. Here is the C# code:


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using System.Threading.Tasks;
  using System.Collections;
  using System.IO;

  namespace MonoBits
  {
      class MonoBits
      {
          static public BinaryReader br;
          static void Main(string[] args)
          {
              if (args.Length == 0)
              {
                  Console.WriteLine("MonoBits will count the number of 1 bits and number of 0 bits in a file.");
                  Console.WriteLine("MonoBits requires a file name.");
                  Environment.Exit(1);
              }
              try
              {
                  br = new BinaryReader(File.Open(args[0], FileMode.Open));
              }

              catch (Exception ex)
              {
                  Console.WriteLine(ex.Message);
                  Environment.Exit(1);
              }
              MonoBitsMethod();
              br.Close();
              br = null;
          }
          static void MonoBitsMethod()
          {
              int zeroes = 0;
              int ones = 0;
              int readAmount = 0;
              int readSize = 1000;

              //reads in the file opened by BR and counts the bits 0 and 1
              byte[] buff = new byte[1000];
              while ((readAmount = br.Read(buff, 0, readSize)) > 0)
              {
                  if (readAmount != readSize) Array.Resize(ref buff, readAmount);
                  BitArray bitArray = new BitArray(buff);
                  foreach (bool bit in bitArray)
                  {
                      if (bit) ones++;
                      else zeroes++;
                  }
                  if (readAmount != readSize) break;
              }

              Console.WriteLine("There are " + zeroes + " 0 bits in this file." + Environment.NewLine);
              Console.WriteLine("There are " + ones + " 1 bits in this file." + Environment.NewLine);
              if (ones > 0) Console.WriteLine("The ratio of 0s to 1s is " + (double)((double)zeroes/(double)ones));
          }
      }
  }


See the Downloads page page for the link to download it.

RandNumGen.exe

Random Number Generator. You know how hard it can be to grab a bunch of random numbers. Well, cry no more. RandNumGen will do all that for you. It will generate as many (pseudo) random numbers as you want, both as a binary file and as a series of numbers like

0x3d, 0x9c, 0xee, 0x35, 0x35, 0x92, 0x9b, 0xb5, 0xec, 0x0f, 0xab, 0xef, 0xf2, 0x0a, 0xc1, 0xb2, 0x4a, 0xc1, 0x97, 0x17, 0xe1, 0x41, 0x8f, 0xae, 0x00, 0x6f, 0xd6, 0xb9, 0xee, 0x98, 0x4f, 0xaa, 0x53, 0x0a, 0xf0, 0x24, 0x73, 0x0b, 0x3d, 0xbd, 0xf9, 0x78, 0xb1, 0x3d, 0xa5, 0xea, 0x63, 0x5d, 0xa1, 0x67, 0xf4, 0x66, 0x2d, 0xac, 0xc3, 0x73, 0x14, 0x0f, 0x4b, 0xb3, 0x5c, 0xc8, 0x28, 0x80, 0x4b, 0x89, 0x23, 0x90, 0x62, 0x7f, 0x71, 0x9a, 0x1c, 0xce, 0x1c, 0xb4, 0xc3, 0x4d, 0xab, 0x5d

I have use of this. Don't know if anyone else does.

See the Downloads page.

Here is the code for RandNumGen:

	class Program
     {        static void Main(string[] args)
         {
             if (args.Length != 3)
             {
                 Console.WriteLine(@"Ronald Gans Software Copyright (c) 2016 All Rights Reserved.
 This app may be freely distributed without any restrictions at all.
 Only 3 args: args[0]=size of random data as a positive integter;
 args[1] is file to output to; args[2] is ASCII or BINARY,
 like this: randnumgen 1000 bindata binary");
                 Environment.Exit(0);
             }
             if (args[2].ToUpper() != "ASCII" && args[2].ToUpper() != "BINARY")
             {
                 Console.WriteLine(@"Only 3 args: args[0]=size of random data as
a positive integter; args[1] is file to output to; args[2] is ASCII or BINARY.");

                 Environment.Exit(0);
             }
             int size = 0;
             int.TryParse(args[0], out size);
             if (size==0 || size > 1000000 || Math.Abs(size) !=size)
             {
                 Console.Write("args[0] must be a whole number greater than 0 and less than 1000000.");
                 Environment.Exit(1);
             }
             string file = args[1];
             byte[] random = new byte[size];
             RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
             rng.GetBytes(random);
             if (args[2].ToUpper() == "ASCII")
             {
                 StringBuilder hex = new StringBuilder(random.Length * 2);
                 foreach (byte b in random)
                     hex.AppendFormat("0x{0:x2}, ", b);
                 try
                 {
                     using (TextWriter tx = File.CreateText(file))
                     {
                         tx.Write(hex.ToString());
                         tx.Flush();
                         tx.Close();
                     }
                 }
                 catch (Exception ex)
                 {
                     Console.WriteLine(@"an exception occurred trying to create or
write to the file " + file + ": " + ex.Message);
                     Environment.Exit(1);
                 }
             }
             else
             {
                 try
                 {
                     using (BinaryWriter bw = new BinaryWriter(
         File.Open(file, FileMode.Create)))
                     {
                         bw.Write(random);
                         bw.Flush();
                         bw.Close();
                     }
                 }
                 catch (Exception ex)
                 {
                     Console.WriteLine("an exception occurred trying to create or write to the file " + file + ": " + ex.Message);
                     Environment.Exit(1);
                 }
             }

             Console.WriteLine("DONE");
             Environment.Exit(0);
         }
     }


IsRandom.exe

And while we are on the subject of random numbers, check out my IsRandom.exe program. It uses code directly from the NIST (National Institute of Standards and Technology). I run it against my encrypted output files from time to time. The application reports some encrypted output of Yull are random and some are not. That worried me a bit, but when I ran it against the random output from my RandNumGen app, I got similar results: some were tagged as random, some not. RandNumGen uses Microsoft's RNGCryptoServiceProvider to generate random (or really, pseudo-random) data. I'm not sure why its output sometimes is reported as not random.

This discussion on crypto.stackexchange.com might be helpful.

It seems that the larger the sample the more likely the NIST test will tag it as non-random.

See the Downloads page.

Histogram.exe

I wrote this to see if my encryption app biases the output one way or another. The app is self-explanatory. Requires Excel on the system.


See the Downloads page.

Batch Files

I found these helpful in writing Yull.

@echo off
REM this batch file will automatically run Yull both encrypting and decrypting
REM using the options file. This batch file assumes the keys are the same name
REM as the source file. You can use one key for all, which is better.
REM you could use the default key if you wanted and put that commmand in the options file.
REM You will probably have edit the directories.
REM Yull uses an encrypt source and output dir and a decrypt source and output dir.
REM They don't have to be different.

yull in=%1 /encrypt @yulloptions
yull in=%1.out /decrypt @yulloptions

Of course yulloptions or whatever you want to call it has to be your options file.

REM use this to compare the source and final output files to confirm they are identical
REM this uses my program fcomp.exe which is like fc.exe but just says if the files
REM are the same or different.

@echo off
		setlocal enableextensions enabledelayedexpansion
		<"dir.txt" (
			for /f "usebackq delims=" %%b in ("keys.txt") do (

				set /p "valueA="
				call doyull.bat !valueA!  %%b
			)
		)

You need to create a dir.txt file. I do this via dir /b >dir.txt. Same for the keys.txt if I want to test Yull against a variety of files and keys.

FCOMP

When I was writing Yull I had to compare the original file with the decrypted output. I found that the DOS FC command was not helpful in that it outputted too much data. I have other tools to look for where the files differ. So I wrote fcomp:

Here's the C# source code:


using System;
using System.IO;
namespace fcomp
{
    class Compare
    {
        static void Main(string[] args)
        {
            if (args.Length != 2)
            {
                Console.WriteLine(@"fcomp. Copyright (c) Ronald Gans 2014.
				Requires two files names");
                Environment.Exit(1);
            }
            String message = "";
            fileCompare(args[0], args[1], out message);
            Console.WriteLine(message);
            Environment.Exit(0);
        }
        static bool fileCompare(String file1, String file2, out String message)
        {
            FileStream fw1 = null;
            FileStream fw2 = null;
            BinaryReader br1 = null;
            BinaryReader br2 = null;
            if (!File.Exists(file1))
            {
                message = file1 + " does not exist.";
                return false;
            }
            if (!File.Exists(file2))
            {
                message = file2 + " does not exist.";
                return false;
            }

            message = "Files are identical.";
            try
            {
                fw1 = File.OpenRead(file1);
                fw2 = File.OpenRead(file2);
                if (fw1.Length != fw2.Length)
                {
                    message = "File lengths are different.";
                    return false;
                }
                br1 = new BinaryReader(fw1);
                br2 = new BinaryReader(fw2);

                for (int i = 0; i < fw1.Length; i++)
                {
                    if (br1.ReadByte() != br2.ReadByte())
                    {
                        message = "Files are different.";
                        return false;
                    }
                }

            }
            catch (System.IO.EndOfStreamException endofstream)
            {
                message = "One of the files ended unexpectedly. " + endofstream.Message;
                return false;
            }
            catch (Exception ex)
            {
                message = "Exception thrown: " + ex.Message;

                return false;

            }
            finally
            {
                if (br1 != null) br1.Close();
                if (br2 != null) br2.Close();
                if (fw1 != null) fw1.Close();
                if (fw2 != null) fw2.Close();
                br1 = null;
                br2 = null;
                fw1 = null;
                fw2 = null;
            }
            return true;
        }
    }
}

And here's the link to the compiled code:

See the Download page.

HXA

I wrote a program recently which takes any file and converts it to HEXASCII:
HEXASCII is an ASCII text representation of binary values. So a binary value like 0, or 99 or 254, when written as Hexadecimal is 0x00, 0x63 and 0xFE. Hexadecimal is a base-16 number system. Like base 10 which we are all familiar where a number like 99 is "really" 9x10 + 9 (and even more really, 9x101+9x100). (Any number raised to the 0th power is 1.) In Hexadecimal, instead of multiplying numbers by powers of 10 we use powers of 16. And represent numbers between Decimal 10 and Decimal 15 by letters A,B,C,D,E,F. So 0xFE is (in decimal) 15x161+14x160, or 254. So when written as HEXASCII these three numbers would be 00, 63, FE, or "0063FE", so just letters and numbers.

HXA converts files between any format and HEXASCII and back to the original format, whatever it is. Additionally, it optionally encrypts the original data before it is outputted to HEXASCII. A byte can have any value between 0 and 255. The corresponding hexadecimal numbers are 00 and FF. HXA will take ANY file as input and output an Hexadecimal Ascii version of that file, like so:

Original data:

What this program does is this, going from binary to ascii. Oh,binary of course includes ASCII in that binary values range from 0 to 255, which is all possible values for a byte and one byte = one ASCII character. (ASCII: American Standard Code for Information Interchange). ASCII values in this case are the letters A-F and the numbers 0-9. The program takes a byte value like, say, 0x20, which is the "space" character (decimal value 32) and converts it into "20". It takes the hex value 0x9F which is decimal 159 or 9x16+15, and converts it into "9F" and so forth.

Output as Hexadecimal ASCII:

5768617420746869732070726f6772616d20646f657320697320746869732c20676 f696e672066726f6d2062696e61727920746f2061736369692e204f682c62696e61 7279206f6620636f7572736520696e636c7564657320415343494920696e2074686 1742062696e6172792076616c7565732072616e67652066726f6d203020746f2032 35352c20776869636820697320616c6c20706f737369626c652076616c756573206 66f722061206279746520616e64206f6e652062797465203d206f6e652041534349 49206368617261637465722e202841534349493a20416d65726963616e205374616 e6461726420436f646520666f7220496e666f726d6174696f6e20496e7465726368 616e6765292e2041534349492076616c75657320696e20746869732063617365206 1726520746865206c65747465727320412d4620616e6420746865206e756d626572 7320302d392e205468652070726f6772616d2074616b65732061206279746520766 16c7565206c696b652c207361792c20307832302c20776869636820697320746865 2093737061636594206368617261637465722028646563696d616c2076616c75652 033322920616e6420636f6e766572747320697420696e746f20933230942e204974 2074616b657320746865206865782076616c7565203078394620776869636820697 320646563696d616c203135392c20397831362b31352c20616e6420636f6e766572 747320697420696e746f209339469420616e6420736f20666f7274682e0d0a

And back again.

In this example, 57 is the ASCII representation of "W" (remember: in hexadecimal, so it is 0x57) as in "What this program does". 68 is "h" from "What" and so forth. This could be useful in sending binary files like executables and zip files as well as anything else as a "text" attachment. Or even in the body of an email. On the other end, just save the attachment as whatever you want and run HXA with DIRECTION=ORIGINAL giving the outputted file any suitable name. If I wanted to send someone an executable I wrote called, say, test.exe, I could not via email in general and often saving such files as downloads from the Internet causes warnings. If I convert test.exe to, say test.hxa via HXA and then attach it and email it. On the receiving end, save the attachment as test.hxa (or whatever you want), run HXA and you're done, having sent an executable via email.

You could also send your file in the body of the email and on the receiving end, save that text (being careful to just save that text and nothing else, not even a line return because the program will error out), convert it back to "binary" and you're done.


This is an example of doing just that:


An example of sending "hex ascii data" via email.

Remember, from the point of view of the Internet and your email program, this is no different from "Hi, how are you?" apart from the number of letters.

This is another example:


could become this:

This is also encrypted. Of course both the sender and receiver(s) would have to use the same key but the key also can be a text file in an email, sent previously.

Important to note: HXA will only convert from HEXASCII. So you would have to select that range of HEXASCII from the email, save it to a file and then run HXA on it, direction=original.



If you do embed the HEXASCII within a mail message (or any other type of file), you must not add extraneous characters, which includes returns, paragraph breaks, etc., any "invisible" characters as that will make the hexascii not usable.

Here is the link to a file of HEXASCII:

Israndom.asc Link

See the Downloads page.

The command line is like this: hxa in=infile out=outfile direction=original|ascii key=THEOPTIONALKEY overwrite=true|false

Fast and easy.
direction=ascii instructs HXA to convert the infile to hex ascii.
direction=original instructs HXA to convert the infile, which was previously converted to HEX ASCII back to its original format.
The key is optional. It is just a series of printable characters like "I like HXA" or "A" or "Whatever you feel like etc."
Anything that can be on a command line, even gigantic text files; whatever. HXA will use the key to create a SHA512 hash which is used to encrypt the data before it is converted to HEX ASCII and back again.
As with all keys, you must use the same key for each direction.

Note: The range of values for the key is all values that can be inputted via any mechanism. They can be normal ASCII letters, or bytes inputted via the ALT-Numeric keypad or alt+0+numeric keypad.



Overwrite=true instructs HXA to overwrite the output file. The default for Overwrite is FALSE.

NOTE: The version of HXA which is 1.22 is NOT LIKE THE PREVIOUS HXA (i.e., pre-version 1.1156b regarding encryption. Version 1.156b added dummy data like Yull does to the encryption so the OUTPUT file will, when using encryption ALWAYS be larger than the input file.

An HXA example:

m:\hxa in=keys.txt out=keys.txt.hxa direction=ascii overwrite=true  key=test1000000000000
HXA Version 1.22 Copyright (c) 2015-2016 Ronald Gans. All rights reserved.
Done! Converted keys.txt to an ascii format that can be easily emailed: keys.txt.hxa

m:\hxa in=keys.txt.hxa out=keys.txt.final direction=original  key=test1000000000000 overwrite=true
HXA Version 1.22 Copyright (c) 2015-2016 Ronald Gans. All rights reserved.
Done! Converted keys.txt.hxa back to its original format: keys.txt.final

m:\fcomp keys.txt keys.txt.final
Files are identical.

The contents of keys.txt is:

Key1.key
Key10.key
Key100.key

Just a simple text file. With HXA you can safely transmit any file.

Here's the file converted to HXA with key=test1000000000000

102dc3d4a12c2e88103e8c588941c26acbacb79ad263f5c6413a9118f525002f99d2ff59d297f40d0a08174a7dd1c7ae8da40c48786db27ad06c50c96f474c994f9b81ce68ac261cd44531a2c98b0da93ca6c7dec709e8e5c2d18461724ea4bc68

My impression is that the download is much faster than with binary files. The conversion from HXA format to binary takes way under a second.

Since the output of HXA for direction=ASCII is just a series of printable letters, you can store them within any other file that can handle ASCII letters, like Word, for instance. So you can embed them within a Word document (or in a cell in a spreadsheet), of course TAKING CARE TO MAKE SURE THE TEXT REMAINS UNCHANGED, even line endings will cause a problem since a file with line endings is NOT HEXASCII and HXA will reject it when trying to convert back to the original.

A 4,661 byte file I tested with underwent 1,037,738 encryptions.

One could, if one wanted to, output a file as HEXASCII, print that file out, then scan it back in (making sure nothing was changed), and run HXA on it again to get back the original file.

TextFromFile

Ever wonder what's in an .EXE file? Or any other non-text file? Well, now with TextFromFile.exe you can find out. TextFromFile.exe will extract all the printable characters from a file and write them to an output file of your choosing.

TextFromFile.exe is small and fast and extremely easy to use.

And here's the source code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;

namespace TextFromFile
{
    class Program
    {
        static void Main(string[] args)
        {
            StringBuilder sb = new StringBuilder();
            FileStream fileStream;
            Console.WriteLine("TextFromFile Copyright (c) 2015 Ronald Gans. All rights reserved.");
            if (args.Length != 2)
            {

                Console.WriteLine("TextFromFile requires two parameters:\n\rthe file being analyzed and the output filename.");
                return;

            }
            try
            {
                fileStream = new FileStream(args[0], FileMode.Open);
            }
            catch (Exception ex)
            {
                Console.WriteLine("Failed to open the file " + ex.Message);
                return;

            }
            try
            {
                using (BinaryReader reader = new BinaryReader(fileStream))
                {
                    int b;
                    int length = (int)reader.BaseStream.Length;
                    int count = 0;
                    while (count++ < length)
                    {
                        b = reader.ReadByte();

                        if (b == 10 || b == 13 || b == 9 || (b >= 32 && b <= 127))
                        {
                            sb.Append((char)b);
                        }
                    }
                    using (TextWriter writer = File.CreateText(args[1]))
                    {
                        writer.Write(sb.ToString());
                        writer.Close();
                    }
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("Failure reading from the file: " + ex);
                return;

            }
            finally
            {
                fileStream.Close();
                Console.WriteLine("Done.");
            }
        }
    }
}