Назначение и общее описание

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

задач:

Защита оригинальных алгоритмов от анализа и модификации.

Защита от нелицензионного использования конфигураций и отдельных

блоков конфигураций.

Защита алгоритмов конфигурации

На данный момент невозможно реализовать обеспечение лицензионности

использования программного продукта, в случае если исходный код этого продукта

открыт. Это связано с тем, что любые проверки лицензионности могут быть простым

образом удалены.

С учетом того, что конфигурации 1С относятся к ПО с открытым кодом, задача

обеспечения защиты конфигураций от нелицензионного использования усложняется.

Штатно 1С Предприятие поддерживает создание конфигураций с отсутствующими

исходными текстами выбранных модулей. В этом случае, на этапе создания поставки

конфигурации выполняется компиляция программных модулей в так называемый «байт-

код» («pi-код», …), т.е. в набор инструкций, которые могут быть обработаны

«исполняющей машиной». В случае использования модулей с исходным текстом модулей

этап компиляции происходит при загрузке модуля в память, т.е. как правило – при первом

обращении к этому модулю (модули объектов и не глобальные общие модули) или при

создании сеанса – глобальные общие модули, а так же модули сеанса, приложения,

внешнего соединения.

При появлении платформы 1С Предприятие 8 использование поставки без исходных

текстов считалось надежным вариантом защиты конфигураций от изменения – структура

хранения конфигурации закрыта и была неизвестна. На данный момент структура

хранения конфигурации достаточно хорошо изучена и существуют (в т.ч. доступны для

скачивания в Интернете) инструменты для автоматического разбора данных

конфигурации и для восстановления исходных текстов модулей из скомпилированного

байт-кода – «декомпиляторы». Принцип работы декомпилятора основан на том факте, что

одна и та же конструкция на встроенном языке 1С Предприятие при компиляции всегда

представляется одинаковой последовательностью команд байт-кода. Таким образом,

можно в автоматическом режиме получить исходные тексты модулей и после этого

изменить их, удалив проверку лицензинности использования конфигурации.

Для защиты конфигураций от модификаций используют разные методики:

Штатными средствами - т.е. поставка без исходных текстов, т.е.

скомпилированный. Эта защита являлась действенной до тех пор, пока не

была доступна методика автоматизированной декомпиляции. На просторах

интернета в свободном доступе можно найти несколько различных версий

декомпилятора. В связи с этим, защита данным методом считается очень

слабой.

Портирование кода на другие языки и использование алгоритмов вынесенных

в библиотеки DLL (внешние компоненты и COM-объекты). Надежность

защиты в этом случае зависит от возможности восстановления исходных

текстов (или логики) и от возможности модификации для удаления защиты. С

учетом того, что восстановление текста на С++ (например) задача не

тривиальная (как минимум для подавляющего числа людей хорошо знакомых

с 1С и с С++), защиту можно считать надежной. Однако такой же не

тривиальной задачей является портирование кода с 1С на С++. Поэтому

данный вариант применяется очень редко, в связи с черезвычайно высокой

стоимостью такого метода защиты.

Вынесение кода внешних обработок (т.е. модулей, которые не являются

частью конфигурации, и хранятся в отдельных файлах) в какое-либо

зашифрованное хранилище. В этом случае создание объекта такого модуля

возможно только при использовании внешней компоненты, которая проверяет

возможность работы с таким модулем. Примерами такой системы защиты

