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

ВИДЕОКУРС ВЗЛОМ
выпущен 2 июля!


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

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

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

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

Ранг: 407.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]



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

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

dosprog пишет:
Плохо. Эта функция как раз и нужна для.

Есть функция запроса единичного файла HIEWGATE_GETFILENAME.
Для сравнения двух файлов вполне достаточно. Один уже открыт в Hiew, второй запрашиваем через плагин.

dosprog пишет:
ну, командную-то строку-то в плагине получить можно?

GetCommandLine валидна для всего процесса, так что плагин тоже может получить командную строку.

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

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

Jupiter пишет:
Для сравнения двух файлов вполне достаточно. Один уже открыт в Hiew, второй запрашиваем через плагин.

Я бы сделал обязательным наличие уже двух открытых файлов.
Если открыт только один - вывод сообщения "ERROR - open 2nd file for compare" и на выход.
Это [Вариант 1].

Jupiter пишет:
GetCommandLine валидна для всего процесса, так что плагин тоже может получить командную строку.

Если достаточно одного открытого файла чтобы вынуть <имя файла для патчения>, то лучше, наверное, не связываться с разбором командной строки, а ограничиться [Вариантом 1]
А можно в случае неудачи по [варианту 1] перед вызовом сообщения "ERROR - open 2nd file for compare" попытаться отыскать это имя второго файла ещё и в аргументах командной строки HIEW, и уж тогда, если и там ничего найти не удалось, вывод сообщения "ERROR - open 2nd file for compare" и на выход. Иначе - работать.



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

Создано: 7 марта 2017 01:40 New!
Цитата · Личное сообщение · #4

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

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

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

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


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

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

dosprog пишет:
если эта функция выводит тот удобный стандартный HIEW-диалог выбора файла, который по F9

Да, и его тоже.

dosprog пишет:
пускай откроют второй файл по F9, и запускают плагин по новой.

В текущей версии HEM SDK можно получить только имя активного файла.

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

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

Jupiter пишет:
В текущей версии HEM SDK можно получить только имя активного файла.

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

Тогда первый, изначально открытый в HIEW и активный файл это NEW_FILE (с правками, комментариями и метками), а второй, имя которого получать вызовом HIEWGATE_GETFILENAME, это нетронутый ORIGINAL_FILE.

В CRK-файле в каждом патче нужно указывать имя ORIGINAL_FILE и байты соответственно <offset: original_byte new_byte>

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

Тогда в приглашении к открытию второго файла нужно выводить "SELECT ORIGINAL FILE FOR COMPARE WITH IT"

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



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

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

Так и предполагал, как ты описал.
К тому же при сравнении можно задавать метки, чтобы потом, при открытии оригинального файла, можно было быстро перемещаться по местам патчей. Автоматические имена могут быть в виде Patch_NNN, Patch_NN.
При наличии меток в текущем файле, можно определять, попадает ли измененный байт в самое начало метки или же идёт со смещением. Такое возможно, когда патч идёт внутри команды, например изменяется адрес jmp/call.

Добавлено спустя 1 час 35 минут
sen, автор Hiew ответил по поводу доступа к открытым файлам.
В один момент времени открыт только один файл. Поэтому доступ к другому файлу проще сделать через явный запрос файла у пользователя через F9.

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

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

Понятно.
Ну, под "доступом ко второму файлу" понималось только получение его имени.

Кстати, насчёт "постоянно открытого одного файла" - так вообще-то быть не должно.
Это реально мешает работать.

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

Понятное дело, если использовать "отображение файла в память", то это сделать проблематично.



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

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

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


Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

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

Jupiter пишет:
sen, автор Hiew

жуткий оффтоп, но --> Link <--

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



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

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

ajax
Интересен ход твоих мыслей, что привело к цитате именно этой статьи с упоминанием Сусликова?


Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

Создано: 8 марта 2017 10:53 · Поправил: ajax New!
Цитата · Личное сообщение · #13

