==============================
CRACKER. Реализация для WIN32 GUI
==============================

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

Самая старая и заслуженная из этого класса программ датируется ещё 1991 годом, от Corner Crackers (CRACKER.EXE v.1.1).
Позже, в 90-х, появилось ещё несколько аналогичных программ, из которых самая, пожалуй, удачная реализация выполнена Professor'ом Nimnull'ом в 1996 году и назывется она Cracker Advanced (CRA.EXE v.0.2.16 и CRA386.EXE v.0.2.14 с PMODE/W) (CRA386 v.2.16 под WinXP глючит).

Вот полный их список, все для DOS (по ссылкам архивы с этими программами):
------------------------------------------------------------------------------------------------------
1) CRACKER.EXE v.1.1 (by Corner Crackers, 1991)
2) Program Cracker (by Dr.Stein's labs, 1993)
3) CRA v.0.2.16, CRA386.EXE v.0.2.14 (by Nimnull, 1996)
4) CRK (by Bolshun/Ivanov, 1996)
5) CRACK-STUDIO (by Turansoft, 1997)
-------------------------------------------------------------------------------------

Так что тема в 90-х была достаточно разработанная.

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

Недостатки этих реализаций прошлого века вытекают из их DOS-овости. (Здесь CRA386, пожалуй, выглядит более достойно, но от остальных он принципиально ушёл недалеко).

Недостатки такие:
- ограничения оперативной памяти (кроме CRA386);
- невозможность работы с длинными именами файлов (LFN) в WIN32;
- невозможность работы в 64-битных ОС.

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


Ну, и к собственно сабжу.

======================================
--> Вот версия 0.002b CRACKER'а для WIN32. <-- (6 May 2018 г.) - Size: ~25 Kb, UPX'ed. MSVC.
======================================



Интерфейс воспроизводит наиболее удачные образцы таких программ прошлого века - минимум лишнего.
(В листбоксе виден фрагмент каталога файлов популярной библиотеки кряков от Corner Crackers, 1991).

Крякер занимается только разбором текста кряков, который составлен руками в желаемом виде,
но с соблюдением некоторых "соглашений" вроде синтаксиса комментариев.
Сами кряки (файлы .CRK) составляются ручками, можно с использованием какого-либо другого инструмента.




==============================================
Краткое описание возможностей этой программы:
==============================================

- Работает с форматами CRK,CRA,XCK (дань традициям).

- Поддерживаются комментарии в стиле Cracker Advanced ('#' в начале строки),
однако его опции #SIZE, #CHCKSUM, #RUN и т.д. игнорируются за явной ненадобностью.

- Поддерживается корректное использование кириллицы в кодировках DOS/WIN (можно выбрать),
(Кстати, все опции программы видны, если отволочь правую границу диалогового окна вправо).

Вот они, опции программы:




- LFN для кряков и имён исправляемых файлов (как и положено в WIN32).

