| Everything Is Byte |
| Well, the creation of this tute took so much time and efforts that any comment I could write about it seems silly for me... just read and judge by yourselves, I hope you'll like it and let me know ;) |
Everything Is Byte
by +mala
- INTRO
- Foreword
- Everything Is Byte
- Structure And Chaos: Headers Vs. Extensions
- FINDING STRUCTURE IN A FILE
- The FILE Command
- About Zip Files
- About Image Formats
- Dumping
- Zeroes
- PLAYING WITH CHAOS
- Some basics
- Patching With Psp
- Executable Images
- Ceci n'est pas win.com
- ACKNOWLEDGEMENTS
============================================================================
INTRO
----------------------------------------------------------------------------
Foreword
Some of you have waited much, much time to read this file; many, on the
other side, just didn't mind. For the first ones, I must apologize and say
that I have no excuses - I just lost my will to finish this file and spent
months while trying to find it again. For the others, I hope that this text
will teach you something you didn't know and that maybe you will be with the
first ones next time.
One more thing: the idea of patching an exe with an image editor is NOT
mine. I just found it on the web some months ago and I really don't remember
the address... but I wanted you to know that someone else had the original
idea. If you happen to find that page, let me know and I will add that
address to this tute.
----------------------------------------------------------------------------
Everything Is Byte
Everything is byte. Of course, this won't sound SO strange to most of you:
after all, everything which resides on a computer's hd, whether it is a
sound, a movie or this plain text file, must be first converted to binary
format. This takes us to some less obvious considerations: if everything
shares the same format, why do I run some files while I play others? Can I
read an executable? Can I listen to an image? The answers are, respectively:
because there is something which tells the system what to do; of course you
can; of course you can... have you ever tried to write, at the linux prompt,
cat /usr/bin/netscape >/dev/dsp ? :)
----------------------------------------------------------------------------
Structure And Chaos: Headers Vs. Extensions
Now, what makes the OS understand what kind of file it is dealing with?
Well, there are different ways: the most buggy one, for instance, is just
looking at the file extension; a better one, instead, is giving a look at
the file header or at a particular sequence of bytes which (almost always)
exactly identifies the file type. Guessing which one is used by Windows is
left as an exercise to the reader ;)
Just look at this example: on your windows disk (if you have one), find all
the files that have ".jar" extension; then, copy one of them in another
place and rename it as ".zip". Now double click on it and - voila' - it
opens correctly as a ZIP file!
Then, copy a file called c:\windows\system\shdoclc.dll in another place and
rename it as shdoclc.html... heh... if you double click it (I cannot assure
it won't damage your system O:-) some strange things will happen!
Why? What happened?
In the first case, JAR files are nothing more than ZIP files with another
extension: so, since Windoze recognizes files according to their extensions,
it's not able to open it unless you change its filename in whatever.zip. In
the second case, shdoclc.dll contains some html code to generate different
pages, but is NOT an HTML document: it's an executable, so if you open it as
a .html you will see some strange codes... and a strange browser behavior,
since it's parsing the content of different html pages all pasted together.
As you may understand, this method is quite buggy, because it doesn't let
you really understand what you're working with. The worst case happens when
some viruses copy themselves by mail as an attachment with a double
extension (such as .txt.com or .mp3.pif): if you've left the "hide extension
for know filetypes" option active, you might not notice they're executables
and run them with a double click. In other cases, instead, this limitation
in extension recognition may be useful for us, as you'll see later.
What can you do to be sure you're correctly identifying a file? Even if in
some cases you CAN'T be sure, you can have better chances by using some
tools called "file analyzers", running both under Windoze and Linux. The
first ones can be downloaded from the "utils" section at
http://www.programmerstools.org/
while under Linux you have the great FILE command, which will be described
in detail in the next section.
============================================================================
FINDING STRUCTURE IN A FILE
----------------------------------------------------------------------------
The FILE Command
"file" (yes, the right command name is all lowercase!) is a great unix file
analyzer which, instead of just looking at name extensions, does various
tests on filesystem, file data and (if data is text) language. The "data"
test is the most interesting for us: during this test, FILE searches for
particular data sequences (called "magic numbers") inside the files to
understand their type. Even if it isn't perfect, it's still a very good tool
and because of its structure it's the best one if you want to learn how file
recognition works. If you type "man file", but still better "man magic", you
will easily learn to look inside the configuration file (called "magic") and
understand file types even without using any program!
Magic file format (under my Debian it's located in /usr/share/misc/magic,
but you can even find it online searching google for "/usr/share/misc/magic"
AND "\177ELF") is quite easy: every line is made up of the following fields
- OFFSET
This is a number specifying the offset, in bytes, of the data which is to
be tested inside the file. It can be preceded by one or more ">", which
indicate the level of the test: if there are no ">" the test is level 0
and only if it succeeds tests of level 1 (one ">") are evaluated, followed
by level 2 tests (">>") and so on.
In a test whose level is higher than 1 you can also find the character "&"
before the offset: this means you don'thave to consider the offset as
absolute, but as relative to the offset of the preceding higher level
test.
Here's a little example: if you give a look at ELF section inside magic
file, you'll be presented with the following
0 string \177ELF ELF
>4 byte 0 invalid class
>4 byte 1 32-bit
...
NOTE: \177 is the value of a byte IN OCTAL (0x7F, 127 dec).
This means: if the file starts with byte 0x7F, followed by the string
"ELF", then it's an ELF file; then, if at offset 4 it has a byte whose
value is 1, then it's a 32-bit ELF, while if it's 0 it's an invalid class
ELF file.
- TYPE
From the previous example you have seen how the TYPE field is used yet: it
just contains the type of the data to be tested. The possible values are
byte: a one-byte value
string: a string of bytes
short, beshort, leshort: a two-byte value (on most systems) in this
machine's native byte order, in big-endian order
(be-) ora in little-endian order (le-)
long, belong, lelong: a four-byte value (on most systems) in this
machine's native byte order, in big-endian order
(be-) ora in little-endian order (le-)
date, bedate, ledate: a four-byte value (on most systems) in this
machine's native byte order, in big-endian order
(be-) ora in little-endian order (le-), which is
interpreted as a UNIX date
- TEST
This is the value to be compared with the value from the file. If the type
is numeric, the value is specified in C form; if it's a string, it is
specified as a C string with the usual escapes permitted (such as \n for
new line). On the test value, depending on its type, you can apply some
operators, such as =, <, > (which work for numbers and strings), & and ^
(AND and NOT, which work only with numbers and require some bits to be set
or not). Give a look at the man page for a more detailed explaination.
- MESSAGE
This is the message to be printed if the test succeeds. If the string
contains a printf format specification (such as "%s"), the value from the
file is printed using the message as the format string.
Here are just some of the things that you could notice after reading the
magic file:
- first of all, there is in fact something that lets your computer know
what file it's dealing with: data themselves, with particular values and
in particular positions inside the file, can identify the file type and
let you discover many other info (just see all that ">>" stuff).
- in most of the cases, the identifying bytes are at the beginning of the
file, but sometimes important information is NOT necessarily in the
header. And that would not be so interesting if it wasn't real for ZIP
files too...
----------------------------------------------------------------------------
About Zip Files
The most interesting detail about ZIP files is that they keep information
about their packed files in the LAST bytes of the zipped archive: this means
that you can add whatever you want or make slight changes at their beginning
and many programs, such as Winzip under Windoze or unzip under linux, will
open them without any problems. Note that FILE utility, instead, will not
recognize them anymore: the line
0 string PK\003\004 Zip archive data
inside magic means that it just checks for the first four bytes, which means
that if you change them with, for instance, "ZZ", FILE won't recognize the
zip anymore, while other programs will be able to open it anyway.
After all, this is not a great limit: FILE also gives you the chance to use
indirect offsets, which could help in tasks of this kind... and it's always
possible to change the sources, so that you can make it recognize offsets
starting from wherever you wish and not just from the beginning of the file.
This, of course, is left as an exercise to the reader... :-)
----------------------------------------------------------------------------
About Image Formats
As you've seen, ZIP utils don't mind if you append anything at the beginning
of their files. On the other side, there are some image formats which don't
mind if you append something at their end: this is because, inside their
header, image width and height are specified, so all the exceeding bytes are
ignored. This works, for instance, for .gif and .jpg images... and joined
with ZIP's property this means that you can append a JPG and a ZIP together
(the image first, the archive last) and, under Windoze, open the first or
the second one just by changing the file extension!
----------------------------------------------------------------------------
Dumping
If you want to study a file, you should have a tool which lets you open it
and dump its contents on the screen in a raw format. A hex editor is a good
tool for this purpose, better if it lets you change the visualization mode
from hex to ascii, best if -like Hiew and Biew- it also lets you disassemble
the files you open. Another great tool is list.com by Vernon Buerg, which
lets you open BIG files of any kind, dump them in ascii or hex, search very
fastly for strings and so on, all working in a DOS box in less than 30KB
(don't search for the latest, "bloated", win9x versions: I've recently
upgraded to v9.6d but v9.0h is still ok for my purposes).
I usually copy list.com in c:\windows\command directory, then run regedit
and create the following register key:
HKEY_CLASSES_ROOT\*\shell\Open with List\command
with the value:
"c:\windows\command\list.com %1"
This allows me to open any unknown-type file with List just by double
clicking it, and any other file clicking with the right mouse button and
choosing "Open with List".
Once you've found a file dumper which suits your needs, learn to use it and
USE it... a lot! After a while you will notice that many patterns occur in
files of the same kind and you will be able to easily recognize them. Also,
you will learn a lot of interesting, useful things. For instance:
- many viruses put their name or some particular bytes at the beginning of
the file they infect, so opening executables with a dumper will let you
not only avoid being infected by viruses, but also understand which one
is trying to hit you. And, since many trojan viruses are around in these
days, dumping your attachments before opening them is often a good idea.
- did you know that CuteFTP saves your password in clear inside its
macros? Well, I know that you can open CuteFTP macro files with ANY text
viewer, but this example is just to show you that you should try to open
ANY file you find on your hard disk :) So, if you have just forgotten
a password you've saved in CuteFTP "FTP site manager" you just have to
start recording a macro, connect to the site you wish and then save the
macro... you'll end up with a text file like this:
Host 123.123.123.123
RemoteDir /home/httpd/mywebsite
LocalDir D:\mywebsite
Retry 20
Login Normal
User myusername
Pass mypassword
Connect
- if you're so unlucky you REALLY have to use M$ Word (in most of the
cases you don't REALLY have to do it, and if you do you're just stupid,
not unlucky ;) start opening your .doc files: it's really amazing how
much unuseful stuff is stored inside them. If you happened to enable the
"quick save my documents" option, you probably have some of them pasted
inside the files of some others, or your errors together with your
corrections. One example? Here it is!
1) Open M$ Word (this experiment has been made with Word97)
2) Be sure that "quick saving" is activated (it's the Save tab inside
the Options window).
3) Create a new document and write:
"Dear boss,
you really stink."
4) Now save your document with whichever name you like most (I've used
example.doc).
5) Now change the text so that it reads:
"Dear boss,
you're really a great man."
(don't worry, if you don't feel you're able to write this you can
change the text as you wish ;)
6) Save again the document and close Word.
7) Open the file with your dumper and think what could happen if your
boss receives it :)
Also, the file has grown drastically... but I don't think I will spend
more time on this subject, I'll rather let you discover all the details
alone, leaving you just one suggestion: when your M$ Word crashes (I'm
sure it will do), making you lose all your last changes, try to open the
~backup files it has left on your hd with a dumper and recover most of
the text with a cut'n'paste.
----------------------------------------------------------------------------
Zeroes
As you may have learned while looking at the files which reside on your hd,
every format has some values which occur in particular places, or more
frequently than others. The reason why I've called this section Zeroes is
because they're often zeroes... but not always!
For example, text files may have a CR (or CR+LF) about every 80 characters:
the line size isn't always the same, but you can suppose you will find some
regularity - and in some cases this may let you understand that a file
contains text even if it's encrypted (just give a look at a .box Calypso
mailbox file and you will understand what I mean). For this kind of tasks, a
good knowledge of the ASCII table may be helpful too... but you'll probably
read something about it later.
If you happen to study executables or other binary files, instead, you will
find that zeroes are widely used: not just as string terminators, but also
as padding at the end of PE sections. If you don't understand this, just
think that if you have long sequences of identical values they may probably
be zeroes. Open, for instance, c:\windows\system\systray.exe and see how
many padding zeroes are there: I wonder if any virus writer has ever thought
of infecting it... it has SO much space to use and it's always loaded at
startup O:-)
Well, I'm sorry I cannot find a similar example under linux... try to
biew /usr/bin/vim and see what happens, but I'm afraid you won't find
a PE file ;)
============================================================================
PLAYING WITH CHAOS
----------------------------------------------------------------------------
Some Basics
Fine. Now you know that files are just a bunch of bytes (wow, what a good
piece of news!) and the software just understands them the way it wants.
Some systems use extensions to recognize file types, others use particular
sequences of bytes, but the most interesting things happen when you try to
open a file with a software which is not designed to handle it :)
Just one last thing, and I'll stop boring you... If you use applications
able to handle files in RAW format (which, in fact, is a non-format), you
can read them as text files (as you have seen with list), images, sounds,
whatever you want them to be.
----------------------------------------------------------------------------
Patching With Psp
Ever cracked a program? Well, don't be shy... it happens sometimes :) Even
if you are one of the lamest ones, and all you've done was running a crack
patch, I hope you've AT LEAST understood what you were doing: you know, the
program is a sequence of bytes (just to change, I'd say) and by modifying it
for even only one byte you can make it do completely different things, such
as telling you are a registered user even if you've inserted the wrong reg
code.
Of course, the operation of patching a program can be done for many other
purposes, like correcting errors or adding new functions to close software
which comes compiled and without sources. Usually, to accomplish this task
you can use Hex Editors like Hiew and Biew or tools like my old hexpatcher
(which is available in my tools section). This time, we will do that using
Paint Shop Pro: anywyay, PsP is only ONE of the programs you can use - you
just need an image editing tool that lets you open images in RAW format.
In this example, we will try to patch a little program, Cruehead's CrackMe
v1.0, available at http://3564020356.org/tutes/crackme.zip. This little Win
app does exactly nothing: it just stays there waiting to be cracked... and
since it has a really easy protection, I won't spend much time on it. Just
know that there's a regcode check and then a jump that either sends you to
the "good guy" piece of code or shows you the "bad guy" message box. For
those who wish to experiment with SoftICE, just bpx on messageboxa and when
the debugger pops up return from the call you're in: the check and the jumps
are just a few lines above the place where you are, at address 401243.
Now, we know from softice that at 401243 in memory there's a jz (0x74) that
we want to change with a jmp (0xEB): where can we find it inside the file
which is saved on your disk?
There are different ways to do it, depending on which tools you have (of
course, we suppose you don't have a hex editor):
- if you have a disassembler or any other program which shows you data about
sections, you can read RVA and Offset and calculate the right offset
inside the file:
Offset in file = (Address) - (Imagebase) - (RVA) + (Offset of section)
For instance, in this case we have these data about CODE section:
Object01: CODE
RVA: 00001000
Offset: 00000600
Size: 00000600
Flags: 6000020
And the Imagebase is 00400000. So, the right offset of instruction at
401243 is
401243-401000+600 = 843 (HEX, of course)
- if you have neither a disassembler nor a PE viewer, you might try with
LIST (I did tell you it was useful!). Just open the executable with it,
press ALT+H to view the data as HEX + dump, then hit backslash to search
within the dump: just enter "c3 74 07" and BANG! You hit it at the first
shot! As you can see, the "74" byte is at 0x843.
- if you don't have either a disassembler, a PE viewer, or LIST... well,
you might try to use PSP itself :)
WARNING: this is not easy and it might even become not funny too, if you
have to search much data or a very common sequence of bytes. But in this
case, fortunately, it's not so hard and you'll also have the chance to
find the place where you have to patch inside the image... so I'll show
you that technique in just a few lines.
If now you're asking yourselves HOW, in practice, you can use an image
editing tool to work on data instead of images, let me explain...
If you want to open a file, preserving its binary information, you have to
open it as RAW: i don't know how it's called inside other applications, but
all you have to see is a greyscale image, where every pixel matches one byte
inside the file you've just opened. Also, since the size of this image is
not specified inside the file (_ALL_ the bytes are pixels), you will have
to choose a size yourself. A good size to choose is 100 (or 1000, if the
file is huge) for width and, for height, anything which multiplied by width
gives you the size of the file (or something bigger, we don't mind adding
zeroes at the end). In our example, since the size is 12288 bytes, we'll
choose width=100 and height=130.
If you want to read what value is one byte (that is, one pixel), just put
your "dropper" or "color picker" tool above that pixel and click. If,
instead, you want to change one byte, just choose a size 1 brush (or pencil
or whatever, I think everything should be identical at size 1), the color
you want and click on the pixel/byte you want to change.
If you want to search for a sequence of bytes... well, I still don't know
if it's possible (probably with GIMP, but definitely not with PSP). The
technique I've learned is the following:
- open the file as RAW and increase its color depth to 16 million colors
- use color replacer to replace one byte (let's say "74") with a bright
color (let's say a red or a green: since the original image was greyscale,
anyway, almost every other color will seem bright). If you're comfortable
with image editing tools you might also choose a size higher than 1 for
your brush, while if you're comfortable with exe manipulations you can
choose to replace colors only in code section, which is quite easy to
individuate at a glance
- now do the same thing with the byte value preceding the one you have
chosen before (using another color, of course). From now on, you can
consider only the sequences of two colored pixels in a row: if you have
more than one, repeat this step.
- At the end, remember to close this version of the file: you don't want
to deal with a 16 million colors image, but with your good old .exe
raw file
NOTE: all the numbers we're dealing with now are hexadecimal, while you'll
probably have to deal with decimal values inside your application, so
learn to convert them quickly or make SoftICE do that for you with
"?" command.
Doing this with crackme.exe will show you the right place in just two steps:
you'll be able to see only two colored pixels in the image, of which the
rightmost one is the one you have to change. Its coordinates, provided you
opened the image with 100x123 resolution, are (15,21).
If you already had the offset of the byte inside the file, you could have
found the right coordinates just by dividing the offset for the width and
keeping the result of the integer division as y, the remainder as x. In
our case:
0x843 = 2115 dec
2115 / 100 = 21 = y
2115 % 100 = 15 = x
Now you have the coordinates, you just have to pick up the color you wish
(0xEB = 235) and "paint" the right pixel to patch your program. Save the
file as raw and you'll have a cracked crackme.exe!
----------------------------------------------------------------------------
Executable Images
Gosh, when I first started to write this tute I had just experimented with
this topic, but now so much time passed and I'm afraid I won't remember all
the things I had found! Anyway, I'll try to explain them by steps and redo
them while I'm writing... I hope it will sound understandable ;)
The first thing that led me to think about an image which was a running app
at the same time was that Psp cracking I was telling you about a few lines
above: we have seen that it's possible to view an executable as an image,
but of course this image is senseless... is it possible to make a "good"
image which is also an executable?
Of course it is, but we have to notice some details before:
- Windows executables have a fixed format (the one I called PE some times
inside this text: to have more info about it, just search for a tutorial,
there are plenty of them around the net) which requires them to have a
header full of data you won't be able to move: this means that the high
part of the image will always be full of junk, unless you use something
different from PE. This is the reason why I decided to work with .com
files, written in ASM and modified by hand
- Even if you create a .com file, it will have to start with some code so
at least a few bytes will have to be present at the beginning of the
image. It's not a big problem, anyway, since they'll just become small
dots in the upper left corner (we'll see how to make them less noticeable
later)
- The more flexibility we want for the data to be hidden, the lowest level
programming language we have to use. That is, we might be able to write a
C program and then fine tune it to work as an image too, but it will be
easier for us if the program is written from scratch in ASM.
- Needless to say (you should have learned it from the Psp patching section
yet, if you've experimented with it) there's a matching between byte
values and greyscale colors: that is, 0x00 will be black while 0xff will
become white; an unconditional jump (0xEB) will be quite bright, while a
conditional one (0x74,0x75) will be darker; the same way, the longer are
your jumps the brighter their offsets will become, but remember that if
the jump offset is signed then a near negative jump will be even brighter
than a far positive one; and so on... Don't start pulling your hair away
from your head, I've just begun with the funny part ;)
So, we want to write a program, AND to create an image with some sense. The
method I'm going to tell you is not formal nor official, it's just the way
I created some examples: if you find a better one tell me and I'll be glad
to publish it here. Now, let's start.
The first thing I did was to create an ASM program which had a lot of empty
space inside it: I thought that few pixels distributed in a huge space would
have been less noticeable, especially after inserting a real image between
them. So, given a VERY easy ASM code to print a string on the screen:
mov ah, 09h
mov dx, offset id_msg
int 21h
ret
id_msg db "Hello world",13,10,"$"
let's change it this way:
mov ah, 09h
jmp lbl00
db 1323 dup 0ffh
lbl00:
mov dx, offset id_msg
jmp lbl01
db 1323 dup 0ffh
lbl01:
int 21h
jmp lbl02
db 1323 dup 0ffh
lbl02:
ret
id_msg db "Hello world",13,10,"$"
What did I do? Well, I've just put some empty spaces between a command and
the following one. Why 1323? It's the number of spaces that will give me a
file which is exactly 4000 byte long, and since we'll have to open it inside
an image editor, size matters ;) Why 0xFFs and not zeroes? "Marty, you are
not thinking quadrimensionally": what we consider zeroes here are ugly black
dots inside our beautiful image, while FFs are empty white spaces inside the
picture! :)
Now, let's open the file inside Psp: 4000 is 50x80, so let's open the .com
as a raw image with this size, using a single color channel (greyscale): in
this way, every byte will be read as a single pixel value. Now we can choose
different approaches to hide our data:
- draw some random noise around the code pixels so that they won't be easily
detectable: as an example, see http://3564020356.org/tutes/step01.gif
Of course, this is just a quick and dirty trick you might use just if you
run out of fantasy: this will NOT generate an image, but just a bunch of
pixels.
- try to draw something with sense, but which will not interfere much with
the data: http://3564020356.org/images/exegif.gif is a writing I've used
to hide the Hello World example you've seen before and, even if not
completely (see the line of pixels at the bottom of the image, it's the
"Hello World" string), it dissimulates the presence of an executable file
quite well.
- fine tune: this is the harder option you can take, but might be the one
with the greatest impact. You should start from a ready-made image and
tune the first jump so that you'll land in a place where your following
code (and the subsequent jump) will have colors which are similar to the
colors of the image. Then, modify the second jump so that the code after
it and the third jump will be hidden well inside the image, and so on.
Hard, but satisfying: I've used it to create a part of Riddle #4 on my
website and a good part of the code is invisible (while I left some other
around the image, more or less intentionally)
If you want to experiment a bit with this technique, I suggest you to use
the good old "television trick", which is a bit harder than random noise
and a bit easier than fine tuning. Its main idea is to put all the "noise
content" (that is the code) in a rectangular area and then use it on a TV
screen or something similar inside the image: of course, this is not a real
way of hiding data and it's not even original (thanx ovid ;), but at least
you have something with sense and having the chance to make a TV say
something intelligent is always nice.
Even if this is still quite easy, you will have some work to do before you
can hide data this way: you'll have to choose a picture before you start,
put noise inside an area and then arrange jumps in your program so that the
noise generated by the code will stay in the choosen area. A funny example
(I've called it "TELEVISION, THE DRUG OF A NATION") can be found here:
http://3564020356.org/pix/misc/silly.gif
Here's how I did it:
- first, I found an image with an old TV and I modified it so that the video
contained white noise
- then, I decided a place to put the code which was easy to remember too: I
chose to start pasting it at (50,30)
- since I had to jump immediately from the beginning of the code to 50,30
and the image resolution was 239x349, I knew that the offset from the
beginning of the file where I had to jump was
249*30+50 = 7520 (0x1d60)
and, since the unconditioned jump itself needed 3 bytes (one for the
opcode, two for the offset), I knew that the offset for the jump just had
to be
249*30+50-3 = 7517 (0x1d5d)
- the source file for the executable, then, was the following (yes, it's SO
EASY! Create a harder one if you can ;)
jmp lbl00
db 7517 dup 0ffh
lbl00:
mov ah, 09h
mov dx, offset id_msg
int 21h
ret
id_msg db "Watch me, you silly slave!",13,10,"$"
- once I assembled the .com file, I just had to open it as a .raw image,
with 249*whatever (try a big one, I put 100) resolution, and paste the two
pieces of code: respectively, the three pixels at the beginning, the other
ones starting at 50x30. I suppose there should be a filter to paste the
images in the right way as if they were simple layers, but I chose the
secure way ;)
That's all. Nah, I was pulling your leg, there's more: the image is so big
that, when saved as a raw .com file, it WILL NOT WORK! You have to keep only
a part of the image (for instance, only the screen... ALWAYS starting from
the upper left corner, of course!) and then save it to have a working prog.
Well, we can say we have some added security, but I think the truth is that
there's a bug in everything I've explained until now ;)
----------------------------------------------------------------------------
Ceci n'est pas win.com
At http://3564020356.org/tutes/malawin_en.htm (malawin.htm is the Italian
version of the page) you can find a tutorial I wrote in March, 2002. Wow,
that's old! I am pointing you there because I think it might be a good
example of how the "everything is byte paradigm" can be used in practice:
working on good (?) old Win98SE win.com, I created a file which is both a
working Windoze executable and an image with some sense, then I started to
think about how copyright could work in this case...
How can you do the same? Easy: open your win.com file (the version I have
is 25175 byte long), as a raw file with height=101 pixels and width=250
pixels and write what you like inside the padding space. You can recognize
it quite easily: some black (0x00) stripes where I decided to put the "Ceci
n'est pas win.com" sentence, together with a "+malagritte" signature (for
the most curious ones, the signature itself is a modification of the
original Magritte's one).
This example, in particular, raises some interesting questions you could
think about, if you have spare time:
- is this win.com or not? If you run it, it is... even if it's modified: it
should be win.com as much as your cracked version of your favorite app is
still your favorite app. But if you save your raw file as a .gif you're
using it as a graphical representation of win.com, which carries much more
information than the program itself, 'cause you've added it. And what
happens if you print it?
- can you get some useful information from the graphical representation of
the file? Sure: first of all, you can easily see where padding space is;
also, you can find strings at a glance, because they're just grey stripes
inside the image (inside win.com, you can see some at the beginning and
MANY at the end of the file)
- can you do the same with other files? Sure: as I've written before, PE
files have a padding made up of zeroes (or, sometimes, custom strings: try
to find all the *.exe files which contain "PADDING" on your C: disk, for
instance) at the end of their sections, so you can hide all the data you
wish there. Anyway, make sure you've made a backup copy before you change
a file, because some of that space might be checked or used by the program
and the effects of your experiments are unknown ;)
============================================================================
Acknowledgements
I have to say a big, BIG thank you to all the +friends at 3564020356.org for
the fun and the satisfaction they give me every day: you never stop amazing
me!
A hug goes to all the friends of the groups I've been (and I'll always be,
unless they kick me out ;)) part of: +HCU, RingZer0, RET (people, this one
is new, go and give a look at their stuff ^__^).
Another big hug goes to all the LOAnians: I haven't put LOA between groups
because it's not a group, it's a forma mentis and it's the best (physical or
not) place I've been in the last years.
A "bravo" to anyone who had the strength to reach this point. I promise I'll
stop exactly NOW.
+mala, April 2003