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

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


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

CRACKL@B CrackMe #3 - абсолютная защита. Гарантия - 2.5 дня

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

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

Автор: terl0g <terl0g@tut.by>

Содержание

[1] Исследование CRACKL@B CrackMe #3
[2] Bruteforce challenge
[3] Реальные приложения
[4] Благодарности
[5] Литература

Введение

Многие программисты, не специализирующиеся на вопросах защиты информации, ошибочно полагают, что использовать криптографические алгоритмы очень легко - достаточно взять готовый модуль, вызвать пару-тройку функций, и работа сделана. На самом деле это не так - существует много нюансов, без учета которых даже при использовании гарантированно стойких алгоритмов результат получается прямо противоположным (интересующимся данной тематикой могу посоветовать отличные работы [1] и [2]). За примерами далеко ходить не приходится. Статья "CRACKL@B CrackMe #3 или четырехзначный пароль - абсолютная защита" [3] заинтересовала меня тем, что, как правило, профессионалы в области защиты информации крайне редко используют эпитеты "абсолютный" и "невозможный" (каждое такое утверждение требует строгого доказательства), и мои опасения оказались оправданными. Несмотря на то, что ее автор привел пример неверного использования алгоритма хэширования в системе защиты ПО, в предложенном crackme он, в свою очередь, сам допустил несколько серьезных ошибок. В данной статье я рассмотрю эти ошибки и опишу методику, позволившуя подобрать регистрационный код соответствующего crackme менее чем за 2.5 дня вместо обещанных его автором 80 - 171 суток. Чтобы не загромождать данный текст ненужными цитатами, я рекомендую читателям предварительно ознакомиться с [3].

1) Исследование CRACKL@B CrackMe #3

В данном параграфе я буду говорить только об ошибках конкретной реализации (а именно, CRACKL@B CrackMe #3), мое IMHO о данном методе защиты ПО вообще будет приведено в параграфе 3. Думаю, очевидно, что единственным методом получения регистрационного кода данного crackme за более или менее разумное время является метод грубой силы (bruteforce), примененный к "процедуре генерации пароля" (в терминологии [3]). Поэтому в дальнейшем я буду рассматривать только следующий фрагмент псевдокода, эквивалентый коду данного crackme:
 01:check_key(string key)
 02:{
 03:   for (i = 0;i < 30001;i = i + 1)
 04:   {
 05:         key = md5digesttostr(md5string(key));
 06:   }
 07:   if (substr(key, 1, 6) == "C948E0")
 08:   {
 09:         //код верный, расшифровываем и демонстрируем картинку
 10:   }
 11:   else
 12:   {
 13:         //код неверен
 14:   }
 15:}
 
В этом коде наибольший интерес представляет цикл (03) - (06), предназначенный для увеличения времени проверки ключа за счет многократного рекуррентного применения алгоритма хэширования RSA MD5[4], что, собственно, и является "изюминкой" данного crackme. Его автор уверяет нас в том, что:
1) данная процедура работает не менее одной секунды на среднем по быстродействию компьютере;
2) эта реализация является оптимальнейшей.

С (1) я вынужден буду согласиться - исходная реализация действительно работает чуть меньше 1 секунды на компьютере с CPU Pentium III 800 Mhz. А вот (2) дает некоторый повод для сомнений. На самом деле алгоритм RSA MD5 (использованный "для задержки" - bad_guy) разработан для хеширования больших объемов данных и допускает весьма быстродействующую реализацию для 32-битной архитектуры. Чем же обусловлена такая низкая производительность?

В данном случае первая ошибка автора связана с выбором метода работы с хэшем и компилятора. Согласно полученным в процессе оптимизации цикла 03-06 результатам, примерно 90% времени выполнения данного кода занимают...вызовы функций обработки строк стандартной библиотеки Delphi (подсчет длин строк, выделение/освобождение памяти, преобразование значения хэш-кода в hex-представление /в дальнейшем bin2hex/ и т.д.)!

Таким образом, первая (и самая очевидная) оптимизация состоит в переписывании данного кода для работы с буферами фиксированного размера, исключение ненужных операций копирования памяти, и использование быстрых функций для bin2hex-преобразования. Если принять производительность исходной процедуры за 1 pps (passwords per second), то в результате описанного выше преобразования мы получим код с производительностью ~ 28 pps (что снижает обещанное автором время перебора ключей до ~ 6 суток на весьма средней по производительности машине)!

Для дальнейшей оптимизации процедуры перебора ключей требуется знание внутреннего устройства алгоритма MD5 и вмешательство в его исходный текст (адаптация универсального алгоритма к конкретной задаче). Ниже я вкратце опишу основные моменты, требующие внимания:
1) Исходная (reference) реализация (см. [4], на ней основано большинство доступных модулей) предназначена как для big-endian, так и для little-endian архитектур; в рассматриваемом случае возможно оптимизировать код для работы только на машинах little-endian архитектуры (x86), исключив процедуры копирования памяти и перерасположения (reordering) байтов;
2) В целях безопасности алгоритм очищает временные переменные, используемые в процессе хэширования; в данном случае этот код можно просто исключить;
3) Для блоков данных фиксированной длины возможно некоторое сокращение числа выполняемых в процессе хэширования операций;
4) Алгоритм MD5 допускает весьма эффективную реализацию для процессоров x86 (P5+), использующую конвеерную архитектуру обработки и спаривание команд.

Таким образом, в результате выполнения операций (1) - (3) пиковая скорость перебора ключей возросла с 28 до ~ 75 pps, а время полного перебора ключей уменьшилось до ~ 2.5 дней работы одной машины (вынесенных в заголовок данной статьи ;-), пункт (4) не был реализован в силу ненадобности.

Приведу краткое резюме - список ошибок, допущенных в реализации данного crackme (я пишу "ошибки", т.к. IMHO снижение прогнозируемого автором crackme времени взлома более чем в 32 раза только за счет оптимизации алгоритмов свидетельствует именно об ошибках):
1) неверная оценка времени выполнения цикла 03-06;
2) применение алгоритма MD5 для хэширования блоков фиксированной, и, кроме того, малой длины;
3) точное указание количества операций, необходимых для проверки правильности ключа (строка 03);

2) Bruteforce challenge

Этот параграф представляет собой чистой воды беллетристику; при чтении его можно пропустить.

Программа перебора ключей (brute.exe), использованная для взлома данного crackme, была написана на C++ (компилятор MS Visual C++ 6.0) и assembler с использованием оптимизированной описанными выше способами реализации алгоритма MD5 (оптимизация алгоритмов происходила параллельно с перебором, версии программы постоянно менялись). Пространство ключей было разделено на 3608 блоков по 4096 ключей в каждом. При помощи скрипта на PHP был сгенерирован bat-файл объемом 537 KB, последовательно вызывающий brute.exe для каждого блока (фрагмент bat-файла приведен ниже).
 @echo off
 goto %1 
 ...
 :b0022
 echo 0022
 start /b /wait brute.exe 0x003DB000 0x003DC000 c:\bruteforce\22.log
 echo block 22 0x003DB000 0x003DC000 >> c:\bruteforce\global.log
 :b0023
 echo 0023
 start /b /wait brute.exe 0x0066E000 0x0066F000 c:\bruteforce\23.log
 echo block 23 0x0066E000 0x0066F000 >> c:\bruteforce\global.log
 :b0024 
 ...
 
Для перебора паролей были задействованы три машины (PIII-800, Athlon-1800 и Athlon-2000XP); процесс перебора выполнялся с приоритетом idle, т.к. машины достаточно интенсивно использовались для других целей. Перебор занял около 2 суток (главным образом из-за того, что наиболее оптимальная версия программы была написана и установлена только к середине вторых суток перебора, производительность последней версии программы позволяла решить эту задачу за ~ 50 часов работы в фоновом режиме на одной машине); за это время было обработано примерно 80% ключей.
 Итогом работы стал лог-файл следующего содержания ;-)
 S[9197125] 00700000 - 00701000
 P ~ '6zYp' ;-)
 D[9254093] 71 PPS
 

3) Реальные приложения

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

