Защитить свой продукт

Продолжим плавно завершать наш разговор о защите коммерческих программных продуктов от несанкционированного доступа. В этот раз коснёмся темы, которую ещё не успели затронуть. Речь пойдёт о защите программных продуктов, которые не скомпилированы в исполняемый файл, а распространяются в виде промежуточного байт-кода или исходных текстов. Таких продуктов достаточно много, поэтому проблема весьма актуальна. В первую очередь, конечно, в защите нуждаются Java и .NET-приложения, байт-код которых достаточно легко поддаётся reverse engineering'у. Но ими этот список не заканчивается, потому что существует большое количество различных скриптовых языков, которые в принципе не допускают трансляции исходного текста в какой-то промежуточный исполняемый код. Это, прежде всего, те языки, которые связаны со Всемирной паутиной, то есть JavaScript, PHP, Perl и т.д. Несколько особняком стоят различные библиотеки для разработчиков, которые, в идеале, тоже должны распространяться в виде исходных кодов. Их защита, пожалуй, вызывает больше всего вопросов. Поскольку категория данного рода продуктов достаточно разношерстна, полагаю, особенно не удивлю, если скажу, что единой методики защиты для всех них не существует. Для части продуктов можно применить метод, называемый обфускацией, ну а для остальных придётся в буквальном смысле изобретать что-то совершенно особенное и, вероятно, не слишком тривиальное. Разработки для разработчиков Для начала немного поговорим о продуктах для разработчиков. Почему немного? Потому что, во-первых, самих таких продуктов не слишком много, а во-вторых, идеальных решений здесь до сих пор не придумано, поэтому и много сказать попросту не получится. Самый распространенный в наши дни способ защиты подобных вещей - это "заворачивание" основного функционала в какую-то защищенную с помощью рассмотренных ранее способов в DLL-библиотеку или что-то подобное. И написание "оберток" для разных языков, чтобы эту библиотеку использовать из приложений, на них разрабатываемых. В общем, схема достаточно проста и, можно сказать, даже в чем-то изящна, но у неё есть ряд недостатков, из-за которых она далеко не всегда применима. Во-первых, кросс-платформенность при таком раскладе обеспечить не всегда возможно в принципе, а о простоте и вовсе приходится забыть. Во-вторых, при прочих равных наверняка разработчики из двух конкурирующих библиотек предпочтут ту, у которой исходный код "открытее". Можно, в случае чего, в нем немного покопаться и "подлатать", что в случае со скомпилированной DLL'кой на практике малореально. Ну а в-третьих, такой подход вовсе не гарантирует невзламываемость продукта, потому что решения для разработчиков, как правило, стоят намного дороже продуктов для массового пользователя, а значит, и резона взламывать их куда больше. Соответственно, и усилий взломщики на это дело не жалеют. Поэтому сегодня достаточно распространена схема, по которой продукты для разработчиков продаются просто в виде исходных кодов, а предварительно предоставляется какая-то демо-версия (например, работающая только при запуске из-под среды разработки). С одной, это возможно благодаря тому, что большая часть разработчиков всё-таки уважают труд своих коллег и жалеют потраченные деньги. С другой стороны, компании или индивидуальные разработчики, продающие коммерческое ПО, всё-таки дорожат своей репутацией, которая может заметно пошатнуться, если выяснится, что достаточно известный разработчик ПО использует в своих продуктах чужой код, полученный на не совсем законных основаниях. Также, поскольку всё-таки продукты для разработчиков достаточно сложны в применении, практикуется продажа поддержки для бесплатных продуктов, но это уже совсем другая модель монетизации ПО, и здесь её обсуждать не будем. Как видно, на рынке библиотек для разработчиков каждый действует так, как посчитает нужным, поэтому, по большому счету, можно больше усилий вкладывать в сам продукт, чем в его защиту. Конечно, рано или поздно взломанная версия любой разработки обязательно появится во Всемирной паутине, но, в отличие от рынка пользовательских приложений, это не должно столь уж катастрофично повлиять на продажи. Обфускация Теперь поговорим про защиту того, что защитить, казалось бы, в принципе нельзя. Если, например, те же PHP-скрипты или браузерные скрипты на JavaScript'е должны продаваться именно в виде высокоуровневого программного кода, то о какой защите в принципе может идти речь? Оказывается, на самом деле всё не так уж и плохо, и защитить от несанкционированного использования можно даже их. Для этого существует такая вещь, как обфускация. Когда-то давным-давно на страницах "Компьютерных вестей" я уже рассказывал о том, что скрывается за этим не слишком благозвучным для уха русскоязычного человека словом. Но это было уже так давно, что напомнить снова будет не просто не лишним, а совершенно необходимым. Обфускация - это процесс, в результате которого код программы приобретает вид, трудный для анализа. То есть, по сути дела, если не вдаваться в подробности, то и те приемы защиты, которые рассматривались в предыдущих статьях, можно отнести к обфускации. Другое дело, что в случае с программным кодом, который исполняется непосредственно операционной системой, никто обычно термин "обфускация" не применяет, а вот по отношению к защите кода для интерпретатора или к виртуальной машине его применяют весьма часто. Интерпретаторы и обфускация Для интерпретируемых языков (тех же PHP или JavaScript'а) обычно обфускация заключается в том, чтобы сделать программный код нечитаемым для человека. Что это означает? Много всего. Например, достаточно часто применяется приём записи всего кода в одну строку, как одного из мероприятий по затруднению его чтения (и, соответственно, модификации). Часто для обфускации меняют имена используемых разработчиками переменных, классов и методов (если, конечно, это возможно). Согласитесь, если вместо "человеческих" названий типа usersCount, accountSettings, docSrc будет записано что-то вроде _____a, iOpndIdfMdJfmn или HackersMustDie1, разобраться в таком скрипте (особенно если он достаточно длинный) будет ой как трудно. Также можно вставлять ничего не значащие комментарии, которые тоже будут затруднять анализ кода. Более серьёзные методы обфускации интерпретируемого кода предполагают рефакторинг с целью разрыва его на ряд вложенных и, на первый взгляд, абсолютно не связанных друг с другом методов, шифрование отдельных участков кода и добавление соответствующих процедур его дешифрования, а также прочие более сложные приёмы, ещё больше затрудняющие работу того, кто возьмётся анализировать текст программы. Стоит отметить, что в случае с интерпретируемым кодом обфускация может преследовать, помимо целей защиты, ещё и задачу его оптимизации, потому что, в отличие от двоичного исполняемого непосредственно процессором кода, защищённый код может в итоге получиться даже более быстрым и "лёгким", чем то, что было изначально. Поэтому сегодня ряд даже бесплатных скриптов предлагается в двух вариантах: обфусцированном и необфусцированном. Сегодня обфускация нередко применяется даже по отношению к коду web-страниц, написанному на HTML'е. Байт-код и обфускация Несколько отдельно от интеретаторов стоит байт-код, используемый в таких известных и популярных в наши дни платформах для разработки, как Java и .Net. В них анализу кода способствуют включаемые в него метаданные, которые, конечно, очень сильно облегчают решение многих задач для разработчиков, но, вместе с тем, представляют собой очень удобную "лазейку" для взломщика. Именно эти метаданные и стараются спрятать при обфускации .NET и Java-приложений. Суть обфускации в данном случае, в общем-то, практически такая же, как и в случае с интерпретируемым кодом. То есть основная задача - запутать взломщика, взявшегося проанализировать и модифицировать программный код после "раскручивания" его метаданных. Методы, которые применяются при такой обфускации, в общем-то, тоже похожи на то, что мы обсудили ранее: замена имён классов, переменных, добавление в код всяких ненужных операций, отвлекающих злоумышленника, и так далее. Само собой, что такое сложное для одного отдельно взятого человека и достаточно трудоёмкое дело, как обфускация, нельзя было не переложить на мощные плечи машины, для которой перелопатить сотню-другую тысяч строк кода - вообще не работа. Поэтому обфускацию сегодня уже никто не делает вручную, используются специально предназначенные для этого программные продукты, называющиеся обфускаторами. Именно обфускаторы, в конечном итоге, и определяют сегодняшний облик среднестатистической защиты среднестатистического программного продукта на каком-то интерпретируемом языке, или на Java, или на .NET'е, с которой борется сегодня такой же среднестатистический взломщик, решивший сэкономить себе и другим энную сумму денег. Обфускаторов на рынке множество, и каждый разработчик сумеет выбрать себе из них что-то, что подойдёт для него и его продукта. А о самых известных и популярных обфускаторах поговорим в следующий раз. Вадим СТАНКЕВИЧ, dreamdrusch@tut.by