По мотивам #ozohht

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

Очевидно, что несостоятельность подобного подхода была доказана сразу же, когда толпы кулхацкеров, вооруженные сочинениями своих более зрелых собратьев на тему "как быстро поставить брейкпойнт на MessageBox и пропатчить джамп, ничего не зная об ассемблере", кинулись отбирать кровно заработанные деньги у авторов. Но даже сейчас можно встретить наивных любителей изобретать велосипеды, не слышавших слова дизассемблер, и считающих, что их минет чаша сия. Иногда они задерживались надолго даже в крупных конторах — j3qq4-h7h2v, евпочя.

Такая ситуация, конечно, пришлась разработчикам не по нраву, и они на время закрылись в своих лабораториях, родив очередное гениальное решение — привязку к железу. Казалось бы — отличное решение: программа генерирует на базе неких параметров пользовательского компьютера ключ, из которого девелопер генерирует серийный номер. Все довольны, ведь теперь Вася не сможет передать свой номер Пете — для него он будет бесполезен. Но и тут свою роль сыграла природная лень большинства авторов прикладного софта — они не хотели глубоко копаться в этих страшных непонятных системных штуках, и выбирали для привязки наиболее доступные их пониманию параметры. Чаще всего таковыми становились дата bios (не вздумай обновить прошивку, юзер!); серийный номер раздела жесткого диска (что?! после форматирования он меняется?! мы не зна-а-али); объем памяти, размер диска (ведь вам не нужно так уж часто делать апгрейд, правда?).

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

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

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

Тут разработчики наконец-то подошли к осознанию Первой Важной Истины — "не стоит усложнять взаимодействие пользователя и защиты, это тупиковый путь; нужно затруднить понимание работы защитного механизма взломщиком". А что для этого нужно сделать? Правильно, как-то зашифровать код. И тысячи обезьянок принялись думать...

Но даже здесь ленивые прикладники решили схалтурить. "Шифрование? это ведь так сложно, нужно понимать, как работает загрузчик, во что превращает код компилятор"... И воспользовались они тем, что уже было создано немного для других целей — упаковщиками исполняемых файлов. Брали они какой-то мейнстримовый upx, паковали им программу, и считали дело сделанным — хацкер открывал файл в дизассемблере, не находил их код, разводил руками и уходил ни с чем.

Идиллия закончилась быстро. Однажды кто-то из хацкеров, придя из школы, случайно набрал upx /?, и научился распаковывать их программы совсем без усилий. Такова печальная судьба ленивых.

Но копирасты не сдавались, и начали запиливать специализированные пакеры без встроенной функции распаковки, одним из самых популярных на просторах снг стал aspack. И тогда старшее поколение хацкеров, еще не забывших, что такое ассемблер, придумали новое секретное оружие — дамперы. Программа запускалась, распаковывала себя в памяти, и тут же дампер ловил ее и сохранял рабочий образ на диск.

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

Развитие защитных механизмов пошло в двух направлениях — противодействие статическому и динамическому анализу.

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

А вторые были нацелены против тех хацкеров, которые умели ставить брейкпойнты в отладчике, находили oep и дампили расшифрованную программу на диск, не парясь по поводу анти-статических механизмов. И заполнились все тематические форумы описаниями "анти-анти-анти-антиотладочных приемов". Чего только не придумывали — и контроль времени выполнения по rdtsc, и попытки вводить отладчик в ступор киданиями эксепшнов, игрой с флагом трассировки... Но на каждый хитрый прием всегда находился "анти-прием с винтом".

А тем временем антистатические механизмы тоже не стояли на месте — начались робкие попытки впиливания виртуальной машины в код протектора; все чаще и чаще звучало на тематических конференциях страшное слово "обфускация". Копаться в таком мало кому нравилось, потому это осталось уделом единиц энтузиастов; остальные же бросили все усилия на динамический анализ.

Уловив этот тренд, разработчики защит сфокусировали внимание на противодействии дамперам. Сначала придумали просто стирать из памяти данные, нужные для загрузки программы, но уже не нужные на этапе выполнения — секцию импортов, например; хацкеры ответили на это простой в своей гениальности софтиной под названием IMPort REConstructor. Копирасты начали расшифровывать код кусками, храня одномоментно в памяти лишь часть программы, чтобы сдампить ее целиком было нельзя — хацкеры научились отлавливать эти куски и дампить по частям...

Это было "золотым веком" защитных систем. Asprotect, невероятно популярный на территории снг; armadillo, дырка в ключевом алгоритме которого долгое время была известна только одной команде; execryptor, в котором впервые была реализована действительно оригинальная и качественная виртуальная машина и которым пугали детей...

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

Так вот, к чему я все это написал. После прочтения указанной в верхушке поста статьи я задумался о будущем программирования. Уже сейчас код, грамотно накрытый тем же vmprotect, например, автоматически проанализировать практически невозможно, как бы нас в этом ни пытались убедить разработчики антивирусов. Да и ручной анализ на поток поставить совсем не просто. И с каждым годом эта тенденция усиливается.

К чему это приведет в итоге? Во-первых практически исчезнет reverse engineering, как явление. С ним исчезнет куча возможностей — нельзя будет проводить аудит кода, проверять его на наличие бекдоров, писать швабодные реализации для разных проприетарных штук, жизнь антивирусов невероятно усложнится etc. Во-вторых бОльшая часть ресурсов компьютера будет расходоваться вхолостую на работу этих защитных механизмов. Попробуйте представить себе фаерфокс, помещенный в обфусцированную виртуальную машину типа вмпротектовской. Мне страшно, а вам?

#otzfng

25 comments recommend bookmark subscribe