[pe] List exports by ordinal as well as by name

[lucasg]

PeViewer does not list exports by ordinal.

ClangDll.def

LIBRARY

EXPORTS  
   fun1		@1  NONAME 
   fun2		@2
   fun3		@3  NONAME   
   fun4		@4
   data1	@5
   data2	@6  NONAME

ClangDll.zip

Results :

• Ida :
  

• Depends :
  

• Peviewer:
  

The "bug" was considering Exports->OrdinalTable as the ordinal table for all exports, whereas it's only for named exports.

Peviewer with "fixed" exports listing :

NB : there is probably a bug with how the VA are computed, since it's not entirerly consistent with ida or depends.

[dmex]

Looks good, thanks!

[dmex]

there is probably a bug with how the VA are computed

user32.dll is a good example of unnamed exports with invalid VA:
http://i.imgur.com/3IyrUN0.png

[lucasg]

I've looked into it yesterday and here's my guess : unlike most PE parsers (dumpbin.exe, pefile, etc.) which works on the file itself, phlib map the PE in memory. I don't know why it has an impact on the computed VA, but it does.

If you look at radare2, it compute the exports address the following way :

• vaddr (virtual address) by rebasing against the PE's base address : https://github.com/radare/radare2/blob/7327642241a5a2fb3c278e86799a663a5013c217/libr/bin/format/pe/pe.c#L306
• paddr (physical address, as in file offset ?) by translating the rva into va : https://github.com/radare/radare2/blob/7327642241a5a2fb3c278e86799a663a5013c217/libr/bin/format/pe/pe.c#L278

It makes no sense, since the official PE-COFF spec sheet explicitely say it's a rva.

Anyway here's the patch :

diff --git a/phlib/mapimg.c b/phlib/mapimg.c
index 05d179f..eae0ce4 100644
--- a/phlib/mapimg.c
+++ b/phlib/mapimg.c
@@ -741,11 +741,7 @@ NTSTATUS PhGetMappedImageExportFunction(
     }
     else
     {
-        Function->Function = PhMappedImageRvaToVa(
-            Exports->MappedImage,
-            rva,
-            NULL
-            );
+       Function->Function = (PVOID)((ULONG_PTR) rva);
        Function->ForwardedName = NULL;
     }

[dmex]

the official PE-COFF spec sheet explicitly say it's a rva

@wj32 would know more about it... I think PhGetMappedImageExportFunction was originally designed with a different purpose hence why it returned different data.

I've committed your patch for now. It does break plugin compatibility but I don't think anything other than peview was using the function so there shouldn't be any issues changing it 😄