eXeLab
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
выпущен 8 мая!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

Русский / Russian English / Английский

Сейчас на форуме: vden, MasterSoft, novichoker (+2 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS · SVN ·

 eXeL@B —› Софт, инструменты —› CRACKER. Реализация для WIN32. GUI.
. 1 . 2 . 3 . 4 . >>
Посл.ответ Сообщение

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 9 ноября 2015 03:27 · Поправил: 30 октября 2016 03:20 dosprog New!
Цитата · Личное сообщение · #1

==============================
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". Например:
Code:
  1. 00001234:  72 ??    ;;"CHECK" - проверка байта. Удобно применять для контроля нужной версии исправляемого файла.
  2. 00001235:  ?? 23    ;;"FORCE" - безусловная замена байта (Но. После этого распатчивание уже будет невозможно)

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

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

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

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

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

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



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

Code:
  1.  
  2.  
  3.       ;допускаются пустые строки
  4.  
  5. Исрправление ошибок в программе Прога.EXE v.1.2       ;можно комментировать, используя ';'
  6. #SIZE = 3333                     ;эти строки игнорируются,
  7. #CHKSUM = 32233223       ;совместимость с CRA286.EXE (даже вернее с C2U.EXE, но это уже другая тема)
  8. #RUN = UPX -d                 ; тоже
  9.       
  10. 1) Убрать наглое окно
  11. ;
  12. ; тут можно добавить ещё какое-нибудь описание исправления
  13. ; (Но символ ';' должен быть в первой позиции.)
  14. ;
  15. Прога.EXE   ;(распакованная)
  16. ;
  17. ; тоже можно добавить строки комментариев. Но символ ';' должен быть в первой позиции.
  18. ;
  19. 000000222:  cc 90
  20. ;
  21. ;
  22. Drv\Прога.DLL
  23. ; снова можно добавить строки комментариев. Но символ ';' должен быть в первой позиции.
  24. .00403С40:  72 EB            ; Virtual Address
  25.  
  26.  
  27.  
  28. 2) Ограничения времени работы
  29. Прога.EXE   ;(распакованная)
  30. .00402222:  72 EB            ; Virtual Address
  31. 000000333:  80 00            ; Абсолютное смещение в файле
  32. Drv\Прога.DLL  ;(распакованная)
  33. .00403С55:  73 EB            ; Virtual Address
- Ну и так далее.
По мере разбора текста, если встречаются ошибки, то выдаётся номер соответствующей строки. Где вышел затык.

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






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

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

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


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

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

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

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


Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 17 ноября 2015 01:38 · Поправил: 8 октября 2016 14:02 dosprog New!
Цитата · Личное сообщение · #2

А вот поспела маленькая безобразная утилита командной строки, воспроизводящая действие команды 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")
Code:
  1. Differences between "1.exe" & "2.exe"
  2. 1.exe
  3. 00000998: 74 EB
  4. 000009A3: 74 EB

Пример запуска "CMP32 /a 1.exe 2.exe"
Code:
  1. Differences between "1.exe" & "2.exe"
  2. 1.exe
  3. .00401398: 74 EB ;00000998:
  4. .004013A3: 74 EB ;000009A3:

Пример запуска "CMP32 /ar /b 1.exe 2.exe" - выводятся адреса RVA+ModuleBase:
Code:
  1. Differences between "1.exe" & "2.exe"
  2. 1.exe
  3. ;.00400000:
  4. ..00001398: 74 EB ;00000998:
  5. ..000013A3: 74 EB ;000009A3:


С файлами 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
Code:
  1. Differences between "Original.exe" & "New.exe"
  2. Original.exe
  3. p=0040127F/FC/90: ;0000067F:
  4. 00000DF0/00/11:
  5. 00000DF1/00/22:
  6. p=00405DE0/00/31: ;00003DE0:
  7. p=00405DE1/00/31: ;00003DE1:
  8. p=00405DE2/00/31: ;00003DE2:
  9. p=00405DE3/00/31: ;00003DE3:
  10. p=00405DE4/00/31: ;00003DE4:
  11. p=00405DE5/00/31: ;00003DE5:
  12. 00004A03/00/44:
  13. 00004A04/00/44:
- Удобство в том, что заодно адреса патчения проверяются на саму возможность использования 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


Ранг: 236.7 (наставник)
Статус: Участник

Создано: 17 ноября 2015 05:34 New!
Цитата · Личное сообщение · #3

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


Ранг: 1107.3 (!!!!)
Статус: Участник

Создано: 17 ноября 2015 06:16 New!
Цитата · Личное сообщение · #4

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

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


Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 17 ноября 2015 10:36 · Поправил: 24 ноября 2015 19:33 dosprog New!
Цитата · Личное сообщение · #5

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


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

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


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

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

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


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

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

Вот и оказалось удобным патчи (для себя) оформить в виде CRK - и в архив.
{ Атач доступен только для участников форума } - rsn33790.rar

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

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

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

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


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


Ранг: 0.3 (гость)
Статус: Участник

Создано: 1 декабря 2015 02:48 · Поправил: 1 декабря 2015 03:03 wzhick New!
Цитата · Личное сообщение · #6

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 3 декабря 2015 00:27 · Поправил: 3 декабря 2015 02:06 dosprog New!
Цитата · Личное сообщение · #7

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

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

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 15 февраля 2016 22:45 · Поправил: 15 февраля 2016 22:56 dosprog New!
Цитата · Личное сообщение · #8

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

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

Ранг: 34.7 (посетитель)
Статус: Участник

Создано: 16 февраля 2016 10:08 New!
Цитата · Личное сообщение · #9

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 16 февраля 2016 13:18 · Поправил: 16 февраля 2016 15:45 dosprog New!
Цитата · Личное сообщение · #10

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



Ранг: 169.3 (ветеран)
Статус: Участник

Создано: 16 февраля 2016 20:47 New!
Цитата · Личное сообщение · #11

Win'32 console

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

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


Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 16 февраля 2016 23:04 · Поправил: 26 марта 2016 06:37 dosprog New!
Цитата · Личное сообщение · #12

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'ях) будет приводить к падению программы после патчения.
Поэтому изменения должны вноситься одновременно одной операцией патчения в несколько разных файлов. Или не вноситься, если обнаружена какая-то ошибка в скрипте или одном из этих файлов.

Как это описано в примере кряка, который был выше - одновременно патчится два файла:
Code:
  1. 2) Ограничения времени работы
  2. Прога.EXE   ;(распакованная)
  3. .00402222:  72 EB            ; Virtual Address
  4. 000000333:  80 00            ; Абсолютное смещение в файле
  5. Прога.DLL  ;(распакованная)
  6. .00403С55:  73 EB            ; Virtual Address


--Добавлено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"..


Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 18 марта 2016 09:34 · Поправил: 29 октября 2016 00:55 dosprog New!
Цитата · Личное сообщение · #13

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

Вот пример такого скрипта для задания разного цвета линий в некоей программе:
Code:
  1. Одна очень классная программка
  2.  
  3. Original color of lines
  4. stcolor.dll
  5. 0002D7B4: 48 ??   ;CHECK BYTE
  6. 0002D7B5: ?? 00   ;PATCH FORCE
  7. 0002D7B6: ?? 80
  8. 0002D7B7: ?? 00
  9.  
  10. Red color of lines
  11. stcolor.dll
  12. 0002D7B4: 48 ??    ;CHECK BYTE
  13. 0002D7B5: ?? C0    ;PATCH FORCE
  14. 0002D7B6: ?? 00
  15. 0002D7B7: ?? 00

- При этом, если действует режим "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 с "перекрывающимися" кряк-файлами работать не будет.

В аттаче пример простого кряк-файла с "перекрывающимися" патчами - { Атач доступен только для участников форума } - test.rar


Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 8 октября 2016 03:28 · Поправил: 8 октября 2016 14:02 dosprog New!
Цитата · Личное сообщение · #14

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

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

