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.

On Sat, 22 Jul 2023 16:51:45 -0700 (PDT), Paul Edwards wrote:
> 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.

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.

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 ?

> It's why each DLL import entry record in PE's import directory table
> has a timestamp.
....
> 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

On Mon, 24 Jul 2023 08:43:09 +0200, R.Wieser wrote:
> 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.

>> It's why each DLL import entry record in PE's import directory table
>> has a timestamp.
> ...
>> 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.

JJ,

>> 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. :-)

> 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.

> 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