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:
recv. I still do not understand why that works: since the
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
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.