Приветствую.

Мне потребовалось написать тулзу, которая будет изменять указанную пользователем строку в PE-файлах (.exe, .dll).

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

В качестве подопытного я взял утилиту nslookup.exe из официального дистрибутива Windows 8 (на всякий случай прикрепил её к данному сообщению).
Для примера я решил "дополнить" строку "Non-existent domain", выводяющуюся при попытке resolve'а несуществующего домена:

Default Server: UnKnown
Address: 192.168.1.1

> test
Server: UnKnown
Address: 192.168.1.1

*** UnKnown can't find test: Non-existent domain

Открываем XVI32, ищем строку, находим её по "физическому" адресу 0x1A48 (это, вроде, raw address называется, поправьте меня, если я не прав). Здорово, значит, она действительно хранится в самом PE-файле, а не во внешних файлах ресурсов.

Вопроса два:
- Что делать дальше? Можно, наверное, найти все ссылки на эту строку и заменить их на другой адрес, по которому мы расположим "увеличенную" версию данной строки (заранее пробежавшись по PE-файлу и обнаружив незанятое место в виде NOP'ов или 0x00). Вот только как искать эти ссылки?
- Почему указанная мной строка, если верить выхлопу PE Tools, хранится в секции .data? Она очень похожа на константную строку, почему же она тогда находится не в .rdata?

Может, есть готовое решение для подобной задачи, кстати?

Заранее благодарю.

1c12_01.11.2016_EXELAB.rU.tgz - nslookup.exe

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

neshta

На счёт хрома да, удивительно как легитимное приложение может использовать дельтаоффсеты.

-----
vx

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

difexacaw пишет: На счёт хрома да, удивительно как легитимное приложение может использовать дельтаоффсеты

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

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

neshta

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

-----
vx

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

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

Причем сама архитектура камня с памятью не располагают к подобному анализу и стало быть фундаментальная проблема.

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

neshta

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

-----
vx

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

difexacaw пишет: Тогда всё будет кодом в этом сегменте и имея все начала ветвей(входы) в принципе можно корректно выполнять анализ.

указатели все равно останутся, а с ними и расстрел памяти.

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

difexacaw пишет:
Сказал ведь, если нет релока
Что-то я запутался...

Смотрите.
Допустим, у меня есть DLL. В ней есть строка "foo" (ASCIZ), находящаяся по file offset'у 0x000C2A0C. Переведём file offset в VA и RVA при помощи CFF Explorer:



Теперь поищем ссылки на данную строку в секции .text. Находятся две (по коду примерно так и должно быть), и обе из них обращаются к "foo" по VA (т.е. с учётом preferred Image Base). Расположены эти обращения по RVA 0x000149BE и 0x00014B73.

Насколько я понимаю, если бы обращение к строке происходило по RVA, то никаких релоков не потребовалось бы (мы же не зависим от Image Base, указанного в Optional Header PE-файла).
Однако в случае с VA (по которым, судя по предыдущим ответам в топике, и будет в основном происходить обращение к данным из секций .data / .rdata в бинарнике) линковщик должен был упомянуть этот адрес в Relocations Table. Следовательно, в моём случае это будет практически всегда.

Вот только что именно линковщик должен поместить в Relocations Table? RVA, по которым находятся упоминания о VA? Т.е. в указанном мной примере 0x000149BE и 0x00014B73?

Читал статью с описанием формата на MSDN, но там всё как-то очень пространно сказано было -- "просто добавляет разницу между preferred Image Base и реальным Image Base к необходимым адресам".

Можете пояснить, пожалуйста?

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

b0r3d0m если вы меняете строку.. одни данные на другие.. (желательно не меня размера строки) то вас виртуальный адрес волновать не должен, виртуальный адрес.. это чисто теоретически.. куда будет спроэцирована ДЛЛ после загрузки. но с виндой.. высше ХР.. эта хрень уже не актуальна. винда сама может засунуть вашу ДЛЛ куда пожелает. Поэтому... строку вы попробуйте менять.. и грузить длл, если будут креши, сравните ваш файл с оригиналом, может вы криво патчите.
ЗЫ. возможно вы еще столкнетесь с проблемой подписи файла, если будете патчить дрова или системные либы

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

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

VodoleY, менять размер строки, к сожалению, придётся, об этом я и говорил в первом сообщении.

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

==============================

Мне вот что интересно. Что именно содержится в Relocations Table? RVA тех мест, где происходит обращение к тем или иным VA? Если так, то здорово -- получается, мне в любом случае трогать эту таблицу не придётся. Я ведь меняю лишь адрес, по которому находится обновлённая строка, а не расположение самого кода, который с этим адресом работает. Я прав?

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

b0r3d0m

> RVA тех мест, где происходит обращение к тем или иным VA?

Нет. Фиксап корректирует ссылку. Ссылка может быть как в данных, так и в самом коде, инструкция может содержать в себе ссылку. Из за релокации модуля эти ссылки необходимо скорректировать. Загрузчик парсит таблицу релокаций и фиксит ссылки, вне зависимости от того, в коде они или в данных. В релоках описаны только смещения ссылок(RVA).
По формату релоков - он прост, но там используется небольшая оптимизация - обьеденение в блоки етц, что в общем не существенно.

Добавлено спустя 2 минуты
VodoleY

> (желательно не меня размера строки) то вас виртуальный адрес волновать не должен

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

-----
vx

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

difexacaw пишет:
Ссылка может быть как в данных, так и в самом коде
Это понятно.

difexacaw пишет:
Из за релокации модуля эти ссылки необходимо скорректировать
Это тоже понятно. Для этого, собственно, Relocations Table и была придумана.

difexacaw пишет:
Загрузчик парсит таблицу релокаций и фиксит ссылки, вне зависимости от того, в коде они или в данных
Это тоже понятно, ему-то пофигу, где они находятся.

difexacaw пишет:
В релоках описаны только смещения ссылок(RVA)
Вот, на этот вопрос я и искал ответ. Вот здесь, получается, я правильно пример расписал, да?

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

b0r3d0m

Обычно я отвечаю всегда, но как то тот ваш вопрос пропустил.

На сколько понимаю вы запутались в VA vs RVA. VA это реальная для железа(процессора) величина, с ними он работает. RVA же не имеет никакого отношения к VA. RVA это смещение в проекции от начала. Соответственно расположение какой то части модуля постоянно относительно его начала, это и есть RVA. Реальный адрес формируется элементарно как VA начала модуля и смещение - RVA.
Есть есчо файловое смещение, оно существует для загрузчика, так как физически память гранулярна(страничная), то нельзя выполнить аллокацию памяти произвольного размера. Соответственно если две секции имеют разные права доступа(два региона в памяти), но коррелируют с физическим размером минимального региона, то единственное решение - выделить для каждого региона свой физический блок(страницу). Но из за выравнивания будет бесполезно использоваться память(утекать) в таком случае. Таким образом в модуле храняться секции с исходным размером, при отображении в память модуля секции выравниваются на гранулярность памяти. Файловое смещение отображается на RVA с учтом гранулярности.

-----
vx

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

difexacaw пишет:
На сколько понимаю вы запутались в VA vs RVA
Да нет, вроде не запутался
Вы, возможно, неправильно поняли мой вопрос.

Если совсем коротко.

Предположим, у нас есть PE-файл со строкой "foo", хранящейся в секции .data по RVA == 0xAABBCCDD.

В секции .text имеется обращение к данной строке, которое находится по RVA == 0x11223344.

Что в таком случае будет храниться в Relocations Table? 0x11223344 без упоминания об адресе самой строки (0xAABBCCDD), верно?

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

b0r3d0m

Обращение к строке" это вы имеете ввиду ссылку. Тоесть адрес строки расположен по адресу 0x11223344. Фиксап же для этой ссылки будет содержать её RVA = 0x11223344 - ImageBase.

-----
vx

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

difexacaw пишет:
Обращение к строке" это вы имеете ввиду ссылку
Да. "Ссылка" просто как-то слишком абстрактно звучит

difexacaw пишет:
Тоесть адрес строки расположен по адресу 0x11223344
Да.

difexacaw пишет:
Фиксап же для этой ссылки будет содержать её RVA = 0x11223344 - ImageBase
Спасибо, понял.

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

b0r3d0m пишет:
Что в таком случае будет храниться в Relocations Table? 0x11223344 без упоминания об адресе самой строки (0xAABBCCDD), верно?

Да. Но нет.
Каждый элемент таблицы имеет размер 16-бит. Что они означают, надо посмотреть в документации - в вашем же случае лучше не заморачиваться, а считать, что адрес адреса строки будет найден и значение по этому адресу адреса строки будет скорректировано системой в соответствии с новым базовым адресом модуля.


.......................................................................................................
Предположим, у нас есть PE-файл со строкой "foo", хранящейся в секции .data по RVA == 0xAABBCCDD.
В секции .text имеется обращение к данной строке, которое находится по RVA == 0x11223344.
..........................................................................................................
difexacaw пишет:
Фиксап же для этой ссылки будет содержать её RVA = 0x11223344 - ImageBase.

Напиши, пожалуйста, что такое VA, а что такое RVA.
И какая между ними связь.



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

dosprog пишет:
Каждый элемент таблицы имеет размер 16-бит
Спасибо, не знал.
Действительно, конечный адрес, по которому необходимо будет сделать релок, вычисляется из двух 16-битных значений (если быть более точным, то из одного 16-битного значения и 14 младших бит другого).

dosprog пишет:
Что они означают, надо посмотреть в документации
Уже посмотрел и поэкспериментировал на минимальном примере. Ещё раз спасибо.

dosprog пишет:
Напиши, пожалуйста, что такое VA, а что такое RVA
Я так и не понял, это мне вопрос или всё же difexacaw?

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

dosprog

> Напиши, пожалуйста, что такое VA, а что такое RVA.

Я же уже обьяснил понятно. А формат таблиц - не существенная деталь, тс с ним сам разобрался. Нужно было понимать что указатель в памяти есть ссылка, так же я говорил что используется оптимизация таблиц.

-----
vx

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

b0r3d0m пишет:
Я так и не понял, это мне вопрос или всё же difexacaw?

) Не тебе.
) Тот чуваг пишит удевитильные вещи. А в перерывах обзывает собеседников хуесосами.

Так пускай объяснит свою очередную хню.

--Добавлено--
)) Ну во. Объяснил. А ты говоришь - RelocationTable. Куда там нахер..
(см. как колбасит чувака, следующий пост, - пока не потёрли).

--Добавлено--
Эхх, потёрли..



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