==============================
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]

А вот поспела маленькая безобразная утилита командной строки, воспроизводящая действие команды DOS "FC /B".
Только эта утилитка WIN32, и умеет выводить различия также и с адресами в виде VirtualAddresses (VA) для WIN32-PE файлов.
(В версии 0.002a - также и с Relative Virtual Addresses (RVA) для WIN32-PE файлов)

Это приблуда для использования с CRACKER'ом. (См. стартпост).

=============================
-->Вот CMP32.EXE (версия 0.002b)<-- (3 Jun 2018 г.) - Size: ~5 Kb, UPX'ed. MASM.
=============================




==================
Примеры использования
==================

Пример запуска "CMP32 1.exe 2.exe" (почти полная аналогия с досовской командой "FC /b 1.exe 2.exe")
Пример запуска "CMP32 /a 1.exe 2.exe"
Пример запуска "CMP32 /ar /b 1.exe 2.exe" - выводятся адреса RVA+ModuleBase:

С файлами CRK в формате вывода из вышеприведённых примеров может работать CRACKER.EXE (WIN32 GUI) v.0.002a.




В версии 0.002b добавлена опция "/rpp" - вывод различий в формате скрипта для --> R!SC's Process Patcher'а <-- (только для WIN32-PE файлов).

Пример запуска: сmp32 /a /rpp Original.exe New.exe
- Удобство в том, что заодно адреса патчения проверяются на саму возможность использования RPP.EXE.
(Или любого другого рантайм патчера памяти).
Те строки, которые начинаются с "p=", можно довольно смело использовать в скрипте RPP.
Все остальные для рантайм-патчера памяти не годятся.

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

.. И ещё. Если заданы опции сравнения /a, /ar, /v, /rpp (с виртуальными адресами),
но патч приходится на "хвост" секции, то выводятся не виртуальные,
а абсолютные адреса от начала файла.
Это сделано специально, чтобы на этапе патчения уже было ясно, что патч кривоватый
и работать будет не всегда.



27 Jan 2018:
- добавлен возврат DOS ERRORLEVEL для возможности вызова из пакетных файлов.
На основании результата сравнения (файл[ы]найдены/не найдены, одинаковы/различны)
можно организовывть ветвления в пакетных файлах (.BAT, .CMD).

Для чего такое может понадобиться - см. например
тут:
-----> CMD/BAT - [решено] Сравнение двух файлов>ветвление "fc" или "diff" <--
и тут:
-----> eXeL@B —› Софт, инструменты —› Inno Setup XDELTA Patch Maker <--



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

Я конечно понимаю, что в чужой моастырь с чужими тапками не ходят и сразу извиняюсь, но тебе не кажется, что ты опоздал с этой софтиной, лет так на %N%-дцать?

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

Это ж для души.

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

Gideon Vi пишет:
Это ж для души.

Да уж, енто не для денег (с)

TryAga1n пишет:
Я конечно понимаю, что в чужой моастырь с чужими тапками не ходят и сразу извиняюсь, но тебе не кажется, что ты опоздал с этой софтиной, лет так на %N%-дцать?

)) Да ничо. Обсуждаемо.

В принципе, именно так мне и кажется. Такую вещь надо было забацать те самые лет ~надцать назад.
Просто всё руки не доходили. И обходился старыми существующими DOS-версиями.

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


Приведу пример. Чтоб далеко не ходить -

--> Вот тут <-- обсуждалась программа regsnap v.3.30.793 (тоже старьё. 2003 год), там, правда, тема касалась распаковки asprotect 1.0,
и всёже после распаковки её надо малость поправить.

Вот и оказалось удобным патчи (для себя) оформить в виде CRK - и в архив.
3a1b_17.11.2015_EXELAB.rU.tgz - rsn33790.rar

В архиве два варианта кряка - в виде абсолютных адресов и в виде виртуальных.
У второго варианта явное преимущество - поскольку такой кряк не будет зависеть от способа распаковки,
когда MZ-заголовок будет разным при различных условиях распаковки.
Зато VirtualAddresses будут (должны быть, во всяком случае) неизменными при любых вариантах. Удобно использовать утиль CMP32.EXE с ключом "/v".
(Если для создания кряка использовать утилиту CMP32.EXE с опцией "/a", то различия будут в виде VA c добавлением абсолютного адреса в виде комментария. Удобная опция).

