Выпущен хьюшный плагин на эту же тему.
Ну почти на эту, но всё равно удобный:
http://old-dos.ru/dl.php?id=25428

Калькулятор просто шикарен! Единственный момент: было бы очень удобно иметь возможность инкремента и декремента значений адреса, например, по колёсику мыши и/или по клавишам Up/Down или Left/Right, с автоматическим обновлением. А то получается лишь "один адрес за один раз" :(

Архив поврежден и не открывается.

Будет ли поддержка файлов x64?

Вот, вспомнилось, кстати, - типичный случай с правками "хвостов" -
exelab.ru/f/index.php?action=vthread&forum=3&topic=13687&p age=11#10
(См. в том посте "--Добавлено--")

- Сейчас то последний пост в теме. Дата 9 ноября 2015 08:05:10

--Добавлено--
Кстати, снова вопросы к загрузчику PE в системе. Нынешние ОС, точно включая XP, размещают в памяти запускаемой программы все страницы секции, физически находящиеся в PE-файле, вместе с заполнителями "хвостов". Если в какой-то из последующих версий ОС адгоритм работі загрузчика станет подобен алгоритму упаковщика UPX, то файлы с правками на месте нулей-заполнителей (выравнивающих секцию по страниуе) окажутся неработоспособны.
Впрочем, пока это только предположение.

Ну, нет так нет.

Траблы с правками в "хвостах" могут возникать только после запаковки и последующей распаковки файла упаковщиками, например, UPX-ом или PECOmpact'ом.

При запаковке упаковщики включают в упакованный код секции только те данные, которые попали в диапазон (FileOffset)...(FileOffset + VirtualSize).
В принципе, это логично. Но таким образом данные из "хвоста", где обычно нули-заполнители для выравнивания по странице, - эти данные не попадают в запаковываемый код. И, естественно, их не оказівается при распаковке секции на их прежнем месте.
Вот если бы они (упаковщики) забирали все данные из диапазона (FileOffset)...(FileOffset + PHISICALlSize), тогда бы не возникло и самой постановки вопроса с этими "хвостами" секций.

Натыкался многократно на эту неприятность.
Раньше я после всяких врезок для проверки тут же паковал-распаковывал файл UPX'ом - если всё работало, тогда моя врезка в "хвост" не попала.
Сейчас я использую новую утиль CMP32.EXE, с помощью которой всё равно протоколирую изменения, - и она мне сразу сообщает о таких стрёмных патчах, если они встречаются (это из этой утилиты была взята та процедурка для ребилда FLC 1.4.0.4).

Ну, в общем такие вот мысли возникли по этому поводу.

..хотя, конечно, врезка по всем параметрам значительно надёжней ребилда.

)) спс.
Труд на удивоение небольшой - на всё-про-всё ушло пару часов.
И то - пытался вначале сделать врезку, но потом решил не заморачиваться и применил тотальный подход.
Прога аккуратно написана - с такими обычно нет проблем.

Хех.
Не удержался, сорри, - малость влез в эту тулзу - очень уж удобная оказалась.
Всё по этому самому поводу проверки "хвостов" секций.
В общем, с минимальным вмешательством в функционал, вышлел вот такой вариант - Картинка:
rghost.ru/7lBjdFwHN

Вот тут архив, в котором можно глянуть, что добавлялось:
rghost.ru/65LCvRQkP
Пассворд тот же, что и раньше.
Дай знать, плз, как утянешь - я прибью раздачу.

Цитата

бесполезно != недопустимо

Ну, в принципе, согласен.

Цитата

Ну раз все починилось, то программу можно считать завершенной.

)Не совсем.
Было бы вот неплохо ввести ещё такую фичу, как предупреждение, что указанный VirtualAddress попадает в необъявленный хвост секции.
Сейчас вспомнил про эту утиль "File Location Calculator", проверил - да, здесь этот неприятный момент тоже никак не обрабатывается.
Обрабатывал такой вот скользкий случай в собственной утилитке CMP32.EXE, после того, как уже натыкался на эту же неприятность при тестировании ArmadilloEnvVarInjector.

Сейчас утиль CMP32.EXE после записи (например!) в FLC v.1.4 по смещению 3380h при сравнении ругнётся, что там патчить что-либо бесполезно.

Вот, сделал картинку, может, пригодится:  rghost.ru/7wWX8nPdn

Цитата

Исправлена ошибка с горячими клавишами. Архив обновлен до версии 1.4.0.4

