Following struct pointers

Question

I'm learning about reversing. I've attached OllyDbg to a program that uses WSASendTo (from WS2_32.dll), and breaks at the call to WSASendTo. When the call is made, the stack looks like the following:

stack layout

According to MSDN, that second argument is a pointer to "an array of WSABUF structures" shown below:

pointer to WSABUF struct

So my question is this: how do I follow the pointers in memory to see the data in memory? Below is a view in OllyDbg of the memory location 0x1970F6B8 (which represents the WSABUF struct referenced from the stack), but from there on, I don't know how this struct is layed out in memory to grab the "char FAR *buf" pointer and find its contents in memory.

memory layout

I've read that the layout of a struct in memory can be compiler-dependent. If so, how does a reverse engineer (or the CPU) determine where the contents of a struct actually exist?

Is that determined by the logic: "argument 1 is 4 bytes(u_long), beginning at byte 0, argument 2 is 4 bytes(pointer), beginning at byte number 3, etc. etc., therefore argument 2 begins at 0x1970F6B8 + 4"? I was a bit hesitant to assume that each argument is layed out right next to each other (I was reading about padding, alignment, and other complexities that I just assumed it wasn't that simple). — zz3star90, May 08 '14 at 17:00
Oh you are right. It is in Windows XP x86. (I was confusing my VM with my host machine, and now I feel dumb). — zz3star90, May 08 '14 at 17:22

score 2 · Accepted Answer · edited May 23 '17 at 10:32

how do I follow the pointers in memory to see the data in memory?

I think you should be able to just right-click on the pointer and choose "Follow in Dump". Then you can choose 4-byte layout in the dump and again follow the buf pointer via the same procedure. Note that the first word in the __WSABuf struct is the length, so you want the second one (in this case, the address is 0x16450370).

I've read that the layout of a struct in memory can be compiler-dependent.

Yes, the compiler has a certain freedom about how it aligns the struct members.

However, the layout of the ABI structures has to be standardized somehow, to ensure interoperability. I don't know how the WinAPI does this in their header files, maybe using some kind of compiler-specific pragmas controlling the alignment. Or maybe they just assume that the compiler does it like MSVC would do it.

score 0 · Answer 2 · answered May 12 '14 at 09:00

when Broken on WSASendTo function

select the WSABUFFER in stack Right Click Follow in dump

in the dump window do RightClick -> long -> Address With Ascii Dump or

Address with Unicode Dump

data will be visible without having to follow

code compiled for demo

http://msdn.microsoft.com/en-us/library/windows/desktop/ms741693(v=vs.85).aspx

tool ollydbg 1.10

break point on ws2_32 WSASendTo

Breakpoints, item 0
 Address=71AC0AAD WS2_32.WSASendTo
 Module=WS2_32
 Active=Always
 Disassembly=MOV     EDI, EDI

f9 to run and app broken on WSASendTo

Log data, item 0
 Message=Breakpoint at WS2_32.WSASendTo

stack as follows

0013F944    004013D7  /CALL to WSASendTo from wsasendt.004013D1
0013F948    00000068  |Socket = 68
0013F94C    0013FD84  |pBuffers = 0013FD84
0013F950    00000001  |nBuffers = 1
0013F954    0013FDAC  |pBytesSent = 0013FDAC
0013F958    00000000  |Flags = 0
0013F95C    0013F970  |pTo = 0013F970
0013F960    00000010  |ToLength = 10 (16.)
0013F964    0013FF60  |pOverlapped = 0013FF60
0013F968    00000000  \Callback = NULL

right click 13f94c and follow in dump

default hex view

0013FD84  00 04 00 00 80 F9 13 00 DC B7 15 00 81 6C 65 00  ...€ù.Ü·.le.
0013FD94  00 00 00 00 CD 3A 35 00 02 00 6C 81 C0 A8 01 01  ....Í:5..lÀ¨

right click in dump window -> long -> address with ascii  dump 

0013FD84  00000400  ...
0013FD88  0013F980  €ù.  ASCII "Data buffer to send"
0013FD8C  0015B7DC  Ü·.  ASCII "127.0.0.1"
0013FD90  00656C81  le.

Following struct pointers

2 Answers2