Addresses and OllyDBG

[Wally88]

Hello, I'm using ollydbg to debug an application. Me being new to the debugging scene, I'm having some trouble understanding what these addresses are all about.

Ok here it goes - I set a breakpoint in ollydbg for a particular function and got this:

Call to send from TheApp.00514321
Socket = 21C
Data = TheApp.009B8F30
Datasize = 8
Flags = 0

Please notice the data being stored at TheApp.009B8F30. I can't find this "address" in the "TheApp" module because the addresses end at like 00700000, so I just moved on.

Later on, just tracing through code I came across this:

LEA EDI,DWORD PTR DS:[EAX+9B8F30]

It's loading a ptr to the data here right? But why does it use the "9B8F30" like an offset? Can someone give me some theory behind this?   :eek The value of EAX at that point is 15059640.

[zemtex]

Ok here it goes - I set a breakpoint in ollydbg for a particular function and got this:

You got yourself a gift there, use it gingerly.  :lol

[dedndave]

Code Select Expand

LEA EDI,DWORD PTR DS:[EAX+9B8F30]

that makes no sense - lol
the tip-off is the segment override   :8)
(dword ptr is meaningless for LEA, also)
it must be data or misaligned code

show us the hex bytes
is this it ?
3E 8D B8 30 8F 9B 00

B8 30 8F 9B 00
would be
mov eax,9b8f30h ;10194736

i have seen some odd numbers generated
once i look at the source, it makes sense
here is a good example.....

Code Select Expand

;ECX = WM_HSCROLL or WM_VSCROLL               ;114h or 115h

Scrol0: push    ebx
        shl     ecx,6                         ;cg.v-cg.h = HvOfs = 64 = 2^6
        push    esi
        lea     ebx,cg[ecx-HvOfs*WM_HSCROLL]  ;EBX points to either cg.h or cg.v structure
it will look odd when disassembled because the offset of (64 x WM_HSCROLL) is 17664
that value is subtracted from the address of the "cg" structure to create the instruction offset
i shift left 6 because there are 64 bytes in the horizontal portion of the "cg" structure
the difference between WM_HSCROLL and WM_VSCROLL is 1
once the cg structure is indexed, i use the same code for both horz and vert scroll  :bg

[zekyr]

I was curious about debugging in ollydbg as well; when I get a handle from a WINAPI call where is that memory at? I know its a handle and not so much an address but where does that memory go? can I even access or look at it from ollydbg?


for example if i did something like this:

        invoke CreateCompatibleDC, hDC

and got back a handle, is there anyway i could take a look at that memory

[dedndave]

an hDc value may well be the address
many handle types are addresses

[dedndave]

.....i might add.....

the hDc may actually be an address to a table of values that describes the Dc