Пример запуска: сmp32 /a /rpp Original.exe New.exe
Code:
  1. Differences between "Original.exe" & "New.exe"
  2. Original.exe
  3. p=0040127F/FC/90: ;0000067F:
  4. 00000DF0/00/11:
  5. 00000DF1/00/22:
  6. p=00405DE0/00/31: ;00003DE0:
  7. p=00405DE1/00/31: ;00003DE1:
  8. p=00405DE2/00/31: ;00003DE2:
  9. p=00405DE3/00/31: ;00003DE3:
  10. p=00405DE4/00/31: ;00003DE4:
  11. p=00405DE5/00/31: ;00003DE5:
  12. 00004A03/00/44:
  13. 00004A04/00/44:

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




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

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

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

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



Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 5 марта 2017 15:17 New!
Цитата · Личное сообщение · #15

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 5 марта 2017 16:30 · Поправил: dosprog New!
Цитата · Личное сообщение · #16

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


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

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

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

Code:
  1. Это патч к программе Тест.EXE
  2. Версия 1.0.0.3
  3. Распаковать UPX
  4.  
  5.  
  6. Патч 1 - описание 
  7. ; продолжение описания
  8. ;
  9. Тест.EXE
  10. 000000345: 21 22   ; описание
  11. ; продолжение описания
  12. ;
  13. 000000545: 21 22   ; описание
  14. ; продолжение описания
  15. ;
  16. 000000645: 21 22
  17.  
  18.  
  19. ;После этого уже должно работать
  20.  


Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 5 марта 2017 20:09 New!
Цитата · Личное сообщение · #17

dosprog пишет:
Что касается "меток" - не вполне понял суть

F12 в Hiew - показ меток
Shift+F12 - задать метку

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

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

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

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 10:22 · Поправил: dosprog New!
Цитата · Личное сообщение · #18

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

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

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

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




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


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

0000010123:
.0000400123:
..0000000123:

- но и в виде:

@0000010123:
@_0000400123:
@__0000000123:


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

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

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

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


Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 11:08 New!
Цитата · Личное сообщение · #19

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


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


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


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

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


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

Было:
Code:
  1. ; Отключаем проверку версии системы
  2. .0000400204: EB 75

Стало так:
Code:
  1. ; Отключаем проверку версии системы
  2. .0000400204: EB 75 ;@VerChkPatch

или так:
Code:
  1. @VerChkPatch:
  2. .0000400204: EB 75 ; Отключаем проверку версии системы


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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 11:13 · Поправил: dosprog New!
Цитата · Личное сообщение · #20

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

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


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


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


Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 11:17 New!
Цитата · Личное сообщение · #21

dosprog пишет:
текста, который составлен руками

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 11:21 · Поправил: dosprog New!
Цитата · Личное сообщение · #22

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

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

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

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

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

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


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

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



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

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




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

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


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

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


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



Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 14:34 New!
Цитата · Личное сообщение · #23

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

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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 17:56 · Поправил: dosprog New!
Цитата · Личное сообщение · #24

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

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



Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 20:39 New!
Цитата · Личное сообщение · #25

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


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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 21:10 · Поправил: dosprog New!
Цитата · Личное сообщение · #26

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

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

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

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

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

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

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



Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 21:17 New!
Цитата · Личное сообщение · #27

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

Добавлено спустя -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

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 6 марта 2017 23:13 · Поправил: dosprog New!
Цитата · Личное сообщение · #28

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


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

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



Ранг: 580.9 (!)
Статус: Модератор
Research & Development

Создано: 6 марта 2017 23:43 New!
Цитата · Личное сообщение · #29

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. Если по данному офсету есть имя/комментарий, то сохранить в файл.

Ранг: 404.8 (мудрец)
Статус: Участник

Создано: 7 марта 2017 00:12 · Поправил: dosprog New!
Цитата · Личное сообщение · #30

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 отдельным плагином..
Между прочим.

. 1 . 2 . 3 . 4 . >>
 eXeL@B —› Софт, инструменты —› CRACKER. Реализация для WIN32. GUI.

Оригинальный DVD-ROM: eXeL@B DVD !

Вы находитесь на форуме сайта EXELAB.RU
Проект ReactOS