Hi, I'm trying to learn about how EAX and other registers work, and how to trace and look at them in Ollydbg. For example:

I know that something like,
MOV DWORD PTR DS:[00ff2100],0000005c

will move the value of 5c into memory at 00ff2100.

But what if I have something like,
MOV DWORD PTR DS:[EAX+AF],4A410000

While EAX is equal to 00120000. Does this mean it pushes the value of 4a410000 into 001200AF? I tried searching the entire stack but didn't find the value so I'm not making much sense of it through digging.

Scanned through all the online tutorials, forums and google but wasn't lucky enough to find anything on how this works.

@cap232: you confused yourself, nothing more. Yeah you are right it works like you described it. You should not scan the whole stack for your magic value of 0x4A410000, better is to take a look at 0x001200AF, there you will find the value.

I bet you simply missed it at that address.

Regards,
OHPen

Its very confusing to me, at that address I'm seeing only 2020202020202020202020202020 throughout that whole area +/-

the stack is permanently on change so its used for temp varibles so your value will not long be there
you should single step and find out where it get changed or set a BP Read/Write on 001200AF
but make sure you did this while the command MOV DWORD PTR DS:[EAX+AF],4A410000
happend in runtime

ahh yes that makes sense, moving values around all over the place to make my head spin. Now I get it. The values must be getting converted too because I couldn't search for them. Thanks a bunch

You're Close
Though the brackets around [00FF2100] mean its a pointer, meaning that the DWORD (4 Bytes) at 00FF2100 is another address which is actually where the value will be stored

Example:


mov 00FF2100, 00401000
//Value (00401000) is stored at 00FF2100
mov [00FF2100], 1
//Value (1) is stored at 00401000, because 00FF2100 = 00401000, therefore when you use it as a pointer it points to the address of its value



No [EAX+AF] refers to the address 001200AF points to



Think of a stack of plates.
I PUSH a new plate onto the stack
I POP the top plate off the stack

Although I can look at any plate on the stack, I cannot take any plate off the stack expect the top, and they must come off the order they go on.

Ya I understand all that now, I was able to use that pointer to track down where everything was stored in memory. But I've noticed something I don't understand again. When I see MOV DWORD PTR DS:[00ff2100],002cff5c, I can see at address 00ff2100 is a value of 5c, address 00ff20ff is ff, and 00ff20fe is 2c (and they will change to whatever i modify the mov to once it runs again). Is that normal to be backwards like that?

Yes. Look up "little endian" memory scheme.

http://en.wikipedia.org/wiki/Endianness

Maybe someone else could verify this for me. I'm a bit bleary-eyed tonight.

Are you sure about those addresses? The statement:

MOV DWORD PTR DS:[00ff2100], 002cff5c

should move 002cff5c so that it starts at 00ff2100. What you have described above is a DWORD starting at 00ff20fe, which is below 00ff2100.

Here's what it should look like after a memory dump and after the MOV. I don't know olly but in softice it's:

d 00ff2100 and it gives you this:

00ff2100 5c ff 2c 00 .. .. .. .. etc.

As naides said, that's Little Endian format. The value 5c should be at 00ff2100 but the other bytes should be at addresses above 00ff2100, not below it as you have indicated. The ff is at 00ff2101, the 2c at 00ff2102, the 00 at 00ff2103. Don't forget the 00 because it's a DWORD (4 bytes). The 00 is not significant in the value but it's important in the program to complete the DWORD.

If you did 4 separate MOVs as follows:

MOV DWORD PTR DS:[00ff2100], 5c
MOV DWORD PTR DS:[00ff2100-1], ff -->ff20ff
MOV DWORD PTR DS:[00ff2100-2], 2c -->ff20fe
MOV DWORD PTR DS:[00ff2100-3], 00 -->ff20fd

then you would end up with the values you describe at 00ff20ff, etc. However, a MOV instruction moving a DWORD wont place those values below the pointer.

I don't know, that's exactly what it says and exactly what its doing. It has the address in brackets like this [00ff2100], the first 2 bytes are going to that address, the 2nd 2 bytes go to the address above/before it. I'm very new to all this and its a lot to learn but, I can definitely see what its doing.

Correction, I knew I was too bleary eyed. I copied the statements above without thinking. It should read:

MOV BYTE PTR DS:[00ff2100], 5c
MOV BYTE PTR DS:[00ff2100-1], ff -->ff20ff
MOV BYTE PTR DS:[00ff2100-2], 2c -->ff20fe
MOV BYTE PTR DS:[00ff2100-3], 00 -->ff20fd


cap232...don't worry, you're doing fine. We all went through this.

The [00ff2100] looks ok and you said the 5c goes there. If a DWORD is moved with a MOV instruction, the least significant byte should go there. In this DWORD, 002cff5c, the 2c is the most important (significant) and the 5c is the least important.

The 002cff5c is stored as 5c ff 2c 00 at [00ff2100], but the ff 2c 00 should be at higher addresses, not lower, as you indicated with ff20ff, etc.

Do you understand that 00ff20ff is below 00ff2100? When you add 1 to 00ff20ff it becomes 00ff2100.

Can you check that again?

Yes, the first 2 bytes went to 100, the 2nd 2 bytes went to 0ff, the 3rd to 0fe. Yes I understand that ff is below 100, but in working with the debugger, the previous address is always listed above. Top to bottom as to least to greatest. So ff is always before/above 100 in the debugger, even though the value ff is below 100. Just a goofy matter of perspective.

cap232: After a while, it becomes second nature to see the innards of the computer in this somewhat counter-intuitive fashion. In fact high level PROGRAMMERS do not even deal with these concepts. Only Reverse Engineers, hackers, virii, hardware engineers have to look at the itsy-bitsy details of memory storage and CPU specific language.
Even when you program in Assembly, modern assemblers have some features of high level programming, by using symbols, named variables and structures, which take care of a lot of details in memory addressing and representation. It is only when you program or read code "down to the bare metal" that these details are relevant, very relevant.

Sorry, I think I understand what your saying but don't understand what your trying to get at..