- Смещения для патчения в файле CRK могут задаваться либо традиционно, в виде абсолютных величин, либо в виде VirtualAddress (VA), как для WIN32 PE-файлов. Тогда перед адресом нужно указывать точку, например, вот так:
.00401005 72 EB
(Это вообще возможность, отсутствующая в программах-аналогах для DOS'а. Расширение синтаксиса CRK).

В версии 0.002a добавилась возможность для WIN32-PE файлов адреса указывать также и в формате Relative Virtual Address (RVA) ,
тогда перед адресом нужно задать две точки, как в выводе утилиты CMP32.EXE v.0.002a, например, так:
..0001005 72 EB


- и кстати - тут сразу возникает предложение к crc1 по добавлению в его CmpDisasm возможностей, касающихся сохранения различий в сравниваемых файлах в формате CRK, но с виртуальными адресами смещений патчения.
(--Добавлено--: Наподобие того, как это делает представленная в следующем посте утилита CMP32.EXE с опцией "/v" или "/a").

- Имеются расширения синтаксиса CRK - "CHECK" и "FORCE". Например:

- Имеется опция "Patch All", когда все кряки, описанные в выбранном CRK-файле, применяются одновременно.

- Вызов редакторов DOS/WIN для редактирования текста кряков, не выходя из программы (пути к редакторам настраиваются).
(Для DOS-овского редактора можно применять LFN или SFN, на выбор.)
По умолчанию это "edit"(+SFN) и "notepad".

- Корректная работа как в WinXP, так и в Win9x. (Без этого никак. Win9x никуда не делась).

- Два размера диалогового окна - компактный (size 1) для режима 640x480 и более просторный (size 2) для высокого разрешения экрана.

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

Справку по "горячим" клавишам можно подглядеть по нажатии кнопки F1:



- Тут можно ещё что-нибудь написать, довольно обильно, - но лучше привести примеры текста CRK, с которым может работать эта программа.
Например, так:

- Ну и так далее.
По мере разбора текста, если встречаются ошибки, то выдаётся номер соответствующей строки. Где вышел затык.

В крякере при чтении этого всего увидим такую картинку (кстати, выбран размер окна "Size 2"):






Сколько кряков может присутствовать в одном файле? - не знаю. И никто не знает.
Но много, и разного размера. Память под них выделяется динамически. Надо пробовать.
В случае чего программа скажет "memory allocation error.." и позорно завершится.

Однако, со всеми старыми, существующими ранее, файлами *.CRK, *.CRA, *.XCK программа должна работать без проблем.

) Ругань можно оставлять здесь в теме, лишь бы по делу - багрепорты приветствуются.


*** См.также: ***

Ссылка на пост #02 этой темы, об утилите --> CMP32 <-- (для использования её совместно с CRACKER'ом).

Ссылка на пост #27 этой темы, о HEM-модуле --> CRACK.HEM <-- (для использования его совместно с CRACKER'ом).



| Сообщение посчитали полезным: elch, ProstoAndreyX, wzhick, zNob, vnekrilov, GMAP, ==DJ==[ZLO]

dosprog пишет:
Но там можно ускорить принятие нужного решения,
а тут придётся только ждать.

Тогда я не понимаю, что для тебя будет аналогом MessageBox.
Ведь изначально я отвечал на твой комментарий:

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

-----
EnJoy!

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

Чтоб не ждать.
А явно выбрать из двух (трёх и т.д.) вариантов.

Как оно сделано сейчас, используя ччч_GetStr() [для двух вариантов Enter & Esc].
Ну, вот как в обычной MessageBox() в Wind'е.

В идеале - возвращаемое значение должно быть кодом нажатой клавиши.
Но тогда Hiew-шное меню теряет смысл - всё можно делать с помощью такого "диалога".

Кстати, вот утилитка полезная на эту же тему: --> MBox <--
Утиль обеспечивает ветвления в BAT-файлах
путём вызова стандартного MessageBox'а Wind'ы.

.. Ну и до кучи - подобный же функционал для BAT-файлов,
но уже просто с помощью анализа нажатий на кнопки клавиатуры. --> vk_check <--
Тут функционал значительно шире, чем в предыдущей утилите Mbox,
именно за счёт использования кодов нажатия клавиш, а не кнопок диалога.

Если бы эти две возможности [кнопки диалога и код клавиш] можно было совместить, было бы очень удобно.



