Quote:
[Originally Posted by Sanelb;71944]0043302F > 68 E4B55900 PUSH Tibia.0059B5E4 ; ASCII "Mana"
What exactly did I find?
What do I do next to edit it?
Do I take the code 004302F and do something with it on cheat engine?
Or the code 68 E4B55900?
Are most codes that are received from OllyDbg go well with cheat engine?
|
I'm writing this because I need a break from what I'm doing. If it's too long, or out of context, feel free to axe it or edit it. I see a lot of questions like this and maybe a very simple explanation like mine may help some people get started. Also, it might add some assembler references to our database that will show up in a search.
Olly or any other debugger doesn't care about cheat engines, I don't even know what one is. If your focus is on cheat engines, your wasting your time and the time of others here. Unless, of course, you can present a coherent analysis of what you need to learn. If you want to learn assembler, I'll give you a push (no pun intended), just to whet your appetite. I'm no expert, however.
The 43302f to the left of the > is an address in your computer's memory. The 'bytes' after it, '68' and 'E4' and 'B5' and '59' and '00' is code, and it's found in memory at that address. The code is in a mathematical code called hexadecimal (Google it), which was developed to avoid writing long strings of binary like 0111 0001 1011. The equivalent of that in hexadecimal is 71B, which is infinitely more readable.
For example, the hexadecimal value 68 (written 0x68) is made up of the binary digits, 0110 = 6 and 1000 = 8. So, 68 = 01101000. If those binary digits are represented by voltages, like 1 = 5 volts, and 0 = zero volts, a computer can understand them. 'Code' is used in general to refer to instructions to the processor, but the word means what it says. Computer (processor) instructions and data are binary codes. A processor only understand two things: a 1 and a 0. How do you talk to it about the alphabet and numbers, or give it instructions, when it has such a limited vocabulary? You form the 1's and 0's into codes.
Here's a real-life example from a test I had to write once. A guy lives on the 15th floor of an apartment with his wife. Each night he comes home, she wants him to go to the store and pick something up. His apartment has 5 windows side by side with blinds. (If a blind is shut it could mean 1, and if it's open it could mean 0). Using those 5 windows, where the blinds can be open or shut in different combinations, how many codes can be formed, hence how many things can she send him to buy? (the answer will be in next weeks supplement)
HINT: there's an easy way which you learn after the hard way. All blinds open = 00000, all blinds shut = 11111. Fill in the codes in between.
One of the basic computer (digital) chips is a decoder. If several 1's and 0's are presented to it in parallel (on a buss), to form a code, the decoder will select a specific output line. If the code put into the decoder, for example, is 0000, the decoder selects output 0. If the code is 1111, the decoder selects output line 15. This is oversimplified, but it is still the basis on which a CPU works. When the CPU receives the hex code 0x68, made up of 01101000 as voltage levels in it's decoding unit, it knows to perform the equivalent of a PUSH instruction. It does that by using the selected output line to turn on a circuit that performs the electronic equivalent of a PUSH.
If you study an ASCII chart ( http://www.pcguide.com/res/tablesASCII-c.html ), you will see columns of hexadecimal numbers with their decimal equivalent. For example, the hexadecimal (abbreviated hex, or sometimes Hx) number 0x40 has the decimal equivalent of 64. This is an important relationship. Hexadecimal 0x41 is decimal 65, but that's not so important in an ASCII table. 0x41 also represents the capital letter A. 0x42 is B, 0X42 is C, etc. A = 0x41 is also 01000001 in binary. Remember, the computer processor only understands binary...1's and 0's.
Binary combinations are formed in
extended ASCII from 00000000 to 11111111 (256 different codes, or combinations of 1's and 0's). In hexadecimal that is 0x00 to 0xFF. All the alphanumeric characters are represented by 'codes' and are contained between 0x30 = 00110000 = 0 (zero) to 0x7A = 01111010 = z (small z). In fact every key on a keyboard has a code. There's no point starting into assembler unless you have a decent grasp of this because the assembler language uses hexadecimal codes that are abbreviations of the binary code the processor understands. In other words, assembler opcodes are instructions to the processor.
The English equivalent (mneumonic) of the opcode is written to the right of it. So, 68 E4 B5 59 00 means PUSH 0059B5E4 in assembler. 'PUSH' is an instruction to the computer's central processing unit (CPU) to move a value onto the Stack, an area of memory reserved for a process, like Tibia. Maybe someone could clarify whether the stack itself is formed by the compiler, and what the relationship is to the CPU.
You don't need to know that at this point, but if you watch what comes right after one or more PUSH instructions, you'll see a 'function', signified by a CALL instruction. That's why you were told to include more code. The PUSH by itself doesn't say a lot but the CALL might, especially if it's a system function and Olly is setup to interpret it into English.
The PUSH statement puts values on the Stack for the function to use. In this case, it's putting the memory address 0059B5E4 onto the stack, and at that address there is a 'string' of ASCII hexadecimal characters that spell Mana (actually, in real memory, Mana would be represented by the electrical equivalent of binary 1's and 0's). The function that follows, at the CALL statement 'might' be a 'string' function, and it's job 'might' be to count the length of the string, move it somewhere, copy it, or whatever. The 'Tibia' part is meaningless to the code...it was put there by Olly to help you out. Also, the ; at the end of the line signifies the end of the code and was put there by Olly. Anything after that is a comment put there by the debugger as well.
One last thing, Look at the code 68E4B55900. It's made up of two parts. There is a 68, which is the actual opcode (operation code), and E4B55900 which is the operand it operates on. Rearrange E4B55900 and you get 0059B5E4. Sound familiar?? It's the address in memory holding the string Mana. The hex 68 represents the binary code for PUSH. The instruction puts the address of mana onto the Stack. Later, the code called by the CALL will do something with it.
OK...this is all Greek right now, and if you're Greek, it might not necessarily help.
Before you jump into this, you need to know about bits, bytes, words, doublewords, binary and hexadecimal. Then you need to know some basic assembler instructions like MOV, PUSH, CALL, CMP, JMP, JE, etc., and the effect they have on the flow of the program. You also need to learn how a central processing unit is made up, the registers, etc. Intel has free information on this at their site. You will also need to learn something about the basic structure of the program you're working on. Usually that's a PE file with Windows apps.
A week or two of serious study will get you to the point where you'll begin to understand assembler at a very basic level. We have all been there. If you don't have the time or interest to do that, you won't get any help on boards like this. I learned most about assembler by doing what you're doing now. I wanted to 'fix' something, and one thing lead to another.
I got a book on assembler opcodes that had a handy ASCII table. Everytime I came to an instruction I didn't understand, I stopped, got out the book, and tried to figure it out. There are a lot of seriously good reversers on this board who will occasionally stop by and give you some real insight if they think you have done your homework. At worst, someone like me can help.
If you're just looking for a hack for a game, forget it.
BTW...Olly is a disassembler as well as a debugger. When programs are written, they are usually written in a high level language, meaning the interface is more human friendly. One high level instruction may contain several hundred assembler instructions, but assembler is about the lowest level of interface to a processor that a human can understand easily. The lowest level is machine language, and you don't want to go there.
When a high level language is 'compiled' it is converted from the human level to the machine level. It is stored on a hard disk in a sequence of 'bytes' that is not legible to the average human mind. A disassembler/debugger like Olly, reads that jumble and attaches human words to it like PUSH, JMP (jump), MOV (move), etc. In other words, it brings order to the mess. Using Olly, you can step (trace) through a disassembly one step at a time. You are actually seeing the program code as it is executed by the processor. It's not quite as a simple, but that gives you the idea.
