Тут RAW = RVA = 0x1B286

Но "калькуляторы" упорно выдают 0x15C86
Я в целом не против, кто я такой, чтобы им указывать и "изысканиями" заниматься сегодня уже нет настроения, но все же лыжи не едут, или?

--> dll <--

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

у меня у самого тут нечто - скачал айтунс запускаю

C:\Downloads\iTunesSetup.exe не является приложением win32

это SFXcab архив выдернул из него потраха то же самое
знаю что win 32 и не битый не пойму мож я тоже в "луже и в лыжах"
в атаче установщик подскажите чё он под xp Не идёт?

b44c_13.08.2018_EXELAB.rU.tgz - SetupAdmin.exe

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

VOLKOFF пишет:
Но "калькуляторы" упорно выдают 0x15C86
да ты чё
грёбанные калькуляторы возомнили себя богами и ещё какую то ересь несут про RVA и FО

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

VOLKOFF пишет:
Но "калькуляторы" упорно выдают 0x15C86
Ну ведь правильно выдают. 0x1b286 (твой виртуальный адрес) - 0x1b000 (виртуальный адрес секции) + 0x15a00 (физический адрес секции) = 0x15с86

Добавлено спустя 8 минут
SDK пишет:
подскажите чё он под xp Не идёт?
OS Version и Subsystem version в заголовке поменяй с 06 на 05. В байтах от начала файла 0x148 и 0x150. Может и заработает.

Но вообще если не идет, то значит и не должен. Ищи версию под XP.

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

hypn0 пишет:
Ну ведь правильно выдают
Ну какбы не совсем.
Если открыть файл любым hex редактором и перейти по 0x1B286 мы попадем на нужные последние байты файла, между тем по "правильному" 0x15C86 совсем "не то пальто".
Прикол в том, что в конце файла прилеплен сертификат, что при просчете не учитывается и с одной стороны по всем признакам это вроде как часть файла, но по сути - чужеродная фигня сбоку. Надо костыль написать под такие кейсы

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

Да всё там правильно.
Загаданный файловый оффсет 0х15с86 по-любому приходится не на оверлей, а на размеченную область.
И это адрес .1001B286

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

Добрый человек, скажи пожалуйста, как RVA у тебя получилось равным RAW? 1B000+286=1B286 и 15A00+286=15C86. Калькуляторы упорно выдают тебе правильное значение RVA=1B286 для RAW=0x15C86 (может тебя ввело в заблуждение что это релоки?)

ClockMan пишет:
грёбанные калькуляторы возомнили себя богами и ещё какую то ересь несут про RVA и FО
мировой заговор калькуляторомасонов, не меньше

VOLKOFF пишет:
Если открыть файл любым hex редактором и перейти по 0x1B286 мы попадем на нужные последние байты файла, между тем по "правильному" 0x15C86 совсем "не то пальто".
Прикол в том, что в конце файла прилеплен сертификат, что при просчете не учитывается и с одной стороны по всем признакам это вроде как часть файла, но по сути - чужеродная фигня сбоку. Надо костыль написать под такие кейсы
Никакой костыль там не нужен. При анализе файла создается список виртуальных и реальных областей, калькулятор берет смещение от базы той области, куда попадает введенный тобой адрес и прибавляет к другой базе этой же области. Сертификат/зип архив в sfx/поэма Гомэра Илиада, дописанные в конец файла, никак не влияют на рассчет RVA/VA/RAW. Что по смещению 1B286 ты куда-то там попал, ну шара залетела значит, повезло. Никакой закономерности тут нет, да, это чужеродные данные, которые даже не загружаются в память при загрузке длл.

-----
2 оттенка серого

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

VOLKOFF пишет:
Если открыть файл любым hex редактором и перейти по 0x1B286 мы попадем на нужные последние байты файла, между тем по "правильному" 0x15C86 совсем "не то пальто".
О чём спор? Попробую попроще объяснить. Там же явно на картинке 0x15C86 - File Offset, смещение в файле до маппинга. Это не то же самое, что RVA. Маппинг секции файла со смещения 0x15A00 при загрузке dll идёт в памяти по адресу 0x1B000

VOLKOFF пишет:
Тут RAW = RVA = 0x1B286
RAW совсем не обязано быть равно RVA!

-----
IZ.RU

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

Эх, хорошо что сегодня понедельник, а не завтра, как вчера...

dosprog пишет:
Да всё там правильно
Для меня "правильно" не когда все сделано по правилам, а когда есть нужный результат