В общем, в HEM'ах для каких-то более сложных ветвлений, видимо, нужно использовать меню, с его F-кнопками.
[вызов из HIEW/HEM стандартного виндового графического MessageBox'а c негодованием отвергаю]



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

dosprog пишет:
В общем, в HEM'ах для каких-то более сложных ветвлений, видимо, нужно использовать меню, с его F-кнопками.

Ну да, ведь на такой F-навигации весь Hiew построен.

-----
EnJoy!

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

Обнаружилась неувязка в выводе CRACK.HEM-плагина при использовании потом CRACKER'а

Дело в том, что для PE файлов HIEW новых версий назначает "локальную" адресацию для MZ+PE заголовков.
Таким образом, после правки заголовка PE-файла и запуска плагина будет получен такой CRK-файл:


Строго говоря, для PE-файла это не является ошибкой.

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

А вот утилита cmp32, даже с ключом "/a", выдаст подходящий для CRACKER'а скрипт:



Нужно будет добавить в плагин CRACK.HEM разбор PE-заголовка и подавление "локальной" адресации для смещений в самом PE-заголовке.
.. Или останется всё, как есть сейчас, пока неясно. Это на будущее.

.. вот так простая, в общем-то, тулза начинает обрастать всякими наворотами ..



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

dosprog
По-моему, ты напутал с адресацией, ведь Hiew сам по себе ничего не назначает.
Всё зависит от типа адресации, которая переключается по Alt+F1.

-----
EnJoy!

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

Да нет, всё правильно.

Давно обратил на это внимание, что HIEW32 с версий 7.x [проверил только что на HIEW32 v.6.86 и v.7.01 - такое различие, действительно, имеется] - HIEW32 начал включать "локалную" адресацию для всего MZ-PE, считая, что MZ расположен "локально" по адресу .400000 (или что там указано в PE.ModuleBase).
Формально-то оно, может, и правильно, но в результате такая вот коллизия, да.

В Hiew 6.x для DOS/WIN32 этого ещё не было - в заголовках шла глобальная адресация вне зависимости от режима (Alt+F1).
[Но там ещё и никаких HEM'ов не было. Они пошли начиная с версий 7.x].

Да оно и не мешало, зацепился за это только сейчас, в контексте использования CRACKER'а, и как только появился CRACK.HEM.

Логику определения "Local/Global" в CRACKER'е менять не буду, там в нём кое-что ещё на неё завязано.
Так что пока останется всё как есть, просто нужно иметь это в виду.
И всё равно полученный с помощью плагина СRK-файл потом редактировать ручками, можно и поправить, при необходимости, прямо там.



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

dosprog
Мы вроде говорили про метки, которые Names.

Проведи следующий эксперимент:
1. В любом месте файла (будь то заголовок, или код внутри секции), переключись (цикличное переключение по Alt+F1) сначала в режим файловых смещений.
2. Установи метку (Shift+F12), например "Local".
3. Переключись на режим виртуальных адресов (всё та же комбинация Alt+F1).
4. Переместись на другой участок, но рядом с первым.
5. Установи метку (Shift+F12), например "Global".
А теперь зайди в список имён (Names, по клавише F12) и ты увидишь, что заданные тобой метки находятся в разных списках - Local и Global (переключение между ними по F3/F4).

-----
EnJoy!

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

Да, именно это и проделал в самом начале знакомства с этой фичей HIEW.
Потом проделал другой эксперимент, когда немного стал понимать, что там происходит:

Одному и тому же адресу назначил "Local" метку и комментарий.

В результате работы CRACK.HEM получилось вот такое:


Всё вроде чинно и нормально.

Дальше переключился в режим "Global" и назначил этому же адресу глобальную метку
- она записалась ПОВЕРХ и ВМЕСТО заданной ранее "локальной"
А перезадать таким же образом глобальный комментарий не получилось вообще - "Error 422".

Но главное, что после этого вывод в CRACK.HEM приобрёл вид:


То есть - глобальная метка вообще не попала в вывод плагина.

Вот это, собственно, мне тогда и не понравилось.
То есть, не только что один адрес может иметь только один комментарий и одно имя (глобально ИЛИ локально), но и что глобальные имена для адресов в области с локальной адресацией вообще никак не вытащить с помощью плагина. Они ему просто не видны.
<<исправлено>>

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

Так. Нашёлся бажек в плагине. Видны будут все имена. Перезаливаю плагин.


--Конец добавленного--


Это никуда не годится, однозначно.
И плагин тут ни при чём. Исключительно фичи HIEW32.
<<Добавлено: Исправлен баг в плагине. Всё в порядке >>


Не знаю, как там в новых версиях HEW32 - просто у меня допотопная версия.
Может, уже и поправлено.



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

Объясни, зачем давать две разные метки одному и тому же коду? Пока не догнал, зачем это нужно.
У Hiew есть API по конверту Local <> Global, если надо из одного в другое преобразовать. Полагаю, что он держит внутри это всё в одной таблице.

-----
EnJoy!

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

Jupiter пишет:
Объясни, зачем давать две разные метки одному и тому же коду? Пока не догнал, зачем это нужно.

Ну, не нужно, так не нужно, я ж не спорю.
Логически такое возможно - например, если в результате корректировки заголовка PE такие метки одного и того же места "расползутся" по разным адресам.

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


Алгоритм в плагине таков:
- поток байтов, естественно используется по факту "глобальная" адресация. (curr_offset).
Для каждого следующего байта, помимо сравнения с аналогичным в оригинальном файле:
- преобразование Global->Local ( curr_offset -> curr_offset_local ).
- Проверки:
- как только pName не NULL - тут же вывод содержимого буфера в отчёт, снабдив соответствующим тегом (например, "L_NAME=").


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

В общем, пока более/менее плагин работает, с небольшими странностями, дальше будет видно.
Может, он вообще не понадобится, этот плаг. И такое тоже возможно.




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

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

А я тебе пытаюсь объяснить неэффективность такого подхода с точки зрения архитектуры самого алгоритма.
Но я продолжу пытаться тебя переубедить ))