Кстати, именно эта возможность использовать VirtualAddresses и побудила наконец-то взяться за эту софтину.

Оглядываясь в историю, первые подобные программы появились как способ распространения кряков в открытом формате, что видно на примере библиотеки кряков от CornerCrackers,1991.
Но потом всилу разных причин такой способ не прижился и стали использоваться в основном патчи в закрытом виде, со всякими свистелками и т.п. После такого патча всё равно приходилось сравнивать файлы до~ и после~ и сохранять различия в виде CRK.

В общем, на сегодняшний день эту прогу можно отнести к разряду мелких тулз для внутреннего использования, не больше. Но кто привык, тех должно устроить, имхо. А так программка уже в ходу, доволен.
Улучшать там сейчас, вроде, нечего, поэтому программка так и "засохнет" на версии 0.001a.
Ну, может, баги какие вылезут по ходу дела. Бывает.


-- Добавлено --
)) Всякие мелкие уточнения за баги не считаются и на номер версии не влияют.
Обновлённые варианты обеих программок перезаливаю с сохранением старых ссылок
и указанием даты обновления.



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

Как раз сегодня искал

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

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

--Добавлено--
)) Ну, пошёл процесс.
При исправлении первой лажи появилась другая.
Снова исправил, перезалил. (3 декабря 2015 г.)

Если в программе нету багов, значит её плохо тестировали.(с)

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

Багфикс 15 февраля 2016 г.
Крякер падал на CRK-файлах нулевой длины или содержащих только пустые строки. ..Классика жанра..
Файл перезалит. Поправлена ссылка на скачивание в стартпосте.

Если в программе нету багов, значит её плохо тестировали.(с)

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

http://www.manhunter.ru/underground/74_programmi_dlya_sozdaniya_patchey_i_loaderov.html
FileCompare 2.8 - вполне юзабельная прога с аналогичным функционалом и не только. Вот только антивирусы ее не сильно жалуют.

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

GMAP пишет:
FileCompare 2.8 - вполне юзабельная прога с аналогичным функционалом и не только. Вот только антивирусы ее не сильно жалуют.


Имеется в виду, как я понял, юзабельная в сравнении с CMP32.EXE?

Тот функционал программы FileCompare 2.8, который интересует меня, (т.н."аналогичный"),
обеспечивается досовской командой "FC /B" и ещё туевой хучей других утилит.
Но все они не могут создавать CRK-файлы c виртуальными адресами патчей для WIN32 PE-файлов. То есть не устраивают.

А упомянутая программа к тому же не принимает аргументы из командной строки,
поэтому всерьёз мною даже и не рассматривалась никогда.
Если нужен статический EXE-cutable патч-файл (т.н. "и не только"), - тогда да, можно применять ту утиль FileCompare 2.8.
Но мне такое бывает нужно очень нечасто.

--Добавлено--
И размер той утили какой-то устрашающий. Там функционала-то всего ничего, а файл раздут непомерно.
В общем, видел я ту страницу у ManHunter'а.
--> Вот <-- ещё полезная ссылка туда же.

--Добавлено2--
Кстати, добавлю-ка новую версию CMP32.exe (v.0.002a) во второй пост темы.
Там прибавилась опция по отображению RVA-адресов. Бывает нужно.

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

Win'32 console

Hack It! Script based file patcher
M$ FC.EXE Replacment * File Binary Comparator

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

gazlan пишет:
Win'32 console

Hack It! Script based file patcher
M$ FC.EXE Replacment * File Binary Comparator


Хм. Ну, в общем-то, программы из этой же серии, да.
Но удобство этой HI.COM не сопоставимо с удобством CRACKER'а, откровенно говоря.
Её работа напоминает в первом приближении как если бы CRACKER запустить в пакетном режиме
с опцией "All" для отдельного файла CRK, заданного в командной строке.
Такой возможности в CRACKER'е нет, специально. И наверное и не будет - всё-таки ж классика жанра..

Впрочем, полезная вещь, - хотя я б не стал затевать написание такой софтины.
Мне она напомнила старую DOS'овскую утиль --> Multiple-Patcher 1996 г. <--, только та утилитка помощней будет. Всёже.

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

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

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

Как это описано в примере кряка, который был выше - одновременно патчится два файла:


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

