Изначальная память процесса и 4-х миллионный байт?

Question

[Альбус Персиваль Вулфрик Брайан дамблдор]

Всем приятного чтения,
Решил я значит своими руками сделать .exe aka PE и он же исполняемый файл. Если конкретней, то на фасме(или я уже на тасм перешёл) пишу с помощью db,rb,dw и dd всякие плюшки дабы в итоге получился полностью рабочий Шник.exe
Но тут я наткнулся на поля ImageBase и Секцию импорта. При этом в статейках со всей уверенностью смешивают противоречивую информацию, сначала говорят, что без импорта никак и нечего я сделать не смогу и тут же говорят, что код надо грузить over4_000_000 byte, но если сделать финт ушами то и 1.млн тоже получится, так как перед этим всё занято системными библиотеками. И тут я выпал. Расскажите пожалуйста откуда можно начинать грузиться, что надо подгружать отдельно через импорт и что будет если я обращусь к нижним адресам ни чего там не проинициализировав?

Answer 1

[none7]

Поле ImageBase указывающее системе в какую часть виртуальной памяти процесса нужно разместить исполняемый файл. Традиционно .exe файлы размещают по адресу 0x400000, это не значит, что он занимает 4 мегабайта, просто адрес. Dll традиционно размещают по адресу 0x10000000; поскольку для dll весьма возможен конфликт адресов, к ним обязательно прикрепляют релоки. Адрес размещения .exe и .dll строго говоря может быть любым кратным 0x10000, но не 0, не адрес ntdll.dll и не в пространстве ядра. Сам же исполняемый файл может занимать минимум 1 страницу(4Кбайт на x86) памяти + минимум по 1 странице на секцию, независимо от адреса размещения исполняемого файла.
То, что без таблицы импорта нельзя ничего сделать, строго говоря неверно. Можно через стандартные адреса выяснить где расположены системные .dll и их экспортируемые функции и через них загрузить всё, что необходимо. Но без самих системных .dll можно только зависнуть или умереть. Подгружать нужно то, что необходимо для работы кода приложения, это полностью зависит от самого приложения. Например для классического HelloWorld

void func() {
    MessageBoxA(NULL, "Hello", "Hello, World!", MB_OK);
    ExitProcess(0);
}

нужны user32.dll:MessageBoxA и kernel32.dll:ExitProcess.
Если обратиться к адресам памяти никак их не проинициализировав, то произойдёт исключение. Если при этом не настроены обработчики исключений, то выскочет традиционное окошко.

Comments

[Альбус Персиваль Вулфрик Брайан дамблдор]

"Можно через стандартные адреса выяснить где расположены системные .dll" - это как?

[Альбус Персиваль Вулфрик Брайан дамблдор]

насколько я помню первые 64кб служат для перехвата null указателей, так что пример скриншота некорректен.

[Альбус Персиваль Вулфрик Брайан дамблдор]

а какой адрес у ntdll.dll

[none7]

Ruins: > "Можно через стандартные адреса выяснить где расположены системные .dll" - это как?
На x86 в fs:[0x18] лежит указатель указатель на TEB(Thread Environment Block). Я уже отвечал на нечто подобное Как правильно написать SEH-обработчик на ассемблере под win32? . Так же требуется реализовать собственную функцию GetProcAddress. Способ бессмысленный и нужен только шелл-коду.
>насколько я помню первые 64кб служат для перехвата null указателей, так что пример скриншота некорректен.
Верно, но окошко будет тоже самое, только адреса изменяться.
>а какой адрес у ntdll.dll
Не фиксирован. Где то выше 0x70000000. Стандартные адреса точно с ней не конфликтуют.

[Альбус Персиваль Вулфрик Брайан дамблдор]

none7: Большое спасибо, насколько я понял либы в адресном пространстве процесса есть и нужно лишь найти их адреса? но если они там уже есть то какие именно и есть ли там ещё чего от других приложений? и раз так то неужели в windows процессам дозволенно работать с физической памятью?

[none7]

Ruins: Сразу после старта в WinXP были только ntdll и kernel32 и этого достаточно. Ведь есть kernel32:LoadLibrary и ntdll:LdrLoadDll. В Win7 у kernel32 появились зависимости, но только от системных библиотек. Но другие процессы вполне могут свободно выделять память, читать и писать в память любого процесса того же пользователя. Запускать новые потоки где им захочется. Так же есть оконные хуки, которые могут загрузить dll для перехвата оконных сообщений. Ещё есть COM который грузит, что попало читая реестр. Так, что чужие библиотеки тоже могут оказаться в процессе. Но к физической памяти доступ есть только у ядра.