Вопреки мнению автора [3] я затрудняюсь указать область применения описанного метода защиты в реальных приложениях. Дело в том, что при грамотном использовании симметричных алгоритмов шифрования c длиной ключа от 128 бит и выше время, необходимое для подбора ключа, заведомо превышает любые разумные значения не только для крэкеров (даже если они развернут общедоступный bruteforce-проект навроде SETI@Home или distributed.net), но и для серъезных правительственных агентств, таких как NSA. Таким образом, для предотвращения взлома методом грубой силы достаточно использовать серийные / регистрационные номера из множества такой же мощности, как и множество ключей применяемого криптоалгоритма, а не искуственно ограничивать их 4-5 символами, применяя затем какие-либо преобразования. Соответственно, особого смысла в применении методов навроде описанного в [3] IMHO нет.

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

4) Благодарности

1) The Svin (процедура быстрого преобразования числа в hex-представление);
2) Pagan God, p1xel (мощные машины, предоставленные для организации bruteforce).

P.S.

В ходе оптимизации алгоритма MD5 (выполняемой, правда, уже для совершенно других целей) мне удалось повысить производительность подбора ключей для этой задачи еще примерно в 2 - 2.5 раза. Таким образом, заголовок статьи следует читать как "Абсолютная защита. Гарантия - 24 часа" ;-)

5) Литература

[1] Павел Семьянов, Почему криптосистемы ненадежны?
[2] Bruce Schneier, Security Pitfalls in Cryptography
[3] bad_guy, CRACKL@B CrackMe #3 или четырехзначный пароль - абсолютная защита
[4] R. Rivest, RFC 1321 - The MD5 Message-Digest Algorithm

Copyright (c) terl0g, 2004
terl0g@tut.by

Комментарий Bad_guy'я:
Мне стало несколько забавно каким дурачком меня выставляет автор данной статьи, хотя конечно безусловно мной были допущены некоторые небрежности в создании защиты, но принципиальных ошибок всё таки не было. Что касается тех кто пытался взломать данный крэкми - были недовольства по повооду того, что всё таки это нельзя назвать "крэкми", так как только лишь при помощи крэкерского опыта его не взломать - нужен тупой перебор. Отчасти это правда, но ведь terl0g доказал, то что всё таки опыт может многое упростить, а те кто не смогли - значит они пока ещё не доросли...

Обсуждение статьи: CRACKL@B CrackMe #3 - абсолютная защита. Гарантия - 2.5 дня >>>


Комментарии к статье: CRACKL@B CrackMe #3 - абсолютная защита. Гарантия - 2.5 дня

UnKnOwN 09.04.2004 09:21:48
Статья просто супер, меня честно говоря удивила :)
---
atol 09.04.2004 14:19:39
да круто:)
---
MW79 20.04.2004 15:23:16
;) \"Допущены некоторые небрежности в защите\" - это, конечно, понты... ;) Подумаешь - всего лишь в 40 раз уменьшить время перебора ключа. ;)))))))))))
---
Bad_guy 18.05.2004 19:31:26
MW79
Хватит мелочиться !
---
Olexander 26.06.2004 19:21:20
ХочBad_gay - молодец, но статья terl0g\’а вобще супер. Такую не часто встретишь. А Bad_guy ты не обижайся тебя просто немного приземлили
---
fan 04.04.2005 01:31:44
ну, именно некоторые неточности. На самом деле один-два порядка в оценке времени перебора роли не играют, bad_guy указал лишь способ, а дальше можно взять серийник \"с запасом прочности\" на всякие оптимизации и т.д.

P.S.: по крайней мере \"первую\" лицензионную копию нужно будет покупать :) А дальше уже работающую кто-нибудь да расковыряет.
---
nameless 19.04.2005 12:28:28
fan, а смысл? Пошифровать куски кода симметрикой с ключиком на 128 бит, и эффект будет тот же самый.
---
drmist 29.08.2005 13:26:31
Отличная статья.
А идея с кракми мне не понравилась - интересно, как Bad_guy собирается генерировать ключи для нормальных пользователей? Тратить на это 30 лет?
Кракми 3 - очередная демонстрация безграмотного применения криптографии, как средства борьбы с крякерами.
---
ZLOvar 11.05.2010 12:54:39

---

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



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


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