|
Страница 1 из 3
Доступность метаданных вплоть до вашего кода (конечно это MSIL, но более читабельный чем ассемблерный код) в продуктах .Net стала головной болью для разработчиков коммерческих продуктов и технологий для .Net. Как защитить код от излишне любопытной публики, как защитить продукт как интеллектуальную собственность (если можно легко декомпилировать в понятный код, значит можно снять защиту от несанкционированного использования, да еще собрать в работающую сборку)?
Вот тут на помощь приходит обфускация.
Результат.
Вот пример исходного метода (перед обфускацией):
private void CalcPayroll(SpecialList employeeGroup)
{
while(employeeGroup.HasMore())
{
employee = employeeGroup.GetNext(true);
employee.UpdateSalary(); DistributeCheck(employee);
}
}
А вот результат (после):
private void _1(_1 _2)
{
while(_2._1())
{
_1 = _2._1(true);
_1._1();
_1(_1);
}
}
Попробуйте поймите смысл алгоритма после обфускации. На это уйдет время – надо узнать, что за классы принимают участие, попробовать понять их назначение, в общем предстоит большой труд.
В этом задача обфускации – затруднить для понимания исходный код, запутать и устранить логические связи в коде.
Что делает обфускатор:
Анализирует метаданные, так как не все члены сборки он может обфусцировать. Например обфускатору не стоит заменять имена конструкторов типа – это может быть чревато. Хотя в некоторых случаях это бывает возможно. Также иногда невозможна обфускация виртуальных или абстрактных методов.
Список членов сборки для обфускации готов. Обфускатор присваивает им новые имена, базируясь на определенном алгоритме. Одни обфускаторы присваивают имена такой же длины что и были но лишенные прежнего смысла, другие базируются на нумерации всех членов и обфусцируют тх соответствии номеру члена сборки, третьи – базируясь на токен (token) члена сборки – уникальный идентификатор члена сборки в MSIL, четвертые стараются минимизировать длину имени и почаще использовать одно и то же имя среди членов сборки (в dotfuscator это называется overload induction)– это дает максимальный эффект обфускации (представьте себе что у вашего класса все методы и поля названы как «1»). После этого производится запись данных обратно в сборку или генерация новой сборки – все это в руках авторов обфускаторов, ее оптимизация – так как многие из обфускаторов способны удалить ненужную информацию из сборки (дебаг-информация, неиспользуемые методы, поля, классы). Вуа-ля – сборка готова. Фактически сборка после обфускации отличается от исходной одной деталью – модифицированным разделом строк (String Heap или #Strings)– одним из пяти разделов метаданных, это итог символьной обфускации, когда обфускатор не модифицирует тела методов. Может быть модифицирован еще один раздел (User Strings или #US) – но пока не встречал таких обфускаторов. Если интересно, могу как-нибудь рассказать о структуре метаданных и PE-файла в .Net сборках. Открываем в ildasm или Reflector или в другом навигаторе по сборкам и оцениваем результат. Некоторые обфускаторы имеют дополнительные фичи: запутывание namespaces (изменение принадлежности различных классов определенным namespace), шифрование строковых и графических ресурсов, контроль обфускации на базе специальных атрибутов, которыми помечаются члены классов в исходном коде, некоторые стараются заигрывать с MSIL-кодом методов сборки. Наука не дремлет, изыскивая новые возможности вам помочь и предложить немного больше чем предлагают (или предполагают :) ) конкуренты. |