В CRACKER v.0.002a добавлена возможность использования RVA для WIN32-PE файлов.
Кряки в таком формате можно получать с помощью утилитки CMP32.EXE из втогого поста темы.
Перезалил, поправил ссылку в стартпосте - 17 Feb. 2016.

Не нравится мне это, но как-то само получилось, машинально.. Не удалять жеж теперь.

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

В старых текстовых файлах часто признаком конца файла служит символ 1Ah,
Его многие старые редакторы вставляли в конец файла при его сохранении.
В CRACKER добавлена реакция на такой встреченный символ конца файла .CRK - <EOF char>.
Перезалит, поправлена ссылка в стартпосте - 25 февраля 2016 г.

--Добавлено4--
)) Пожаловались на CRACKER, что у него-де нет кнопки "Exit/Quit". Таких кнопок две - одна с крестиком в правом верхнем углу виндоусного окна, а другая на клавиатуре <Alt+F4>, обе работают вполне надёжно.

TODO: надо будет, как только появится время, малость усовершенствовать логику работы опции "PATCH_FORCE"..



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

Усовершенствована опция CRACKER'a "PATCH_FORCE".
Теперь его можно использовать и в качестве тупо переключателя опций для всякого софта -
когда на одно и то же место без проверок безусловно записываются разные данные.

Вот пример такого скрипта для задания разного цвета линий в некоей программе:

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

Перезалил архив, поправил ссылку в стартпосте - 18 Mar. 2016.





--Добавлено-- 7 Окт. 2016 г.

В общем-то, всё работает без проблем.

-------------------------------------------------------------------------- о "перекрывающихся" патчах -----------------

Единственно, что вызывает задумчивость, это вариант кряк-файла,
в котором описаны несколько последовательных кряков одних и тех же адресов. (см.пример в аттаче к посту).

В принципе, проблем нет - в режиме одиночного патчения кряки применяются последовательно, начиная с первого.
Распатчивание в одиночном режиме по таким крякам тоже не проблема - кряки отменяются последовательно, начиная с последнего.

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

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

Это при патчении (PATCH_ALL). При распатчивании (UN-PATCH_ALL) та же проблема,
но только начиная с последних описанных в кряк-файле кряков.

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

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

В аттаче пример простого кряк-файла с "перекрывающимися" патчами - e46b_07.10.2016_EXELAB.rU.tgz - test.rar



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