Итак, что должно попасть в итоговый файл .crk?
(Пункты ТЗ)

1. Данные об изменённых байтах. Обязательно.
2. Метки к изменённым байтам, если есть. Опционально.
3. Метки к любым другим данным (не изменённым), если они попадают в определённый диапазон. Опционально.

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

Как алгоритмически корректнее выстроить логику программы?

Не пытаться всё сделать за один проход.

1. Сначала быстро просканировал оба файла блоками по 64КБ, например, нашёл diff'ы (пусть даже пока побайтно, без дельты). Сформировал массив изменённых данных с блоком адресов. Это быстро и компактно. Памяти много не жрёт, особенно если размер блока небольшой. В тех случаях, когда оказываются данные на стыке блоков, можно раздвинуть границы кадра.
2. Получаешь от Hiew всю необходимую информацию о метках, комментариях и т.п., собираешь массив данных.
3. Вот только теперь за один проход дампишь в файл .crk все найденные данные. При этом если у тебя будет активна опция сохранения вообще всех меток (пункты 2 и 3 ТЗ), то даже проверять ничего не потребуется - просто выводишь их как есть в файл.
Если же необходимо фильтровать метки для вывода в файл только тех, которые в непосредственной близости от изменённых данных, то для этого используешь функцию, которая на вход принимает адрес, и если находит его среди меток, то возвращает метку и ближайший адрес, а саму метку удаляет из массива. Таким образом при проходе следующего блока она уже не будет мешаться при поиске.
4. Переходишь к следующему блоку.

Разумеется, тут много нюансов и возможностей оптимизации, но общую мысль ты, надеюсь, уловил.

-----
EnJoy!

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

Jupiter пишет:
Разумеется, тут много нюансов и возможностей оптимизации, но общую мысль ты, надеюсь, уловил.

Уловил, да.
Об этом и писал выше:

dosprog пишет:
Обработка потоковая. Иначе просто море сложностей.
Кстати, благодаря этому и кряки могут иметь в результате совершенно безумные размеры, и всё будет работать нормально].
Поэтому, по-любому, для каждого из байтов и приходится выполнять поиск в базе имён. [но не наоборот].
Хотел сказать, что непринципиально [не так уж и ~], кто и по какой базе выполняет такой поиск
- HIEW по своей или плагин по своей [полученной единоразово от HIEW].

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


Ну, посмотрим.

А может, если сама идея с таким плагином окажется юсефул, кто-то и возьмётся реализовать навороченный алгоритм.
Меня не очень вдохновляют такие усложнения.

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

Надо будет глянуть, по свободе.



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

dosprog пишет:
для каждого байта
Нет, не для каждого. Только для изменённых.

-----
EnJoy!

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

Jupiter пишет:
Нет, не для каждого. Только для изменённых.

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

