Доброго времени суток! Есть задача: в произвольном экзешнике необходимо в таблицу импорта дописать свою dll, возможно, не одну. Для этого было решено: найти таблицу в исходном файле, найти место в файле, которого достаточно для размещения модифицированной таблицы(с добавлением своих dll), записать модифицированную таблицу в новое место. Модифицировать необходимые RVA. Пока что не могу справиться с последней задачей, модификацией необходимых RVA. Так как не могу понять какие RVA нужно править. Не понятно, что должно лежать в IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress: то-ли смещение таблицы внутри файла, то-ли адрес, по котрому загрузчик должен отобразить таблицу. Саму секцию импорта найти не могу, потому как О ЧУДО, она в подавляющем большинстве экзешников не называется .idata. Каждый линкер обзывает как хочет... Да и её поля VirtualAddress и PointerToRawData тоже не всегда имеют тот смысл, который описан в доках. В каких-то экзешках IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress и .idata::VirtualAddress равны, в каких-то вообще не рядом. Да и по .idata::PointerToRawData практически никогда не лежит смещение таблицы внутри файла... Люди добрые, хакеры продвинутые, ну направьте на путь истинный!!!!! HELP!!!!!!!!!!
>> IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress там лежит смещение относительно начало образа в памяти, уже промапленного загрузчиком. Я объяснял вам уже зависимость между оффсетом и rva здесь http://wasm.ru/forum/viewtopic.php?pid=431187#p431187 >> Саму секцию импорта найти не могу, потому как О ЧУДО, она в подавляющем большинстве экзешников не называется .idata Физическая структура (секции + заголовок) PE файла не зависит от логической (Data Directory). >> Да и её поля VirtualAddress и PointerToRawData тоже не всегда имеют тот смысл, который описан в доках. Они всегда имеют, смысл описанный в доках, иначе загрузчик не загрузит файл >> В каких-то экзешках IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress и .idata::VirtualAddress равны они и не должны быть равны, см выше. я это объяснил >> Да и по .idata::PointerToRawData практически никогда не лежит смещение таблицы внутри файла Там и не должно оно лежать. Там лежит оффсет начала секции. Секции описывают непрерывные области памяти, с одинаковыми аттрибутами защиты и данные которые нужно туда поместить Вы либо не читали документацию, либо её не поняли совсем. =\
>>они и не должны быть равны, см выше. я это объяснил Читайте текст внимательно! В раpных экзешниках, которые я парсил, по разному! В каких-то они равны! >>Физическая структура (секции + заголовок) PE файла не зависит от логической (Data Directory). DataDiractory не описывает физическую структуру! Она лишь описывает оффсет конкретной области от начала файла, если верить документации! А на самом деле оффсет от начала образа, уже отмапенного загрузчиком! >>Вы либо не читали документацию, либо её не поняли совсем. Что самое главное, читал не один я, а поняли все одинаково. Что-то сильно сомневаюсь, что вы её поняли с первого раза и не задавали подобных же вопросов. Понимание приходит во время практики, как известно.
как все запущено. Вы хотя бы попытались понять, что я вам написал? >> Читайте текст внимательно! В раpных экзешниках, которые я парсил, по разному! В каких-то они равны! "не должны" вы прочитали как никогда не будут равны? Эти адреса никак не зависят друг от друга и описывают разные объекты в файле. Они могут совпадать или не совпадать в зависимости от линкера. Лоадеру похрену где конкретно находится одна из директорий, главное чтобы в пределах не дискарабл секции (или заголовка даже). >>DataDiractory не описывает физическую структуру! а я что описал. И я не об IMAGE_DATA_DIRECTORY говорю только, я говорю о Data Directory как об объектах в пе файле. Массив структур IMAGE_DATA_DIRECTORY описывает их расположение в pe файле. Вот это и называется логической структурой. >> Она лишь описывает оффсет конкретной области от начала файла, если верить документации! А на самом деле оффсет от начала образа, уже отмапенного загрузчиком! ну и как вы документацию читаете? >> Что-то сильно сомневаюсь, что вы её поняли с первого раза и не задавали подобных же вопросов. Понимание приходит во время практики, как известно. не сразу согласен, но я не бежал на форум, а обкладывался распечатками статей, спецификации, хидеров и сурцов лоадера и курил до просветления.
>> Вы хотя бы попытались понять, что я вам написал? Примерно как и вы, написанное мной. >> не сразу согласен, но я не бежал на форум, а обкладывался распечатками статей... Во-первых, кто вам сказал, что я сразу побежал на форум, а сам в это время ничего не искал и не читал, а тупо ждал пока мне на форуме кто-то ответит? Исходники загрузчика, и вообще исходники ntdll по части RtlImageXXX к моменту вашего ответа я уже изучил и понял, что нужен перевод Rva <-> fileoffset. Во-вторых, а зачем тогда вообще форум нужен?.. По-моему, он и нужен для того, чтобы тот, кто сталкивался с подобной задачей, объяснил новичку, чтобы тот не изобретал велосипед.
в данном случае изобретение велосипеда необходимо, тк это база, без которой совсем грустно. Ладно, давайте не оффтопить.
