Blogs‎ > ‎Tech Stuff‎ > ‎

2015.06.15 Encrypting Data with GFA BASIC 32

posted Jun 15, 2015, 5:31 PM by Troy Cheek   [ updated Jun 15, 2015, 5:31 PM ]
Please let us suppose that, for whatever reason or another, you've decided to encrypt some data on your hard drive.  You want to keep this data around, but you don't want anyone else to be able to read it.  Luckily, there are many many many programs out there that will allow you to encrypt your data, many using very complicated and sophisticated methods that are, for all practical purposes, unbreakable.

There are two problems with using one of these readily available programs:
  1. If the program is known, then the encryption method it uses is known, leaving it open to brute force attacks.
  2. If it's known you have encrypted files, someone can hold a gun to your head and force you to type in your password.
A brute force attack means using a computer (or multiple computers) to try each and every possible password (or key phrase or whatever it's called in your particular case) until by sheer chance you stumble upon the correct one.  Some programs will just throw up an error message if you try a wrong password, but some will go ahead and try to decode the data anyway.  If you're lucky, an incorrect password may be close enough for some of the data to come through in the clear, giving you an indication that you are close and allowing you to zero in on the actual password.

A phrase which comes up when discussing brute force attacks is the "heat death of the universe."  This means something like "Sure, you can try every possible password, but it will take so long that the universe itself will end before you can finish."  In other words, it would take so long to brute force guess the password that you don't have to worry about it even as a possibility.  The problem with that assessment is that computing power roughly doubles every time you change your underwear.  My first computer had 16 KB (that's kilobytes) of RAM and ran at a whopping 1.7 MHz.  I'm typing this on a computer with 16 GB of RAM and 8 cores running at 3.6 GHz each.  I have literally a million times more memory.  I am running literally two million times faster, or 16 million times faster if multithreading.  This means a calculation that would have taken 100 years on my first computer would take a bit over 3 minutes on my current one.  "Heat death of the universe" suddenly translates as "next Tuesday."

Have you ever heard of a video game designer who put in options that even the most powerful commercially available video cards couldn't render?  It's because they knew that by the time they finished the game and it was ready to ship, the next generation of video cards would come out and be able to handle it.

The other problem is that if they know you used a famous encryption program to encrypt the data, they can just fire up said encryption program and force you to hand over the password.  They don't even have to hold a gun to your head.  Supposing that the police are investigating a crime.  You are of course completely innocent, but in investigating you they have discovered some encrypted files on your computer.  These files are completely unrelated to the crime at hand, but you don't want to turn over the password because the files are personal.  If you decide to keep your big mouth shut, the police can simply have the courts cite you for contempt and lock you away in jail until you change your mind.

Now, there are encryption programs which admit the possibility that you might be forced to give up your password.  They allow you to set up multiple levels of encryption.  You can use one password to encrypt and recover certain files, and a second even more secret password to encrypt and recover the really secret hidden files.  After a certain amount of token resistance, you can give up the standard password which will decode some decoy files you are only pretending to want to keep secret.  The really secret files are still hidden.  The problem, of course, is that to use this method you have to have that encryption program installed on your computer, and the possibility of really secret hidden files is mentioned right there in the README file.  We're right back to the problems of brute force and guns to the head.

The presence of obviously encrypted files is a bit of a red flag.  Any geek worth this soldering iron will recognize encrypted files as encrypted files, and probably recognize which type of encryption is used.  You can hide your encrypted files by using steganography, which is any of various methods in which one file can be hidden inside another file.  You can hide a sound file inside an image file and vice versa, for example.  The problem again is that, like encryption programs, the presence of steganography programs on your computer will tip off the geeks that you've hidden something, and once again you're in jail or have a gun pointed at your head.

Obviously, the solution is to encrypt your data in a nonstandard way that doesn't call attention to itself as an encrypted file.

Enter GFA BASIC 32 or your obsolete/obscure programming language of choice.

GFA BASIC 32 has the crypt command, which encrypts a string using a key (max 116 characters = 924 bits according to the help file) which seeds a random number generator.  This fires off a substitution cypher, meaning each single byte of the string is replaced with another single yet seemingly random byte.  This process is symmetrical in that using the same command with the same key will reverse the process.  Think of it as ROT13 on steroids.

This is a string to be encoded.  It contains SECRET information!

Processed through the crypt command, it looks something like this:


