Доброго времени суток и приятного прочтения,
Я тут решил по заниматься садо-программированием PE на Ассемблере, то есть и т.д. И вроде всё шло очень даже прилично(ещё не компилировал, но вроде как проблем в понимании написанного не возникало) и тут я добрался до import table и вообщем загрузки модулей, где как раз и началось недопонимание. Хочется сделать всё максимально эффективно(чтоб клик по иконке, а окошко уже 10 секунд как открыто), сначала думал обойтись вообще без таблиц импорта: вылавливать kernel32.dll и через него подгружать нужные библиотеки чуть ли не кусками в удобные места моего кода, позже начал рассматривать статическое связывание. И тут информации почти нет: вроде как есть таблица куда заносишь имя библиотеки и версию, он проверяет версию и если она совпадает, тогда он её грузит. Только там нет указания адреса, то есть (насколько я понял) он грузит её по imageBase, которая для 90% dll = 0x10000000, а это значит - все кроме первой dll будут загружены по другим адресам и при этом сам PE-загрузчик ни куда не возвращает новый адрес загрузки. А если самому грузить, то к чему вообще этот вид связывания и тогда надо через динамическую линковку грузить первую kernel32.dll как минимум.
В общем: как лучше(быстро) всё это грузить? если через статику, то как правильно, да вообще как? и kernel32 можно ли выловить по быстренькому?

Честно говоря я вообще не рассчитываю на скорость со стороны PE-загрузчика Windows.
Конкретные библиотеки: user32, vulkan-1(не то что бы я убийцу ГТА собрался писать, просто ведьмака3 хочу оптимально переписать) - тут у меня вопрос: vulkan поставляется производителем ГП вместе с дровами, а значит что размер dll может отличаться, а если это внешний общий api, который на всех компах одинаков, значит он переадресует на другие dll(которые уже от производителя) - будет ли статика здесь приемлема?

Просто сложно ставить эксперименты с заголовком PE, я как процессор без переходов, всё строго последовательно, иначе боюсь потеряться.
Ну вроде всё, всем спасибо - все свободны, возвращайтесь когда мозги снова начнут что либо воспринимать))

| Сообщение посчитали полезным:

Ты задачу бы описал что ли. Начал за здравие, а кончил за упокой.
Динамическое связывание - это LoadLibrary + GetProcAddress. Получить базу загруженного модуля можно через GetModuleHandle с оговорками.
Статическое связывание у тебя отрабатывает система при CreateProcess.
Загрузка по разным базам корректируется через релоки. Системные dll предзагружены по "фиксированным" адресам.

-----
старый пень

| Сообщение посчитали полезным:

Ruins007

> И тут информации почти нет: вроде как есть таблица куда заносишь имя библиотеки и версию, он проверяет версию и если она совпадает, тогда он её грузит.

Сформулируйте свои мысли более корректно и чётко, а так совсем не понятно. Вы хотите реализовать свой загрузчик или для каких то целей(каких?) использовать системный ?

-----
vx

| Сообщение посчитали полезным:

Я специально вынес отдельно,
Ruins007 пишет:
В общем: как лучше(быстро) всё это грузить? если через статику, то как правильно, да вообще как? и kernel32 можно ли выловить по быстренькому?
Я рассматриваю разные способы загрузки dll. Мне интересно какой способ даёт максимум скорости при запуске Шник.exe? и как этот способ правильно использовать?

Добавлено спустя 6 минут
r_e пишет:
Динамическое связывание - это LoadLibrary + GetProcAddress. Получить базу загруженного модуля можно через GetModuleHandle с оговорками.
Статическое связывание у тебя отрабатывает система при CreateProcess.

Описание таблицы импорта cs.usu.edu.ru/

| Сообщение посчитали полезным:

Максимальную скорость даст склеить все EXE и DLL в один модуль, при этом пофиксив импорты, релоки, ресурсы и т.д., проставить прямые адреса в системных библиотеках в таблицу импорта и вырезать ее, вырезать релоки.
И положить все это говно на RAMDISK.
Только нахера? Все равно создание процесса - операци достаточно быстрая, кроме совсем уже извращенных случаев.

| Сообщение посчитали полезным:

Так каким образом мне "проставить прямые адреса в системных библиотеках"?
kunix пишет:
Только нахера? Все равно создание процесса - операци достаточно быстрая, кроме совсем уже извращенных случаев.
Это не для практичного решения, а скорей интерес в создания максимально быстрого импорта

| Сообщение посчитали полезным:

Все просто.
Пройтись по таблице импорта каждого модуля и проставить туда нужные адреса в системных библиотеках.
Потому убрать таблицу импорта из модулей, чтобы загрузчик PE не обрабатывал ее еще раз.
И конечно же, отключить ASLR для данного процесса, чтобы системные DLL имели всегда нужные адреса.
А вообще вы маетесь херней.

| Сообщение посчитали полезным:

Не надо заниматься бесполезными вещами.
Загрузка DLL "более эффективная", чем системным загрузчиком, всё равно не получится.

Можно залепить PE-файл вообще без PE-таблицы импорта,
то есть весь импорт загружать динамически (LoadLibrary/GetProcAddress) из программы.
Но зачем такое нужно?

Что касается "моделирования PE" - тоже бесполезная затея.
Не надо напрягать транслятор самодельными эквивалентами функционала линковщика.

Кстати, посмотрите, как всё это организовано в FASM'е.

| Сообщение посчитали полезным:

Просто ему заняться нечем, вот и мозги сношает. У баб тоже так, когда заняться нечем - мозг сношают, а так борщ отправляешь варить и все нормально

| Сообщение посчитали полезным:

ТС так и не ответил, ну ладно. Обычно пытаются примитивными методами реализовать загрузку - разбор пе, вот недавно заспамила все форумы примитивная поделка --> Link <--

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

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

За всё время было лишь одно приемлемое и эффективное решение, но это не просто примитивная реализация работы с пе - враппер над системным лодером(LWE). Оно было реализовано под ось младших версий, но подход оказался крайне годным - в каждой новой версии системы оно робит без ошибок или багов.

-----
vx

| Сообщение посчитали полезным:

И на том спасибо, ладно буду всё таки import table использовать.

| Сообщение посчитали полезным: