Жанр: Учеба
Главы книги о взломе
...т число ложных
срабатываний, но не так много, как кажется на первый взгляд. Представим для
начала, что нам известен лишь фрагмент А. Какова вероятность того, что он
совпадет с A'?
---------------¬
L--------------- ,
ТАТ-------------ТАТ----- - - -
+---------------+------- - - -
¦ ¦
¦<---- L ------>¦
Давайте представим себе последовательность AA. Естественно, что она
будет "вмещать" в себя A^2 элементов. У скольких элементов левая "половина"
равна правой? Обозначим левую часть как L, а правую как R. Легко видеть что
для каждого L существует только один равный ему R. Число совпадающих
вариантов равно множеству элементов А. Тогда вероятность совпадения
произвольных А и А' равна #A/#A^2 == 1/#A, где # - число элементов
множества.
Однако, нас интересуют только те совпавшие числа, которые находятся
строго на расстоянии L друг от друга, где L как видно равна длине ключа.
Задачу подсчета данной вероятности я оставлю любопытным читателям решить
самостоятельно, здесь же только отмечу что она на несколько порядков ниже
от общего числа ключей, которое нам бы пришлось перебирать в противном
случае. Даже если #A равна одному биту (!) у нас не плохие шансы. И гораздо
более высокие, чем показал расчет любознательных читателей. Точнее говоря
они МОГУТ СТАТЬ несравненно выше. Используемая нами математическая модель
исходила из предпосылки равновероятности всех символов. Это очень упрощает
расчеты, но не соответствует действительности. Как правило, нам известно
хотя бы приблизительное распределение вероятности встречаемых символов. Это
поможет отбросить часть вариантов, как заведомо ложные или (что более
правильно) начать перебор с наиболее вероятных ключей к менее вероятным.
Вышесказанное звучит захватывающе, однако так и не подсказывает где нам
взять хотя бы 64+1 битовую последовательность для атаки по открытому
тексту. Ассемблерских команд такой длины и даже устойчивых их сочетаний не
существует. Но так уж в самом деле не существует ли? Может плохо искали?
Например, все языки высокого уровня используют стандартные
библиотеки, сингатуры которых известны, а число пренебрежительно мало (по
сравнению с числом возможных ключей, разумеется). Это применимо далеко не к
каждой программе, но к значительному их числу.
Допустим, автор защиты это учел и использовал неизвестный доселе
компилятор или полностью реализовал весь код на ассемблере и отважился
выбрать ну очень длинный ключ, настолько длинный, что даже не будем
уточнять какой точно. Восторжествует ли он на этот раз? Увы (или ура - в
зависимости от ориентации читателя). Злоумышленник применил масочную атаку!
Суть ее сводится к следующему, да пусть нам не известно сколь-нибудь
длинной стоки из зашифрованного текста, но мы наверняка знаем много
коротких! И при этом с некоторой достоверностью известно расстояние L между
ними.
Алгоритм атаки следующий - пусть s0 одна из существующий в шифротекст
последовательностей. Применим атаку по открытому тексту и в результате
получим ОГРОМНОЕ множество подходящих, но ложных ключей. Что ни один из не
верен это ясно из того, что длина каждого равна #s0. По условию s0 короче
пароля, следовательно ни один ключ не является законченным паролем. Однако,
ясно, что настоящий пароль включает в себя некоторые элементы полученного
множества. Возьмем другую известную последовательность s1 и повторим
аналогичную операцию. Теперь выберем общие для f(s0) и для f(s1)
элементы. Вероятнее всего, что именно из них и составлен пароль. С каждой
интерацией число символов, общее для всех последовательностей стремительно
уменьшается а вместе с ним и число вероятных паролей. Когда все
последовательности исчерпаны, выберем только те, которые разнесены в
границах предполагаемого расстояния (если такая информация имеется).
Существует множество вариантов получения пароля из заданного множества
фрагментов, однако нет нужны перебирать их все. Я доставлю читателю
удовольствие самому решить несложную задачку уменьшения числа возможных
вариантов. Привычка получать все в готовом виде в самом деле очень вредна.
А для хакера более того в корне неприемлема! В моем понимании хакер - это
человек который в любой ситуации привык рассчитывать только на себя.
Готовые технологии и знания это непозволительная роскошь.
Однако наводящую подсказочку я все же дам. Пусть нам неизвестна
никакая вероятность всех встречаемых в шифротексте символов, но для
аждой последовательности Sn, вероятность образующих ее элементов
звестна наверняка!
Как ломать crackMe03 (фрагмент книги)
При атаке на шифр считается, что криптоалгоритм известен с точностью до
реализации, и требуется найти пароль. В качестве примера к этому
рассмотрим программу crackme0.com (file://CD:/SRC/Crackme.com).
Алгоритм расшифровки ничем не защищен и его легко можно изучить. Однако,
это нам не дает никакой информации об исходном пароле.
CalcCRC: ; <--------------------------------¬
LODSB ; Читаем байт введенного пароля ¦
ADD AH,AL ; Суммируем ¦
LOOP CalcCRC ; --{CX}----------------------------
Эта процедура вычисляет CRC с введенного пароля. CRC очень простой и с
плохим рассеиванием. Множество паролей будет иметь одно и то же CRC,
поэтому нет никакой возможности предсказать на основе всего восьми-битного
числа исходный пароль.
LEA SI,Crypt ; На начало зашифрованных данных
Decrypt: ; <--------------------------------¬
XOR [SI],AH ; Расшифровать байт ¦
INC SI ; Следующий байт ¦
CMP SI,offset Buffer; ?Мы уже все расшифровали ¦
JB Decrypt ; --{SI
Шифротекст расшифровывается значением контрольной сумы от пароля!
Причем всего может существовать 0x100 (256) вариантов расшифровки! Нетрудно
было бы перебрать их всех найти исходный. Даже если бы использовалось слово
(0x1000) то вариантов было бы все равно не много!
Между прочим, это довольно распространенный примем в некоммерческих
программах. Удивительно, как это не учитывают авторы защит! Если
перебирать не пароли, а ключи (т.е. сами хеш-значения), то можно достичь
скорость порядка нескольких сотен ключей тысяч ключей в секунду. Таким
образом не спасет даже использование двойного слова (0x100000000). Оценим
наихудшее время, необходимое для перебора тридцати-двух битного ключа.
Исходя из средней скорости сто тысяч ключей в секунду, мы найдем результат
не более чем за 167 секунд, или приблизительно три минуты. Практически
мгновенно, не так ли? Все дело в высокой скорости перебора ключей,
обусловленной простотой алгоритма.
Автоматического перебор ключей опирается на возможность контроля
идентичности расшифрованного текста и оригинального. Программа, очевидно,
должна была контролировать правильность ввода пользователя и подсчитывать
CRC либо пароля, либо расшифрованного текста. Рассмотрим следующих код:
CmpCRC: ; <--------------------------------¬
DEC SI ; Следующий байт ¦
ADD CL,[SI] ; Суммировать ¦
CMP SI,offset Crypt ; ?Конец ¦
JNB CmpCRC ; --{SI>offset Crypt}---------------
CMP CL,0C3h ; ?Значение CRC верно
JZ Crypt ; --CRC OK-->
; СRC FAIL
Очевидно проверяется контрольная сумма исходного текста. Мы можем
исследовать хеш-алгоритм и хеш-сумму исходного текста. В нашем случае она
равна 0xC3.
Однако, сколько существует неправильных вариантов расшифровки, при
которых тем не менее их контрольные суммы совпадают? Очевидно, что больше
одного! И с ростом числа вариантов расшифровки количество "ложных" ключей
стремительно растет! Так, уже при 32-битных ключах основную проблему будет
представлять не поиск подходящий ключей, а выборка единственного верного
исходного текста, среди расшифрованных вариантов! При этом у нас никаких
достаточно строгих критериев по которым можно было бы автоматически
отличить ложные варианты. Разработчик защиты добился-таки своего!
Вероятностью, что пользователь введет неправильный, но подходящий пароль,
достаточно мала, что бы ей было можно пренебречь. Действительно,
предположим, что хотя бы 1% паролей будет давать ложные срабатывания, тогда
для 0x10000 (65536) ключей это составит 655 вариантов, а для 0x10000 уже
42.949.672! Обратим внимание, что с точки зрения криптографии все эти
варианты равноценны!
Разумеется, мы в любом случае имеем хотя бы косвенное представление об
исходном тексте. Но как его использовать? Можно по типу данных
предугадать вероятность того или иного символа, проверить на совпадение со
словарем, поискать некоторые закономерности... Но как же все это будет
медленно работать! И в любом случае (особенно на коротких фрагментов) нет
никакой гарантии, что даже самый надежный алгоритм всегда распознает
исходный текст.
Разработчики защиты могут торжествовать! Они заставили хакера
призадуматься. Хакеры же пошли другим путем. Криптографам был давно
известен метод атаки по открытому тексту. В самом деле, если злоумышленник
обладает хотя бы частью открытого текста, то он может сделать обратную
шифрованию операцию и найти колюч! Вспомним свойство операции xor:
X xor Key = Y, Y xor Key = X, но X xor Y = Key!
В нашем примере с восьмибитным ключом достаточно достоверно знать всего
лишь один байт открытого текста, что бы получить Key, который можно
применить ко всему шифротексту в целом. Но откуда же можем знать какой-то
байт чужого текста да еще и достоверно? Оказывается, можем, да еще как!
Конечно, не достоверно, но с определенной степенью вероятности мы можем
ПРЕДПОЛОЖИТЬ его наличие!
Весьма вероятно, что в приведенном шифротексте встретиться инструкция
INT 0x21. Ее двух-байтовый опкод 0x21CD (мы ведь помним про обратный
порядок байт в слове?) превышает длину ключа, а значит делает его на этом
промежутке неслучайным. В самом деле в уравнении X xor Y = key мы не знаем
ни X, ни key, при выбранном Y они могут быть любыми. Если #Y > #Key, то мы
получим X1 xor Y1 == X2 xor Y2 == key!
Может это объяснение покажется туманным, поэтому давайте приведем
практический урок, который поможет это усвоить. С помощью утилиты hiew
попробуем расшифровать секретный фрагмент применяя операцию XOR 0x21CD.
--------------¬
¦ рисунок 4 ¦
L--------------
00000030: C3 74 08 B4-09 BA BE 01-CD 21 C3 B0-B5 E4 BB A9
00000040: 00 20_20 2E-0C E7 51 8C-72 9E 76 82-73 89 21 A2
00000050: 4A CC^01 E7-25 7D 01 CD-21 CD 00 00-00 00 00 00
00000060: 00 00¦00 00-00 00 00 00-00 00 00 00-00 00 00 00
¦
Обратим внимание на последовательность 0x2020. С большой вероятностью в
оригинальном тексте здесь находилось 0x21CD, зашифрованное ключом 0x20!
Следует учитывать, что данный метод допускает ложные срабатывания. Поэтому
предпочтительнее использовать по возможности более длинные
последовательности. В этом случае мы получили только один возможный ключ, а
что бы мы стали делать если бы их оказалось несколько? Если мы знаем
частоту появления выбранной последовательности (а именно такие и стоит
выбирать), то мы можем определить истинный ключ простым сравнением! Однако,
допустим, два или более ключей имеют очень близкую к ожидаемой вероятность
появления. Как быть тогда? В этом случае необходимо попробовать поискать
другую последовательность, ожидаемую в шифротекст. В нашем примере это
может быть 0xA0D - перенос стоки. Весьма вероятно, что пример выводит
какую-то строку, которая вероятно завершается возвратом каретки. Оставим
читателю провести этот эксперимент самостоятельно, а сами обратим внимание
на следующий момент - в самом деле редкая программа обходится без вывода
текстовых сообщений. Но ведь в любом языке не так уж много слов, а тем
более распространенных! Это очень уязвимое место подобных систем. В самом
деле даже не потребуется утомительно перебора. Поищем такие стоки, как ©,
Copyright, OK, Cancel, Yes, No... Хорошо действует двойной пробел, пробел+
запятая и т.д.
Кроме того, не забываем, что CRC исходного текста нам известен,
следовательно можно быстро определить какой ключ из нескольких -
правильный. Я не буду приводить расчетов вероятности появление ложных
паролей скажу только, что при использовании последовательностей из двух и
более символов она уже достаточно невелика. Таким образом криптостойкость
данного шифра при атаке по открытому тексту (даже не зная точного
расположения последнего) равна нулю!
В данном примере использовался ключ 0x20. Внешне этот ключ абсолютно
ничем не примечателен, но взгляните за зашифрованный фрагмент:
----------------------¬
¦ ¦
¦ рисунок 5 ¦
L----------------------
И это ЗАШИФРОВАННЫЙ текст? Как же такое могло произойти? Магическое
свойство xor 0x20 переводить английский текст в противоположный регистр
сыграло с автором защиты очень злую шутку. У каждого алгоритма есть
некоторые число СЛАБЫХ паролей, которые в разной степени снижают его
криптостойкость. Об этом мы говорили выше. А теперь если вспомнить, что
0x20 - 100000b, то нетрудно убедиться, что такой ключ меняет всего один бит
на каждый байт! Т.е. шифротекст будет мало чем отличаться от исходного.
Хорошие криптосистемы делают проверку на слабые ключи, плохие - нет.
Учитывая, что число слабых ключей у иных шифров не так мало, как это
кажется на первый взгляд, с вероятностью использования такого ключа стоит
считаться.
ORC
¦ От переводчика.Это очень неплохое руководство местами содержит неточности
¦ которые я "осмелился" исправить. Так же некотореы вопросы я отваживаюсь
¦ углубить для более ясного понимания материала. Все ругательные обороты
¦ невозможно достоверно воспроизвести в силу разницы культур и языков,
¦ поэтому в ущерб точности я постарался передать сам дух автора.
L= 12-02-99 = 23:04:07 =
HOW TO CRACK, by +ORC, A TUTORIAL
=================================
[УРОК 1: ВВЕДЕНИЕ] [PoolDemo.exe]
"""""""""""""""""" """"""""""""""
Лучший путь для изучения кракинга (т.е. прекрасно понять, точно
определить и изганть (приостановить, отодвинуть) одну или больше схем
защиты внутри программного обеспечения без наличия исходных текстов)
начать самостоятельные хакерские эксперементы, используя СТАРЫЕ приложения,
которые имеют СТАРЫЕ системы защиты.
В этом случае вы быстро усвоите основую технику хакерской професси. Не
забывайте, что развите систем защиты шло не единственным путем... строго
говоря это даже не было развитием: вы неприменно обнапужите много новых
"умных" трайков {от trick - хитрость, трюк. Здесь и дальше в фигурных
скобках примечания переводчика}, но большее время придется откапывать
только избитые подражания прошлым (и хорошо изученным) идеям. Это не
удивительно: НАСТОЯЩИЕ знания "коммерческих" программистов (называющие сами
себя "протекционистами" {игра слов -"protectionists" это и сторонник
протекционизма и "защитник" программ} очень часто ограничены: онм склонны
использовать старые методы (иногда немного измененные, временами даже
усовершенстованные) взамен разработки новых технологий. Это типичная
"коммерческая" дегенерация, случающаяся с всякий раз с людьми,
работающими ради денег, вместо творения ради самого процесса или для
своего удовольствия. Эта "коммерческая" мода безрасудно возноситься
дурацким, бакс-ореенитрованным обществом, в котором мы вынуждены жить.
Поэтому я начинаю "настольную" часть (начинающуюся с урока 3),
использующу для примера немного "старых" приложений и немного "старых"
защит. Позднее мы сможем переключиться на новейшие защиты с целью понять
их. И вы научитесь как обламывать и этот вид гадости то же. Я так же
объясню ГДЕ вы сможете найти кучу программ для лома и сохранения
своих денег и КАК вы должны приступать к работе.
Это учебник для начинающих кракеров. Быть может просто раздумывающих
"а не захачить ли мне что-нибудь" или уже имевших попытки с переменным
результатом. Я не могу обещать, что вы получите что хотите, но я буду
стараться изо всех сил. С другой стороны, если вы уже вырубали немного
работающего кода на ассемблере и уже вскрывали много различных защит, тогда
этот туторал вероятно покажется элементарным для вас. (Если вы хотите
освежить основы, и не имеете более занимательного объекта време
препровождения, можете оставаться).
Для успешного взлома вам потребуется следующие основыне понятия:
v хорошее знания языка ассемблера (чем больше вы заете, тем лучше и
быстрее ломаете)
v Чуть-чуть интуиции
v Немного помощи более опытных кракерв { например, моей :) }
Приложения, что вы будете использовать для обучения могут быть поделены на
категории:
v изувеченные паролем (простейшие для взлома)
v изувеченные счетчиком дней или запусков (доволько простые для взлома)
v приложения, ограниченные датой исполозования (простые для взлома)
v приложения с некоторыми заблокированными функциями ( иногда простые
иной раз сложные)
v защищенные Дисковым доступом (которые сейчас считают устаревшими)
v привязанные к CD-ROМУ (очень простые для взлома)
v КРИПТОГРАФИЧЕСКИЕ (т.е. вариации из вышеупомянутых защит, но с добавкой
самомодифицирующегося кода (XOR & SHL) (довольно просты для взлома)
v ни какая из вышеперечисленных. (часто тяжелы для взлома)
ГДЕ ПОИМЕТЬ STUFF]
""""""""""""""""""
Получившие широкое распростанение "DEMO" сидиромки настоящая
сокровищница для кракера! {У нас такие то же есть. Например "Российский
СОФТ 97" - целый сидюк демок и дешево} Немного погодя после их выпуска вы
получите все оставшиеся копии, что остались непроданными практически
бесплатно {увы но не у НАС. Рынок, еще мать его...} Демонстационные CR-ROМы
позволяют вам хапунть сразу кучу приложений (старых и новых), что часто
каким-либо методом покуверканы (иногда интересными методами). Действительно
чудесный простор возможностей для кракеров! Гы! Нахаляву мы можете поиметь
целый диск до отказа набитый LOTUS {це фирма такая} приложениями (или M$
или WordPrefect) на "триал в течении 30 дней" или "20 запусков" редакций.
Вы действительно насладитесь взламывая их, используя каждое и каждого и\или
снисходительно-благосклонно поместите их на web для бедных ламеров, что не
имеют ни $$$ ни мозгов.
ИГРЫ определенно не будут больше выпендриваться! Они очень интересны
для будующих кракеров, т.к. часто "перезащищены" Я имею ввиду, что они
имеют защитные схемы действительно ОЧЕНЬ высокого уровня, скрытые внутри
файлов, которые относительно малы. Теперь, смотрите, это намного проще и
легче захачить и поскипать защитную схему внутри одинокого 35.000-байтного
исполняемого файла, чем локализовать ее внутри сборища множества длинных
DDLей, которые раздуты до 2.000.000 байт каждый. Ленивая куча
"современных" программистов, систематически релизяцих защитные схемы на
этой "скрытой желчи в недрах десерта" логике. Фактически они больше не
способны программировать на ассемблере: они больше и больше опираются на
"толстых" монстров яка Выжел Бацик, Делфы или Visual C++ {ну MS VC на мой
взгляд не плохой полигон. Тем паче, что можно кодить и без MFC} (Не
беспокойтесь... Я все же научу как быстро ломать эти огромные приложения)
Другой причиной выбора "рабочим материалом" игр, взамен приложениям
является часто ТОЧНО ТА ЖЕ защитная схема, которую вы можете
обнаружить во многих простых (и компактных) шаровых игр, позднее была
использована для "защиты" многих "могучих" и крайне экспенсивных
графических приложений.
По этой причине в моем туторале мы будем часто вскрывать защищенные
игрушки, даже если мы позднее применим эти знания в основном к коммерческим
схемам защиты или краку защит доступа к удаленным серверам (BBS или даже
ATM) {ATM вряд-ли, т.к. АвтоматическихТорговыхМашин у нас еще нету. Мож в
Москве и есть уже - не знаю, но считаем что нету}
Давайте теперь вместе взломаем как вступительный пример "time-protect"
защиту. Мы изучим позднее (-> Урок 4) что все приложения, что "взведены" на
время (т.е. "как много раз" вы используете их или "как долго") базируются
на сходных принципах (иногда с огромным числом вариаций по этому поводу)
v они могут иметь счетчик с "кликми" : НАЙДИТЕ ИХ и ВЫРУБИТЕ ИХ
v они могут вызывать таймерный прерывания : ПЕРЕХВАТИТЕ ИХ САМИ
v что-то-там сравнивать с переменной : NOOPим ИХ
v проверять дату ваших файлов на диске : НАЙДИТЕ СРАВНЕНИЕ и JMP!
Я хочу начать с современным примером защиты "счетчика кликов", просто дать
вас почуствовать крак, и я выбрал широко распростаненную дему: вы должны
найти ее сравнительно легко. С целью показать некоторые, подстерегающие нас
проблеммы мы сломаем для примера "неверно" (вы научитесь как ломать
эффективно в "настольных" уроках).
ПРИМЕР: [ARCADE POOL]
"""""""""""""""""""""
Демонстрационная версия для PC by East Point Software Ltd, © Team 17
Software Ltd 1994. Эта дема была опубликована многими журналами на их
сидюках в 1995 году {и где же сейчас ее искать?}
Эта прекрасный бильярд имеет "time" узуверки. Вы можете играть только 2
минуты, после чего "nag"-разражатель напомнит где и почем вы сие творение
можете купить {малось ругательств поскипна без извращения сути}
Ну, что бум делать? Здесь вы можете сделать (но необязательно должны):
взть [Soft-Ice] и загрузить его в ваш config.sys (Как сие сделать вам
раскажет "Инструменты нашей професси" и аналогичное "Инструменты, которые
мы вибираем by KPNC") Версия 2.6 Софт-Айса была взломана MARQUIS DE SOIREE
и легко может быть найдена на Web {или www.dore.da.ru - там лежит soft-ice
2.8 - последний из серии для DOS}
v сохраним все вектора перед загрузкой нашей малышки
v пшла, залетная! ldr pooldemo.exe
v сравним вектора и распечатаем перехваченные
v {...скипнуто, как длинное и не существенное...}
v рассмотрим карту памяти
v теперь дампим, занятую PoolDemo память на диск
v секуду-другую ничего не делаем
v дампим память еще раз
!IDA DEBUGER!
А вы пользуетесь отладчиком IDA? Нет? А зря. Очень рульная штука. И
удобная. К тому же мощная!
Идея пришла неожиданно. У нас же есть готовая интерактивная среда и
встроенный язык плюс дешифратор команд! Написать эмулятор только особо
ленивый не сможет. Конечно, встроенного языка в версии 3.6 не хватит даже
для игрушки, поэтому нам нужны более поздние версии. Там можно на Си
написать DLL и подключить. Скорость будет обеспечена. Курсор перемещать мы
может, горячие клавиши можно реализовать через макосы (вызовы новых функций
с консоли).
В чем новизна и удобство идеи? А в том, что можно сделать не полный,
а _контекстный_ отладчик! Что это такое? Обычный дебарег отлаживает всю
программу целиком. Это хорошо, но чаще всего нас интересуют только
выбранные фрагменты. В IDA можно подогнать курсор к нужному месту, задать
начальные значения регистров и пусть на выполнение эмулятор. Такой подход
прежде всего упорщает задачу, т.к. тут скорость не трубуется. А как удобно!
Можно видеть работу кода в динамике! И не ломать голову какие будут
значения регистров\флагов на выходе из такого и такого фрагмента и куда
метнеться условный переход. Можно просто прогнать чисто локальный кусок с
любой его точки.
Это сразу легко позволит делать расшифрвку - подводим курос - пошли
его расшифровывать. Причем можно автоматически анализирвать расшифрованный
код, что бы все выглядело цивильно! И бряк-поинты можно организовать!
Обычно IDA и ICE используются в связке ради уточнения некотрых
мелочей. Когда неясно как работает данный код и что он делает - загружае
ICE (можно прямо из IDA) и смотрим. Потом опять в IDA и продолжить поиски.
Так вот, удобнее было бы никуда не метаться, а прямо в IDA все это и
дебагить.
Реализовать это все просто. Осталость найти время. Или заинтересовать
людей и всем миром - каждый со своей локальной задачей - это решить! Идей
есть - это главное.
Поділитися у соцмережах