Хех, нижеописанные глюки с окном FLC на Win 8.1 x64 больше не наблюдаются (в пред. обновлении (с фиксом для Win 10) они были). Спасибо!

Hello,

Sorry for the English comment, but I don't know Russian. Would it be possible for you to publish the algorithm you use for the calculations? I think this will benefit a lot of people in the security industry will benefit from correct calculations.

If you don't want to publish the code, could you maybe outline the mistakes other algorithms (possibly including the ImageRvaToVa one) made?

Thanks in advance

Win 10 x86 D) Мсье знает толк в извращениях ;)

ManHunter, а с какими опциями паковать? а то на 10 действительно никак (

На Win 8.1 x64 тоже немного странно себя ведёт, если запускать из Total Commander (в x32 и в x64, тыцканьем по flc.exe, где-то минуту крутится курсор мыши: http://fs1.directupload.net/im...f4wyg6h.png, а если из Проводника, то всё норм., также нет проблем, если открыть что-нибудь в flc через кнопку Тотала) или с ярлыка на раб. столе (устанавливается фокус на заголовке окна flc). С версией 1.3 такого не наблюдается.

На планшете с Windows 10 не запустилась :(

Update,thanks

Как и обещал, выкладываю файл clipboard1.exe.  http://rghost.ru/7nKdXKxxq
1. SizeOfRawData первой секции = 0. Твоя утилита flc.exe при VA = 401003h
показывает File Offset = 403h, имя секции .data и байты 10 40 00 00 00 00 00 6A... Но т.к. размер секции .data  на диске = 0, эти байты принадлежат секции .code и мое имхо некорректно в этом случае говорить об имени секции и Offset'е. Байты 10 40 00 00 00 00 00 6A... расположены по адресу VA = 402003h (хотя их Offset = 403h)
2. При VA = 402150h flc.exe сообщает нам Offset < Out of file > и имя секции ERROR, хотя Offset в данном случае будет 550h имя секции .code и байты по этому сещению 50 50 50 0A 00 00 (это я их нарисовал в файле для наглядности).
RVA тоже имеется за счет выравнивания секции, SectionAlignment = 1000h.

Если буфер обмена пустой или там содержатся данные отличные от CF_TEXT, при Ctrl+V в поле VA прога крешится.
Думается нужно сделать проверочку при событии WM_PASTE
If IsClipboardFormatAvailable(CF_TEXT)...
Еще, имхо, утилита не всегда корректно считает, сейчас нет под рукой файла где ошибка, через день выложу

Ну может из за того что восьмерка система у меня.
Хотя все работает и 2005 года и 2010.
Только этот не хочет.

Но проблему решил.
Написал плуг который запускает утилиту.
Спасибо.
Нужная вещь.

У меня прблем нет ни с однип плагом для пейда.
Только этот не пашет, сама утилита работает.
Архитектура х64.
http://i008.radikal.ru/1501/0c...3e726b71.png
http://s50.radikal.ru/i127/150...00f2fdd3.png

Мне почемуто кажется что это из за ультрасовместимости плуга с анализаторами.
Старая только под дие и пейд была.

Plugin для Peid не пашет.
Выдает ошибку при запуске Peid-а 0хс0000005.
Версия 1.0 без проблем.

good

Пережал из zip'а в 7z, 7 кило веса сэкономил. ;) Даешь весовую культуру! ;))

Цитата

Добавлена возможность поиска перекрестных ссылок на адреса, которых физически нет в файле.

Спасибо, полезно. Версию 1.3 сразу же вытянул на винт.

thanks

Спасибо за инструмент! ManHunter, я не было такой мысли написать свой инструмент для восстановления импорта, все существующее на данный момент тоже не всегда корректно справляются с этой задачей?

ManHunter, вот тепеь всё ясно и понятно.

ManHunter, так чем DIE от Hors'а то не угодил? Чем вызвана такая политика?

Хехе, класс ! для моего основного детектора Die 0.65 в самый раз )

Detect It Easy 0.88 не видит плагина.

Большое спасибо! Очень пригодилась и помогла. А вы можете сделать поддержку 64-бит приложений?

А как же память как аргумент перехода? 4Гб очень мало.

Спасибо, забираю плаг для любимого анализатора Die 0.65 ;)

it's well.

Переходите кодить на 64 бит... 21 век всё таки... Там веселее...

very good!

Приходилось натыкаться на ошибки расчётов PETools и CFF Explorer.
Спасибо! Отличная утилита, супер что есть плаг!

Спасибо, за тулзу !!!

Thanks