The result is the same length as the original, but I think some of the characters didn't copy properly.  Even if you don't know the key (which in this case is "GFA BASIC 32" without the quotes), there are only 256^116 possible keys, which is ripe for a brute force attack.  However, this implies that you a) know what GFA BASIC 32 is, and b) you know the crypt command.  Now, if they encrypted file is in your GFA BASIC 32 folder next to a program called MyFirstCrypt.G32, that will be pretty easy to figure.  However, if there's no such program and the encrypted file is hidden away somewhere (more on this later), this may never occur to them as a possibility.

GFA BASIC was designed in many ways to be similar to Visual Basic.  VB has, I'm told, ways to access the standard Microsoft Encryption API which has encryption methods much more secure than GFA BASIC.  Why not use VB then?  Because, as mentioned before, it's standard.  If you use any standard encryption method, it's likely to be recognized, and once it's recognized, out comes the brute force and/or guns.

Mentioned in the crypt help file is the pack command.  The pack command compresses data similar to the ancient ARC program, which most of you have never heard of.  Consider it the ancestor of ZIP.  Running our "This is a string..." example through the pack command gives us a result something like this:

PCk1= @ 8 @ ../ð.D..OõE.1¡/ÑOc.ovF_ÇuLôûK.¿¡**ÝÊ’D.óá6.;(@ÂÄ%¶ž›¿M

Now, technically, this isn't encrypted so much as compressed at the bit level, but the effect is pretty much the same.  You'd never look at that and think it had anything to do with the data we started out with.  However, the geeks among you will note that the compressed info starts with "PCk1" from which you can probably guess "pack method 1" without too many hints.  Also, if the data being compressed is too short or too complicated, pack will give up and output the original data, so watch out for that.

Of course, you're probably thinking that it's a bit overcomplicated to use a cryptic command in a discontinued language to compress data when you can just use the ARC I mentioned or ZIP or any modern equivalent.  Again, the reason is that the GFA BASIC 32 pack command is nonstandard.  It's like ARC, but it isn't ARC.  You can't just use ARC or ZIP or another modern archive program to uncompress it.

(As an aside, back in my university days, a group of computer science students were working on cryptoanalysis.  A few underclassmen like me were asked to encrypt an example text file on the supplied disk using any method we saw fit.  The upperclassmen would take the encrypted file and figure out how we had encrypted it.  They already knew what the example file said, so I thought it wasn't a fair challenge, but I was game.  Using the recently released pkzip program, I compressed the file.  I snipped the "PK" off the start of the file.  I added a bunch of junk bytes to the end of the file to pad it out to the size of the original text file.  I might have reversed the whole file or done something else like that using one of the "standard" programs which was included on the supplied disk.  I copied the encrypted file back to the disk and turned it in.  If I remember right, at the end of the semester I was accused of cheating by turning in a "random" file from which the original could in no way be recovered.  I had to show the upperclassmen how to recover the original text in front of the grad student running the contest.  Re-reverse the file, add back the "PK" identifier, pkunzip the file.  The upperclassmen still thought it was cheating because pkzip wasn't one of the "standard" encryption tools supplied on the disk.)

The pack command isn't symmetrical, but it takes no genius to figure out that the command to reverse it is called unpack.

Another command mentioned in the help file is UUEncode, which uses standard methods to uuencode the specified data.  Since it's standard, we won't use that.  You can reverse it with UUDecode, by the way.

Another command mentioned in the help file is MiMeEncode, which uses standard methods to mime64 encode the specified data.  Since it's standard, we won't use that.  You can reverse it with MiMeDecode, by the way.

However, mentioned in the MiMeEncode help file entry is "There are also two keywords _MiMeEncode and _MiMeDecode which seem to be unrelated but correlate with each other as do MiMeEncode and MiMeDecode BUT do not perform the same conversion with the latter being the correct versions for MiMe64."  In other words, they do a similar conversion but in a nonstandard way.  Nonstandard being the word of the day, let's check that out.  Once again, we start with the following:

This is a string to be encoded.  It contains SECRET information!

Running it through the standard UUEncode we get this:


Running it through the standard MiMeEncode we get this:


But running it through the nonstandard _MiMeEncode we get this:


Now, any geek worth his salt can probably recognized these examples as examples of UUencoded and MiMeEncoded text.  I'll bet that there are some people out there who could do the conversions in their heads.  But the last example is a nonstandard implementation.  Even if it's recognized as some form of MiMe64, using standard decode methods yields this:

R.šÌ.šÌ.˜€ÁÝÊY›œ.¼.˜”.™¸Ý›‘Q™¸ ˆ%.ȏٛÐUš¸ÑÈM].IQ.‚I››Ùœ´Q§Ù›„