Jupiter
погуглил sen'a, в каком он возрасте atm - насколько всякие нововведения интересны для хиева

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

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

Так возраст это плохо или хорошо, в данном контексте?

) Кстати, иногда вспоминаю поговорку "Если б молодость умела, то и старость бы хотела".

Молодые учиться не хотят, иначе бы имелся сопоставимый аналог HIEW.
А его нет.

А sen что - он предоставил интерфейс HEM - а дальше плюшки можно,
при желании, прикручивать самостоятельно.
Это, конечно, не то, что было бы, имейся сорсы, но хоть что-то.

ajax,
статья понравилась, спасибо.
Эти горелые чайники..
И насчёт пьянок, повеселило, - мне вот тоже несколько раз удавалось засесть за компьютер "в состоянии",
писалось невообразимо классно и плодовито, но потом приходилось всё похерить.
Точно так же, как описано в статье.



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

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

dosprog пишет:
Это, конечно, не то, что было бы, имейся сорсы


Hiew почти беспроблемно разбирается в IDA до уровня компилируемого .asm файла.
С циклом обновлений Hiew раз в квартал, а то и раз в полгода, нет проблем с различными версиями.

ajax пишет:
насколько всякие нововведения интересны для хиева


Ну так sen же коммерческий продукт создаёт, и поддержка форматов ELF, Mach-O и дизасма ARM добавлены не просто так )


Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

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

dosprog пишет:
Так возраст это плохо или хорошо, в данном контексте?

все относительно. если под полтинник и более - все грустно. обычно, куча забот к такому времени. не время быть "в тренде". плюсы - набитая рука и понимание предмета
dosprog пишет: А его нет
qview юзал часто до x64. biew вроде в сырках + мультиплатформ, не пользовал
dosprog пишет:
мне вот тоже несколько раз удавалось засесть за компьютер "в состоянии"

"некоторые" (ай эм) в таком состоянии код выдают, что потом фик поймешь. а, работает, и не придраться
Jupiter пишет:
Ну так sen же коммерческий продукт создаёт, и поддержка форматов ELF, Mach-O и дизасма ARM добавлены не просто так

однако, от капстона и тп дистанциируется. про мак я ему писал хз сколько времени назад. и, только "разродился"

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

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

Jupiter пишет:
Hiew почти беспроблемно разбирается в IDA до уровня компилируемого .asm файла.


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

ajax пишет:
qview юзал часто до x64. biew вроде в сырках + мультиплатформ, не пользовал


Qview в старые-старые времена пытался приспособить для себя, не понравилось.
И очень неаккуратный код, такое сложилось впечатление.
Имхо конечно.
Сейчас имеются сорсы, но клонов что-то не наблюдается. Скорей всего потому, про что написал выше.
BIEW вообще ..своеобразная вещь. Тоже не устроил в своё время.

Вот так разобраться - что такое хекс редактор -
1) Собственно редактор текста, не очень сложный, как интерфейс (но тема бездонная. Например, плагины, скриптовый язык и так далее т.п.)
2) Код поддержки форматов
3) Дизассемблер.

По пунктам 2) и 3) можно да, лазить в старые сорсы, а по пункту 1) - там брать практически нечего, затевая проект "типа аналог HIEW" нужно опираться уже на немного другие принципы, чем в тех утилитах.

Пункт 1) тут самый ..трудный.

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

В общем, HIEW это вполне реальность, и ничего страшного, наверное, в этом нет.

ajax пишет:
все относительно. если под полтинник и более - все грустно. обычно, куча забот к такому времени. не время быть "в тренде". плюсы - набитая рука и понимание предмета

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


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

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

dosprog пишет:но у молодёжи безнадёжно в смысле "эстетствования", поэтому ничего путного и не выходит.

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

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


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

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

) Ну вот, пожалуйста. Как раз и приплыла иллюстрация того, про что писалось выше.