могут служить комплексы СЗК (http://www.1c.ru/news/info.jsp?id=3046 ), ИЗК

версии 1.0 (http://www.intelis-it.ru/software/intelis/safety.html ). Однако с учетом

логики работы 1С с внешними обработками (например, платформе 1С

необходим расшифрованный файл на диске как минимум на время создания

объекта, ...), есть возможность получить эту обработку как файл и далее взлом

защиты сводится к декомпиляции кода (как правило, защищаемые обработки

поставляются без исходного текста). Стоит заметить, что такой возможности

при использовании системы ИЗК 1.0 нет — обработка не появляется в

расшифрованном виде на диске никогда. Недостатком этой методики является

необходимость выносить код во внешние обработки и сложность

использования.

Исполнение зашифрованных исходных текстов 1С во внешней компоненте.

Для этого могут использоваться как собственные компиляторы /

интерпретаторы (например, в СЗК), так и особенности 1С (используется в

ИЗК). Надежность данного метода можно считать высокой, т.к. исполняемый

текст если и появляется в незашифрованном виде, то только в памяти и

только на время выполнения этого текста. Недостатком является сложность

отладки такого кода и наличие ограничений налагаемых системой защиты на

защищаемый код. Таким образом, этот метод стоит использовать для защиты

текстов запросов и алгоритмов построения текстов, т.е. объемных, но не

сложных по структуре алгоритмов, для создания которых наличие отладчика

не обязательно.

Прочие мало применяемые на практике механизмы – например сохранение и

выполнение зашифрованных текстов запросов. Однако, с учетом того, что

подавляющее большинство запросов, которые имеет смысл защищать,

строятся в результате работы какого-либо алгоритма, данный способ мало

применим. Есть и другие варианты - обфускация текстов.

Обфускация байт-кода скомпилированного модуля 1С. В большинстве

случаев для обхода защиты, взломщику требуется изучить принцип работы ее

кода, и то, как она взаимодействует с самой защищаемой программой. Этот

процесс изучения называется процессом реверсивной (обратной) инженерии.

Обфускация (от лат. obfuscare — затенять, затемнять; и англ. obfuscate —

делать неочевидным, запутанным, сбивать с толку), это один из методов

защиты программного кода, который позволяет усложнить процесс

реверсивной инженерии кода защищаемого программного продукта. Суть

процесса обфускации — приведение исполняемого кода программы к виду,

сохраняющему ее функциональность, но затрудняющему анализ, понимание

алгоритмов работы и модификацию. Для выполнения обфускации

применяются специальные программы – «обфускаторы». Задача обфускатора

заключается в том, чтобы запутать программный код и трансформировать его

так, чтобы он был очень труден для изучения и модификации посторонними

лицами (будь то взломщики, или программисты которые собираются узнать

уникальный алгоритм работы защищаемой программы). Но обязательным

условием такой обработки байт-кода является сохранение функциональности

кода. Использование данного метода делает невозможным использование

автоматических декомпиляторов. А с учетом того, что неавтоматизированный

анализ байт-кода процесс очень трудоемкий, данный метод защиты кода

конфигураций 1С можно считать достаточно надежным.

Лицензирование конфигураций

Для лицензирования использования ПО могут использоваться разные методики,

например:

«Привязка к компьютеру» - лицензия может быть активирована только на

одном ПК, может использоваться только на нем и не может быть перенесена

на другой ПК. В этом случае ПО привязывается к компонентам ПК (диск,

материнская плата, процессор, сетевая карта, …). В случае замены ПК или его

компонентов программа перестает работать.

«Код активации», «файл лицензии» – использование последовательности

символов, удовлетворяющих какому либо условию. Т.е. если пользователь

знает подобную последовательность, то имеет возможность использовать

данное ПО (даже не имея лицензии).

«Аппаратные ключи» - использование специальных устройств, без которых

нормальная работа защищенного приложения невозможна. Использование

аппаратных ключей делает себестоимость ПО несколько выше, за счет

необходимости включения в комплект поставки аппаратного ключа, но его

стоимость в большинстве случаев сравнима со стоимостью упаковки

комплекта поставки программного продукта. При использовании аппаратных

ключей снимаются проблемы переноса ПО между компьютерами, есть

возможность реализовывать многопользовательские лицензии. Подделать

аппаратный ключ практически невозможно. Существует вероятность

эмуляции ключей, однако современные комплексы защиты с использованием

аппаратных ключей сильно затрудняют процесс эмуляции.

Принципы реализации Интелис: Защита Конфигураций 2

Механизм ИНТЕЛИС: Защита Конфигураций 2.0 позволяет защитить конфигурацию

на платформе 1С Предприятие 8.2 от нелицензионного использования путем обфускации

байт-кода модулей конфигурации, частичного шифрования данных и осуществляет

привязку к аппаратному ключу Hasp SRM.

Принцип обфускации байт-кода был выбран исходя из следующих соображений:

Возможность защиты как модулей внутри конфигурации 1С, так и отдельных

внешних обработок и отчетов.

Возможность использования защищенных модулей как на клиенте (толстом),

так и на сервере 1С Предприятия.

Нет необходимости выделения защищаемого функционала в отдельные

обработки.

Возможность автоматизированной установки защиты (в т.ч. и привязки к

аппаратному ключу).

Отсутствие (на данный момент) инструментов для автоматизированного

снятия защиты и высокая сложность создания таких инструментов.

Шифрование данных значительно усложняет процесс реверсивной инженерии

кода.

При использовании ИЗК 2.0 защита конфигурации происходит практически

полностью автоматическом режиме. Разработчику требуется лишь указать, что именно

следует защитить и обеспечить наличие компоненты защиты.

Порядок защиты конфигурации:

Подготовка конфигурации

1) Определение списка модулей, которые требуется защитить. Защитить можно

общие модули и модули обработок. Модули не должны содержать

синтаксических ошибок, директив препроцессора. Так же не допускается в

защищаемых модулях использование методов «Выполнить» и «Вычислить»;

2) Следующий шаг – установка пароля на защищаемые модули (Меню «Текст –

Установить пароль») (это нужно для компиляции исходного текста в байт-код):

В процессе установки защиты исходный текст будет удален;

3) Для функционирования системы защиты необходима библиотека защиты –

рекомендуется сохранить ее образ в макете типа «Двоичные данные»:

4) Необходимо обеспечить в защищаемых модулях наличие функции

«GetUSBKeyComponentLocation». Функция должна возвращать полное имя

макета, в котором хранится образ библиотеки защиты, либо полное имя файла

библиотеки защиты:

Функция GetUSBKeyComponentLocation вызывается перед загрузкой библиотеки

