PE Export Directory Table's OrdinalBase field ignored? - dll

Question

In my experience and that of others (http://webster.cs.ucr.edu/Page_TechDocs/pe.txt), the PE/COFF specification document incorrectly claims that the Export Address Table indices that are contained in the Ordinal Table are relative to the Ordinal Base, and even gives an incorrect example (Section 5.3). In actuality, the indices in the Ordinal Table are 0-based indices into the Address Table for the normal case in which Ordinal Base = 1. I have seen this in VS Studio generated PE libraries and in system libraries like Kernel32.dll.
My question is, have you ever observed a binary with an Ordinal Base that was not equal to 1? I want to know if this an off-by-one error, or if the Ordinal Base is never applied to Ordinal Table entries.

Answer 1

Here's a dump for mfc42.dll, version 6.06.8064.0.
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file mfc42.dll
File Type: DLL
Section contains the following exports for MFC42.dll
00000000 characteristics
4D79A4A3 time date stamp Fri Mar 11 05:27:15 2011
0.00 version
5 ordinal base
6939 number of functions
6 number of names
ordinal hint RVA name
5 0 0000ED7C ?classCCachedDataPathProperty#CCachedDataPathProperty##2UCRuntimeClass##B
6 1 0000ED44 ?classCDataPathProperty#CDataPathProperty##2UCRuntimeClass##B
7 2 000DEEAC DllCanUnloadNow
8 3 000DEE6C DllGetClassObject
9 4 000DED0A DllRegisterServer
10 5 000DEEDE DllUnregisterServer
256 0004F84F [NONAME]
[...]
6943 0003B412 [NONAME]
Here's how it looks in the binary:
;
; Export directory for MFC42.dll
;
dd 0 ; Characteristics
dd 4D79A4A3h ; TimeDateStamp: Fri Mar 11 05:27:15 2011
dw 0 ; MajorVersion
dw 0 ; MinorVersion
dd rva aMfc42_dll ; Name
dd 5 ; Base
dd 1B1Bh ; NumberOfFunctions
dd 6 ; NumberOfNames
dd rva functbl ; AddressOfFunctions
dd rva nametbl ; AddressOfNames
dd rva nameordtbl ; AddressOfNameOrdinals
;
; Export Address Table for MFC42.dll
;
functbl dd rva ?classCCachedDataPathProperty#CCachedDataPathProperty##2UCRuntimeClass##B; 0
dd rva ?classCDataPathProperty#CDataPathProperty##2UCRuntimeClass##B; 1
dd rva DllCanUnloadNow ; 2
dd rva DllGetClassObject; 3
dd rva DllRegisterServer; 4
dd rva DllUnregisterServer; 5
dd 0F5h dup(rva __ImageBase); 6
dd rva ??0_AFX_CHECKLIST_STATE##QAE#XZ; 251
[...]
;
; Export Names Table for MFC42.dll
;
nametbl dd rva a?classccachedd, rva a?classcdatapat, rva aDllcanunloadno
dd rva aDllgetclassobj, rva aDllregisterser, rva aDllunregisters
;
; Export Ordinals Table for MFC42.dll
;
nameordtbl dw 0, 1, 2, 3, 4, 5
So yes, it seems you're right and the indexes in the ordinal table are 0-based.

Answer 2

It's not an off-by-one error and the Ordinal Base is not applied to the Ordinal Table entries but to the calulation of the ordinal itself. And yes, the Microsoft PE specification (http://msdn.microsoft.com/en-us/library/windows/hardware/gg463119.aspx, section 5.3.4) is wrong. This is how the calculations should be done:
i = Search_ExportNamePointerTable(ExportName);
ordinal = ExportOrdinalTable[i] + OrdinalBase; // The "+ OrdinalBase" is missing in the official PE specification
SymbolRVA = ExportAddressTable[ordinal - OrdinalBase];
Or, expressed in a different way:
i = Search_ExportNamePointerTable(ExportName);
offset = ExportOrdinalTable[i];
SymbolRVA = ExportAddressTable[offset];
ordinal = OrdinalBase + offset;
If I dump my mfc42.dll...
dumpbin mfc42.dll /exports |more
...this is what I get:
Microsoft (R) COFF/PE Dumper Version 12.00.20827.3
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file mfc42.dll
File Type: DLL
Section contains the following exports for MFC42.dll
00000000 characteristics
4D798B26 time date stamp Fri Mar 11 03:38:30 2011
0.00 version
5 ordinal base
6888 number of functions
8 number of names
ordinal hint RVA name
1452 0 000EF5D8 ?AfxFreeLibrary##YAHPEAUHINSTANCE__###Z
1494 1 000EF5A4 ?AfxLoadLibrary##YAPEAUHINSTANCE__##PEBD#Z
1497 2 000F8344 ?AfxLockGlobals##YAXH#Z
1587 3 000F83DC ?AfxUnlockGlobals##YAXH#Z
7 4 000FC83C DllCanUnloadNow
8 5 000FC7E0 DllGetClassObject
9 6 000FC870 DllRegisterServer
10 7 000FC87C DllUnregisterServer
5 0001C910 [NONAME]
6 0001C8E8 [NONAME]
256 0005DEC0 [NONAME]
257 000423C0 [NONAME]
258 00042400 [NONAME]
259 00042440 [NONAME]
[...]
The 7th function (for example) above is DllRegisterServer, which corresponds to the 7th word (0x0004) in the export ordinal table in the below hex dump of mfc42.dll. The start is A7 05.
59 CC 12 00 6B CC 12 00 A7 05 D1 05 D4 05 2E 06
02 00 03 00 04 00 05 00 4D 46 43 34 32 2E 64 6C
The calculations:
i = Search_ExportNamePointerTable("DllRegisterServer") = 7 - 1 = 6 // zero-based
offset = ExportOrdinalTable[6] = 4
SymbolRVA = ExportAddressTable[4] = ...
ordinal = OrdinalBase + offset = 5 + 4 = 9

Answer 3

NO, PE Export Directory Table's OrdinalBase field is NOT ignored!
The sample provided above (mfc42.dll) is a good one (since its Ordinal Base is not 1).
Here two remarks about this issue:
. the output of the Dump tool is correct as far as the ordinal field is concerned. It shows, that the Base field is 5. This means that, when importing an exported function from mfc42.dll by name, the computed offset in the Export Address Table will be x-5. The Microsoft specification Section 5.3 is correct.
. the output of the Dump tool is NOT correct as far as the Hint is concerned. Export Tables have NO Hint field, ONLY Import tables have a Hint field.
As a matter of fact, the Ordinal Base is applied NOT in the Ordinal Table BUT when retrieving the index of the Address Table!