В общем, надо будет по свободе поковыряться с HEM'ами. А оно не хочется

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



Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

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

dosprog пишет:
Вот разбогатею, приобрету лицензию на HIEW и всех делов

C "трендом" тоже неплохо
не соглашусь. мак и т.п. надо было вводить n лет назад, к примеру. аргументы были - "это надо паре юзеров". в итоге сотворил
я оф юзер был. после того, как аллсофт и прочее затребовало фио и тп - забил нафик на подписку
shellstorm
что ви тут делаете, вопрос? есть куча форумов, где ваши нью-тру-знания оценят

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

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

Глянул HEM.

В первом приближении, - примитивный сравнивальщик двоичных файлов
в виде HEM-модуля, генерирующего файл различий в формате CRK.
(Расширенный формат PE CRK для CRACKER'а, c Virtual Address'ами).

Метки/комментарии из HIEW в отчёт (CRK) не вставляются.

*************************
CRACK.HEM --v.0.000a - (*УДАЛЕНО*) <Дальше в теме уже есть --> версия с добавлением в отчёт имён <-->
*************************

<<Добавлено: Обработки клавиши <ESC> тут нет, поэтому на очень больших файлах прервать сравнение не удастся, придётся подождать.>>

Кстати, помнится, подобный функционал имелся в QView.
Но только CRK с абсолютными адресами.

Тут адреса выводятся в отчёте в абсолютных (Global) величинах, если HIEW не сумел распознать файл как исполняемый и не обнаружил в нём "локальной адресации". Это, например, может быть любой файл, от DOS-MZ, до обычного текстового.

Если "локальная адресация" (Local) в файле распознана, тогда адреса выводятся в отчёт в двух представлениях - в "локальном виде" (Local) с символом точка '.' вначале значения (например, для виртуальных адресов WIN32 PE-файлов) и как "комментарий CRK" в виде абсолютного значения.
Такой файл CRK будет похож на результат запуска утилиты "cmp32 /a"

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

Теперь уже придётся добавить в этот HEM вывод меток, имён и комментариев из HIEW.
Другого выхода нет..

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



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

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

dosprog
И всё-таки я привёл тебя к написанию собственных модулей для Hiew ))
Ура!


Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

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

Jupiter
мне больше всего нравится дотнет править в хиеве... поиск по сигнатуре и правка. саппорт инструкций sen'у тоже не судьба сделать

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

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

Равно как и суппорт нативных VB-кодов.
.NET это полова, которую постигнет та же участь, что и видеобасик.
Имхо конечно.


Ранг: 327.6 (мудрец)
Статус: Участник
born to be evil

Создано: 10 марта 2017 13:15 · Поправил: ajax New!
Цитата · Личное сообщение · #25

dosprog
"может быть когда нибудь". проблем не вижу особых с подключением движка. единственное - капстоун или типа того - лицензия на коммерческое применение. или dnlib/etc
нисколько не ставлю под сомнения заслуги sen'a, hiew был супер с 95 года, или ранее. не помню


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

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

dosprog пишет:
суппорт нативных VB-кодов.

Ты имеешь в виду P-Code?
Потому что Native - это обычный x86, который Hiew и так отображает.

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

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

ajax пишет:
нисколько не ставлю под сомнения заслуги sen'a, hiew был супер с 95 года, или ранее. не помню

)) С 91-го. --> Hiew v.2.2 <--


Jupiter пишет:
Ты имеешь в виду P-Code?

Ну конечно, да. Его. Ошибся..




**************************************************************************************
--> CRACK.HEM <-- - v.0.001a/fixed/optimised (ПЕРЕЗАЛИТО 2 - 15 марта 2017).
**************************************************************************************

Добавлен [опциональный] вывод в отчёт всего, что при редактировании файла в HIEW32 подобавляли в виде комментариев, имён и меток.
<<Добавлено: сравнение очень больших файлов можно прервать клавишей <ESC> >>
<<Добавлено: Немного оптимизировано сравнение с поиском имён и меток HIEW >>


