| Сейчас на форуме: (+8 невидимых) |
 |
eXeL@B —› Вопросы новичков —› bound-импорт - каова его истенная суть? |
| Посл.ответ | Сообщение |
|
|
Создано: 26 мая 2014 16:11 · Личное сообщение · #1 Доброго времени суток всем! Пишу свой загрузчик PE файлов, уже месяц... и вот остановился на такой непонятной вещи, как bound-импорт. В интернете не нашел ничего путнего по этой теме. на сайте http://xaknotdie.org/22h/4/10.html более-менее нормальная информация, но все-же не достаточно точно описанная... я обычно проверяю всю подобную информацию на деле, но тут нет даже и не знаю с чего начать... меня интересуют оба варианта bound-импорта (старый, с использованием поля ForwarderChain и нового, использующего таблицу "связанного импорта"). Если есть люди, связывавшиеся с этой темой, пожалуйста объясните как оно работает! ------------------------------------------------------------------------------------------------------------------------ Чтобы было проще, ниже я опишу как я понял отдельные части этой статьи... Старый bound-импорт: Если DLLэкспортирует функцию, код которой находиться в другой DLL, т.е. при передаче экспорта, то используется поле ForwarderChainструктуры IMAGE_IMPORT_DESCRIPTOR. Поле ForwarderChainсодержит индекс в массиве FirstThunk первого импортируемого форварда. Если переданная функция - последняя, то это значение элемента соответствующего данному индексу равно -1. Если это не последний форвард в цепочке, то элемент содержит следующий индекс в этом же массиве. Т.о. происходит проход по цепочке переданных функций и заполнение адресами соответствующих двойных слов массива FirstThunk. Т.к. у нас есть параллельный массив - OriginalFirstThunk, то мы используем информацию из него об именах форвардных функций. Обратите внимание, то массив OriginalFirstThunkобязан быть не нулевым, чтобы использовать биндинг форвардных функций. Если утилите BIND передается PE-файл в котором нулевой массив OriginalFirstThunk, то она отказывается обрабатывать такой файл. Как я это понимаю: Пусть есть LIbrary1, которая производит импорт из некоторой Library2 функции Func1. поле ForwarderChain записи таблицы импорта Library1 содержит значение 1, а в таблице экспорта Library2 есть экспортируемая функция Func1, содержащая строку перенаправления экспорта из таблицы адресов экспорта (т.е. строки вида Library3.Func1, Library3.234, Library3.#55). т.е. ForwarderChain соднржит индекс названия/ординала импортируемой функции такого, который в таблице экспорта импортируемой библиотеки обязательно будет содержать "строку перенаправления экспорта"? (и если ForwarderChain = -1, то перенаправления не будет, а в адресах экспорта лежит непосредственно RVA функции). Новый импорт: Перед загрузкой файла в массиве элементов типа IMAGE_THUNK_DATA уже также содержатся адреса импортируемых функций. Изменится механизм импорта переданных функций. При NEWSTYLEBINDING поля TimeDateStampи ForwarderChain для DLL, из которых происходит экспорт форвардов, равны -1. Загрузчик ориентируется на эти значения -1, и использует директорию bound-импорта, где содержится информация о форвардных функциях. Bound-импорт называют также - привязанный импорт. В массиве DataDirectoryэлемент с индексом 11 соответствует директории отложенного импорта. Отложенный импорт используется при NEWSTYLEBINDING. Используя bound-импорт можно также оптимизировать процесс загрузки, т.к. есть возможность не пропатчивать, даже адреса, переданных функций. Как я это понимаю: Если в какой-либо записи таблицы импорта (путьс из LIbrary1) содержатся значения TimeDateStamp = -1 и ForwarderChain = -1, то это означает, что импортируемые функций расположены не в самой Library1, а в других библиотеках, в "таблице bound-импорта" (т.е. производится поиск IMAGE_BOUND_IMPORT_DESCRIPTOR-а с названием функции по адресу OffsetModuleName равным "Library1", а функции ищутся в либах, описанных ниже (в IMAGE_BOUND_FORWARDER_REF)). т.е. такой вариант допускает разброс списка функций по разным библиотекам, так???? --------------------------------------------------------------------------------------------------------------------------------------  |
|
|
Создано: 26 мая 2014 21:30 · Поправил: Dr0p · Личное сообщение · #2 MasterMan342 Есть очень много механизмов, которые полноценный лодер должен поддерживать. Это делает бессмысленным написание своего лодера, темболее что существует полноценный нэйтивный. Используйте его. В этом случае не нужно вообще думать про сабжевые механизмы. |
|
|
Создано: 26 мая 2014 22:40 · Личное сообщение · #3 Dr0p пишет: Есть очень много механизмов, которые полноценный лодер должен поддерживать. Это делает бессмысленным написание своего лодера, темболее что существует полноценный нэйтивный. Используйте его. В этом случае не нужно вообще думать про сабжевые механизмы. Я пишу загрузчик лишь для общего понимания сути дела)) ---------------------- в общем, с новой системой импорта я разобрался! остается вопрос, как работает старое перенаправление импорта по полю ForwarderChain? |
|
|
Создано: 26 мая 2014 23:11 · Личное сообщение · #4 MasterMan342 Все ответы есть в исходниках загрузчика. Мне конечно всё равно, просто советую вам как надо делать, ибо сам их написал дохера. В любом случае лучше чем LWE мотор вы ничего не реализуете. Забавно, но таких вопросов тут было хз сколько 
|
|
|
Создано: 27 мая 2014 17:40 · Личное сообщение · #5 Dr0p человек разобраться хочет с PE, а ты руки отбиваешь... Лучше бы ссыль на хорошую доку кинул, раз сам их написал дохера 
----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
|
Создано: 27 мая 2014 21:19 · Личное сообщение · #6 Isaev > Лучше бы ссыль на хорошую доку кинул, раз сам их написал дохера Я их не по докам писал. Небыло никаких технологий в этой области, пока я не продвинул. |
|
|
Создано: 03 июня 2014 14:03 · Поправил: theCollision · Личное сообщение · #7 MasterMan342 Разобрался или нет? Чем могу быть полезен? Приведу краткую выдержку, для тех кто столкнется с таким же вопросом. 1) Основная цель баунда: Избежать настройки адресов для импортируемых элементов. Это возможно в случае если тот самый модуль из которого Вы импортируете расположен строго по тому адресу загрузки, где Вы его и ожидаете. Тогда этап настройки адресов можно пропустить, в противном случае все как обычно. 2) Термин "баунды" не совсем корректный. Лучше применять "привязку". 3) Есть два типа привязки, старый и новый. Определение этих типов : bool isBindingNew = ( impDescr.TimeDateStamp == UINT32_MAX ); bool isBindingOld = ( impDescr.TimeDateStamp > 0 ) && !isBindingNew; где impDescr - IMAGE_IMPORT_DESCRIPTOR Если останутся вопросы, то прошу задавать по-короче, большие посты читать лень! Добавлено спустя 5 минут 4) Для малварщика привязки это дополнительный механизм сокрытия хуков. Другими словами, можно привязаться к какому либо модулю и поставить в один из импортируемых элементов адрес на свой "зловредный" код. Тогда, если совпадет фаза луны, то код может быть выполнен. Этот тип сокрытия хуков не используется по причине того что антивирусы это обнаруживают достаточно легко, а вот коэфициент срабатываемости хука слишком низкий. Вот пример обнаружения: Code:
----- My love is very cool girl. |
|
eXeL@B —› Вопросы новичков —› bound-импорт - каова его истенная суть? |
Для печати