Оригинальный DVD-ROM: eXeL@B DVD !
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
выпущен 12 ноября!


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

Стандартизация краков и лоадеров

Обсудить статью на форуме

Массу крэкерских инструментов, видеоуроков и статей вы сможете найти на видеокурсе от нашего сайта. Подробнее здесь.

Автор: TR\"]F <truf666@rambler.ru>

Стандартизация краков и лоадеров

0. Intro.

Статья посвящена необходимости выработки единого стандарта хранения информации в патчах и лоадерах. Наличие подобного стандарта позволит создавать базы краков, размеры которых будут ненамного превосходить существующие сейчас базы серийников (ориентировачно 7.5мб ~ 60.000 записей). Примерами подобных баз могут служить Avenger, Oscar, Serials 2000 (с кучей клонов и модификаций), Serials 2004 и т.п.

1. S2K и Avenger.

Все мы хорошо знакомы с такой программой как Serials 2000 - это база серийных номеров к огромному количеству софта. S2K была лидером среди своих аналогов на протяжении нескольких лет, но к несчастью проект загнулся. Теперь мы - REVENGE Crew - создали программу, которую можно назвать не только "преемницей" S2K, но и следующим этапом в эволюции подобного рода программ. Наш проект - Avenger, уже сейчас по всем без исключения параметрам превосходит своего предшественника. Но разговор пойдет не о нем.
Avenger способен хранить в своих базах и серийные номера, и файлы-ключи, но главное - краки и лоадеры. Разъясню поподробнее: есть большое множество патч-генераторов, создающих однотипные краки. Принцип такой - имеется готовый exe-файл патч, который знает что по такому то оффсету в нем записано сколько байт нужно пропатчить, а по такому-то - массив из этих байтов. Точно также в нем хранится и прочая информация (имя автора, группы и т.д.). Все что делают патч-генераторы - сохраняют патч-шаблон на диске и изменяют в нем эту информацию. Некоторые генераторы даже хранят такой шаблон целиком в качестве ресурса.
Итак, что мы видим - все патчи созданные генераторами однотипны. Мы берем патч или лоадер, распознаем его тип и извлекаем по заранее известным офсетам всю необходимую нам информацию. Далее эта информация хранится в базе Avenger’а в виде ASCII строки и по размеру не на много превосходит пресловутый серийный номер. Такой способ хранения позволяет в сотни раз сократить размеры базы. Avenger таскает с собой по несколько шаблонов-образцов к каждому поддерживаемому патч-генератору и при извлечении информации из базы краков просто патчит этот шаблон. Минусы конечно налицо - патч генераторов много, созданные ими файлы различаются от версии к версии, да и разобраться в их структуре не всегда бывает просто. К тому же большинство более-менее продвинутых кракеров пользуются своими патчерами, которые не могут быть как-либо стандартизированы.

2. Перспектива.

Задумаемся о путях решения данной проблемы. Я предлагаю совместными усилиями выработать стандарт хранения информации в патчах и лоадерах. Для начала вспомню Нью-Васюки и распишу все плюсы такого стандарта, а потом вернемся к технической части вопроса.
Имея подобный стандарт, программы вроде Avenger смогут извлекать информацию из патчей любого типа. Информация эта будет содержать минимальные данные, необходимые для патча программы (По моим приблизительным оценкам, от 30 - 70 байт). Тем самым мы сможем создавать базы краков практически не превышающие размером базы серийников (напомню 7,5мб - 60.000 записей). Обновления к таким базам будут очень малы и могут легко распространятся по сети. Более того, после выработки подобного стандарта обычные exe-шники будут играть роль не более чем оболочки, к которой подключается необходимая информация. Группы могут выпускать просто универсальные патчеры с различными скинами, а релизить только лишь подобные модули данных. Все это позволит каждому иметь "мини" асталависту на собственном PC, при чем "мини" - от размера подобной системы, а функциональность у них будет вполне сравнима.
Может, вы назовете меня фантазером, но вспомним о .CRK формате. Поначалу применявшийся лишь парой групп, он стал мировым стандартом, а Crack2Compare и ему подобные - чем не универсальные патчеры и патч мейкеры. В принципе .CRK формат и есть тот идеал, от которого по ряду причин пришлось отказаться.

3. Реализация.

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

4. Структура.

Приведу пример подобного модуля (скорее для иллюстрации, нежели чем для выработки какого-либо формата).
В общем виде, секция может иметь формат:

 {Везде string - null terminated string, bynary - произвольная последовательность байт}
 
  [Patch Author] : string; //Ник автора
  [Group] : string; //Название группы
  [File Name]: string; // Target файл
  [File size]: dword; // размер Target файла
  [File CRC32]: dword; // контр. сумма, если 0 - игнорируется
  [Module Type] : byte; //Идентификатор структуры Patch Info
  [Patch Info] : binary;
 
 
Где [Patch Info] в зависимости от [Module Type]:

 // Стандартные записи для Patch’ей //
 
 [Module Type] = $0;
 [Patch Info] :
    [Byte Count]: dword; //Число записей в массиве
    {                    //оно же - число изменяемых байт в файле
     [Offset]: dword;
     [Old value]: byte;
     [New value]: byte;
    }
 
 [Module Type] = $1;
 [Patch Info] :
    [Byte Count]: dword; // То же, но без проверки Old value
    {
     [Offset]: dword;
     [New value]: byte;
    }
 
 [Module Type] = $2;    //По заданному офсету меняется сразу 
 [Patch Info] :         //послед-ть байт, оговоренной длины.
    [Rec Count]: dword; //Число записей в массиве
    {
     [Offset]: dword;
     [Byte Count]: dword;//Длина последов-ти
     [Old value]: binary;
     [New value]: binary;
    }
 
 [Module Type] = $3;
 [Patch Info] :
    [Rec Count]: dword;//То же но без проверки на old value
    {
     [Offset]: dword;
     [Byte Count]: dword;
     [New value]: binary;
    }
 
 [Module Type] = $4; //Seak & destroy механизм
 [Patch Info] :
    [Seq Count]: dword;//Число вхождений, которое нужно пропустить,
                       //прежде чем патчить файл
                       // если 0, то патчим сразу
    [Rep Count]: dword;//Кол-во вхождений строки, которые нужно
                       //пропатчить, если 0 - то патчатся все
                       //найденные строки
    {
     [Search str]: binary;
     [New str]: binary;
    }
 
 
