Very Simple Data Segment Question

[enteleky]

I was wondering... Take the following line:

move eax, ds:[121d5ac]

Taking the assumption that the OS I was on is using the flat memory model and sets the DS register to 0x1f. Would the value in eax be equivalent to 0x1f000000 + 0x0121d5ac?

Yes or No answer is fine with me. If I am not correct I will just go try and read more.

[Shynd]

First off, your operating system is not using a flat memory model because a flat memory model is not conducive to multitasking at all. It's good for low-level, single-operation kernels, and that's about it, unless I've misunderstood all of the things I've ever read on the subject. More likely, you want to be asking questions about a paged or segmented memory model, in which mov eax, dword ptr ds:[121D5ACh] would indeed move the value at address 0x121D5AC (in the current process context) into your eax register.

[Cypher]

First off, your operating system is not using a flat memory model because a flat memory model is not conducive to multitasking at all. It's good for low-level, single-operation kernels, and that's about it, unless I've misunderstood all of the things I've ever read on the subject. More likely, you want to be asking questions about a paged or segmented memory model, in which mov eax, dword ptr ds:[121D5ACh] would indeed move the value at address 0x121D5AC (in the current process context) into your eax register.

TLDR Version:
The segment registers are not used in Windows can can be safely ignored in most cases. The only exception to this is the FS register (used for TLS).

I suggest picking up Reversing: Secrets of Reverse Engineering. It explains things like this.

[enteleky]

Alright thanks.

Do dword ptr keywords affect anything? Or do they only affect expected type?

[Shynd]

The difference between dword ptr ds:[] and word ptr ds:[] and byte ptr ds:[] should be pretty obvious.

[romanshade]

I suggest picking up Reversing: Secrets of Reverse Engineering. It explains things like this.

I just picked up this book, by Eldad Eilam ... and it's awesome! Although I don't have any other RE books to compare it against, but I'm really enjoying it so far.

It's serving as a father figure on my journey to becoming a man ... aka learning ASM/C++ ...

Cheers-
'Shade

[enteleky]

The difference between dword ptr ds:[] and word ptr ds:[] and byte ptr ds:[] should be pretty obvious.

Yup thats what I thought... But if the size of the data isn't defined should I assume its a byte(8bits)?

[Shynd]

The size of the data is always defined in one way or another. If it's being moved into a 32-bit register--eax, ecx, ebx--then it's 32-bit or lower and can be read as a DWORD (generally). If it's being moved into a 16-bit register... you get the idea.

[enteleky]

Alright. Thanks a lot. *Goes back to trying to figure out stuff*

Alright so I just tried a thing out.

At offset 121d5ach was 108afe1f in this certain instance. And later in the same code it does this operation:

mov ecx, [eax+0C4h]

But the problem is that eax which at the current time was 108afe1f is not able to be read so how could it possibly add 0C4h to the data it got out of it?

Also if I just did something wrong just say No and that will suffice and I know I just need to go rethink stuff.

[Shynd]

mov ecx, [eax+0C4h] is the same as mov ecx, [108AFEE3h], in your example. I find it hard to believe that there's data at 0x121D5ACH but not at a lower address, 0x108AFE1F. 'Course, I've never used an apple computer besides my phone, so I suppose I don't know a thing about memory management in an OSX context and am just blindly assuming based on my Windows knowledge.

[enteleky]

mov ecx, [eax+0C4h] is the same as mov ecx, [108AFEE3h], in your example. I find it hard to believe that there's data at 0x121D5ACH but not at a lower address, 0x108AFE1F. 'Course, I've never used an apple computer besides my phone, so I suppose I don't know a thing about memory management in an OSX context and am just blindly assuming based on my Windows knowledge.

Well 0x108afe1f is higher than 0x121d5ac isn't it?

Doesn't 0x121d5ac really equal 0x0121d5ac?

And yeah its just weird because 0x108afe1f doesn't hold anything its just not there.

I guess simply put its just not the offset I am looking for I guess.

[Shynd]

Er, yeah, sorry. I apparently can't read straight after an orgasm.

[enteleky]

That is definitely understandable. Hopefully it wasn't self induced... :-P. Thanks. And I guess I can assume that 121d5ach is not the offset I am looking for. Thanks for your help.

[Cypher]

This is Shynd irl:
[ame=http://au.youtube.com/watch?v=4pXfHLUlZf4]YouTube - Jizz In My Pants[/ame]

[enteleky]

I have another question having to do with the same thing...
This could just be me being really stupid...

So this operation below

mov eax, ds:dword_121d5ac

should move the contents of 0x0121d5ac into eax.

Well when I read 0x0121d5ac from the client it is something completely different and random compared to if I set a breakpoint and read eax from the breakpoint. What could this be?