And once again we're back to completely unreadable nonsense.

So, let's combine all these nonstandard techniques available in GFA BASIC 32 into a simple program that we can type from memory.  If we don't save a copy of the program, it's not there to be found by the police or whoever, so there's no evidence that a GFA BASIC 32 program was used to encrypt anything.

a$ = "This is a string to be encoded. It contains SECRET information! The fate of the world depends upon this."

b$ = _MiMeEncode(a$) ' use the nonstandard MiMe64 encoder

c$ = Pack$(b$,2) ' compress the result using nonstandard archiver

d$ = Crypt$("GFA BASIC 32",c$) ' encrypt the result using nonstandard encryption

I changed our secret message because the original one turned out to be just short enough and just complicated enough in _MiMeEncode format to cause pack to barf back the string in it's original form.  Making it a little longer surprisingly made it pack better.  Anyway, we start off with this:

This is a string to be encoded.  It contains SECRET information!  The fate of the world depends upon this.

Running it through _MiMeEncode gives us this:


Running this result through pack gives us this:

PCk1Š ” … ” .1ORÒ1¸?(ee(11‘:?.¡.4..o..A...49Eph"84Ï%I*Wÿ.†£B.çé¡­o1Ú¾Y_q
Ä’Šg|.œ.}K*Ø    (í0çÚßo¼I 09£"oYqŠ&çº^zÂMAwJs].Ò\쬋ʥ޷mI….Hûá¨Daú

And running that through crypt gives us this:

#¾ñ.Ì3Ð9ÛÍ娑+Ï~é@ms8.    š,³.Ui«v.Î÷–œ¸ÉFf.ì.Ü`¼r \–¹U?·Ð.\.Á¶...àà.~œº€šË5ŸpÝuŒI...

This gives us an encrypted file which isn't obviously any known encryption.  Even if through brute force (which requires at least some understanding of the encryption method used) someone can guess the right key used in the crypt statement, it will be buried in billions of other results.  Since it's not plain text, it probably won't be recognized.  If they recognize it as some kind of compressed data, they'll have no idea how to decompress it, unless they are familiar with GFA BASIC 32 and the pack command.  Even if through brute force they manage to uncompress the data, the correct data will be buried in billions of other results.  If they do recognize the data as MiMe64, they'll have to figure out a nonstandard encoding scheme, which will be the easiest step in the whole process because the results will be plain text.

If the original input wasn't plain text, but rather a picture or sound or video file or the like, or a word processor document that already uses its own compression and/or encryption, well that just makes it all the harder to recognize the original file among the zillions of other possibilities while trying to brute force the problem.

Now for the fun part.  If you've got a file laying around called encrypted.txt, the police or whoever else is snooping around on your computer is going to know something is up.  We may have made it impossible to brute force the file because they have no idea how it was encrypted in the first place, but there's nothing to keep them from putting a proverbial (or literal) gun against your head and forcing you to decrypt the information.  We need to hid the encrypted file.  The easiest way to do this it stick the string "GIF89a" on the front of the file, save it as unassuming.gif, and store it in a folder full of a hundred other gif files.  It will help if a few of the other gif files in that folder were also "corrupted while downloading."

Now, exit the GFA BASIC 32 editor without saving the program.  Delete the original file.  Delete any temp or backup or shadow files.  Defragment your drive.  That should make it impossible to recover any scraps of info.  You might want to set up a RAM drive and do all your work on that.

Any police tech squad or snooping spouse or J. Random Hacker looking for incriminating evidence won't find any.  If they find a few mangled gif files mingled in a collection of hundreds, they won't think "Aha!  Encrypted data!" but rather "This guy still uses gif files?"

But when you need the data, it's a simple matter of finding your unassuming.gif file, snipping off the "GIF89a" at the front, writing a quick GFA BASIC 32 program using the crypt, unpack, and MiMeDecode commands in the right order, and you've got your original data again.  I've tried it and it takes about three tries to be able to write the encrypt and decrypt programs from memory.  It will probably take less effort than trying to remember that huge random password that the real encryption program wants you to use.

This method is called "security through obscurity."  It's not that it's better in a technical sense than the latest greatest encryption method, but it's better in that no one will ever figure it out because they've never heard of the techniques being used.  For maximum effect, don't do any of the things I've described here.  Come up with your own unique technique.  Try it against some local college students.  It's a blast!