И т.д., Потом, то же самое для лоадеров и пр.
Cтандарт можно будет в дальнейшем совершенствовать (сохраняя обратную совместимость ест.), благо у нас будет возможность задать 256 различных структур и, даже если одна из них устареет - мы просто добавим новую.

Кстати, заметьте, я не включил в общий формат модуля никаких URL, графики и тому подобной инфы. ИМХО - все остальное избыточная информация и должна храниться в nfo или в самом патчере.

5. Вопрос рипперства.

Да, храня инфу в подобном формате патчи не защищены от рипперства, но здесь есть пара нюансов. Во первых, срипать крак или лоадер и без того труда не составляет - рипают в основном кейгены, а их стандартизация не касается. Во-вторых, рипперство среди групп перешедших на подобный стандарт станет практически невозможно. Если раньше можно было содрать оффсеты с пропатченной чужим краком проги, а потом маскировать эту информацию в кучах кода, то теперь модуль открыт и прозрачен. Т.е. вы конечно можете переставить модуль с чужого крака на свой, но выдать его за свой уже не сможете.
Подобная "прозрачность" стандарта только усложняет рип.
Конечно, полученные из модуля данные могут быть использованы и не в стандартизированных краках, но, как я уже сказал, от этого невозможно защититься и сейчас.
Стоит отметить, что юзерам глубоко наплевать, сриппан крак или нет - они хватают тот что первый увидят, и ищут крак они не на сайте любимой кракерской команды, а в спец. поисковиках. Вот тут то и вспомним, что Avenger и т.п. софт как раз прямой конкурент подобных поисковиков. А т.к. в Avenger будут содержаться в 99.9% случаях модульные краки (а они неподдельны), то возникает интересная ситуация. Есть стандартизированный крак в базе и есть его сриппаный аналог; - в идеале юзер первым делом полезет не на поисковик, а скачает обновление базы Avenger и поищет в ней. Получается, что рип есть, но он не востребован. Своего рода симбиоз - нам нужны краки - вам их распространение, которое просто блокирует рипы.
Группы, перешедшие на модульный принцип, сами блокируют себе дорогу к рипперству, чем только подтверждают свою честность.


6.
Итак, хотелось бы выслушать мнения всех заинтересованных лиц в ближайшем форуме, и, в случае положительного решения - организовать своего рода "комиссию" :) по выработке всех необходимых стандартов. Со своей стороны могу гарантировать поддержку стандартизированных краков программой Avenger. Все они будут включатся в базу и в регулярно выпускаемые к ней обновления.

Жду ваших мнений и предложений.

With best regards
TR"]F [REVENGE Crew] http://revengecrew.net
truf666 @ rambler. ru

Обсуждение статьи: Стандартизация краков и лоадеров >>>


Комментарии к статье: Стандартизация краков и лоадеров

Admin 09.12.2004 17:00:33
Обсуждение этой статьи здесь:
http://cracklab.ru/f/index.php?action=vthread&forum=1&topic=1091
---
GPcH 09.12.2004 23:02:09
А мне вот вчера пришла мысль сделатьстандартизованный формат статей... то есть все скриншоты всех хак тулз хранятся в одной проге и чтобы написать сатью нужно выбрать необходимые скрины вставить в них нужный текст и сгенерить скрипт... но потом я понял, что у меня нет времени это реализовать и решил забить
---
MadSmoker82 27.01.2005 10:09:04
Когда то подобная прога существовала или до сих пор, там краки можно было подключать, т.е. делаешь или скачиваешь и прогой цепляешь в ее БД так сказать. Но серийников там было мало. Так что идея хороша и потребна. :)
---
TR\"]F 01.02.2005 14:44:31
Вскрытие показало, что не так уж и хороша, и не так уж и потребна :(
---
tum 25.02.2005 14:37:20
Идея правильная, а реализация ущербна.
Гораздо удобней (на мой взгляд) такой
алгоритм:
любой патч с некоторым обусловленным параметром командной строки должен
выдать инфу текстом на дисплей или файл.
например:
patch.exe -info >0read.me
или
patch.exe -info -0read.me
Гораздо легче сделать стандартный интерфейс, чем требовать
стандартной структуры..
;)
---
DroZ 23.08.2005 20:52:25
Для пальмов этот принцип уже давно применяется:
http://www.pilotwarez.com
http://www.chez.com/powershot/pwpatcher/
Теоретически можно даже PWP-Lite использовать для патча Win32 прог.

---
LiceZ 27.03.2006 21:22:32
Чего-то не понял, почему это нельзя подделать, т.е. выдать скажем за свою работу? Например, отрезаем первые две строки и приклеиваем свои.
---
qwerty1999 23.03.2008 15:08:54
Если для каждой программы делать уникальные кряки, то надо создать БД программ, чтобы народ не мучился и не изобретал велосипед.
Словом: одна программа-один кряк.
---

Материалы находятся на сайте https://exelab.ru



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


Вы находитесь на EXELAB.rU
Проект ReactOS