А>Если бы для ntdll не применялась ASLR, то ASLR бы эффективно отсутствовала – какой смысл рандомизировать что-то, если известна база хоть одного исполняемого модуля? Да ещё такой модуль как ntdll, ух.
Хм, ntdll и правда релокейтится. Но вообще сама идея ASLR под винду полный уг, учитывая что список модулей с базами и именами вычитывается из PEB'а кодом в несколько десятков строчек, без использования каких либо API.

А>Дело в другом. При создании секции для образов применяется ASLR и фиксятся релоки. Кроме того, соответствующим образом изменяется база в заголовке (для секции!). Когда такая секция мапится, система пытается отобразить её по выбранному ранее адресу (который редко совпадает с адресом в PE-хидере в файле на диске). Если это удаётся, возвращается STATUS_SUCCESS, а если нет, то маппирование происходит по другому адресу – и возвращается STATUS_IMAGE_NOT_AT_BASE (говорящий о том, что нужно пофиксить релоки перед использованием имаджа).
Спасибо, я сам когдато писал загрузчик PE имаджей который делал все вышеописанное.

А>Так что способ узнать дефолтный рандомизированный адрес "промапить и прочитать из хидера" полностью валиден. Кстати, юзермодный загрузчик проверяет необходимость применения релоков к первичному модулю процесса именно таким способом – сравнивает базу в заголовке с заполненным ядром полем Peb->ImageBase.
Редко какой ехе имеет таблицу релоков.