1

In tracing how the recv function works on Windows, I observe the following trace:

...
0x743817d2  push eax                      C:\windows\system32\WSOCK32.dll recv                     
0x743817d3  push dword ptr [ebp+0x8]      C:\windows\system32\WSOCK32.dll recv                     
0x743817d6  call 0x7438193e               C:\windows\system32\WSOCK32.dll recv                     
0x7438193e  jmp dword ptr [0x74381000]    C:\windows\system32\WSOCK32.dll setsockopt               
0x77287089  mov edi, edi                  C:\windows\syswow64\WS2_32.dll  WSARecv                  
0x7728708b  push ebp                      C:\windows\syswow64\WS2_32.dll  WSARecv                  
0x7728708c  mov ebp, esp                  C:\windows\syswow64\WS2_32.dll  WSARecv  
...

Unfortunately, once again I found it quite strange. First, there is a direct call: 

call 0x7438193e

inside recv. I still do not understand why that works: since the WSOCK32.dll (containing recv) will be loaded "arbitrarily" in the user-space, how does recv guarantee that the setsockopt locates at this address?.

Second, I see nowhere in the application (here it is wget) can modify the memory at 0x74381000 (that is the target of jmp inside setsockopt), so normally the value at this address is always 0x77287089 and that means recv calls always WSARecv(!!!). I doubt that is not true because there is no official document (i.e. MSDN) saying that.

Many thanks for any consideration.

Improve this question

1 Answer 1

Reset to default
3

how does recv know that the setsockopt locates at this address?

The relative virtual address of the function setsockopt is in WSOCK32.dll's Export Table, so your disassembler/debugger was smart enough to match the virtual address 0x74381000 to the relative virtual address of setsockopt.

"recv calls always WSARecv"

That's correct; in Winsock, recv is a wrapper around WSARecv.

Improve this answer
6
  • Thanks a lot Jason. For the virtual address of setsockopt, is it always located at 0x74381000 even when the ALSR is enabled?
    – Ta Thanh Dinh
    Commented Mar 12, 2014 at 8:13
  • No, it's not.​​
    – Jason Geffner
    Commented Mar 12, 2014 at 13:29
  • Thanks again Jason, but this is actually what I found strange: because the address 0x7438193e is hard-coded inside recv, so does that mean recv will not work when ALSR is enabled?.
    – Ta Thanh Dinh
    Commented Mar 12, 2014 at 13:50
  • 1
    When PE files are compiled, they are compiled using a preferred base address. Within the PE file is a relocation table which has all the calls that have used this preferred base address. When the binary is loaded, the loader compares the preferred base address to the actual base address and applies a delta to all the addresses in the relocation table.
    – jbh
    Commented Mar 12, 2014 at 15:01
  • Thanks a lot jbh. As far as I understand, the relocation table is used in linking and not loading, so when I "see" an absolute address in the target of JMP, that means no loader can modify it.
    – Ta Thanh Dinh
    Commented Mar 12, 2014 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.