apisetschema.dll

Если вы когда-нибудь смотрели windows 7, то могли заметить что многие системные .dll имеют очень странные импортированные модули api-MS-Win-Core-XXX.dll, которые хотя и присутствуют в %SystemRoot%\System32 (как hidden files), но кода внутри себя явно не содержат.
Гугл говорит что это извращение было сделано для поддержки мифического режима MinWin, хотя мне эта версия не кажется убедительной. Как бы там ни было, было бы весьма недурно знать, как резолвится импорт на эти модули на самом деле

Kernel mode

В функции PspInitializeApiSetMap (вызывающейся из PspInitPhase1, которая в свою очередь вызывается из PsInitSystem) происходит загрузка в ядро apisetschema.dll и поиск ее секции .apiset. Размер этой секции и прочие атрибуты сохраняются в переменные ядра PspApiSetOffset, PspApiSetMap & PspApiSetSize
Используются же они в функции PspMapApiSetView, которая делает мапинг секции .apiset из модуля apisetschema.dll и кладет его в поле PEB.ApiSetMap. Сама PspMapApiSetView вызывается из PspAllocateProcess & PspSetupUserProcessAddressSpace
Никакой магии

User mode

Как вы могли предположить, отмапленная секция .apiset используется загрузчиком в ntdll.dll - функция ApiSetResolveToHost, вызывающаяся из LdrpApplyFileNameRedirection, а последняя в свою очередь вызывается много откуда, включая например LdrpLoadDll

Mapping

Формат секции .apiset тривиален, так что приведу результат парзинга:

API-MS-Win-Core-Console-L1-1-0	kernel32.dll
API-MS-Win-Core-DateTime-L1-1-0	kernel32.dll
API-MS-Win-Core-Debug-L1-1-0	kernelbase.dll
API-MS-Win-Core-DelayLoad-L1-1-0	kernel32.dll
API-MS-Win-Core-ErrorHandling-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-Fibers-L1-1-0	kernelbase.dll
API-MS-Win-Core-File-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-Handle-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-Heap-L1-1-0	kernelbase.dll
API-MS-Win-Core-IO-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-Interlocked-L1-1-0	kernelbase.dll
API-MS-Win-Core-LibraryLoader-L1-1-0	kernelbase.dll
API-MS-Win-Core-LocalRegistry-L1-1-0	kernel32.dll
API-MS-Win-Core-Localization-L1-1-0	kernelbase.dll
API-MS-Win-Core-Memory-L1-1-0	kernelbase.dll
API-MS-Win-Core-Misc-L1-1-0	kernelbase.dll
API-MS-Win-Core-NamedPipe-L1-1-0	kernelbase.dll
API-MS-Win-Core-ProcessEnvironment-L1-1-0	kernelbase.dll
API-MS-Win-Core-ProcessThreads-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-Profile-L1-1-0	kernelbase.dll
API-MS-Win-Core-RtlSupport-L1-1-0	ntdll.dll
API-MS-Win-Core-String-L1-1-0	kernelbase.dll
API-MS-Win-Core-Synch-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-SysInfo-L1-1-0	kernelbase.dll
API-MS-Win-Core-ThreadPool-L1-1-0	kernelbase.dll
API-MS-Win-Core-UMS-L1-1-0	kernel32.dll
API-MS-Win-Core-Util-L1-1-0	kernel32.dll	kernelbase.dll
API-MS-Win-Core-XState-L1-1-0	ntdll.dll
API-MS-Win-Security-Base-L1-1-0	kernelbase.dll
API-MS-Win-Security-LSALookup-L1-1-0	sechost.dll
API-MS-Win-Security-SDDL-L1-1-0	sechost.dll
API-MS-Win-Service-Core-L1-1-0	sechost.dll
API-MS-Win-Service-Management-L1-1-0	sechost.dll
API-MS-Win-Service-Management-L2-1-0	sechost.dll
API-MS-Win-Service-winsvc-L1-1-0	sechost.dll

Небольшое пояснение - откуда взялась третья колонка. Дело в том, что kernel32.dll - да-да, какой сюрприз, тоже имеет в своей import table ссылки на api-MS-Win-Core-XXX.dll. Чтобы не произошло зацикливания - используется имя из третьей колонки при dll import resolving, если имя загружаемой .dll совпадает с именем во второй колонке