Кстати, и баг отыскал, из-за которого глобальное имя не попадало в отчёт.
(перезалью версию в --> посте #27 <--, для порядку).

Спасибо за дельные замечания.

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

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

Jupiter пишет:
1. Сначала быстро просканировал оба файла блоками по 64КБ, например, нашёл diff'ы (пусть даже пока побайтно, без дельты). Сформировал массив изменённых данных с блоком адресов. Это быстро и компактно. Памяти много не жрёт, особенно если размер блока небольшой. В тех случаях, когда оказываются данные на стыке блоков, можно раздвинуть границы кадра.

Сканирую блоками по 200h байтов. "На стыках" проблем быть не может, поскольку размер данных 1 байт.
А вот памяти база различий может сожрать немеряно, фактически, в пару раз больше самого размера файла,
- Например, если в результате какой-то ошибки пытаются сравнивать файл с ним же самим, сдвинутым на 1 влево/вправо. Тогда вообще программа может завершиться падением или сообщением о нехватке памяти.
Как сделано сейчас - просто надуется файл отчёта.
Впрочем, это всё надо взвесить, да.

Jupiter пишет:
Ты пытаешься выполнить сразу все три пункта сразу. На мегабайтных объёмах это крайне неэффективно, поскольку ты гоняешь запросы для каждого (жесть!) байта.

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

Будет что сделать в версии 0.002a.



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

dosprog пишет:
база различий может сожрать немеряно
Не может. Я сразу же в качестве примера привёл размер кадра 64 КБ.
Даже если файлы - это белый шум и всегда различаются на 100%, то в таком случае потребление памяти будет только 64 КБ * размер адреса (для 32 бит это 32 бита/4 байта/DWORD), итого 256 КБ в худшем случае, пусть даже 512 КБ..
Так или иначе, объём потребляемой памяти измеряется в килобайтах, а никак не "немеряно".

-----
EnJoy!

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

Jupiter пишет:
Так или иначе, объём потребляемой памяти измеряется в килобайтах, а никак не "немеряно".

Ну, базу-то различий придётся накапливать всё равно в памяти.
Потому и написал, что если сравнивать два абсолютно различных файла, например размером 1 Гб,
то на базу различий потребуется 1024^3 * (sizeof(__int64)+2) = 10'737'418'240, то есть 10 Гб.

Связываться с вируальными штучками по "отображению файлов в память" не хочется,
обычно стараюсь ориентироваться на доступную оперативную память 64Мб максимум.

.. Хотя при сравнении таких файлов по 1Гб "с тупым поиском имён" времени уйдёт столько, что можно сделать перерыв и позаниматься чем-то другим. Посмотреть какой-нибудь фильм или сходить по делам ..
Да оно и без "тупого поиска имён" будет работать довольно вяло.



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

dosprog пишет:
Ну, базу-то различий придётся накапливать всё равно в памяти.
Нет, не придётся.
Обработал блок, если есть различия, то сдампил данные в .crk файл (закрыл файл, открыл заново), перешёл к следующему блоку.
Буфер всё тот же. Сравниваемые файлы всё те же. Только смещения меняются. Данные пишутся в конец дампа файла .crk.
Перечитай ещё раз то, что я написал ранее в комментарии, где описал алгоритм.
У меня ощущение, что ты так и не понял, зачем нужно чтение по блокам.

-----
EnJoy!

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

Так и надо сделать.

Тогда и "двух проходов" не потребуется.
Вернее, их будет по два на каждую порцию.

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

Должно работать нормально, имхо..



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

dosprog пишет:
его можно не закрывать, зачем?
Зависит от твоей реализации записи в файл. В общем случае достаточно FlushFileBuffers.

-----
EnJoy!

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

Мда. Такие наблюдения по работе плагина CRACK.HEM:

1)
При "тупом алгоритме поиска имён" файлы размером 140Мб сравниваются примерно 1 минуту. (2.4 GHz CPU)
[при том, что файлы свежие, поэтому закэшированы].
Если отказаться от поиска имён (CRK без меток и комментариев), то сравнение этих же файлов длится 10 секунд
[это если файлы в кэше. При чтении "с нуля" раза в три дольше].
Это нереально долго.
Эти же файлы сравниваются утилитой cmp32.exe в течение буквально долей секунды (против 10 секунд работы плагина).

Придётся констатировать, что для гигантских файлов идея с плагином-сравнивальщиком оказалась пагубной.
Пагубной - Если он использует для работы с адресами встроенные API-функции HIEW32.
Таким образом, пожалуй, целесообразней всего не полагаться на API HIEW,
а получить из него список имён и дальше работать совершенно автономно.
Это сильно, на порядок, усложняет задачу.

