ne_viens
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Я думаю, что автор статьи ошибся, так как сделал анализ кода не с той стороны.
Если посмотреть сo стороны ntdll.dll, то увидим такое:
Код: signed __int64 __fastcall LdrLoadDll(__int64 a1, _DWORD *a2, __int64 a3, _QWORD *a4)
{
__int64 v5;
__int64 v7;
v7 = a1;
v5 = a3;
...
if ( !(LdrpPolicyBits & 4) && (v7 & 0x401) == 0x401 )
return 0xC000000D;
...
LdrpInitializeDllPath(*(_QWORD *)(v5 + 8), v7, &v19);
v14 = LdrpLoadDll(v5, &v19, v13, &v18, v16, v17);
...
} |
Как видим, в ф-ю с характерным именем LdrpInitializeDllPath отдается первый и третий аргументы (path и DllName), а её выходное значение v19 отдаётся в LdrpLoadDll(). Напрашивается вывод, что LdrpInitializeDllPath суммирует путь к длл и название длл, а LdrpLoadDll() загружает именно эту длл, а не делает стандартный поиск по текущей директории, \system32, \Windows, итд.
Адресное пространство процесса начинается с 0х10000, соответственно, адрес строки не может быть меньше этого значения.
Я уже давно начал замечать, что эти (и не только эти) свободные биты (0хffff) кодеры начали использовать для передачи информации. В этом случае для дополнительных флагов (0x401), которые скорее всего как-то влияют на LdrpPolicy.
В связи с этими двумя наблюдениями я думаю, что первый аргумент всё-таки PWSTR DllPath, a автор перепутал дополнительные флаги с DllCharacteristics.
|
