Здравствуйте знатоки работы компьютерного железа !

Мне нужно пояснить одну вещь.

Допустим что при выполнении прикладной программы она вызывает подпрограммы WINDOWS — API-функции.
Но чтобы вызвать подпрограмму нужно задать процессору в инструкции вызова подпрограммы либо явно адрес начала кода вызываемой подпрограммы в самой инструкции вызова, либо адрес ячейки памяти где хранится адрес начала этой подпрограммы. Так же обстоит дело с вызовом API-функций. Значит прикладная программа имеет либо то либо другое.
Известно что адрес какой-нибудь функции АПИ можно узнать, если загрузить библиотеку в которой находится эта функция в память функцией LoadLibrary, а потом узнать адрес функцией GetProcAddress. После этого можно вызывать АПИ функцию ссылаясь на ячейку памяти в команде call m32. В ячейке памяти m32 имеется тот адрес, который получен функцией GetProcAddress.
Хорошо. Так можно узнать адреса почти всех АПИ-функций.
Но если мы таким образом вызываем функции АПИ, то как мы можем вызвать сами функции LoadLibrary или GetProcAddress?
Ведь мы не можем узнать их адресов самой же функцией GetProcAddress, потому что выше приведенным образом в этом случае мы не можем вызвать функцию GetProcAddress так как эта же функция должна выдать свой адрес. То же самое и с LoadLibrary.
Выходит, что адреса этих двух функций должны быть константами.
Если это так, то где я могу узнать значения адресов этих АПИ функций (LoadLibrary и GetProcAddres) ?
А может я вообще туплю...
Многие наверно подумают "ну для того чтобы вызывать АПИ есть же подключаемые файлы "*.inc" чего тут голову морочить ?"
Я знаю, что для того чтобы можно было вызывать АПИ в ассемблерной программе, есть подключаемые файлы.
Но меня уже задолбало то, что во всех книгах написано, что эти файлы нужно использовать, а не объясняется их содержание и то как они используются компилятором.
И вообще в конечном итоге, интересно, какой же тип команды процессора вызова подпрограммы-АПИ используется в WINDOWS пиложениях ?
Может адреса АПИ функций имеют всегда постоянное значение и их не обязательно узнавать функцией GetProcAddress ?
Может постоянное значение имеют только адреса функций LoadLibrary и GetProcAddress ?
Ну могу я понять в конце концов что на самом деле представляют инструкции типа call GetProcAddress, call LineTo и другие ?
Ведь я же знаю, что процессору нужно каким-то образом задать адрес этих функций !
Я не хочу просто так подчиняться каким-то указаниям учебников не зная что делается на самом деле.

Тут пример с GetProcAddress на VB:
VB-VB-002158

А ну попробуйте так


Проверьте, я прав или нет ?
А то я могу и ошибаться
Теперь за сколько времени сдвигается... ?


Это сообщение отредактировал(а) sgi1981 - 31.3.2006, 03:39

Обычная проблема для вирусов Но обычное приложение использует ИМПОРТ адресов функций - посмотри конец EXE-файла для Windows, и ты увидишь...



Дельная мысль ! Но асм - это наименьшее evil в этом смысле. Инклюды для асма - те же инклюды для C. Однако все, что нада сделать - это подставить в PE-файле те функции, которые тебе нужно ИМПОРТИРОВАТЬ. См. также формат PE-файла.



Нет, это "богохульство" Нет никаких загадочных "выделенных функций". Есть только машинные команды _в_любом_случае_, хоть те DOS, хоть те UNIX.

Я несколько часов назад убедился что все API-функции WINDOWS из библиотек ядра этой ОС
kernel32.dll
user32.dll
gdi32.dll

всегда имеют постоянный адрес в памяти независимо от того как занята память.
Значит адреса этих функций - это константы.
Я даже вызывал отдельные АПИ используя заранее известные их адреса.

Например

Это будет аналогично