2)
Если вывести "Прогресс" с помощью отображения ччч_WaitMessageOpen(progress_string) на каждой
порции сравнения по 200h байтов, то работа плагина тормозится настолько, что можно считать его повисшим.
Хотя по этому "Прогрессу" будет видно, что он не висит, а всёже работает.
(Пришлось прервать сравнение кнопкой ESC).
Таким образом, вывод - ччч_WaitMessageOpen(progress_string) - крайне медленная функция и использовать её нужно пореже.

3)
Но зато теперь более/менее стало ясно, в каком направлении развивать эту идею с плагином сравнения.
Если не пропадёт желание.



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

dosprog
Я подразумеваю, что всё, что нужно от Hiew - это получение имён файлов и меток.
Вся остальная работа выполняется своими силами.

-----
EnJoy!

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

Jupiter пишет:
Я подразумеваю, что всё, что нужно от Hiew - это получение имён файлов и меток.
Вся остальная работа выполняется своими силами.

Ну, для меня это стало очевидно только после того, как повозился с этим компаратором.
Просто никогда не пользовался в HIEW комментированием и назначением меток,
и никогда не возился с HEM'ами.
Так что для меня эта тема абсолютно новая, может, и полезно было.
Впрочем, где-то так и предполагал, в смысле эффективности, что оно и будет.

У меня даже мелькнула идейка сделать в CRACK.HEM просто вывод "списка имён" в заголовке CRK (result.CRK),
а дальше вызвать из него SHELL "cmp32 /a" >> result.CRK - оно бы работало нормально, но такие половинчатые решения мне не нравятся.

.. хотя бы потому, что и cmp32 и CRACKER умеют работать только с x32 PE, а есть ещё и x64 PE, и ELF и что там ещё HIEW поддерживает ..
Комплексного и целостного решения у меня не выйдет, должен признать.

--Добавлено--
Конкретно вот эта задача, имхо, требует даже реализации на asm'е,
в виде инлайна в Си или раздельной компиляции.
А может, проще даже и целиком на asm'е.
Имхо.

.. Глядя, как вяло работает в самом HIEW тот же поиск байтов ..


Jupiter пишет:
ЛС открыты и доступны

Ок. Написал ЛС.

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

dosprog пишет:
но у тебя же личка закрыта
ЛС открыты и доступны

-----
EnJoy!

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

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

В HEM-API отсутствует возможность для получения собственного "Списка Имён".
Найти в базе имён HIEW заданное имя - пожалуйста.
Но проба наугад с поиском имени "*" ни к чему не привела.

Функции типа ччч_NameFindFirs & ччч_NameFindNext отсутствуют.

То есть HEM-API позволяет только запросить общее количество имён
и получить имена только для конкретного адреса лок/глоб.
Для заранее известного имени также можно получить его адрес.
И это всё.

.. Отсутствие функций ччч_NameFindFirs & ччч_NameFindNext выглядит как явная логическая дыра. ...

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

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


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

Малость соптимизировал уже существующую версию CRACK.HEM

Перезалил - --> ссылка в посте #27 стр.2 <--.

(Увеличен буфер файла и добавлена подстановка умолчательного имени файла отчёта.
Работает быстрее, но при выборе опции "Искать Имена" может работать и почти так же вяло, как и раньше.
Однако этот процесс немного оптимизирован, как написано выше.
Впрочем, если в HIEW никакие имена не объявлялись, тогда плагин работает сравнительно шустро
и никакие дополнительные запросы касательно проверок имён не выводятся).

Файл размером ~50Мб c объявленными именами в его младших адресах сравнивается в течение ~1 секунды
(..Хотя это всё равно сильно зависит от состояния кэшированности файла..).
Этим уже более/менее можно пользоваться.



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

Раз уж пошёл такой цырк с HEM'ами, - пришлось запилить, для тренировки, ещё пару-тройку полезных плагинов.
Ссылка - в теме про --> Hiew <--