Новая версия сравнивалки CMP32 - v.0.002b (перезалита, ссылка в посте #2 ).

Добавлена опция "/rpp" - вывод различий в формате скрипта для R!SC's Process Patcher'а (только для WIN32-PE файлов).

Пример запуска: сmp32 /a /rpp Original.exe New.exe

Удобство в том, что заодно адреса патчения проверяются на саму возможность использования RPP.EXE.
(Или любого другого рантайм патчера памяти).
Те строки, которые начинаются с "p=", можно довольно смело использовать в скрипте RPP.
Все остальные для рантайм-патчера памяти не годятся.




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

В CMP32.exe поправлена ошибка определения PE-файла,
из-за которой он падал при сравнении
с опцией "/a" DOS-MZ запакованных файлов.
(Перезалито, ссылка в посте #2 ).

Аналогичная правка CRACKER.EXE:
Поправлена ошибка определения PE-файла,
из-за которой он падал при попытке патча
по виртуальному адресу в DOS-MZ запакованном файле (что неверно).
(Перезалито, ссылка в посте #1 ).

Некритичные, но неприятные ошибки.



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

dosprog
Сделай в виде плагина к Hiew, чтобы создавал метки и опционально применял патч.
Кстати, как я вижу из твоих описаний, для мест, в которых производится патч, не предусмотрено "метки", которую можно было бы добавлять к дизасму, например. А описания слишком длинные для того, чтобы их использовать в качестве метки.
В идеале было бы расширить формат описания .crk файлов для включения метки и описания для каждого адреса.

-----
EnJoy!

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

Jupiter пишет:
Сделай в виде плагина к Hiew, чтобы создавал метки и опционально применял патч.

Была задумка сделать не в виде плагина, а просто добавить функционал, позволяющий по тычку в тексте .CRK раскрыть ковыряемый файл в HIEW на адресе, по которому тыцнули - чтобы удобней было разглядывать правки в виде DISASM'а HIEW.
Но идею занесло в сторону и выкинуло на обочину, поскольку решил просто[не-просто] добавить, в будущем, встроенный HEX/DISASM вьювер.
А там, как часто бывает, старая задумка уже завяла, а новая ещё не созрела. Так и пользуюсь пока, в режиме классического CRACKER'а.
Кстати, в более старых версиях HIEW менее навороченная DOS-командная строка для передачи аргументов, и там передать адрес через параметры Shell'а не удастся. Это тоже поостудило идею.

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

Ну, поизощряюсь сейчас для примера:



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

dosprog пишет:
Что касается "меток" - не вполне понял суть
F12 в Hiew - показ меток
Shift+F12 - задать метку

Не уверен, что в той допотопной версии, которую используешь ты, был такой функционал.

Если ты программируешь на асме, то должен знать и понимать, что такое метка.
Метка имеет формат "текст_метки:"

Это полезно в случае, когда тебе необходимо, например, заменить вызовы. Ты можешь задать метку, например "patch", и при ассемблировании вызова, тебе будет достаточно ввести "call patch" или "jmp patch", а не адрес метки.

В том листинге, который привёл ты, никаких меток я не заметил.

-----
EnJoy!

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

Jupiter пишет:
Не уверен, что в той допотопной версии, которую используешь ты, был такой функционал.

Да, такую возможность не использую.

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

Иначе [если использовать "метки" HIEW] потом нужно постоянно хранить хьюшный файл .SAV,
а у HIEW работа с сохранением/восстановлением в/из этого файла сделана категорически криво.
Мне не нравится.




Jupiter пишет:
В том листинге, который привёл ты, никаких меток я не заметил.

Можно добавить в крякер функционал (дополнительно), чтобы адрес можно было указывать не только в виде:

0000010123:
.0000400123:
..0000000123:

- но и в виде:

@0000010123:
@_0000400123:
@__0000000123:


Такое решение помогло бы?

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

Впрочем, метки вида "@000123" не заменят меток с именами в словесной форме, если я правильно понял о чём речь.

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

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

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

Имена хранятся в файле .names, а подсвеченные байты в файле .cmarkers. Каких-то катастрофических проблем в работе Hiew с этими файлами я не замечал.


dosprog пишет:
@0000010123:
...
Такое решение помогло бы?

Это бессмысленно, если это не буквенная метка вида "VersionCheck". То, что ты предложил, это чуть другое представление всё того же адреса, а не метки.

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

Вообще не только Hiew поддерживает создание именованных блоков, тот же 010 Editor через Template тоже позволяет это делать. При парсинге .crk файла в его существующем виде, все блоки, если их именовать будут выглядеть одинаково (Patch_01, Patch_02 .. Patch_0000010123). Но если добавить (пусть даже в поле для комментария) имя метки, то все эти места уже можно будет назвать.

Было:

Стало так:

или так:


На данный момент при сравнении двух файлов нужно постоянно держать открытым файл .crk, чтобы иметь возможность прочитать комментарии. При наличии меток, можно будет быстрее ориентироваться по файлу в том же Hiew.

-----
EnJoy!

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

Тогда, честно, не понимаю, в чём проблема.
И так ведь можно вcтавлять "метки" в виде комментариев вслед за символом ";".

Крякер занимается только разбором текста, который составлен руками в желаемом виде,
но с соблюдением некоторых "соглашений" вроде синтаксиса комментариев


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

Точно. У меня крякер так и висит запущенный постоянно.
Для этого там и есть опция "перечитать CRK файл" (F3, Alt+F3)
и даже "вызов внешнего редактора для кряков" (F4),
хотя второй опцией практически не пользуюсь.

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

dosprog пишет:
текста, который составлен руками
ОК, я то полагал, что утилита cmp32 позволяет автоматизировать процесс.

-----
EnJoy!

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

Jupiter пишет:
ОК, я то полагал, что утилита cmp32 позволяет автоматизировать процесс.

Тогда понятно.

Утилита cmp32 это всего лишь-навсего [абсолютно атономный] эквивалент досовской команды "C>FC"
с [опциональным] добавлением особенностей PE-файлов при выводе результатов сравнения.

Добавляю новый патч в CRK-файл вызовом:

C>cmp32 orig.exe new.exe >> file.crk

- Как это делается уже овер тридцать лет. Оно работает


) Обе тулзы просты, как два велосипеда.

И являются ремейками, чуток "осовремененными", давно известных и популярных инструментов.



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

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




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

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


.. Кстати, [тут выше есть об этом, в описании,] в другом случае, предлагал добавить опцию в CMPDISASM для генерации кряков в пристойном виде, и тишина. После какого-то периода тишины пришлось запилить утилитку cmp32 и забыть об этих всех проблем. CMPDISASM не использую.

Вот тот текст:
- и кстати - тут сразу возникает предложение к crc1 по добавлению в его CmpDisasm возможностей, касаюшихся сохранения различий в сравниваемых файлах в формате CRK, но с виртуальными адресами смещений патчения.




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

> А вот желаемый функционал, касающийся добавления меток при генерации кряка,как и сама генерация кряка - это вопросы сугубо к автору HIEW.

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

-----
EnJoy!

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

Согласен,
но сам разработкой плагинов для HIEW заниматься не стану.

На это тупо нет времени.
Если оно появляется, то в стеке несколько задач, на которые его приходится тратить.



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

dosprog пишет:
но сам разработкой плагинов для HIEW заниматься не стану.

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

-----
EnJoy!

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

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

Jupiter пишет:
Техническое задание?

Та ну..
Просто размышляю, в качестве оффтопа.

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

Это повторная возня по разбору текста CRK.

Двумя строчками не реализуешь. Прикидываю, стоит ли "жечь свечки".

Хотя, если в будущем добавлять встроенный вьювер, то это придётся делать по-любому.



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

Техническое задание?

Добавлено спустя -5 минут
dosprog пишет:
Просто размышляю, в качестве оффтопа.

Ну так размышляя, формулируй ТЗ.


dosprog пишет:
как бы поизящней прикрутить в крякер вызов HIEW для целевого файла на нужном адресе.

Выдержка из справки Hiew 8.53:

Командная строка
Hiew [options] [/s]filemask...[/s][filemask]
/O[thc]=OEP|END|[.]offset[th] - задать стартовые режим и смещение
/MACRO0=<macrofile> - сразу запускать макрос
/SAV=<savefile> - откуда брать savefile
/INI=<inifile> - откуда брать inifile
[/s]filemask...[/s][filemask] - можно задавать несколько файлов,
включаю маску с шаблоном.

* Опция /s переключает поиск с подкаталогами:
hiew /s *.dll *.exe /s *.txt -> будет искать .dll и .exe с подкаталагами и
.txt только в текущем каталоге

* смещение в опции '/O' можно указывать во всех видах, воспринимаемых внутри hiew:
- с точкой впереди как локальное смещение
- основание по умолчанию (16) может быть изменено суффиксом 't'
а также:
- специальное смещение 'END' (без кавычек) ставит курсор на последний байт файла
- специальное смещение 'OEP' (без кавычек) ставит курсор на точку входа Exe-файлов
примеры:
/Ot=END - текстовый режим, конец файла
/Oc=OEP - режим кода, курсор на точке входа
/Oh=1234 - hex режим, смещение 1234 (hex)
/Oh=0x1234 - тоже самое что выше
/Oh=1234t - hex режим, смещение 1234 (decimal)
/Oc=.401234 - режим кода, локальное смещение 401234

* с версии 7.40 опция '/O' применяется ко всем файлам командной строки при
CtrlF9/CtrlF11/CtrlF12

-----
EnJoy!

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

Jupiter пишет:
Выдержка из справки Hiew 8.53:

Да то понятно.
Дело в том, что получив из EditBox'а в крякере строчку,
нужно выполнить её разбор, и после этого найти её запись в откомпилированной базе кряк-файла, а уже оттуда и брать искомое имя файла для патчения и оффсет в нём.
Довольно громоздко получается.
(Тут "база" - это то, листиг чего выводится в файл по дебаг-опции Ctrl+Alt+L.
Чтобы можно было убедиться в её, "базы", соответствии исходному CRK-файлу.
Для меня это отладка, для юзеров контроль работоспособности движка
[хотя эта опция им по-хорошему не сильно-то и надо]
).

А что до "техзадания" (может, громко сказано,) -
довольно смутно представляю себе возможности программирования плагинов.
Ну, имена-то файлов 1 и 2 вытащить можно, принять у юзера имя файла результата тоже - дальше сравнение - и вот тут нужно вынимать из HIEW для несовпадающих байтов всю добавленную информацию ("метки") и просто выводить её в файл. Соблюдая формат кряка.
На "бумаге"-то оно просто..



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

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


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

dosprog пишет:
Ну, имена-то файлов 1 и 2 вытащить можно
Это делается либо передачей в Hiew двух параметров с именами файлов:
hiew32.exe /Oc=OEP File1.exe /Oc=OEP File2.exe
либо открыв файлы последовательно уже в самом Hiew по команде F9 [Files].
Переключение между файлами происходит по Tab.
На данный момент в SDK не хватает функции получения имён всех открытых файлов (HIEWGATE_GETFILENAME).

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

dosprog пишет:
дальше сравнение
Если сравнивать, как это делает CmpDisasm, то это тупо побайтное сравнение.
Метки получаются по HiewGate_Names_GetLocal/HiewGate_Names_GetGlobal, а комментарии по HiewGate_Names_GetLocalComment/HiewGate_Names_GetGlobalComment. Если по данному офсету есть имя/комментарий, то сохранить в файл.

-----
EnJoy!

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

Jupiter пишет:
Ты же можешь заранее соотнести все выводимы строки с определёнными данными из .crk файла, а не заново искать эти данные по строке.

Так и придётся делать, да. Сейчас этого нет.
Поэтому и говорю, что это или головняк по повторному разбору текста,
или усложнение базы, которая сейчас нормально работает.
Представление о нынешнем формате базы можно получить из её листинга (Ctrl+Alt+L).
Исходного файла CRK при работе крякера в памяти уже нет, и сам файл закрыт,
чтобы можно было его редактировать или дополнять.
Полностью текст в памяти не хранится ещё и потому, что он может быть ну ооочень большой, включая сюда ещё и комментарии, которых может быть немеряно..
То, что видно в EditBox'e 2 при выборе отдельного патча в списке патчей ListBox'а - это интерпретация уже на основе базы.
Хотя, при выборе в листбоксе 1 файла из списка CRK-файлов, текст каждого из CRK-файлов ещё виден в исходном виде - и это потенциально чревато, поскольку EditBox-то не безразмерный..
Впрочем, этот EditBox 2 при этом имеет только демонстрационное назначение, помогающее выбрать нужный файл из списка CRK-файлов, и если в нём текст будет в конце обрезан, то ничего страшного случиться не должно.
..Ничего страшного не должно случиться и в случае отображения там интерпретированного содержимого базы - ничего страшного, если нет нужды лазить по тому тексту курсором и выбирать желаемое смещение для отображения его в HIEW...
***********************************************************
--- Вот и вспомнил, во что тогда упёрлась та идея с вызовом HIEW.
--- Потенциально текст в EditBox'е 2 может быть обрезан самой виндой, что делает наличие такой опции в крякере потенциально костыльной. На этом идея и была похерена.
Так что дальнейшие навороты уже должны сопровождаться своплением текста для отображения его в EditBox'e, и оно, это усложнение, уже нецелесообразно именно поэтому.
В общем, на этом проект можно считать успешно завершённым.
По этому поводу и написал в своё время:
Улучшать там сейчас, вроде, нечего, поэтому программка так и "засохнет" на версии 0.001a.
Ну, может, баги какие вылезут по ходу дела. Бывает.
***********************************************************
Память.. Времени-то уже прошло прилично, полтора года однако же. Стал забывать детали.


Jupiter пишет:
На данный момент в SDK не хватает функции получения имён всех открытых файлов (HIEWGATE_GETFILENAME).

Плохо. Эта функция как раз и нужна для.
Уже получаются костыли - если не передал имена в командной строке HIEW.
(ну, командную-то строку-то в плагине получить можно?..)

Jupiter пишет:
Это можно не узнавать, а генерить автоматически по имени исходного файла.

Тоже вариант..

Jupiter пишет:
Если сравнивать, как это делает CmpDisasm, то это тупо побайтное сравнение.

Так и надо. Это же сравнение "байт-в-байт"..

Jupiter пишет:
Если по данному офсету есть имя/комментарий, то сохранить в файл.

Причём даже если и нет отличий байтов - сохранить просто в виде комментария "\n;\n; %s\n;\n;".

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



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