pe-bear icon indicating copy to clipboard operation
pe-bear copied to clipboard

Cannot view imports/exports of nt 3.1 executables/dlls

Open 0Alastair1 opened this issue 1 year ago • 9 comments

Opening nt 3.1 pe32 files results in the following warning, image And the import/export tabs are missing. This happens with all the nt 3.1 executables and dlls in the SYSTEM32 folder (that I've tested), including NOTEPAD.EXE. These executables are able to be ran on the latest version of Windows (they are the same executable type) and the imports/exports appear in programs like ida. image PE-bear version: v0.6.7.3

0Alastair1 avatar Feb 17 '24 18:02 0Alastair1

Hi @0Alastair1 ! Thanks for reporting. It seems the format of those executables is slightly different. https://www.betaarchive.com/forum/viewtopic.php?t=25041 Could you share with me some of the binaries, so that I can use them as testcases? You can pack them and attach here. I will fix it as soon as I get some free time.

hasherezade avatar Feb 18 '24 02:02 hasherezade

Sure thing! 'link removed' Executables tested working on Windows 10 and Windows 11. Edit: I just realized theres public test cases, I'll remove this link and look into building an executable with an old build system so we have a license.

0Alastair1 avatar Feb 18 '24 02:02 0Alastair1

I managed to build some executables with the same behavior. Feel free to use for whatever purpose. nt31testapps.zip Still not sure why they don't load properly in pe-bear though.

0Alastair1 avatar Feb 18 '24 21:02 0Alastair1

@0Alastair1 - Thanks for sharing! Now I see where the problem lies. For some reason it doesn't use Virtual Size - all the Virtual Sizes in the sections are set to 0.

virtual_sizes

That's why PE-bear assumes that those sections aren't mapped (that would be the case in any normal PE). And when sections are not mapped, data directories are not resolved. If you try to edit the section header, and copy Raw Size of each section into the Virtual Size, all parses correctly.

I can solve it by checking the OS version in the Optional Header, and parsing this type differently (using their Raw Size as Virtual Size).

hasherezade avatar Feb 19 '24 02:02 hasherezade

This fixes reading the nt 3.1 executables thanks! As for that check, I did some further research, executables from nt 3.50 have the same exe OS version as 3.1 but it has got the virtual size fields filled out (their virtual sizes differ from raw sizes). Just to test I changed the OS version of the nt 3.1 executable to a modern OS version and Windows loaded it fine, I also changed the virtual size from 0 to a random high value, and it failed to load. Perhaps Windows uses Raw Size or calculates virtual Size if Virtual Size is 0, regardless of exe OS version? But changing virtual size to 0 on normal executables makes most not load (some load), not sure what a better check would be.

0Alastair1 avatar Feb 19 '24 19:02 0Alastair1

After some experimenting it does seem that Windows sets Virtual size to Raw size if Virtual size is 0, regardless of OS version. If you take any exectuable where the Virtual Size equals the Raw Size, and set the Virtual Size to 0 (for that particular section), the exectuable loads fine.

0Alastair1 avatar Feb 19 '24 19:02 0Alastair1

@0Alastair1 - thanks for checking it, you are right! It will be fixed soon.

hasherezade avatar Feb 20 '24 13:02 hasherezade

please check the test builds and let me know if everything is fine now: https://ci.appveyor.com/project/hasherezade/pe-bear/builds/49229790/job/ee57glyaii5l8mxl/artifacts

hasherezade avatar Feb 20 '24 14:02 hasherezade

works great, thanks!

0Alastair1 avatar Feb 20 '24 19:02 0Alastair1