f13nd,DenCoder
Сертификаты адресуется не по RVA, а по файловым смещениям (тк не грузятся в память, существуя только на диске).
Канонический подход заключается в прокрутке цикла NumberOfSections, выравниванию размеров (по необходимости) и проверке попал ли адрес в диапазон.
Для оверлеев такая схема не будет работать. Можешь вставить сырой оффсет (1B286) оверлея в любой калькулятор и он тебе покажет 'Out of file' в RVA, что очевидно.
Поэтому я перестал заниматься "канонизмом" и запилил фикс, учитывающий подобные кейсы, проблема решена. На этом какбы и все

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

Как самый примитивный "живой" пример: патч оверлея > дифф любой тулзой с RVA адресацией (да, это достаточно распостранено и даже VA бывает в редких случаях удобнее, если ASLR нет, многие знают толк в извращениях, но не признаются Хотя с другой стороны не было бы тогда выбора VA|RVA адресации в популярных тулзах ).
В итоге любой патчер по такому диффу запатчит мимо, или ругнется, т.к. адрес посчитает "по классике".

Тему оставлю ради дальнейших бесценных комментов Инде. Всем Добра!

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

VOLKOFF пишет:
Для оверлеев такая схема не будет работать.
Правильно. Она и не должна работать, потому что оверлей, это просто данные, которые "приклеели" к ехе-файлу. Следовательно если нужно работать с оверлеем, то нужно просто найти его начало (физический адрес последней секции + физический размер этой секции) и попадаем ровно на начало оверлея. Обратиться к нему через RVA и не получится.
VOLKOFF пишет:
Как самый примитивный "живой" пример: патч оверлея > дифф любой тулзой с RVA адресацией
Я всё-таки не понимаю, почему нельзя "вручную" определить начало оверлея? Это же очень просто. Берем таблицу секций, ищем последнюю и выше написал как считаем.

Хотя знаю случай когда такой метод не сработает. У микрософтовских обновлений для WinXP часто стоит некорректный физический размер (значения размером с сам файл) последней секции. Для этого можно взять виртуальный размер секции. Правда при этом попадём на паддинг, но его не сложно пропустить.

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

VOLKOFF
К слову, File Location Calculator от ManHunter / PCL определяет корректно.

Скачать: File.Location.Calculator.1.4-PCL.zip

-----
EnJoy!

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

Jupiter пишет:
К слову, File Location Calculator от ManHunter / PCL определяет корректно
О, прикольно, у меня на скрине версия 1.0, оказывается обновка есть
Только он выдает ровно тоже. Тут действительно "специфический" случай и универсально это зафиксить
в отрыве от контекста имхо труднорешаемая задача. В моем коде есть возможность валидации входящих данных, поэтому залатать удалось, а в стэндэлон калькуляторе хз, тут без магии не обойтись

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

VOLKOFF пишет:
Только он выдает ровно тоже
File Location Calculator от ManHunter показывает абсолютно корректное значение.
Возможно, тебе нужна инструкция по тому, как его использовать?

1. Запустил "flc.exe"
2. Кинул твой файл "d3dhook.dll" в окно File Location Calculator
3. Выбрал "File Offset:"
4. Вставил в поле справа от "File Offset:" твоё значение: 1B286
5. Нажал "Calculate"
6. Получил в поле "PE section name" значение "Overlay" и в поле "Hex Data" данные "58 ED".

-----
EnJoy!

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

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

-----
2 оттенка серого

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

Jupiter пишет:
3. Выбрал "File Offset:"
Детектить оверлей по RAW это конечно хорошо и просто, но только это значение нужно вставлять в RVA поле
Об этом в первом посте и речь.

f13nd пишет:
проще, чем сделать патчер, работающий с файловыми смещениями
Хороший патчер должен уметь покрывать все потенциально возможные кейсы. Патчить только по RAW много ума не надо, такого добра навалом везде...

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

VOLKOFF пишет:
Детектить оверлей по RAW это конечно хорошо и просто
Это не "хорошо и просто", а единственно возможный вариант, поскольку никаких RVA для overlay не существует. Overlay по определению находится за границами виртуальных адресов.
Я то думал, ты прогой не умеешь пользоваться, а ты вообще матчасть не знаешь.

-----
EnJoy!

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

