strange wsock32

[Paul Edwards]

When I do:

C:\winpath>odwin -x cvs.exe | more

I get:

...
Entry e 00000000 00000000 Reserved
Entry f 00000000 00000000 Reserved

There is an import table in .rdata at 0x471b98

The Import Tables (interpreted .rdata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
00071b98 00071d3c 00000000 00000000 00071d88 0006e154

DLL Name: WSOCK32.dll
vma: Hint/Ord Member-Name Bound-To
80000074 116 <none>
80000073 115 <none>
80000008 8 <none>
80000002 2 <none>
80000003 3 <none>
8000000a 10 <none>
80000039 57 <none>
80000009 9 <none>
80000034 52 <none>
80000017 23 <none>
8000000b 11 <none>
...


00071bac 00071bf0 00000000 00000000 00071ea6 0006e008

DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
7235e 45 CreateDirectoryA
7234e 260 GetDriveTypeA
7233a 551 RemoveDirectoryA
7232c 87 DeleteFileA
72312 458 LocalFileTimeToFileTime
72304 620 SetFileTime
722ee 616 SetFileAttributesA
722de 505 PeekNamedPipe
722c0 273 GetFileInformationByHandle
722a8 605 SetCurrentDirectoryA
72290 245 GetCurrentDirectoryA
72280 609 SetEndOfFile
72266 610 SetEnvironmentVariableA
72254 34 CompareStringW
...


I have never seen those "wsock32.dll" empty functions before.

I've only ever seen the latter - ie kernel32.dll etc.

This cvs executable almost certainly only uses wsock32.dll
if there is network access, which in this case, there won't be.

So I just need a dummy wsock32.dll to satisfy the load.

I tried just copying an existing msvcrt.dll (of my own) to
wsock32.dll, but that caused HX to crash.

Any idea how to dummy up something here?

And what those blank function names actually are?

Thanks. Paul.

[JJ]

Post by Paul Edwards
C:\winpath>odwin -x cvs.exe | more
...
Entry e 00000000 00000000 Reserved
Entry f 00000000 00000000 Reserved
There is an import table in .rdata at 0x471b98
The Import Tables (interpreted .rdata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
00071b98 00071d3c 00000000 00000000 00071d88 0006e154
DLL Name: WSOCK32.dll
vma: Hint/Ord Member-Name Bound-To
80000074 116 <none>
80000073 115 <none>
80000008 8 <none>
80000002 2 <none>
80000003 3 <none>
8000000a 10 <none>
80000039 57 <none>
80000009 9 <none>
80000034 52 <none>
80000017 23 <none>
8000000b 11 <none>
...
00071bac 00071bf0 00000000 00000000 00071ea6 0006e008
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
7235e 45 CreateDirectoryA
7234e 260 GetDriveTypeA
7233a 551 RemoveDirectoryA
7232c 87 DeleteFileA
72312 458 LocalFileTimeToFileTime
72304 620 SetFileTime
722ee 616 SetFileAttributesA
722de 505 PeekNamedPipe
722c0 273 GetFileInformationByHandle
722a8 605 SetCurrentDirectoryA
72290 245 GetCurrentDirectoryA
72280 609 SetEndOfFile
72266 610 SetEnvironmentVariableA
72254 34 CompareStringW
...
I have never seen those "wsock32.dll" empty functions before.
I've only ever seen the latter - ie kernel32.dll etc.
This cvs executable almost certainly only uses wsock32.dll
if there is network access, which in this case, there won't be.
So I just need a dummy wsock32.dll to satisfy the load.
I tried just copying an existing msvcrt.dll (of my own) to
wsock32.dll, but that caused HX to crash.
Any idea how to dummy up something here?
And what those blank function names actually are?
Thanks. Paul.

It's just a list of function import by ordinal. Function imports don't have
to be by name. Function ordinal is an exported function ID number, and it
doesn't have to start at zero. IOTW, it's not a function index.

Function imports can also be bound by address, but it's no longer used,
since it's highly depend on specific imported DLL build. Imported DLL build
checking is done by checking the DLL file timestamp. It's why each DLL
import entry record in PE's import directory table has a timestamp. IIRC, it
was used in Win9x and pre NT4 era. This kind of import is much faster since
it doesn't need any lookup, but it broke easily on mismatched imported DLL
build.

[R.Wieser]

JJ,

Post by JJ
Function imports can also be bound by address, but it's no longer used,
since it's highly depend on specific imported DLL build. Imported DLL
build checking is done by checking the DLL file timestamp.

Do you have a code example of how that binding works ?

Post by JJ
It's why each DLL import entry record in PE's import directory table
has a timestamp.

...

Post by JJ
This kind of import is much faster since it doesn't need any lookup,

If no (initial, resolving) lookup is needed than how are those "directory
table timestamp"s found ? And if a lookup (of any kind) is needed for
timestamp checking than don't you also have (access to) the functions
address ?

IOW, I'm not quite understanding what that "bound by address" method
entrails (compile and runtime wise), and could use a bit of explanation. :-)

(I'm not thinking of using it, but would like to know how it works.)

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
JJ,

Post by JJ
Function imports can also be bound by address, but it's no longer used,
since it's highly depend on specific imported DLL build. Imported DLL
build checking is done by checking the DLL file timestamp.

Do you have a code example of how that binding works ?

IIRC, it has to be done using the BIND tool from WinSDK, if not from a
linker switch. It's not done via C source code.

Post by R.Wieser

Post by JJ
It's why each DLL import entry record in PE's import directory table
has a timestamp.

...

Post by JJ
This kind of import is much faster since it doesn't need any lookup,

If no (initial, resolving) lookup is needed than how are those "directory
table timestamp"s found ? And if a lookup (of any kind) is needed for
timestamp checking than don't you also have (access to) the functions
address ?
IOW, I'm not quite understanding what that "bound by address" method
entrails (compile and runtime wise), and could use a bit of explanation. :-)
(I'm not thinking of using it, but would like to know how it works.)

See below. It may not explain everything though.

https://devblogs.microsoft.com/oldnewthing/20100318-00/?p=14563

Either way, it's an old way of using DLL. It's quite disadvantageous.

[R.Wieser]

JJ,

Post by JJ

Post by R.Wieser
Do you have a code example of how that binding works ?

IIRC, it has to be done using the BIND tool from WinSDK, if not
from a linker switch. It's not done via C source code.

I already got the "not done by normal means" feeling. :-)

Post by JJ
See below. It may not explain everything though.
https://devblogs.microsoft.com/oldnewthing/20100318-00/?p=14563

Thanks.

Hmmm... I see I misread your "each DLL import entry record in PE's import
directory table has a timestamp". Its not about each named/ordinal entry
having a timestamp, but just the DLL entry header those named/ordinal
entries part of.

Post by JJ
Either way, it's an old way of using DLL. It's quite disadvantageous.

As you said, it needs very specific versions of DLLs to be present. In a
world where those can be updated at any moment that alone is quite a
drawback (same goes for "by ordinal" import as far as I'm concerned - even
though its slightly better).

Regards,
Rudy Wieser