Замечания:

1)
Если выбран "Вывод в отчёт имён", то уже работает не так и быстро. [От него можно и отказаться].
Потому, что тупо приходится вызывать всю серию проверок на наличие имён для каждого байта файла.
Это можно поправить, если вначале создать базу всех имён, а потом проверять каждый адрес по этой базе.
Тоже будет долго, но теоретически быстрее, чем мучить для этого HIEW.
<<--Добавлено-- А можно применить и --> "навороченный способ" <--, предложенный Jupiter'ом >>

2)
Парадокс, что в набор пользовательских функций не включена обычная функция-аналог MessageBox.
Поэтому для имитации этой отсутствующей функции приходится использовать функцию ччч_GetString().
Это выглядит немного странновато, но работает вполне нормально.

<<Добавлено: Впрочем, функция ччч_Message вроде бы возвращает код нажатой клавиши ..>>

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

-------------------------
По самому HIEW32:

4)
Не вполне понятна логика "Local/Global" для имён.
Поэтому вывод их в плагине сделан немного тупо
- всё, что есть, вываливается в отчёт гамузом, снабжённое тегами- "L_NAME=/G_NAME=" , "L_COMM=/G_COMM=".
Впрочем, уже даже в таком виде плагин вполне можно использовать для протоколирования правок.
Это действительно удобно.
Отдельно благодарность Jupiter'у за полезную идею.

Пример результатов работы плагина:

Code:
  1. Fixing of 1 
  2. File size 492032 (0x78200)
  3.  
  4. Differences between "1" and "2" 
  5. 1
  6. .004017F9: 90 31 ;000019F9: ;L_NAME="label_xor" ;L_COMM="zero eax"
  7. .004017FA: 90 C0 ;000019FA:



5)
По редактированию в HIEW - не понятно, как редактировать (удалить) отдельную запись в таблице имён (которая по F12).
Ну, это уже, наверное, в новых версиях HIEW усовершенствовано.




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

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

ajax пишет:
мне больше всего нравится дотнет править в хиеве... поиск по сигнатуре и правка. саппорт инструкций sen'у тоже не судьба сделать

А ты .NET сборки исследуешь в Hiew?


dosprog

Тебе нужен дизасм P-Code именно в основном окне Hiew? Или вариант с плагином тоже подходит?


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


Очевидно, что так гораздо быстрее. Меток то может быть всего ничего, а байт в файле дохера и больше.
Уж точно меток меньше, чем байт в файле.
Ты можешь получить количество имён/меток через HEM_NAMES_COUNT_NAME, HEM_NAMES_COUNT_LOCAL, HEM_NAMES_COUNT_GLOBAL:
HiewGate_Names_CountName, HiewGate_Names_CountLocal, HiewGate_Names_CountGlobal


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


Есть же MessageWait (HIEWGATE_MESSAGEWAITOPEN) на зелёном фоне.
Запускай её в цикле с автоматическим закрыванием по таймеру.


Пример:
Вызываешь HiewMsgWaitOpen
В цикле зовёшь HiewIsKeyBreak и ожидаешь HEM_KEYBREAK

Выходишь по HiewMsgWaitClose, когда отработает цикл, либо когда пользователь нажмёт Esc


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


Можно разницу записывать в отдельном потоке данных как bsdiff


dosprog пишет:
Не вполне понятна логика "Local/Global" для имён.


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


dosprog пишет:
По редактированию в HIEW - не понятно, как редактировать (удалить) отдельную запись в таблице имён (которая по F12).


Для этого есть HEM_NAMES_DEL_LOCAL, HEM_NAMES_DEL_GLOBAL.
И соответствующие функции HiewGate:
HiewGate_Names_DelGlobal, HiewGate_Names_DelName

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

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

Jupiter пишет:
Для этого есть HEM_NAMES_DEL_LOCAL, HEM_NAMES_DEL_GLOBAL.

