Некоторое время назад открыл для себя ручную распаковку исполняемых файлов. В процессе ковыряния столкнулся с тем, что некоторые пакеры заменяют адреса API'шек в IAT на переходники, и в этом случае приходится соответствующим образом редактировать файл, создаваемый тулзой "Import Reconstructor". Восстановление так называемых подсказок для загрузчика показалось мне зело муторным занятием, и после нескольких распаковок я не выдержал и накатал прожку, делающую это автоматически. Вот сцыль, может кому пригодится.

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

ни в коем случае не пытаюсь зарубить на корню сие деяние. но, на кой фик восстанавливать хинты? и по какому принципу - текущая ОС? смысла нет

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

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

Блин, забыл предупредить: не натравливайте прожку на файлы, побывавшие под UPX'ом – он похабит импорт, съедая завершающие нули у имён функций.

ajax:
…на кой фик восстанавливать хинты?

Ну, наверное на тот же самый, на который мелкомягкий (про другие не скажу) линкер их генерит.

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

FalseMaster пишет:
Блин, забыл предупредить: не натравливайте прожку на файлы, побывавшие под UPX'ом – он похабит импорт, съедая завершающие нули у имён функций.

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

Запилил по этим мотивам плагин для HIEW - PE_HINTS.HEM. Ссылка тут: --> Тема Hiew <--



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

dosprog, только сейчас заметил, что ты тут отписался. Воткнул короче проверку хинтов на валидность. Теперь имена DLL'ок, хинты на импортируемые функции из которых забаранены, выделяются в логе тёмно-красным цветом.

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

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



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

>Тупо чёрный экран.

Я бы и рад помочь, но у меня при всём желании не получается сделать так, чтобы прога не завелась. Хотя как-то раз было дело – упала на PE'шке с левыми значениями в заголовках секций.

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

Да это просто багрепорт.

В программе криво сделан вывод на консоль.

Запустить её с выводом на экран удалось только поправив .CMD файл, добавлено принятие аргумента:

@E:\PEFixHints.exe %1
@PAUSE

Тогда перетаскиванием в эксплорере EXE/DLL файла на этот .CMD удаётся получить вывод на экран.
Также можно запускать это всё поправленное хозяйство из FAR'а, тоже работает вроде:

C> CMD /c PEFixHints.CMD 1.EXE
Или просто
C> PEFixHints.CMD 1.EXE

- но после отработки программы FAR тоже теряет размер экрана, и приходится его восстанавливать по <Alt+F9>.

Из VolkovCommander'a (сеанс COMMAND.COM) вывода на экран не удаётся получить по-любому.
Это вздрочь короче, так консольные программы работать не должны.

Должна нормально отрабатывать команда без всяких батников:

PEFixHints.exe SomeFile.EXE

-сейчас она отрабатывает без вывода на экран, хотя файл, который в аргументе (SomeFile.EXE), в результате выходит изменённым.

Так пользоваться этим всем хозяйством нереально.

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



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

dosprog пишет:
результат плохой реализации RTL в паскале
это результат кривой реализациии работы с консолью у ТС, а не паскаль

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

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

dosprog

>Запустить её с выводом на экран удалось только поправив .CMD файл, добавлено принятие аргумента:
>...
>Тогда перетаскиванием в эксплорере EXE/DLL файла на этот .CMD удаётся получить вывод на экран.
Запуск из проводника мышкой:

Батник:
@"C:\Software\Programming\PE-Tools\PEFixHints.exe" ImportRec.exe
@PAUSE

Сеанс DOS в command.com:


>Да это просто багрепорт.
Не по адресу, ибо если NTVDM не может очухаться после Волкова или некая консольная прога (FAR) самопроизвольно меняет размер окна (SetConsoleWindowInfo у меня не вызывается), то в этом никак не может быть виновато стороннее приложение.

>это результат плохой реализации RTL в паскале
Какая к хренам RTL (прямо вот обидел меня)? Ты на размер экзешника посмотри.

dosprog, а ты часом меня не троллишь?

ajax

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

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

ajax пишет:
это результат кривой реализациии работы с консолью у ТС, а не паскаль

Да, так и есть. ) Зря паскаль ругнул.
Ну, выберу время - гляну. По свободе.

--Добавлено--
Вот --> так <-- уже более/менее можно пользоваться.
Хотя там и остался небольшой косяк с выводом имени обрабатываемого файла, но он не мешает.

--Добавлено2--

FalseMaster пишет:
Сеанс DOS в command.com:


Кстати, скриншот с этим сеансом command.com вообще ни о чём не говорит.
Для эксперимента подобное стоит проделать в сравнительно современной системе - и там файл просто не запустится, по причине его "длинного имени".

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

Поэтому утилитки с обычным текстовым "телетайпным" выводом в консоль стараюсь делать без использования функций разрисовки экрана а-ля прямой доступ к видеопамяти в DOS'е.
Только стандартный телетайп. Тогда оно работает нормально, к тому же позволяет записать нагенерённый программой текст в файл, перенаправив в него вывод из программы.
Это удобно.

И так же работают все стандартные утилиты "командной строки".



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

>Да, так и есть. ) Зря паскаль ругнул.
Признаю, налажал. Не учёл, что ранее запущенная программа может изменить размер консольного буфера или полностью его сожрать, выставив курсор на последнюю строку. Пофиксил.


>Вот --> так <-- уже более/менее можно пользоваться.
И как этим пользоваться? Я старался расцвечивал, чтобы сразу было видно, какой модуль был полностью обработан, какой частично, какой пропущен (с хинтами всё в ажуре), с каким вышел затык (не найден, занят etc), а ты взял и разом всё похерил, вместо того чтобы ошибку найти. Да ещё и ожидание с клавы в конце закорячил. Нахрена? А если прога в батнике будет вызвана n*10 раз, не надоест кнопки тыкать?

>…проделать в сравнительно современной системе - и там файл просто не запустится, по причине его "длинного имени".
Возьми и переименуй. Если ты не заметил, это приложение под старый добрый Шindows, а не под новомодный DOS

>…FAR перерисовывает экран…
Ну так это уже вопрос к разработчику FAR'а.

>…позволяет записать нагенерённый программой текст в файл…
А оно надо в данном конкретном случае?

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

FalseMaster пишет:
А если прога в батнике будет вызвана n*10 раз, не надоест кнопки тыкать?

Вот для таких случаев предусматривают ключ командной строки "/w" ("wait").
Тогда без ключа программа работает с задержками, чтобы удобно было тыцкать по ней в эксплорер'e или в FAR'е,
а в BAT-фйле просто указывается этот ключ - и всё работает нормально.
Но это был не тот случай, когда хотелось заморачиваться.
Дело пятнадцати минут - подменил две функции и всё.

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

В данном случае лучше было перед выводом имени каждой DLLи выводить символ признака успешности, например:
' ' - ничего не исправлялось
* - всё исправлено без ошибок
? - частично исправлено, но часть пропущена
! - ошибка, ничего не исправлено или пришлось прервать процесс.

И в подсказке /? ("usage") выводить эту легенду.

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

>Но это был не тот случай, когда хотелось заморачиваться.
Это тот случай, когда все эти заморочки совершенно излишни. Загнал всё в батник, один раз запустил, проскроллил, закрыл и забыл.

>…в некоторых случаях просто получается дисфанкшен.
Оно?

>В данном случае лучше было перед выводом имени каждой DLLи выводить символ…
Ясно, надо было делать так, как удобно персонально тебе.

P.S. Про FAR ты, кстати, нагнал. Я щас качнул для пробы – всё нормально там с окном, ничего он не изменяет и не стирает.

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

FalseMaster пишет:
Оно?

Типа

FalseMaster пишет:
P.S. Про FAR ты, кстати, нагнал. Я щас качнул для пробы – всё нормально там с окном, ничего он не изменяет и не стирает.

В какой системе?



)..Вот прямо делать больше нечего, кроме как нагонять на чужие глючащие программки, ага


FalseMaster пишет:
Ясно, надо было делать так, как удобно персонально тебе.

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

) а эта утиль пускай так и остаётся, я ж не возражаю. Дело вкуса короче



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

FalseMaster пишет:
Ясно, надо было делать так, как удобно персонально тебе.
имхо, если делал для себя - оставь себе и не выеживайся
а если делаешь для людей - радуйся, что хоть кто-то проявил интерес, багрепортит и высказывает пожелания по улучшению.
сама по себе идея из разряда поиграться и забыть, так как хинты в иат в принципе не особо-то и нужны.

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

dosprog

>В какой системе?
32-bit, если ты об этом.


-=AkaBOSS=-

>радуйся, что хоть кто-то проявил интерес
Не вижу причин для радости. Вот если б кто-то другой написал нужную мне софтину, а я на неё случайно наткнулся, тогда да, а так…

