Начнем с того, что защита и лицензирование программного обеспечения – разные понятия. Экономические потери производителей программных продуктов от действий «пиратов» вызвали необходимость разработки и применения мер, препятствующих теневому обороту ПО. Эти меры условно можно поделить на законодательные (лоббирование законов, регламентирующих ответственность за несанкционированное использование и распространение ПО), организационные (установление контроля над пользователями путём регистрации их персональных данных, персонального режима обновления версий продукта и т.п.) и технические (использование программно-технических средств, препятствующих несанкционированному использованию и/или копированию программных продуктов).
В силу того, что лоббирование законов возможно лишь для крупных компаний или объединений производителей ПО, а организационные меры требуют значительных затрат на реорганизацию торговой инфраструктуры и могут привести к переходу части клиентов на продукты конкурентов, не применяющих таких мер, самыми популярными стали технические меры противодействия теневому обороту ПО.
Таким образом, получили широкое распространение системы программной защиты ПО, основной целью которых является техническое противодействие несанкционированному использованию и распространению программных продуктов. Такое положение дел сохранилось, в целом, и до настоящего времени, не смотря на то, что производителями ПО достаточно активно используются законодательные и организационные меры защиты своих программных продуктов.
Основная задача, решаемая Системами Защиты Программного обеспечения (СЗПО) состоит в защите программного обеспечения от нелегального использования.
При этом защитить программу от копирования невозможно: любой файл, который может быть прочитан, будет скопирован — для запуска приложения операционная система должна прочитать файл и загрузить его в память компьютера. В этом разрезе словосочетание «защита от копирования» в отношении программного обеспечения не имеет смысла.
Кому и зачем это нужно
Свыше тридцати лет существует «экономическая криминалистика», использующая методы экономического анализа для исследования различных типов нарушений закона. В рамках данной дисциплины преступник рассматривается как «рационально мыслящий экономический агент», принимающий решение о совершении преступления или отказе от него, руководствуясь экономической оценкой затрат на совершение преступления, выгоды от его совершения и риска быть пойманным органами правопорядка. В то время как применимость анализа «экономического поведения» сразу ко всем видам правонарушений может подвергаться сомнениям, экономическая сущность «компьютерного пиратства» говорит в пользу перспективности подобного подхода к изучению причин и выработке мер противодействия нарушениям на рынке ПО.
Разработка системы защиты
Процесс проектирования и разработки СЗ ПО можно логически разбить на следующие этапы:
- Выявление целей и задач, стоящих перед производителем ПО.
- Определение требуемого уровня защиты.
- Определение стратегии защиты программного продукта (меры и средства).
- Выбор оптимальной СЗПО (внешняя, встраиваемая, комбинированная, парольная, с электронным ключом, и т.п.).
- Оценка общих планируемых затрат на разработку и внедрение СЗПО с учётом влияния защиты на потребительские свойства ПО.
- Оценка планируемого снижения потерь от "пиратства".
- Принятие решения о целесообразности применения проектируемой СЗПО.
- Доработка спецификаций СЗПО с возвратом к п.7, либо приобретение сторонней разработки, удовлетворяющей спецификации, с переходом к п.12.
- Разработка и оптимизация алгоритма СЗПО.
- Выбор (с обоснованием) языка программирования для реализации СЗПО.
- Программная реализация СЗПО и её тестирование.
- Применение СЗПО к продукту и проверка влияния защиты на показатели функциональности защищаемого ПО. В случае использования сторонней разработки – переход к п.17.
- Доработка СЗПО с возвратом к п.12.
- Тестирование фактического уровня защиты, обеспечиваемого СЗПО.
- Доработка СЗПО с возвратом к п.12.
- Документирование СЗПО
- Сопровождение СЗПО.
из мира 1С для ИТ-Директоров
Какие методы защиты конфигураций 1С есть на данный момент
Защита посредством штатных средств, т.е. поставки без исходных текстов. Эта защита являлась действенной до тех пор, пока не понадобилось изменить защищенный таким образом код.
Портирование кода на другие языки. Надежность защиты в этом случае зависит от возможности восстановления исходных текстов (или логики) и возможности модификации для удаления защиты. С учетом того, что восстановление текста на С++ задача нестандартная, защиту можно считать надежной.
Однако такой же не задачей является портирование кода с 1С на С++. Поэтому данный вариант применяется очень редко и тиражных решений, использующих его для защиты конфигураций, нет (если не считать таким вариантом СЗК).
Вынесение кода внешних обработок (т.е. модулей, которые не являются частью конфигурации и хранятся в отдельных файлах) в какое-либо зашифрованное хранилище. В этом случае создание объекта такого модуля возможно только при использовании внешней компоненты, которая проверяет возможность работы с таким модулем. Примером такой системы защиты могут служить комплексы СЗК, СЛК, а также система «WiseAdvice: Защита Конфигураций». Однако с учетом логики работы 1С с внешними обработками (например, 1С хочет расшифрованный файл на диске, как минимум, на время создания объекта и т.д.), есть возможность получить эту обработку как файл, далее – декомпиляция кода (как правило, защищаемые обработки поставляются без исходного текста).
Исполнение зашифрованных исходных текстов 1С во внешней компоненте. Для этого могут использоваться как собственные компиляторы/интерпретаторы (например, в СЗК), так и особенности 1С (возможность, доступная только при особой интерпретации документации 1С, используется в «WiseAdvice: Защита Конфигураций» в.1 и в КЗ).
Надежность данного метода можно считать высокой, т.к. исполняемый текст появляется только в памяти и только на время выполнения этого текста. Недостатком является сложность отладки такого кода и необходимость обработки конфигурации перед созданием поставки. Таким образом, этот метод стоит использовать для защиты текстов запросов и алгоритмов построения текстов, т.е. объемных, но не сложных по структуре алгоритмов, для создания которых наличие отладчика не обязательно. Хотя «надежность данного метода можно считать высокой», это не совсем так. Точнее это зависит от его реализации. Исследование методики, примененной в СЗК, затруднено отсутствием реальных примеров использования. Реализация в КЗ недостаточно эффективна. Реализация ИЗК 1 считалась более удачной, но со временем и в ней были обнаружены недостатки.
Прочие мало применяемые на практике механизмы – например, сохранение и выполнение зашифрованных текстов запросов (например это используется в КЗ). Однако, с учетом того, что подавляющее большинство запросов, которые имеет смысл защищать, строятся в результате работы какого-либо алгоритма, данный способ применим мало. Также, в зависимости от реализации, этот способ может быть надежным, а может быть только видимостью защиты (как в КЗ). Есть и другие варианты – обфускация текстов и пр.
Обфускация программного кода скомпилированного модуля 1С (т.е. изменение кода, таким образом, чтобы 1С могла работать с этим кодом, а декомпилятор не смог бы восстановить исходный текст).
Этот метод на данный момент мало распространен, хотя защита в этом случае достаточно высока, по крайней мере до тех пор, пока не будут созданы декомпиляторы, которые умеют работать с таким программным кодом. С другой стороны, широкое использование данного метода приведет к появлению инструментов, которые будут позволять изменять непосредственно программный код для достижения требуемой задачи (например, отвязка от ключа или изменение функционала). На сегодня этот метод защиты максимально трудоемок для взлома, поэтому считается наиболее надежным.
На момент написания статьи, существует единственное тиражное решение использующее эту методику: «WiseAdvice: Защита Конфигураций, ред. 2», и не существует инструментов, позволяющих получить исходный текст защищенного модуля.
Принцип обфускации кода для защиты от декомпиляции основан на том, что при компиляции конструкции языка 1С транслируются в определенные последовательности команд исполняющей машины. Конкретные конструкции в конкретные последовательности. На этом строится алгоритм декомпиляции. Если заменить эти последовательности команд на идентичные по логике, но отличные по составу, декомпилятор не сможет распознать исходную конструкцию. Если новая последовательность будет к тому же случайной по составу команд (но не по общей логике), то задача декомпиляции еще усложнится.
консультация эксперта
самые свежие новости 1 раз в месяц