Я имел в виду вопрос какие формы машинной команды CALL используется при вызове функций АПИ в программах

Ты не прав потому, что "the number to shift by" передается при помощи указателя на него. Почему я не помню. Но никто не запрещает провернуть всю работу описанную в статье и сказать, что value можно передать "по простому". Посмотреть надо ли запоминать esp или нет (компилятор это делает) и замерить время исполнения.

А вообще статья не про то как писать сдвиг на ассемблере.

"get the number to shift by" - число разрядов на которое сдвигается операнд -
это значение которое записывается непосредственно в стек.


Передается при помощи указателя значение
"get the pointer to the number to shift" - операнд который нужно сдвинуть.



В данном случае запоминать esp не нужно потому, что мы учитываем все команды push и pop и esp при выполнении этой подпрограммы никак не может измениться против нашей воли. Даже если процессор переключится на подпрограмму обработки прерывания, то при выходе из неё он все равно восстановит значение esp таким какое оно и было до выполнения прерывания.


Потому что в противном случае сдвигаемое значение осталось бы в стеке и не скопировалось назад в оригинальный операнд.

Это сообщение отредактировал(а) sgi1981 - 1.4.2006, 00:28

Интересно. Ладно, спасибки, посмотрим как-нибудь. Если хочешь попробуй сам протестировать, мне пока некогда...

Правда,

суммирование здесь забывать не стоит. Возможно из-за него то на то и выйдет - то есть быстрее не будет.

Это будет аналогично ТОЛЬКО в данной версии OS, данном ее билде.

Существует несколько способов узнать адрес API, минуя импорт в PE (актуально для вирусов и тп). Например, сканирование kernel32 и проверка crc32, и т.п.

Допустим.
Каким тогда образом прикладная программа узнает адрес API-функции работая на разных версиях ОС ?
Ведь чтобы вызвать подпрограмму процессору нужно указать её адрес. А это можно сделать либо непосредственным указанием адреса точки перехода в машинной инструкции, либо указать на ячейку памяти где хранится адрес начала кода подпрограммы.
Если как вы говорите адреса АПИ могут меняться от одной версии ВИНДЫ к другой и одна и та же программа будет выполняться, то должны существовать ячейки памяти куда либо ОС либо программа должны будут подставлять новые адреса для АПИ в ходе выполнения программы!


Ну это опять из оперы "нажмите на эту кнопку и все сделается за вас". Нет мне это не нравится.


Ну я же писал про функции

LoadLibrary и GetProcAddress.

Значит в исполняемом файле формата PE есть такая секция, где перечисляются названия нужных функций API и между названиями четырехбайтные ячейки памяти. Когда загрузчик запускает такой файл, он просматривает имена подпрограмм в той секции и уже в памяти подставляет нужные адреса в эту секцию.
Так все происходит ?

Примерно так Я же рекомендовал открыть EXE в far'е и посмотреть его таблицу импорта. Импорт может быть также по ординалу - ID функции, но это не рекомендуецца.

Для удобного просмотра разнообразных исполняемых файлов и файлов других типов есть прекраснейшая программа PEView (30 K)

Она, кстати, прилагается к книге Свена Шрайбера "Недокументированные возможности Windows 2000 (8 M)",
что служит весомым подтверждением в пользу программы (которую я использую уже много лет)
Автор программы открыт для общения (можно присылать ему замеченные ошибки - он их исправляет)

Сайт разработчика, посвящённый программированию на Ассемблере содержит несколько других полезных программ,
например, программу преобразования H-файлов в INC-файлы и удобно структурированного просмотра полученных файлов (29 K)

Также есть там и начальные примеры программ для Windows на Ассемблере (67 K)

самый эффективный способ получения адреса LoadLibrary - "разборка" имаджа кернела загруженого в память
проще говоря кернел же у нас мапится автоматом в любой процесс
вот и сканируем память на присутствие таблицы ехпорта
(вариант с SEH не будет пахать на МЕ к примеру)