If you open up a textfile with notepad you see the literal text. The text is the actual content of the file and is literally showed as text by the program which you use to open the file. The same with Word documents for example. Open them up in Word, and Word interprets the actual data inside the file as a document (with layout and stuff). Now open that same Word document in notepad. It simply will show you the 'codes' because it thinks it is text.
Now, all this goes for every file on your computer. The data inside the file differs from filetype to filetype. Executables are no different; they consist of many characters and if you open it up in notepad you'll see some of those characters (the ones that notepad can display at least).
If you open up an executable in Windows itself, it will be recognized as an executable and the codes (aka characters) are executed.
These 'codes' can be viewed with a
hexadecimal viewer/editor. A hexadecimal viewer/editor is actually nothing more then a notepad type program. Only instead of showing the characters as text (ASCII), it shows the
ASCII codes of those characters as
hexadecimal numbers (eg: the letter 'Z' is in ASCII decimal code '90' and in hexadecimal it would be '0x5A').
A typical screen of a hex-editor, viewing a program would be:
As you can see in the middle column, the hexadecimal numbers of the actual characters are shown in rows of 16 numbers. On the right you'll see the actual characters (the ones that can be displayed). The numbers on the left represent the first "character number" of the line of where we are in the file, this is called
the offset and is also typical represented as a hexadecimal number.
In the example this is number
0x1BD0 (or the 7120th character inside the file) which represents the character '91'...
But how do all those characters execute any code? Well, some characters are interpreted as routines inside the computer. So a certain
sequence of characters can represent a
certain programming statement. (vice versa: your programs must be translated into these characters before it can actually run and this is called compiling.)
Other characters represent nothing more then
text, and these can, of course, easly be recognized as text when you view the right column in a hex-viewer; they wont appear as random characters but as the actual text of course.
Also, all the
positions of the codes are very
important. (even if they are just text). And because of the fact that some characters can't be shown in text editors and are simply ignored, you will damage the executable beyond repair if you edit it in a text editor!
So all this explains what you actually are seeing in a hex-viewer. And this is were
patching comes into play. Patching means:
changing something in something different.
Eg: some text is stored inside an executable. You want to change this text from "something" to "SoMeThInG". So you open up your hex-editor and search for that string and overwrite it with "SoMeThInG", then you save the file again. Now you have successfully patched the executable.
But also note that both
strings were of the
same length! This is very important because you don't want to overwrite the codes which come after this string. Also "inserting" or "deleting" will not work because every order and place of the codes is very important!
These type of patches are very easy to make as you can see; you search for the string, replace it with something of the same length, et voila... done...
But most patches do more then that, they change the actual workings of a program. In other words, they change those unreadable random characters.
How does one know what to replace? Well, that's easly said, but very hard to do: You need to
dissassemble the program. This means that you need another program to translate all the different sequences of characters
back to understandable programming code. Understandable is an understatement here, because it is actually very hard to understand this kind of language, also known as
ASM.
Because you have now translated it back to programming code, you can begin to change the program itself. When that is done you compile the program again. (same principle as you would do in another higher language like VB or C++).
Of course you didn't change all of it's code, only a few bits and bobs. So to redistribute your altered program, you don't need to provide the whole program again (imagine if it was a 10Mb program, it would take some time to send it to your friends) and that is where patches come into play again.
So you have your altered program and you also have the original program. Now you can compare those two byte per byte (character per character). You only need to know the changes in those character sequences and the positions of those changes to make your patch.
Eg: in the example image above on the first line you'll see it states:
"
91 34 BA 76 2F CB 6B 40 99 61 0E 0C 4C DA AE F2".
Imagine that we have dissassembled the program, changed it, compiled it again and the result is:
"
91 34 BA 76 99 CB 6B 40 99 61 0E 0C AF DA AE F2".
You can see 2 changes in the sequence:
0x2F to
0x99 and
0x4C to
0xAF. And this happened in offsets
0x1BD4 and
0x1BDC. So all we need to do now is write a small program (in VB, C++, or whatever) that opens up the original file, changes those characters at those positions, and saves the file back and we have our patch...
And that is how people know what and where to change something; they search for the string to change or they "just" alter the programming code of the executable itself, and then compare the differences.
In this way, you can simply give the offset and the bytes to change into, like I did in these posts:
"
TABS in MSN v6.1.0207 (How-To) (also extra games)" (text-patching)
"
CookieRevised's reply to How to disabled auto complete emot?" (code-patching)
"
CookieRevised's reply to Url's In Name <<Help>>" (code-patching)
Then the people who want to do the patch manually need to open the file in a hexadecimal editor, go to those offsets and change those bytes....
Note: This whole principle can be done with any filetype of course. Even with pictures, documents, etc. As long as you have something to translate those unreadable "random characters" (which aren't random at all as you know now) back to some readable things.
More practical info about polygamy patches for MSN Messenger (and explanation of loader-patches, etc):
Polygamy (what/why/when/etc...)
Note: Patching is in many cases illegal!
Note: If you don't know what you're doing then don't even try it! Things can really turn bad!
EDIT: phew... I'm going to bed now
...
btw, sorry for the spelling mistakes spelling fixed thanks to Time