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.
Quote from: Wally88 on August 01, 2011, 01:11:58 PM
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
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.....
;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
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
an hDc value may well be the address
many handle types are addresses
.....i might add.....
the hDc may actually be an address to a table of values that describes the Dc