Remember back when HTML was a Markup Language used to link keywords to actual
information without the constant bombardment of multimedia distractions that lend readily to the
adoption of a channel-surfing as opposed to a knowledge-seeking attitude? When browsing implied a specific
goal, an area of knowledge that needed illumination? Perhaps you do not...
| Assembly | Education | Tools | Links | Ring |
Mammon (ma'mun) n. The god of this world. The word in Syriac means riches. (See Milton: Paradise Lost, bk. i. 678.) His speech in the council is book ii. 229, etc. Brewer's Dictionary of Phrase and Fable
New: Reslib.idc mod 12.27 | PE File Format started 1.04
Wrong. The Intel x86 instruction set is very complex, and contains a lot of redundancies. The complexity results mostly from Intel's memory addressing scheme, in which offsets which are referred to by the programmer can reside in any number of 64K (64 thousand, not 64 Kilobyte) segments; in addition, there is no standard sequence for interleaving data and actual code in a program, so that a disassembler must make multiple passes in examining the program to determine what is actual code and what is, in fact, data. The redundancy inherent in the x86 instruction set is due to machine-code functions that have multiple mnemonics in order to make the assembly language somewhat more intuitive for the programmer; as a quick example the functions JZ (Jump If Zero) and JE (Jump If Equal) both translate to Jump If Zero Flag Is Set (or Jmp ZF=1), which translates to 74 hex in machine code...yet the clarity of the surrounding code will depend on whether the instruction is testing the result of an equality test or a "zero-ing" test.
So what exactly is required in order to properly Reverse Engineer? 1) Time. And lots of it. I know this because I have none.... 2) An intimate knowledge of assembly language (ASM), and a general familiarity with high-level languages such as C/C++, Pascal, Visual Basic (well, some people call it a language), and generally any language that the target program might have been written in (Java, Perl, Fortan). 3) Books. The amount of reference material you need, either on- or off-line, is staggering: an Op-codes listing (a listing of the assembler mnemonics and their hexidecimal machine-code equivalents), a list of OS and BIOS services, hardware and programming documentation of APIs, port numbers, etc. 4) Tools. The more tools you have, the less reference material you are likely to need. Good software tools (such as disassemblers, resource editors, etc.) pull information from the executable itself and will save you a ton of research. 5) Perseverance. If you have excellent concentration and a bulldog-like determination, Reverse Engineering is the sport for you.
Is it wrong? Like so many other things in life, it depends on what you do with it. There is nothing wrong with Reverse Engineering a program out of curiosity to see how it works; it is considered wrong to steal code gained by Reverse Engineering a product, and the art of "cracking" programs by Reverse-Engineering their protection schemes often brings cries of "software piracy". Most companies--given the chance--will not allow you to Reverse Engineer their products even if you are a registered owner; the code of the product, while lying visible for anyone with Debug.exe to read, is considered a trade secret. What it all boils down to is something that must be viewed rationally and with great practicality: with the popularity of the Internet: Knowledge (or software or code) is Free. Whether or not you make your knowledge/ code/ software available to the Internet or not, it will end up there, and someone will reverse-engineer it if it is interesting, someone will crack it if it is protected, and someone else will inevitably get a free ride. The best you can do is either to a) throw on the heaviest protection scheme you can afford and charge enough so that the purchases of the people who can't crack your program will cover your losses, or b) provide the source code with the program and ask for donations. You will find that most of the software developers who choose to profit from their trade will follow one of these two courses.
Once again, is it wrong? In my view, no. If you have the wit and will to draw the source code from a 4 MB executable, then you deserve the routines that lie therein. If you can go one-on-one with a protection scheme and crack the program, you've won: it's yours. This is mostly a practical attitude: short of monitoring every PC in the world, you cannot stop a person from cracking or Reverse Engineering a product, so you might as well not exhaust yourself trying to prevent it. It would be nice if only those who were able could benefit from cracks, i.e. if they were only available within the "cracking community" (which, to some extent, they are), but the nature of the medium prevents that; any user can type Winword Crack on their search engine and pull up results.
Some of the best tutorials on the web are available from this mirror of Fravia's +ORC and +HCU pages.
The following links may prove useful to those interested in Reverse-Engineering and other hard-core PC ventures:
The following links may help the ASM aspirant on his quest for knowledge:
In addition, many web development resources and tools have been collected on the Web Developer page, and a bulletin board intended as a Q&A forum for reverse engineering tools has been set up at the Reverse Engineering Forum, hosted by the Server Corporation, home of WebApps.
Free Email:
Free WebPages:
_m