PE_RWE.HEM - плагин, устанавливающий атрибуты всех секций PE-файла в [r/w/e].
Там же ссылка на BLOCK.HEM (операции XOR,ADD,SUB блока со строкой или файлом)
Там же ссылка на BL_MD5.HEM (подсчёт MD5 суммы выделенного блока)
Там же ссылка на PE_TAILS.HEM - убрать "хвосты" всех секций PE. Устанавлиывает VirtSize>=PhisSize для всех секций.
Там же ссылка на PE_HINTS.HEM - настройка хинтов импорта PE-файла. (--> Original idea by FalseMaster <--)
Там же ссылка на KBD_CYR.HEM - Русификация ввода в HIEW32, шесть раскладок клавиатуры.








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

Как оно сейчас:

Чтоб можно было и так:


Но



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

Minor fix/add to CRACKER.EXE:

То, о чём было в предыдущем посте.
Добавлена корректная обработка случая, когда в описании патча следом за двоеточием адреса сразу без пробела следует оригинальный hex-байт для патчения. Такое отсутствие пробела случается, если файл составляется вручную. Раньше выдавалось невнятное сообщение об ошибке в строке.

Теперь в кряке не обязательно наличие пробела после двоеточия адреса.
Можно и так:
и так:

Перезалит архив в стартпосте: CRACKER v.0.002a (30 Nov 2017).

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

Слыхал мнение, что в CRACKER неплохо бы ввести возможность поиска с заменой.
Но, имхо, это лишнее.
Во-первых, такая процедура будет довольно [сравнительно] длительной, особенно для больших файлов,
а во-вторых она необратимая, то есть, если пропатчить файл с поиском и заменой, то, чаще всего, обратная операция приведёт к полной порче файла, и концы потом не найдёшь.
В функционале CRACKER'а и так уже есть необратимая функция PATCH_FORCE, когда по определённому адресу прописываются нужные байты вне зависимости от текущего их содержимого.
Не хотелось бы добавлять в функционал сомнительные операции.
В общем, для поиска с заменой лучше использовать HIEW.

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

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

Решается элементарно с помощью fuzzy hashing и созданием лога отката, сигнатура замены old:new и hash блоков в которые происходила замена, работает быстро и лагов не будет даже бинарях за сотню мегабайт.

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

dosprog пишет:
сомнительные операции.
А в чем сомнительность? Search and Replace практически во всех патчерах есть и активно используется против всяких "шаблонных" защит

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

TryAga1n пишет:
А в чем сомнительность?

Необратимость, это раз.
А во-вторых, классический формат кряк-файла не позволяет такое делать,
CRK это довольно примитивная штука на самом деле.
Соответственно и CRACKER тоже, - прост, как велосипед.

.. вот что действительно было бы нужно -
так это возможность дописать n-ное количество байтов к файлу,
чтобы потом в тех байтах с помощью CRK прописывать всякие чудеса.
Это да. И такое, кстати, вполне даже обратимо.

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

И тут же при использовании VA/RVA адресации для PE начинается сплошной мрак и ужос.
-------------------------------------------------------------------------------


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


TryAga1n пишет:
против всяких "шаблонных" защит

Для таких вещей есть хоть бы тот же GSAR, если лень вручную в HIEW ковыряться.
[ведь фрагменты для S&R могут быть, и даже должны быть, довольно приличного размера]

Назначение CRACKER'а скорее не в снятии защит, а в протоколировании правок, по возможности обратимых.

Если на каком-то этапе нужно выполнить S&R, тогда можно в кряк-файле в виде комментария
указать нужную процедуру поиска и замены. И выполнить её с помощью сторонней утилиты.

.. может, надо добавить CRK-директиву #EXEC, - вызов shell'а с запуском сторонней какой утилиты, с параметрами ..
Но этого не хотелось бы


shellstorm пишет:
Решается элементарно с помощью fuzzy hashing и созданием лога отката, сигнатура замены old:new и hash блоков в которые происходила замена, работает быстро и лагов не будет даже бинарях за сотню мегабайт.

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

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

Взгляну с нескрываемым интересом.



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

dosprog пишет:
Для таких вещей есть хоть бы тот же GSAR

Просто хочу убедиться, что правильно понял:
Вы имеете ввиду
gsar (General Search And Replace) is a utility for searching for and --- optionally --- replacing strings in both text and binary files?

-----
Give me a HANDLE and I will move the Earth.

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