>багрепортит и высказывает пожелания по улучшению.
Найденный баг – это хорошо, а вот называть багом заточенность под чьи-то личные предпочтения – совсем нет. Это как если бы склонять автора того же FAR'а к переделыванию его файл-манагера под GUI, потому как, видите ли, тулбара нет.

>сама по себе идея из разряда поиграться и забыть…
Вот и именно. Так стоит ли мудохаться с двумя вариантами лога?

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

FalseMaster пишет: написал нужную мне софтину, а я на неё случайно наткнулся, тогда да, а так…

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

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

FalseMaster

> Некоторое время назад открыл для себя ручную распаковку исполняемых файлов

Теперь вы столкнулись с процессом восстановления данных в памяти, а далее столкнётесь с механизмами виртуализации данных, в таком случае они существуют только в некоторый нужный приложению момент; тогда восстановление данных смысла иметь не будет, это будет уже реконструкция приложения

-----
vx

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

shellstorm

>не вижу в ней ничего нужного от слова совсем.
1. Я имел в виду абстрактную прогу, а не конкретно эту.
2. А я вижу. У меня софт быстрее запускается.

>она пишется несколькими строками в том же питоне.
И выполняется в 20 раз медленней. За то время, пока обработаются к примеру все бинарники AIMP'а, можно наверное будет чаю попить и покурить. Одним словом, питонство

difexacaw
Не думаю, что до этого дойдёт. Я ведь крякерством как таковым не занимаюсь, только если уж совсем припрёт.

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

FalseMaster

> Я ведь крякерством как таковым не занимаюсь

Тогда как обычно достаточно подождать когда приложение сформируется в памяти. И не нужны никакие извраты. А если по какой то причине нужны, то юзаются загрузчики, врапперы и прочее всё. Зачем париться с ресерчем апликухи, если можно дать ей отработать(развернуться) до нужного момента/события. Очевидная проблема в таком случае есть только одна - не коденг.

И почему вы юзаете какие то древние дос тулзы. Есть много хороших инструментов.

-----
vx

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

FalseMaster пишет: И выполняется в 20 раз медленней.

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

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

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

) Ты прожку-то скачай, загляни туда, а потом про убогие рантаймы делфи пиши.
А то не пробовал, но осуждаю, ибо где-то читал.(с)

FalseMaster пишет:
32-bit, если ты об этом.

) У меня на скриньшоте тоже тридцатидвухбитная. Прикинь?





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

dosprog

> Ты прожку-то скачай, загляни туда, а потом про убогие рантаймы делфи пиши.

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

-----
vx

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

difexacaw пишет:
Может архив малваря качнуть и запустить через батник, а потом заглянуть, если конечно получится..

)) Ну, не запускай, чувак. Я ж написал - загляни в неё
И можешь удалить не медля

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

shellstorm

>это древний как говно мамонта стереотип
Ну конечно, ведь байт-код куда быстрее нативного. Жаль только дядьки из Intel'а об этом не знают. Открой глаза олухам, вот тогда заживём – пока ось загрузится, глядишь уж и пеку выключать пора, ха-ха.

>делфи будет аутсайдером из за убогого рантайма и отсутствия вменяемой оптимизации
Не дождёшься, ибо рантайм в делфях настолько ох**нен, что никакая оптимизация не требуется.


dosprog

>У меня на скриньшоте тоже тридцатидвухбитная.
Может версия не очень свежая? Судя по инфе на сайте прога очень активно развивается.

difexacaw

>достаточно подождать когда приложение сформируется в памяти.
Дык я так и делаю тащемта.

>И почему вы юзаете какие то древние дос тулзы.
С чего ты взял? Для вскрытия/патчинга я юзаю OllyDbg, ReloX, Import Reconstructor, PE Tools, Haker's Disassembler – усё под вендовоз.

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

FalseMaster пишет:
ибо рантайм в делфях настолько ох**нен, что никакая оптимизация не требуется.

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



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

FalseMaster пишет: Ну конечно, ведь байт-код куда быстрее нативного.

Внезапно да, на некоторых задачах может быть существенно быстрее.

FalseMaster пишет: рантайм в делфях настолько ох**нен, что никакая оптимизация не требуется

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

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

FalseMaster

> cdecl

Вы вкурсе что это сишный деклар, а сишка сама его отладить не может, если в нём бага, так как нет цепочки фреймов и она может быть выделена только рандомом ?
- хороший, годный пример для начала

-----
vx

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

)) Тебе вон выложили пример функции strcmp(). Какие такие jit компиляторы

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