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

Чем добавление новой секции может быть принципиально лучше увеличения размера последней из существующих? (цель -- записать в бинарник свои данные, которые гарантированно не будут перезатёрты / перезаписаны кем-то другим)

Везде советуют именно добавление новой секции, хотя с точки зрения кода это несколько сложнее (надо не забыть поменять больше разных полей и заполнить больше разных структур). В случае же с увеличением размера последней секции мне необходимо поменять лишь SizeOfRawData и VirtualSize этой секции, а также SizeOfImage в Optional Header'е).

Единственное, что приходит на ум, так это неудовлетворяющие требованиям добавляемых данных Characteristics последней секции, но и их поменять тоже не проблема.

В чём тогда соль?

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

b0r3d0m

Такая проблема возникает только в виксах, где не верный атрибут секций или формат(расположение массивов данных в кодосекции etc) приводит к срабатыванию авера.

Так же обычно последняя секция не исполняема, а установка RWE не есть хорошо, это будет детектится ав и не ясно как это совместимо с DEP на последних версиях нт.

-----
vx

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

difexacaw пишет: Такая проблема возникает только в виксах

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

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

difexacaw пишет:
Такая проблема возникает только в виксах
Виксах?

difexacaw пишет:
где не верный атрибут секций или формат(расположение массивов данных в кодосекции etc) приводит к срабатыванию авера
Что значит "неверный атрибут"? Например, execute у секции .reloc?

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

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

b0r3d0m пишет:
Например, execute у секции .reloc?
типа того. если там ресурсы - могут какие-нибудь траблы вылезти в 2k/xp sp0. поэтому и рекоммендуют, все винды протестить не просто уже

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

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

Блин, это ж столько мороки с добавлением новой секции...
Из-за добавления ещё одного IMAGE_SECTION_HEADER все адреса из RelocationTable тоже передвигать придётся, получается...

Добавлено спустя 26 минут
Хотя нет, фигню сказал.
Если добавление новой секции не приведёт к тому, что размер PE-заголовков станет "накладываться" на первую замапенную в виртуальное адресное пространство секцию (так было бы, если, например, размер заголовков PE-файла стал равен 0x1100, а VirtualAddress первой секции == 0x1000), то всё будет нормально.

Другое дело, что в случае добавления новой секции нам так же придётся менять header'ы всех других секций (PointerToRawData etc).

Я прав?

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

b0r3d0m пишет:
Из-за добавления ещё одного IMAGE_SECTION_HEADER все адреса из RelocationTable тоже передвигать придётся, получается..
Это с какого перепуга? Да изучи ты мат часть, хоть раз разберись на любом примере. У мелкомягких всё прозрачно написано. А то уже в нескольких темах глухой со слепым обсуждают (как два глухаря на току) какие у слона яица!
Один клоун даже очень смело утверждает, что динамический анализ - это панацея. Хотя бы прописал, что только в некоторых случаях. И есть масса случаев, когда он вряд ли поможет. Вообще-то это NP задача.

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

DrVB_5_6 пишет:
Это с какого перепуга?
Да я дальше уже написал. Чисто теоретически, я так понимаю, это всё же может случиться при добавлении секции, разве нет?

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

DrVB_5_6

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

-----
vx

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

difexacaw пишет:
Обычно формат модуля нормальный, он собран компилятором, а не автоматикой.
Я, правда, не совсем понял насчет автоматики, а почему-то постоянно натыкаешься на не совсем "нормальные" модули, хотя и собраны они компиляторами. Извращениям несть числа...

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