Hi everyone...I am new here and all i can say is: this site rocks!!!!

I have a small question for you guys that i cant figure out (nor google for that matter):
Are the RVA's/exported names of the winsock obfuscated?
When I open the ws2_32.dll in olly and lordpe the rva for the function "send" is 0x659B, but when i open it in a tool i am busy developing i get the rva as
0x418A (which is actually the rva for "getaddrinfo". ALL the functions are obfuscated like this when i view it in my tool; all the rva's point to diffrent, yet valid, functions.
I think this might be due to the fact that my tool is reading the export directory from file and not from memory (like ollydbg). But as far as I know, LordPE also reads from file and not from memory, but it retrieves the correct addresses.
All other dlls i have tested with had no problems, that is why i dont think there it is programmatical error in my application causing this.

Any ideas?

Regards
Jud

forwarded imports

Hi
Thanks for the quick response.
As far as my understanding of forwarded imports is: It redirects a function from one dll to ANOTHER DLL; and also the function names would be unique so that forwarding can occur ... but this is not what is occuring in winsock because the base address (0x77850000) corresponds for both the correct rva and incorrect rva, therefor all this is occuring in the address space of ws2_32.dll and no other dll's.
Also, lordpe gets the correct export rva offline (without going through a runtime to find the unforwarded function).
And last but not least, the export addresses/names might be wrong, but they point to the ACTUAL, non-forwarding, functions that execute normally.


Maybe my understanding of forwarded functions is wrong? or, maybe LordPE does infact load the target application into memory in order to read it correctly??
Once again, thx for the response man
Regards
Jud

your app probably incorrect calculates RVA to VA

I doubt it. I have a lot of features that depend on my rva to va calculations (such as a debugger and dissasembler). I have tested it on numorous applications and libraries including all the most common such as ntdll, kernel32, user32 etc. and i have never had any issues regarding getting the rva's of exported fuctions up until i came accross the winsock lib.
Even if i were making an error calculating the VA, what are the chances of EVERY "WRONG" VA stil pointing to a valid function?....but maybe you are right; if you guys dont think the ws lib is any diffrent than the common kernel libraries, then I will accept it probably is MY bad coding...
So, IS the ws lib any diffrent in structure than the common kernel libs? is there any protection on the winsock lib? -does any1 know?

in ollydbg using Loaddll or using some exe which loads this ws2_32.dll and going to memory map

how do you see rva in ollydbg ? using rightclick view executable ?

does olly show you 0x65## or are you deducing it ?

what is your os

in xp-sp2 i see ws2_32 send is at via windbg



via ollydbg

I am using an debugging an exe to load the winsock dll.
At the moment i am using vista sp1 and xp sp2. Same issues on both machines.
Olly doesnt show me the rva for send is 0x659B, but i assume it is since the VA is 0x7785659B AND LordPE also specifies the RVA is 0x659B when loading the dll directly into LPE.

The jump table from the ollydbg output is this:


$- FF25 00204000 JMP DWORD PTR DS:[<&kernel32.Sleep>]
$- FF25 08204000 JMP DWORD PTR DS:[<&ws2_32.WSAGetLastErr
$- FF25 0C204000 JMP DWORD PTR DS:[<&ws2_32.WSAStartup>]
$- FF25 10204000 JMP DWORD PTR DS:[<&ws2_32.connect>]
$- FF25 14204000 JMP DWORD PTR DS:[<&ws2_32.htons>]
$- FF25 18204000 JMP DWORD PTR DS:[<&ws2_32.inet_addr>]
$- FF25 1C204000 JMP DWORD PTR DS:[<&ws2_32.send>]
$- FF25 20204000 JMP DWORD PTR DS:[<&ws2_32.socket>]


The jump table from my tool is this:

JMP [402000] send.exe KERNEL32.dll.Sleep
JMP [402008] send.exe WS2_32.dll.WahCloseSocketHandle
JMP [40200C] send.exe WS2_32.dll.WahCreateNotificationHandle
JMP [402010] send.exe WS2_32.dll.GetAddrInfoExA
JMP [402014] send.exe WS2_32.dll.InetPtonW WS2_32.dll.WSAAddressToStringA
JMP [402018] send.exe WS2_32.dll.SetAddrInfoExW
JMP [40201C] send.exe WS2_32.dll.WSAAsyncGetHostByName
JMP [402020] send.exe WS2_32.dll.WSAAsyncGetServByPort

(as you can see the Sleep function was correctly detected, but not the ws functions)
at runtime the values in these addresses are exactly the same for both tools:
olly: 00402000| 6B 1C 35 76
my tool: 402000| 6B 1C 35 76

olly: 00402008| 35 30 85 77
my tool: 402008| 35 30 85 77

olly: 0040201c| 9B 65 85 77
my tool: 40201c| 9B 65 85 77

etc...

My tool use these values in as in process memory then searches through the FILE's export table for matches in order to creat its jump table. Can this contribute to the problem? -Should i rather be reading from the export table as it is in MEMORY?

Then using olly's view modules->ws2_32->view names: i get this
Names in ws2_32, item 212
Address = 7785659B
Section = .text
Type = Export
Name = send
Comments = Ordinal = #19

But in my app the same feature
Address = 7785418A:
Name = WS2_32.dll.send

i see WS2_32.dll exports WS2help.dll...
look, maybe it redirects exports!?!?