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:
-
Copy the Andromeda code
- Save it to a file
- Name it whatever you want .cs
- Add that file to your C# project
- For the encryption part:
Andromeda androm = new Andromeda();
androm.inBuff = data;
androm.Key = key;
androm.initializeDelegateArray(true);
androm.EncryptStart();
data = androm.inBuff;
And for Decryption:
Andromeda androm = new Andromeda();
androm.inBuff = data;
androm.Key = key;
androm.initializeDelegateArray(false);
androm.DecryptStart();
data = androm.inBuff;
Where data is a byte[] array of the data you want to encrypt/decrypt.
That's it.
This page has download links as well as text versions of some small helper apps and batch files.
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.
Histogram.exe download[histogram.exe - MISSING]
Histogram HXA[histogram.hxa - MISSING]
//
// File Checksum Integrity Verifier version 2.05.
//
1ad7c8ac11088fe14d5bae9db2f0124d histogram.exe
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:
FCOMP.EXE link
Here's a link to the Hex Viewer I prefer to use:
XVI32 Link
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 Hexadecimaal, 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.
Here is the link to a file of HEXASCII:
Israndom.asc Link[israndom.asc - MISSING]
And here is the link for HXA.exe (version 1.156b):
HXA.EXE link Version 1.156b
Here's the SHA1 hash for this file
94940c3840cceba9bcd2e3afdc219270 hxa.exe (hxa.exe)
Just remember: Any files encrypted with the previous version WILL NOT BE decryptable with this.
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.156b is NOT LIKE THE PREVIOUS HXA regarding encryption. Version 1.156b adds 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.156b Copyright (c) 2015 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.156b Copyright (c) 2015 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
Yull in HXA Format
And here's YullG in HXA format:
YullG in HXA Format
Just download it; it's pure Hex Ascii (which is, of course, pure ASCII). Use HXA.EXE to convert it back to its binary format:
hxa -in=yull.hxa -out=yull.exe -direction=original
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.
TextFromFile.exe download[textfromfile.exe - MISSING]
TextFromFile HXA
Here's the SHA1 hash for this file:
7f0eabf98c2530d83a75fce0437ffdd5 textfromfile.exe
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.");
}
}
}
}
| 