И ещё несколько слов о защите разработок...

Дневные мысли о механизмах защиты кода...


Мысли по поводу разных способов защиты конфигураций 1С 8.
Я постарался описать беспристрастно разные методы защиты конфигураций.


Для 1С 8.х (7.7 не рассматриваем как устаревший продукт) есть следующие пути закрытия кода:

  1. Штатными средствами - т.е. поставка без исходных текстов, т.е. скомпилированный . Эта защита являлась действенной (для меня по крайней мере) до тех пор, пока не понадобилось изменить защищенный таким образом код. Взлом защиты в этом случае состоит из двух этапов - получение из базы (структура ее не документирована) необходимых модулей и декомпиляция их. На данный момент существует как минимум две методики получения необходимых модулей. Создание качественного декомпилятора занимает у специалиста (у меня ) неделю. На просторах интернета в свободном доступе можно найти несколько версий декомпилятора. В связи с этим, защита данным методом считается защитой очень слабой. Тем не менее, некоторые разработчики систем защиты (например АЗК http://www.ailant-distribution.ru/goods/protect/ ) считают, что защита действенна.

  2. Портирование кода на другие языки. Надежность защиты в этом случае зависит от возможности восстановления исходных текстов (или логики) и возможности модификации для удаления защиты. С учетом того, что восстановление текста на С++ (например) задача не тривиальная (как минимум для подавляющего числа людей хорошо знакомых с 1С), защиту можно считать надежной. Однако такой же не тривиальной задачей является портирование кода с 1С на С++. Поэтому данный вариант применяется очень редко. Тиражных решений, которые позволяют использовать этот вариант для защиты конфигураций я не знаю (если не считать таким вариантом СЗК).

  3. Вынесение кода внешних обработок (т.е. модулей, которые не являются частью конфигурации, и хранятся в отдельных файлах) в какое-либо зашифрованное хранилище. В этом случае создание объекта такого модуля возможно только при использовании внешней компоненты, которая проверяет возможность работы с таким модулем. Примером такой системы защиты могут служить комплексы СЗК (http://www.1c.ru/news/info.jsp?id=3046), СЛК (ссылку найти не удалось, может кто подскажет?), Интелис: Защита Конфигураций в.1 (http://www.intelis-it.ru/software/intelis/safety.html ). Однако с учетом логики работы 1С с внешними обработками (например, 1С хочет расшифрованный файл на диске как минимум на время создания объекта, ...), есть возможность получить эту обработку как файл и далее взлом защиты сводится к декомпиляции кода (как правило, защищаемые обработки поставляются без исходного текста). Замечу, что такой возможности при использовании системы ИЗК нет — обработка не появляется в расшифрованном виде на диске никогда. С другой стороны наличие файла на диске для взлома подобной защиты и не требуется - подобная система защиты ломается на удивление просто. Правда я не нашел на просторах интернета описания методики, и свою методику тоже не буду описывать. Тем не менее, однозначно что я не один являюсь носителем такого знания.

  4. Исполнение зашифрованных исходных текстов 1С во внешней компоненте. Для этого могут использоваться как собственные компиляторы / интерпретаторы (например, в СЗК), так и особенности 1С (возможность, доступная только при особой интерпретации документации 1С, используется в Интелис: Защита Конфигураций в.1 и в КЗ (http://keyprotect.ru/ )). Надежность данного метода можно считать высокой, т.к. исполняемый текст появляется только в памяти и только на время выполнения этого текста. Недостатком является сложность отладки такого кода и необходимость обработки конфигурации перед созданием поставки. Таким образом, этот метод стоит использовать для защиты текстов запросов и алгоритмов построения текстов, т.е. объемных, но не сложных по структуре алгоритмов, для создания которых наличие отладчика не обязательно. Хотя я и сказал, что "надежность данного метода можно считать высокой", это не совсем так. Точнее это зависит от реализации. Методику применненную в СЗК я особо не исследовал, т.к. не нашел реальных примеров использования. Реализация используемая в КЗ не представляет особых сложностей для взлома. Реализация ИЗК 1 чуть лучше, но со временем я нашел и в ней дыры.

  5. Прочие мало применяемые на практике механизмы – например сохранение и выполнение зашифрованных текстов запросов (например это используется в КЗ). Однако, с учетом того, что подавляющее большинство запросов, которые имеет смысл защищать, строятся в результате работы какого-либо алгоритма, данный способ мало применим. Так же в зависимости от реализации этот способ может быть надежным, а может быть только видимостью защиты (как в КЗ). Есть и другие варинты - обфускация текстов, ...

  6. Обфускация п-кода скомпилированного модуля 1С (т.е. изменение п-кода, таким образом, чтобы 1С могла работать с этим кодом, а декомпилятор не смог бы восстановить исходный текст). Этот метод на данный момент мало распространен, хотя защита в этом случае достаточно высока, по крайней мере до тех пор, пока не будут созданы декомпиляторы, которые умеют работать с таким п-кодом. С другой стороны, широкое использование данного метода приведет к появлению инструментов, которые будут позволять изменять непосредственно п-код для достижения требуемой задачи (например отвязка от ключа или изменение функционала). Этот метод защиты наиболее трудоемок для взлома на данный момент, поэтому я считаю его наиболее надежным. На момент написания этих строк, существует единственное тиражное решение использущее эту методику: WiseAdvice: Защита Конфигураций 2 (http://www.1c-zk2.ruhttp://www.intelis-it.ru/software/intelis/safety.html, http://infostart.ru/public/68368/ ) и не существует инструментов, позволяющих получить исходный текст защищенного модуля. Принцип обфускации кода для защиты от декомпиляции основан на том, что при компиляции конструкции языка 1С транслируются в определенные последовательности команд исполняющей машины. Конкретные конструкции в конкретные последовательности. На этом строится алгоритм декомпиляции. Если же заменить эти последовательности команд на идентичные по логике но отличные по составу команд - декомпилятор не может распознать исходную конструкцию. Если же новая последовательность будет к тому же случайной по составу команд (но не по общей логике) то задача декомпиляции еще усложнится.