Jupiter пишет:
никаких RVA для overlay не существует
Спорно. Это оверлея в замапленом (SEC_IMAGE) образе не существует, а именно при таком маппинге конвертируются адреса. Однако это совсем не значит, что нельзя получить "псевдо RVA" адрес оверлея и среди прочих "валидных" его определить и использовать впоследствии на полном маппинге файла (или образе на диске). Я уже говорил, крайне специфический кейс с определенной долей здорового "извращенчества", но ничего сверхестественного

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

VOLKOFF пишет:
Сертификаты адресуется не по RVA, а по файловым смещениям (тк не грузятся в память, существуя только на диске).
Так сказал бы сразу, что у тебя оверлей, быстрей бы тебе ответ нашли. )

-----
IZ.RU

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

VOLKOFF пишет:
Спорно
Видя всё, что ты пишешь, очевидно, что у тебя каша в голове в части понимания понятия "overlay".
Ты попробуй для себя сформулировать, что такое "overlay", как ты это понимаешь. Такое ощущение, что у тебя какое-то личное, своё, отличное от других понимание термина "overlay". И в твоём понимании у "overlay" есть не только файловое смещение, но и относительный виртуальный адрес.

-----
EnJoy!

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

Jupiter пишет:
Такое ощущение
Независимо от твоего ощущения, мой код не становится менее рабочим
Несмотря на то, что тема открыта для общего обсуждения (мало ли что интересного понапишут), вопрос уже был решен. Матчасть помним... скорбим

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

VOLKOFF пишет:
мой код не становится менее рабочим
А давай проверим:
допустим, у тебя есть функция ImageRVAtoFileOffset, которая возвращает файловое смещение для заданного значения RVA. Какое значение возвратит эта твоя функция для значения RVA = 1B286 в файле из твоего первого поста ?

-----
EnJoy!

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

VOLKOFF пишет:
Независимо от твоего ощущения, мой код не становится менее рабочим
Ну дай то Бог... В верхнем посте ни про какой оверлей речь не шла. Там RVA 1b286 находится в секции релоков, прога так и говорит. Для проверки, на скриншоте есть hex-дата. Можно поискать.
А вот если перейти в файле по физическому адресу 1b286, то попадаем на два последних байта оверлея. Видимо в адресах запутался, так как похоже тут реально "смешались в кучу кони, люди..."

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

hypn0 пишет:
1b286
Имея FO перевести его в FO что то новое

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

Ога, в этой жизни ко всему нужно быть готовым, никогда не знаешь когда придется переводить RAW в RAW

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

VOLKOFF пишет:
Спорно. Это оверлея в замапленом (SEC_IMAGE) образе не существует, а именно при таком маппинге конвертируются адреса. Однако это совсем не значит, что нельзя получить "псевдо RVA" адрес оверлея

Нельзя.

Потому что для этого нужно было бы иметь "псевдо RVA" его начала в таблице объектов PE.
А его там нет.

Jupiter пишет:
Overlay по определению находится за границами виртуальных адресов.

[это больше для VOLKOFF'а]

Сам термин "оверлей" переводится как "перекрытие".
Появился он для MZ файлов DOS, когда была изобретена подгрузка и исполнение кода в оверлейном буфере
для преодоления нехватки оперативной памяти.

Но этим занимался код самого MZ-EXE файла. Системе ничего не было известно о содержимом неучтённого куска данных, дописанных в конец файла MZ-EXE.

И этот код даже не загружался в память при запуске MZ.
То же самое происходит и с PE-EXE.



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

Не пойми о чем спорят, дайте топикстартеру RAR-JPEG уже пусть на кошках потренируется

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

mdscorp
Топикстартер даже на простой конкретный вопрос из его же примера ответить не в состоянии, уходит от ответа.

-----
EnJoy!

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

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

-----
2 оттенка серого

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

f13nd пишет:
А щас хорошую мину при плохой игре строит, че докапываться
Да всё понятно, вот только зачем другим мозги пудрить, когда у него самого каша в голове?
(вопрос риторический)

-----
EnJoy!

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

Немного странно видеть такое агрессивное поведение модератора в исчерпавшем себя топике и преследующем уже какие-то свои цели (кому-то доказать что "топикстартер не прав"? ). Я не понимаю твоего намерения и считаю странным "обязанность" отвечать на неинтересный мне вопрос, ответ на который есть в первом посте и далее.
Можете до посинения тут копья ломать и "топикстартера гнобить", я совсем не против, значит вы просто не поняли о чем на самом деле было это кино

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