Import by ordinals

[Mikl__]

There are four types of imports:

• Classic import by name
• Classical import by ordinals
• delay import
• bind import

• If the program is compiled and linked without additional options it is import by name
• If the program is compiled and linked and processed by utility bind "bind –o –u %filename%.exe", it is bind-import
• If to the linker command line is to add /DELAYLOAD:<DLLNAME>, where <DLLNAME> is the name of the DLL that you want to be loaded, such as:

Code Select Expand

/DELAYLOAD:COMCTL32.DLL it is delay import

a. How should I change the command line so that I can import by ordinals?
For example, I see the exported functions from user32.dll

Code Select Expand

Bin\dumpbin /EXPORTS %WINSYS32%\user32.dll /OUT:user32.txtb. I know  MessageBoxA function ordinal is 2043. How do I call the MesageBox function in the program using an ordinal?

Code Select Expand

call user32.#2043

[TWell]

user32.dll ordinals are not constant.

normal use of ordinals needs import library created for ordinals.

example def

Code Select Expand

LIBRARY USER32.dll
EXPORTS
MessageBoxA @2097


[Mikl__]

Hi, TWell!

user32.dll ordinals are not constant

I know about it -- Information is of a fact-finding nature
If I created my def-file in which the ordinal MessageBox = 1023 then how should I issue the def-file so as not to specify the function name so that the linker created import from user32.dll by ordinal? And how do I call such a function? call user32.1023 or call user32:1023?

[TWell]

just call MessageBoxA and linker find that ordinal from import library.

[Mikl__]

Thank you very much, Tim!

[Vortex]

Hi Mikl__,

Attached is an example for you.

[Vortex]

The same example using the corresponding import library.

[ragdog]

Hello

user32.dll ordinals are not constant.

Correct.

My user32.dll version
6.1.76.01.23594


Ordinal 2039  MessageBoxA

I have read import by ordinal is not safe by system dlls.
but i have not tested.

Donkey

I should note that imports by ordinal are pretty dangerous, most DLL's in Windows use a sequentially generated ordinal number and from one version to another the values are pretty much the same for named exports and always the same for ordinal only exports. However this tends to break down once a function is deprecated or a new function is inserted, for example in Common Controls, version 5.8 has the function CreatePropertySheetPageA at ordinal location 18, in version 6.1 it is an unnamed ordinal (CreatePropertySheetPageA is at ordinal 19 in that version). However calling GetProcAddress for ordinal 18 will succeed in both cases but give 2 different functions and will likely crash your program or lead to some pretty bizarre behaviour. If you need a list of static Windows API exports by ordinal you can check my header project which has a pretty extensive list of them in various header files (mostly in Commctrl.h and shellapi.h).

I guess the lesson is to always use named exports whenever possible and only use ordinal exports that you are fairly certain are static but avoid them if you can