0

I am currently working on a personal project: a 32 bits PE loader.

I did a lot of research and followed some very interesting tutorials such as :
https://bidouillesecurity.com/tutorial-writing-a-pe-packer-part-1/
https://0xrick.github.io/win-internals/pe8/#initparse

Very quickly, the main goal of my project is to load and execute into memory a 32 bits PE.
To do so, I have done the following steps:

  • allocate an amount of memory equivalent to the size of the image (SizeOfImage) of my 32 bits PE (calc.exe in my case)
  • load in memory the headers of my PE
  • load in memory the sections of my PE
  • load the dll functions used by my PE
  • perform the relocation
  • put the right permissions on each section
  • execute the entry point of my PE

I followed the two links above, but I get an error and it's impossible for me to run calc.exe ("C:\Windows\SysWOW64\calc.exe").

After several hours of investigation, I realized that I could not get the address of several functions exported from the msvcrt.dll. Indeed, the GetProcAddress function returns me the error code 127 for three of them. Here they are:

  • __p__fmode
  • __p__commode
  • _except_handler4_common

Thanks to the Microsoft documentation, I realized that these functions are Internal CRT functions and function macros. I have to admit that I didn't fully understand what they were used for and if there was a real link with my problem.
Source: https://learn.microsoft.com/en-us/cpp/c-runtime-library/internal-crt-globals-and-functions?view=msvc-170

PS: I am under windows 11, I code on visual studio 2022 and I did not change the default compilation options.

Antoine Hazebrouck
  • 41
  • 2
  • 8
  • Yes, macros have no address, nor in fact any runtime identity at all. They have their full effect at compile time. There are several things that "internal function" could mean, but most are consistent with not being able to obtain the function's address from a separate module, nor, in fact, to refer to it by name for any purpose in another module. "Another module" would include `calc.exe`, so I suspect that these issues are a red herring for you. – John Bollinger Nov 23 '22 at 15:27
  • @JohnBollinger Thank you for your answer. Do you think that my loader is not working cause the default compilation options of Visual Studio 2022 ? Or cause my OS version (I'm on Windows 11)? Indeed, by copying and pasting the source code of the project of these tutorials, I can't execute calc.exe. To come back to the macro functions, how can I use them in my loader (because GetProcAddress returns me an error)? – Antoine Hazebrouck Nov 23 '22 at 19:14
  • Sorry, I'm not prepared to guess why your loader is not working. As for macros, you can use a macro if and only if there is an in-scope definition of that macro. For third-party macros such as you are asking about, such a definition is ordinarily obtained by including an appropriate header file. Each macro use is processed at compile time -- no reference to any macro is retained in the resulting executable code. – John Bollinger Nov 23 '22 at 19:19
  • My copy of `msvcrt.dll` does have these 3 functions, and `GetProcAddress` returns them to me just fine. – ssbssa Nov 24 '22 at 11:54
  • @ssbssa what's your compilation options please? – Antoine Hazebrouck Nov 25 '22 at 12:03
  • No special compilation options needed (and I can't think of any offhand that could change the behavior of this anyways). – ssbssa Nov 25 '22 at 12:13
  • @ssbssa got an error with GetProcAddress. Still don't understand why :/. Here is my code: HMODULE dll = LoadLibraryA("msvcrt.dll"); if (!dll) failure("LoadLibraryA failed"); FARPROC func = GetProcAddress(dll, "__p__fmode"); if (!func) failure("GetProcAddress failed"); – Antoine Hazebrouck Nov 27 '22 at 13:11

0 Answers0