music |
OSdata.com |
OSdata tech blog
256 files to control them all
OSdata RSS News Feed |
256 files to control any computer
This is one my more bizarre samples.
My thought experiment was regarding being able to get up and running under very limited conditions.
take over any computer
The proposed method allows someone to take control of a computer by combining 256 special files.
The proposed method will work for literalyl any kind of computer, with or without an operating system. It does require knowledge of the machine code for the target computer.
If there is a minimal operating system and some simple text editing tools, this system is fairly straight-forward to implement. Because you can build on any computer and transfer the results to the target computer, this is a fairly low level of requirements.
You do need to have appropriate permissions on the target computer to take complete control of the computer. It may be possible to obtain the needed access without having explicit permission.
I am not at all worried about crackers and other bad players using this system because they have access to much easier to use methods for breaking into a system. For that matter, I dont actually expect anyone to use this method because there are so many other better tools for this purpose.
basic process
It occurs to me that if you had 256 files, each one byte long containing each of the 256 possible binary values for a single eight-bit byte (yes, in the early days of computers there were different byte sizes, most commonly six bits to a byte).
If each of these 256 files is declared as a plain text file (for operating systems that have OS-enforced file types), then you could use a plain text editor to open a specific file, select all, copy, and then paste into a target text file. Repeat this process as many times as needed to fill up the target file with its contents.
You can manually create any kind of file. Image files, sound files, executable machine code files.
Just save the file as plain text and then do whatever is needed to inform the local file system of the new nature of the finished file (such as adding an appropriate file extension or running chmod in UNIX).
small executable
Creating files using this manual method borders on nightmarish. Creating an executable program with this method is essentially machine code programming (not even as high a level as symbolic assembly). This is only worth doing if the file created is very small.
Well, it turns out there is one very useful executable that is very, very small, and that is the essential kernel for Forth or some other similar threaded language.
Charles Moore created Forth at a time when digital computers were fairly new and the hardware was undergoing rapid change. He needed to be able to get a development system up and running on new hardware in a minimal amount of time.
Typically less than 100 bytes are needed to implement a Forth inner interpreter and a handful of essential words. Add an outer interpreter (which can be an extension of those first parts) and a simple device driver to input and output and you have a working, functional development system. You can then use those few parts to build out a full version of Forth. The entire finished prorgam is typically less than 4k bytes.
So, the obvious small executable is the essential parts of Forth. You can avoid writing device drivers if the machine has the equivalent of Terminal running (it can be any shell system, not just Unix-like shells).
256 files
You will find a copy of all 256 files at this website. The file names are the hex values of the 256 possible byte values (all lower case) with the .txt file extension. So, these are names: 00.txt, 01.txt, 02.txt, 09.txt, 0a.txt, 0b.txt, 0f.txt, 10.txt, fe.txt, ff.txt.
For example, to obtain the file with the exclamation point character, point your browser to http://www.osdata.com/blog/201407/256files/21.txt.
Or you can use the following C program to generate your own copies of the files. If you load these onto your own server for FTP access from anywhere in the world, remember to make your transfers as binary (raw data) rather than as text.
C program
Here is a simple C program to generate all 256 files. There are no comments because the program is so trivial that it would probably be an insult to your intelligence to add comments.
#include<stdio.h>
int converter ( int x );
int main(void)
{
FILE *filepointer;
int character;
char filename[7];
int firstpart;
int secondpart;
filename[2] = '.';
filename[3] = 't';
filename[4] = 'x';
filename[5] = 't';
filename[6] = 0;
for( character = 0 ; character < 256 ; character++)
{
firstpart = character / 16;
filename[0] = converter(firstpart);
secondpart = character % 16;
filename[1] = converter(secondpart);
filepointer = fopen(filename, "w+");
fputc(character,filepointer);
fclose(filepointer);
return 0;
}
}
int converter ( int x )
{
switch (x)
{
case 10:
x = 'a';
break;
case 11:
x = 'b';
break;
case 12:
x = 'c';
break;
case 13:
x = 'd';
break;
case 14:
x = 'e';
break;
case 15:
x = 'f';
break;
default:
x = x + 48;
break;
}
return x;
}
Forth kernel
I am not actually going to give the code for the Forth kernel here because that will vary by processor and operating system.
It is a fairly simple programming problem to create Forth. The difficult part is learning enough about machine code to hand ccompile a program and put the raw bytes into the correct order.
I hope you find this thought experiment as fun as I did.