EntryOffset points to the start of the array of API_SET_NAMESPACE_ENTRY structures, which in our case comes exactly after API_SET_NAMESPACE.Įvery API_SET_NAMESPACE_ENTRY points to the name of the “api-ms-win-*” DLL via the NameOffset field, while ValueOffset and ValueCount specify the position and count of API_SET_VALUE_ENTRY structures. The data starts with a API_SET_NAMESPACE structure.Ĭount specifies the number of API_SET_NAMESPACE_ENTRY and API_SET_HASH_ENTRY structures. typedef struct _API_SET_NAMESPACE API_SET_VALUE_ENTRY, *PAPI_SET_VALUE_ENTRY I took the following structures from there.
#PYTHON RUNNER 3.7 CODE#
Just for completeness, after the publication of the current article, I was made aware of an article by deroko about the topic predating those of Quarkslab.Īnyway, I searched some more and found a code snippet by Alex Ionescu and Pavel Yosifovich in the repository of Windows Internals. Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F Ascii In fact, the second article shows a version number of 2 and at the time of my writing the version number is 6. However, I quickly figured that, while useful, they were too dated to provide me with up-to-date structures to parse the data. Searching on the web, the first resource I found on this topic were two articles on the blog of Quarkslab ( Part 1 and Part 2). apiset section, whose data can easily be identified as some sort of format for mapping “api-ms-win-*” names to others. If we don’t have any prior knowledge on the topic and just do a string search inside the Windows directory for such a DLL name, we’ll find a match in C:\Windows\System32\apisetschema.dll. These DLLs actually expose C runtime APIs like strlen, fopen, exit and so on. Interestingly, in the downlevel directory we can’t find any of the files imported by python.exe. There’s a MSDN page documenting these DLLs. If we search for the prefix in the Windows directory, we’ll find a directory both in System32 and SysWOW64 called “downlevel”, which contains a huge list of these DLLs.Īs we’ll see later, these DLLs aren’t actually used, but if we open one with a PE viewer, we’ll see that it contains exclusively forwarders to APIs contained in the usual suspects such as kernel32, kernelbase, user32 etc. The first thing which comes to mind is that in new applications we often find these “api-ms-win-*” DLLs. We have a missing vcruntime140.dll, then a bunch of “api-ms-win-*” DLLs, then only python37.dll and kernel32.dll.
So let’s turn our attention to the imports. If we try run the application now, we’ll get an error message due to a missing API in kernel32. Most of you probably already know that you need to adjust these fields as follows:įortunately, it’s enough to adjust the fields in the executable we want to start (python.exe), there’s no need to adjust the DLLs as well.
#PYTHON RUNNER 3.7 PORTABLE#
This happens because of some fields in the Optional Header of the Portable Executable. If we try to start any new application on XP, we’ll get an error message informing us that it is not a valid Win32 application.
Our target application will be the embedded version of Python 3.7 for x86. There’s no real purpose behind this article, beyond the fact that I wanted to know what could prevent a new application to run on XP. I didn’t find any prior research on the topic, but I also didn’t search much. Namely, running applications compiled with new versions of Visual Studio on Windows XP. To restart my career as a technical writer, I chose a light topic.
0 kommentar(er)