Из плагина да.
Но должно же работать и просто из меню F12..

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

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

Просто разметка в HIEW это то, чем не пользовался вообще никогда.

Jupiter пишет:
Очевидно, что так гораздо быстрее. Меток то может быть всего ничего, а байт в файле дохера и больше.
Уж точно меток меньше, чем байт в файле.

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

Пока оставлю как есть, понаблюдаю, как оно работает.

Jupiter пишет:
Есть же MessageWait (HIEWGATE_MESSAGEWAITOPEN) на зелёном фоне.
Запускай её в цикле с автоматическим закрыванием по таймеру.

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

Вообще, тоже странно, что от клавиатуры может быть только два значения - Enter и Esc.
Лучше бы возвращался код клавиши - был бы простор для программирования условий.
Без этих всех меню.

Ну, то уже как есть

Jupiter пишет:
Можно разницу записывать в отдельном потоке данных как bsdiff

Да нет, там может быть такая туча "различий", что всё потеряет смысл.
Если, например, поредактированный выдранный (MZ+PE)-заголовок сравнивается с оригинальным необрезанным файлом..
Там "всё не так однозначно"(с)

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

Впрочем, это сильно частный и притянутый за уши случай.

Пока тайм-аут, попользую плагин, посмотрю, что да как.



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

Создано: 10 марта 2017 22:18 New!
Цитата · Личное сообщение · #30

dosprog пишет:
Быстрее-то будет, но не на порядки, а в пару-тройку раз.


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


dosprog пишет:
Но там только завершение такого "диалога" по таймеру, а это решение не устраивает абсолютно


То ли ты невнимательно читаешь, то ли тебя и моё предыдущее предложение не устраивает.
Я совершенно чётко указал, что есть два параллельных варианта: таймер И нажатие клавиши Esc.
Можешь вообще обойтись без таймера, тогда окошко будет висеть бесконечно до нажатия Esc.

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

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

Jupiter пишет:
Но я уже ранее написал, что меток точно меньше, чем байт в файле.
По-моему, это настолько очевидно )
Допустим, файл весит несколько мегов. Его пропатчили в нескольких местах. Допустим, в десятке мест.
И получается, что меток несоизмеримо меньше, чем байт в файле.

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

Сейчас там при сравнении будет выводиться зелёное окошко "Processing...", чтоб не молчать.

Так вот, при сравнении файлов размером пол-мегабайта, если без проверки имён,
то это окошко даже не успевает появиться.
С проверкой имён оно появляется на секунду-полторы и его вполне видно.
[..а машина сравнительно шустрая..]

Jupiter пишет:
Можешь вообще обойтись без таймера, тогда окошко будет висеть бесконечно до нажатия Esc.

)) Такой вариант тоже попробовал. Но тогда нет выбора.

while(1){ choice=HiewGate_IsKeyBreak(); if(choice==HEM_KEYBREAK) break;}

Вот если бы HiewGate_IsKeyBreak() могла вернуть просто код клавиши,
тогда бы и можно было организовывать нормальные ветвления в программе
с её помощью. И не только "двоичный выбор", как с этой ччч_GetString().

) Но с такими пропозициями я к sen'у обращаться не буду, пошлёт вдаль, 100%.

Jupiter пишет:
Я совершенно чётко указал, что есть два параллельных варианта: таймер И нажатие клавиши Esc.

Правильно. - А если мне не нужен этот выбор, который обеспечивается нажатием <Esc> ?
- Тогда придётся ждать. Это и не устраивает.

В других софтах это меня тоже раздражает,
начиная с задержки выбора дефолтной конфигурации
в boot-menu Windows и т.д.
- Задашь длинный период задержки - плохо, (но можно ускорить явным нажатием)
- задашь короткий - тоже плохо, иногда не успеваешь.
Но там можно ускорить принятие нужного решения,
а тут придётся только ждать.

Эргономика..

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

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

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