Разработчики часто сталкиваются с необходимостью защитить свой программный код от несанкционированного доступа, просмотра или изменения. Это особенно актуально для коммерческих решений и интеллектуальной собственности. Один из частых вопросов, который возникает у программистов 1С, связан с тем, почему в мобильных приложениях, установленных из Play Market, отсутствует исходный код, тогда как при открытии файла конфигурации (.cd) из других источников код виден.
Давайте подробно рассмотрим, как работает механизм сокрытия кода в мобильных приложениях 1С и какие методы мы можем применить для защиты наших конфигураций.
Прежде всего, давайте выясним, почему мы не видим исходный код в мобильных приложениях 1С, установленных из Play Market. Ситуация, когда при получении .cd файла из такого приложения модули и формы кажутся очищенными от кода, не является результатом какой-то специальной настройки, сделанной разработчиком конфигурации. Это встроенный механизм защиты самой мобильной платформы 1С.
Формат дистрибутива: Из Play Market устанавливается не напрямую .cd-файл, а APK-файл (Android Package Kit). APK-файл — это архив, который содержит все необходимые элементы для установки приложения на устройство Android.
Отсутствие исходного кода: Мобильная платформа 1С, особенно в более новых версиях (после 15-й), при формировании APK-файла не включает в него исходные тексты модулей 1С. Вместо этого, в приложение компилируется байт-код. Этот байт-код не подлежит простому просмотру или декомпиляции обычными средствами 1С Конфигуратора.
Сложность декомпиляции: Извлечь исходный код из такого скомпилированного байт-кода практически невозможно с помощью общедоступных инструментов. Это значительно усложняет обратную разработку и обеспечивает высокий уровень защиты интеллектуальной собственности, заложенной в логике приложения.
Низкоуровневые компоненты: Большая часть критического кода самой платформы 1С в APK-файлах мобильных приложений часто содержится в скомпилированных библиотеках C++ (.so файлах), что дополнительно затрудняет его анализ.
Обфускация байт-кода: Файл classes.dex, также входящий в APK, содержит байт-код Java/Dalvik. Этот код может быть подвергнут обратной разработке, но часто он уже обфусцирован или минифицирован, что делает его трудночитаемым.
Таким образом, когда мы берем свое собственное приложение, разработанное в Конфигураторе 1С, и сравниваем его с версией из Play Market, мы видим разницу в наличии исходного кода. Это не баг и не упущение, а заложенный функционал мобильной платформы, предназначенный для защиты.
Хотя для мобильных приложений 1С из Play Market вопрос сокрытия кода решается на уровне платформы, для обычных конфигураций 1С, используемых на ПК, существуют другие методы. Рассмотрим их подробно.
Мы должны понимать, что абсолютной защиты от декомпиляции или обратной разработки не существует. Однако мы можем значительно усложнить этот процесс, требуя от потенциального взломщика значительных усилий, времени и специализированных знаний.
Это один из самых базовых механизмов защиты, предоставляемых платформой 1С. Он позволяет закрыть программный код модуля объекта от просмотра в Конфигураторе.
Механизм: Мы можем открыть модуль объекта (например, документа, справочника, отчета), перейти в меню "Модуль", выбрать пункт "Текст" и затем "Установить пароль". После установки пароля исходный текст модуля будет преобразован в байт-код и станет недоступным для просмотра в Конфигураторе.
Ограничения: Этот метод имеет важные ограничения:
Этот метод тесно связан с установкой пароля и предоставляет более системный подход для поставщиков конфигураций. Он используется при формировании поставки (.cf или .cfu файла).
Механизм: В настройках поставки конфигурации (обычно в свойствах конфигурации, раздел "Поставщик") есть опция "Не включать в поставку исходный текст модулей объекта". Если мы устанавливаем этот флажок, то при формировании файла поставки вместо исходного текста модулей в него включается только скомпилированный байт-код. Это означает, что конечный пользователь, получивший конфигурацию в режиме "Поставщика", не сможет просмотреть исходный код этих модулей через Конфигуратор.
Ограничения: Как и в случае с паролем, этот метод имеет свои рамки:
#Если Клиент Тогда)Пример обхода ограничений для серверного кода: Для эффективного сокрытия серверного кода, который не подпадает под эти ограничения, мы можем использовать следующую схему:
.cfu).Обфускация — это процесс запутывания исходного или байт-кода, делающий его нечитаемым и значительно усложняющий анализ и декомпиляцию. Этот метод не скрывает код полностью, но делает его почти бесполезным для чтения и понимания человеком.
Мы можем применить обфускацию как к исходному коду, так и к байт-коду.
Методы обфускации: Обфускация может включать следующие техники:
Процедура123, _aBc).Инструменты: Существуют как коммерческие решения (например, "Нетленка: Защита конфигураций 1С"), так и самописные инструменты, которые автоматизируют процесс обфускации. Мы можем также разработать собственные скрипты для частичной обфускации. Обфускация байт-кода 1С совместно с обфускацией исходного кода существенно повышает устойчивость к взлому.
Для критически важной функциональности и алгоритмов, требующих максимальной защиты, мы можем вынести часть кода во внешние компоненты (.dll или .so файлы), разработанные на других языках программирования (например, C++, Java).
Механизм: Мы разрабатываем внешнюю компоненту, которая реализует необходимую логику, компилируем ее. В конфигурации 1С мы затем регистрируем эту компоненту и вызываем ее методы. Например, для вызова внешнего метода мы могли бы использовать что-то вроде:
ВнешняяКомпонента = Новый ("AddIn.МояСуперЗащита");
Если ВнешняяКомпонента.Подключить() Тогда
Результат = ВнешняяКомпонента.ВыполнитьЗащищенныйРасчет(Параметры);
КонецЕсли;
Преимущества: Этот метод обеспечивает один из самых высоких уровней защиты, так как исходный код компоненты не хранится в базе 1С. Исполняемый код появляется только в оперативной памяти на время выполнения, что значительно затрудняет отладку и анализ. Для обратной разработки потребуются специализированные знания реверс-инжиниринга для скомпилированных языков.
Если мы хотим защитить значительные объемы кода, которые часто обновляются, мы можем использовать внешние обработки, хранящиеся в виде макетов в основной конфигурации.
Механизм: Мы разрабатываем внешнюю обработку или отчет, закрываем её модули (например, методом из пункта 1 или 2). Затем сохраняем эту обработку в бинарном виде и загружаем как макет в основную конфигурацию. В основной конфигурации мы можем динамически загружать и выполнять код из этих макетов.
МакетОбработки = ПолучитьМакет("МойЗащищенныйМодуль");
ДвоичныеДанные = МакетОбработки.ПолучитьДвоичныеДанные();
ИмяВременногоФайла = ПолучитьИмяВременногоФайла(".epf");
ДвоичныеДанные.Записать(ИмяВременногоФайла);
ВнешняяОбработка = ВнешниеОбработки.Подключить(ИмяВременногоФайла);
Если ВнешняяОбработка <> Неопределено Тогда
ВнешняяОбработка.ВыполнитьЗащищеннуюФункцию();
ВнешниеОбработки.Отключить(ИмяВременногоФайла);
КонецЕсли;
УдалитьФайлы(ИмяВременногоФайла);
Преимущества: Этот подход позволяет нам обновлять логику, скрытую в макетах, без необходимости обновления основной конфигурации и без раскрытия кода. Также он позволяет нам использовать методы защиты, применимые к внешним обработкам.
Недостатки: Основной риск заключается в том, что пользователь может извлечь файл внешней обработки из макета, сохранить его на диск и попытаться декомпилировать.
Для повышения уровня защиты и контроля использования наших решений мы можем внедрить механизмы лицензирования.
Аппаратная привязка: Мы можем реализовать проверки уникальных идентификаторов оборудования (например, MAC-адреса сетевой карты, серийного номера диска или USB-ключей HASP/Sentinel). Код проверяет наличие или соответствие такого идентификатора. При его отсутствии или несовпадении критичные операции или сама программа могут быть заблокированы. Этот метод обеспечивает высокую степень защиты, но может быть сложным и дорогим в реализации.
Программное лицензирование: Мы можем встроить в код проверки срока действия лицензии, механизмы онлайн-активации или регулярного обновления ключей. Это требует наличия серверной части для управления лицензиями и взаимодействия с ней из конфигурации 1С.
Это скорее организационный, чем технический метод, но он играет важную роль в общей стратегии защиты.
Механизм: Мы должны убедиться, что у конечных пользователей сняты права на запуск Конфигуратора 1С. В типовых конфигурациях 1С, начиная с версии 8.3, также активно используется механизм "Защита от опасных действий", который предотвращает выполнение произвольного кода, если он не подписан или не добавлен в доверенный список.
Преимущества: Этот метод не скрывает код, но предотвращает его просмотр и изменение неопытными или недобросовестными пользователями, которые не являются разработчиками.
Как мы видим, вопрос сокрытия программного кода в 1С имеет несколько аспектов. Для мобильных приложений, распространяемых через Play Market, защита кода осуществляется на уровне платформы за счет компиляции в байт-код. Для обычных конфигураций мы можем использовать комбинацию методов: установка пароля, исключение текстов из поставки, обфускация, вынос критичных частей в защищенные внешние компоненты или макеты, а также системы лицензирования и организационные меры. Каждое из этих решений имеет свои преимущества и недостатки, и их совместное применение значительно усложняет обратную разработку, защищая нашу интеллектуальную собственность.