защиты.

5) Подготовленную таким образом конфигурацию нужно сохранить в файл (Меню

«Конфигурация – Сохранить конфигурацию в файл…»):

6) На этом этапе все подготовительные шаги завершены. Можно запустить

конфигурацию ИЗК 2.0 для установки защиты. При запуске конфигурации

открывается форма установки защиты:

Использование формы защиты конфигурации

1) В поле «Имя исходного файла» указывается полный путь к ранее сохраненной

конфигурации, которую требуется защитить.

2) В поле «Имя файла библиотеки защиты» указывается полное имя файла

используемой библиотеки защиты:

При установке защиты требуется наличие установленного ключа защиты той

серии под который выполняется защита. При этом, если используется модульное

лицензирование, то в ключе должны быть доступны эти модули;

3) После этого необходимо нажать кнопку «Анализ файла конфигурации», и после

завершения анализа файла конфигурации будет построено дерево модулей,

которые можно защитить;

4) Далее требуется указать функции, при вызове которых должен проверяться ключ

защиты. Для выбранных функций, необходимо указать номер модуля – Feature ID

для ключей Hasp. Feature ID «по умолчанию» для ключей Hasp имеет номер 0:

5) Следующий шаг – непосредственно установка защиты путем модификации

конфигурации. Для выполнения этого этапа необходимо нажать кнопку

«Установить защиту». Измененная конфигурация сохраняется в то же каталог, в

котором расположен исходный файл, и имя аналогичное исходному файлу с

добавлением текущих даты и времени. В окно сообщений выводится полный

путь к созданному защищенному файлу конфигурации.

6) На этом процесс защиты конфигурации завершен.

Использование защищенной конфигурации

При отсутствии лицензии на выполнение защищенной функции при выполнении

такой функции будет сгенерировано исключение с описанием ошибки.

Особенности лицензирования сессий

В зависимости от режима работы защищенного модуля необходимо установить

различные методы конкуренции для ключей:

Если выполнение модуля происходит в контексте сервера 1С предприятия, должны

использоваться только сетевые лицензии с конкуренцией по логинам. При этом учет

лицензий осуществляется для каждого экземпляра модуля (т.е. для каждого сеанса –

отдельная лицензия). При этом, если несколько модулей конфигурации одновременно

используют один и тот же Feature ID – для каждого защищенного модуля будет выделена

отдельная лицензия. Таким образом, не стоит защищать различные модули конфигурации,

используя один Feature ID.

Известные проблемы

Кэш метаданных

Следует учесть, что при загрузке защищенной конфигурации возможно не будет

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

конфигурации при работе в режиме 1С Предприятие. Для решения этой проблемы

возможно использование следующих методик:

1) Очистка кэша метаданных, согласно рекомендациям фирмы 1С.

2) Вторая методика заключается в модификации любого свойства защищенного

модуля или обработки (например комментария) и обновлении конфигурации

базы данных. При этом кэш медатанных должен обновиться.

3) Можно перед загрузкой защищенной конфигурации удалить из текущей

конфигурации защищаемые объекты и обновить конфигурацию базы данных.

После чего загружать измененную конфигурацию.

Указание расположения компоненты защиты

Для платформы 1С 8.2.10.77 недопустимо указывать в качестве расположения

компоненты защиты путь к файлу, если путь содержит русские буквы – ошибка

платформы 1С 8.2.10.77.

Для платформы 1С 8.2.10.77 недопустимо указывать в качестве расположения

компоненты защиты полное имя макета, в том случае, если макет содержится во внешней

обработке – зарегистрированная ошибка платформы 1С 8.2.10.77.

Для платформы 1С 8.2.10.77 возможно зависание лицензий до момента завершения

сеанса или в случае выполнения на сервере – до момента завершения всех сеансов работы

с этой базой – зарегистрированная ошибка платформы 1С 8.2.10.77.

Описание примера

Для примера демонстрации возможностей системы используется конфигурация

«Демонстрационная конфигурация "Управляемое приложение"». В конфигурацию

добавлена оригинальная обработка «Матрица ролей пользователей». Обработка защищена

таким образом, чтобы без ключа защиты обработка не могла изменять права

пользователей, но могла их отображать. Для открытия обработки «Матрица ролей

пользователей» необходимо запустить прилагаемую демо конфигурацию и в панели

разделов выбрать пункт «Предприятие», а далее на панели действий выбрать пункт

«Матрица ролей пользователей»:

Для достижения заданного уровня защиты была установлена проверка ключа только

для процедур:

Процедура ПользовательДобавитьРоль(ИмяПользователя, ИмяРоли) Экспорт

Процедура ПользовательУдалитьРоль(ИмяПользователя, ИмяРоли) Экспорт

Оригинальный текст модуля обработки содержится в макете

«ТекстМодуляОбработки»

Ограничения при работе с ключами демо-серий

При установке защиты с использованием ключей демо-серий, в принудительном

порядке устанавливается проверка ключа для всех процедур и функций защищаемого

модуля.