Защита кода конфигураций и обработок в 1С8х
Введение
В «восьмерке», также как и в «семерке» защита исходного кода штатными средствами не является достаточно надежной. В Интернете можно найти способы и средства для взлома защищенных конфигураций 1С. Относительно легко снять пароли на вход, как в режим «Предприятие», так и режим «Конфигуратор», а в версии 1С8х, где вместо исходного кода можно оставить только интерпретируемый байт-код, имеется возможность декомпилировать псевдокод в исходное состояние, хотя и без сопутствующих, первоначально, комментариев.
Однако в большинстве случаев штатных средств 1С вполне достаточно для «защиты от дурака». Проблема возникает, когда существует необходимость защитить конфигурации от специалистов, заинтересованных во взломе, например, при распространении полнофункциональных демо-версий через Интернет. Поэтому если возникает потребность в использовании серьезной защиты, то необходимо применение нештатных средств. Те, кто уже заработал достаточно средств на своих программах, может использовать коммерческие решения от сторонних фирм, но для тех, кто только планирует разместить свои конфигурации, да еще на бесплатных сайтах, платить за защиту программ, которые не факт, что окупятся, не всегда есть возможность. Конечно, многие предложат выкладывать собственные программы безо всякой посторонней защиты, если они еще достаточно сырые, однако у авторов разработок на этот счет могут быть иные мнения.
Другой вариант, это попытаться применить собственные нештатные средства, тем более что такое нередко встречается на практике. Применительно, к восьмой версии 1С задача может быть сформулирована более конкретно. Как самостоятельно защитить от декомпиляции байт-код 1С8х, так чтобы это не повлияло на работу интерпретатора данного псевдокода? Иначе говоря, как сделать, чтобы пи-код был легальным с точки зрения интерпретатора и нелегальным с точки зрения декомпилятора?
Немного теории
Известно, что языки высоко уровня (ЯВУ) делятся, по способу выполнения своего кода, на две большие группы: интерпретируемые и компилируемые. Интерпретатор выполняет промежуточный, предварительно оттранслированный код, который затем преобразуется в непосредственный код процессора, а компилятор готовит родной машинный код в виде исполнимого файла, для выполнения его средствами операционной системы. Здесь важно отметить тот факт, что декомпиляция бинарного кода хотя и возможна, но уровень декомпиляции (код ассемблера либо жалкое подобие языка Си) практически не позволяет эффективно использовать декомпилированую программу целиком. Зато промежуточный байт-код любых интерпретируемых языков относительно легко восстанавливается в исходный вид. Достаточно вспомнить про декомпиляторы Visual FoxPro, Java, Adobe Flash и т.п.
Таким образом, перед нами стоит задача, если не защитить от декомпиляции байт-код 1С (что довольно трудно сделать без посторонних средств), то хотя бы максимально затруднить восстановление кода и его осмысление. Первое, что приходит на ум это обфускация или запутывание и усложнение кода для понимания и восстановления. И действительно, данный метод широко используется в защите конфигураций и обработок 1С, например, AWA (
http://infostart.ru/profile/13819/ ) таким образом защищает собственные обработки вроде, Декомпилятор1Сv8.epf, что подтверждается его словами:
«если выдается сообщение, что "Возможно, модуль обфусцирован", в 99.9 процентах случаев модуль действительно обфусцирован. Обфускаторов байт-кода существует много, самый известный - WiseAdvice. После некоторых обфускаторов кода можно восстановить корявый текст, однако в открытом доступе таких средств на данный момент нет.» (
http://helpf.pro/files/view/60.html ). Тем не менее, он ничего не говорит о принципах самой обфускации, хотя для своих разработок он использует собственную обфускацию.
Чисто теоретически принципы обфускации сформулировать нетрудно. Это:
1. Замена осмысленных пользовательских имен переменных, меток, функций и т.п. на бессмысленные.
2. Удаление форматирование текста, т.е. представление всего кода программного модуля в виде одной длиной строки. Хотя на самом деле это слабая защита, достаточно поставить символы перевода строк после каждой точки с запятой. Легко добавить и другие автоматические средства восстановления форматирования кода.
3. «Раздувание» кода за счет малополезных и не слишком эффективных действий и вычислений. Например, чтобы получить заранее известный параметр либо логическое условие, выполняется масса бестолковых операций, в конечном итоге выдающих гарантированный результат.
4. Замена простого и естественного кода на более сложный и менее понятный эквивалентный код. Например, все операторы выбора и циклов заменить сложными условными и безусловными переходами. Причем, за счет злоупотребления оператором «Перейти ~Метка;» можно строить чрезвычайно запутанный и малопонятный код.
Данные принципы действуют на уровне ЯВУ. Но можно предложить достаточно эффективный метод, на уровне байт-кода, который заведомо положит на лопатки любой декомпилятор, пытающийся восстановить исходный код. Этот метод мы назовем методом «мусорных ям». Принцип его действия прост. Нужно, с помощью блоковых операторов, таких как операторы выбора, циклов, попытки- исключения, неиспользуемых процедур и функций, операторов безусловного перехода и т.п. сформировать области кода, которые заведомо не получит управление. Например, как в операторе вида:
1.
2.
3.
Если Ложь Тогда
// «Мусорный» код
КонецЕсли;
Естественно, что это может быть реализовано менее явным образом. Затем в полученном байт-коде заменяем легальные команды мусорного кода на произвольный байт-код, например, нелегально используем легальный код, скажем, применяем стековые команды к пустому стеку, либо к чужим данным. Либо заменяем исходный байт-код на нелегальный или несуществующий псевдокод, который заведомо обрушит любой декомпилятор, пытающийся выполнять команды на уровне формы (заметим, что интерпретатор выполняет пи-код на уровне его содержания). А поскольку интерпретатор никогда не получит управление на ложный байт-код, то он никогда об него и не споткнется. Зато, декомпилятор, пытающийся восстанавливать весь код, сломает себе шею на бессмысленных командах. Его типичные сообщения при этом будут: «Выход за пределы стека либо индексов массивов» и «Несуществующая либо невыполнимая команда псевдокода». И действительно подобные сообщения выдает декомпилятор 1С от Авы, когда с его помощью пытаются декомпилировать его самого либо обфусцированный как надо исходный код. Таким образом, нас вполне устраивает подобный уровень защиты, который хотя и не абсолютный, зато может быть бесплатным и отсечь достаточный процент недобросовестных пользователей. Ну а от суперхакеров и профессиональных взломщиков защищаться особого смысла нет, эти ребята достанут и чёрта лысого из его нычки.
Как правило, из любой нетривиальной идеи всегда можно получить нетривиальные выводы. Посмотрим, что нас ожидает в нашем случае. Первое, мы пришли к пониманию, что есть два вида интерпретаторов, одни выполняет команды на основе их содержания, а другие на основе их формы. Например, условные команды на уровне содержания:
присвоят переменной
a числовое значение 123. А те же команды на уровне формы вернут строку текста: «
a = 123». Т.е., в первом случае мы получаем числовую переменную, а во втором конкретную строку. Это различие, в принципе естественное, но не очевидное. Кстати, рассматриваемые нами декомпиляторы являются интерпретаторами формы. А интерпретатором содержания будет интерпретатор байт-кода 1С.
Второе, данный метод защиты годится не только для интерпретируемого кода, но и для компилируемого. Действительно, размещая в уже скомпилированном коде, в областях закрытых для управления (помеченных заранее известным мусорным кодом), бессмысленный код, мы положим на лопатки любой декомпилятор или лучше сказать дизассемблер, даже такой как IDA PRO. Т.е. дизассемблерный листинг мы, скорее всего, получим, но местами абсолютно бессмысленный и не доступный для получения на его основе хотя бы более-менее осмысленного псевдосишного кода. Иначе говоря, трудную жизнь любителям восстанавливать бинарный код на уровне ассемблера, можно еще более усложнить. Возможно, я вернусь к этой теме в отдельной статье (достаточно будет привести простой код на ассемблере, бинарный вариант которого приведет IDA PRO в ступор, а его плагин по получению псевдо Си-кода не даст ничего путного).
Итак, путем несложных рассуждений мы пришли к пониманию, как можно бесплатно защитить свой код в 1С8х, хотя бы на уровне Авы. Для этого пишем собственный двухуровневый (ЯВУ и байт-код) обфускатор по сформулированным выше принципам. При этом можно применять разные степени усложнения и запутывания. Причем байт-код 1С (после исключения текста модулей из поставки конфигурации) можно менять как штатными средствами, путем выгрузки конфигурации в xml-файлы, в последних версиях «восьмерки», так и нештатными, вроде V8Unpack. Данный метод относительно несложен и позволяет использовать собственные трюки и маленькие секреты.
Однако следует сказать, что знание защиты позволяет использовать и пути ее обхода. В нашем случае, для того, чтобы не вызывать жалобы декомпилятора при пережевывании им обфусцированного псевдокода, нужно вообще отказаться от использования, в нашем понимании, интерпретатора формы, другими словами, стековой или Форт-машины. Иначе говоря, ограничится только дешифровкой команд и данных либо попытаться вместо стекового интерпретатора использовать некий синтаксический анализатор. Но последний должен уже обладать зачатками искусственного интеллекта, что наверняка вызовет избыточные трудности при программировании. Поэтому, самый простой вариант обхода защиты обфусцированного байт-кода это просто расшифровать его команды и данные и анализировать полученный полуфабрикат уже вручную. Конечно, это будет уже удовольствие на любителя, ведь при должной двухуровневой обфускации анализировать полученный результат будет непросто.
Вот пример попытки частичного восстановления обфусцированого байт-кода обработки Авы:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
{Процедура e3(оо, эw, Var0д)}
{Cmd_12225:}
{сд}{Неопределено}{=}
{Var6е}{."БазовыйТип"}{зш}{==}
{хщ}{41,1314}
{Cmd_12234:}
{=}
{Неопределено}{=}
{хщ}{41,10520}
{Cmd_12242:}
{Функция:5}{пj()}{=}
{Var6е}
{Go Cmd_11302}
{Cmd_12248: # Cmd_12248:}
{сt}{оо}{Функция:2}{r0()}{Var0д}{че}
{ElseGo Cmd_1671}
{Cmd_12255:}
{КонецЦикла}
. . .
Как видим, здесь чёрт ногу сломит, поэтому на таком уровне пусть изучают наш код, сколько угодно.
Заключение
По идее мы должны были в данной статье предоставить собственной вариант программы по защите кода 1С. Но поскольку подобная задача только встала перед нами, то требовалось сначала разобраться с руководящими принципами. Теперь, когда стало ясно в каком направлении двигаться, можно заняться непосредственно программой, хотя ее принципы, как нам кажется, достаточно интересны сами по себе, чтобы начать их обсуждение до получения конкретного результата. Поэтому встречные рассуждения и конструктивная критика приветствуются.
