Информационная безопасность

       

Граничные условия, вход/выход, etc.


Будем считать, что с UseCase разобрались. Теперь немного архитектурных решений. Для начала - о том, что у нас есть или что считать входными данными.

Итак, есть исполняемый файл для Windows, написанный на C++/MFC (предположительно - в формате PE). Если он был сжат/закодирован, будем считать, что эта часть проблемы уже решена: сжатие/кодировка - это отдельная тема, для которой имеется свой инструментарий, а в Сети существуют даже специализированные ресурсы по этому вопросу.

Для того чтобы разговор был предметным, возьмем очень известную в Сети программу (условно назовем ее СБ). Эта программа известна всем, кто пытался получить деньги за серфинг. Причин для такого выбора несколько: во-первых, она представляет собой хороший пример "кристально чистого" кода MFC без каких-либо методов шифрования самого кода. С другой стороны - это весьма интересный freeware-код для взлома, (по вполне понятным причинам коммерческие программы мы с вами ломать не станем).

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

Интерес тут другого рода: программисты выложили в сеть программу для получения легких денег - и вполне естественно, что все киберпанки тут же бросились ломать клиентскую часть с целью получения незаконных прибылей. Также понятно, что в программу встроена тысяча и одна защита от таких взломов. Иными словами СБ - это пример открытого и честного противостояния: группа кодеров vs. Большая Сеть, причем противостояние это длится аж с 1999 года, что уже само по себе факт примечательный.

Итак, есть наша программа - СБ.exe. Пропускаем ее через IDA и получаем огромный листинг СБ.asm. То, что перед нами C++/MFC, вне сомнений; но пока мы видим просто текст на ассемблере, причем размер его составляет около 30Мб.
Работать с ним неудобно, а некоторые текстовые редакторы вообще виснут (тот же F4 в Far, например). Кроме того, нам видно много лишних деталей: технические комментарии, код пролога и эпилога функций, передача параметров по push и т.д. Короче говоря, полученный текст приблизительно в 10-20 раз длиннее, чем нам нужно для понимания и реставрации алгоритмов программы.

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

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


Содержание раздела