Обфускация JavaScript
В статье собраны всем известные методы и предельно извращенные. Эту статью я решил написать после недавнего прочтения поста в блоге Badass JavaScript и решил её дополнить своими находками.
Первый способ
Он всем известен — обфускация минимизаторами такими как JS Packer, JSmin, YUI Compressor, Closure compiler или можно просто пугуглить «JavaScript Obfuscator» и найдется ещё сто штук разных обфускаторов.
Они превращают существующий код
В какой-то такой вид:
Но ничего не стоит его восстановить с помощью jsbeautifier.org либо просто убрать eval и получить исходный код, многое потеряем, но смысл кода восстановим. Ну и с первого взгляда мы видим, что перед нами JavaScript.
Все это были цветочки под катом жесткие методы обфускации.
Способ второй
Изменение кода до неузнаваемости, который превратит наш мизерный скрипт:
alert(0)
Или вот в такой (код может не работать ибо хабрапарсер):
ﾟωﾟﾉ= /｀ｍ´）ﾉ
Тут с первого раза и не скажешь, что перед нами работающий JavaScript.
Тулза делающая код вида один, код вида два. Vladson нашел ещё одну тулзу jjencode
Объяснение некоторых моментов способа два
Таким образом _/_ = 3/3 = 1
Таким образом первая строка станет ($ = [] [«s» + «o»+ «r»+ «t» ] )()
($=[][«sort»])()
Идем дельше
[__[_/_]+__[_+
Строка превращается…
[__[_/_]+__[_+
Превращается в
[ «a» + «l» + «e» + «r» + «t» ](1)
В конце мы получаем ($=[][«sort»])()[«alert»](1)
Разобьём по частям
a = [] // Создает массив
b = a[«sort»] // Получает ссылку на метод sort
c = b() // Выполяет метод вне контекста массива для получения ссылки на window
d = c[«alert»] // Получает ссылку на window.alert
d(1) // Выполняет window.alert с аргументом 1
Это, конечно, искусственный пример и никакой из обфускаторов так не сможет.
Способ третий
Первый способ делал код похожим на JavaScript, второй совершенно не похожим, а третий сделает код вообще невидимым.
Готовых решений не видел, концепт, подсмотренный с одного из видео JS конференций.
Код будет состоять из двух частей: видимая честь — можно использовать что-нибудь описанное выше для её обфускации и невидимая часть.
Если с видимой все ясно, то секрет невидимой вот в чем: Имеющийся «плохой код» (иначе зачем его прятать) мы пропускаем через наш обфускатор-изчезатор, который превращает видимый скрипт в невидимый т.е. в строку состоящую из знаков табуляции (бит 1) и пробелов (бит 0).
В итоге мы получим в 8 раз больше кода чем имели. Видимая часть будет декодировать невидимую часть и её выполнять: декодирует биты в число, а число переделает в символ String.fromCharCode() ну а дальше eval
В конце получается что-то такое (невидимую часть не обязательно скрывать в элементе)
decodeAndEval(document.getElementById(«evilCode»).innerHTML);
Буду рад ответить на ваши вопросы и увидеть способы обфускации известные вам.
PS Представленный код может не работать, ибо хабрапарсер©, ссылки на тулзы имеются — в случае чего сделайте свой код.
UPD В комментариях ещё несколько раз писали про способ обфускации в png подробнее
Прячем JavaScript-код на фронтенде от посторонних
Рассказывает веб-разработчик Денис Лисогорский
Давайте представим ситуацию, когда вы и ваша команда пишете интересный и сложный код на JavaScript. Причём этот код в кратчайшие сроки нужно использовать в проекте. Если его функциональность действительно уникальна, то в процессе разработки и у вас, и у членов команды вполне резонно возникнет вопрос: «Как защитить код от копирования?».
Как защитить код: веб-сокеты, крипторы и обфускация
Разумеется, все мы прекрасно понимаем, что JavaScript выполняется на стороне браузера. И любой зашифрованный код всегда можно расшифровать, если знать принципы работы браузера. Поэтому можно попробовать лишь затруднить понимание данного кода, а это, в свою очередь, очень сильно помешает злоумышленнику модифицировать его под свои нужды.
Итак, есть несколько вариантов защиты кода:
Крипторы приводят код в нечитаемый вид, используя, как правило, base64 (что неизбежно приводит к увеличению объёма кода примерно на 30%). Затем к полученному результату прибавляется так называемая «соль» — набор символов, который при разборе кода функцией-дешифровщиком используется в качестве ключа. Ну а потом вся строка кода обычно выполняется через eval(). Проблема крипторов в том, что если понять принцип их работы, отсечь «соль» и декодировать, то сразу становится доступен весь код в его исходном виде.
Обфускаторы же изменяют сам код, вставляя между операторами нечитаемые символы, меняя имена переменных и функций на набор визуально непонятных символов. При этом объём кода также сильно увеличивается из-за вставки дополнительного псевдокода, а также замены символов на hex, когда любые символы переводятся в их hex-значения (например, латинская буква ‘e’ может быть записана как ‘\x65’, причём это прекрасно интерпретируется любым браузером). Можете посмотреть, как работает перевод в hex через любой сервис Text To Hex, например на Crypt Online.
Также есть всем известный Closure Compiler от Google, который кроме минимизации анализирует JavaScript-код, удаляет мёртвый код, переписывает и сводит к минимуму то, что осталось. Он также проверяет синтаксис, ссылки на переменные и типы и предупреждает об общих ошибках JavaScript. Имеет хорошо документированный API.
Кроме предложенных методов можно сделать следующее:
Всё это, разумеется, не станет стопроцентной защитой. Тем не менее чем сложнее процесс дешифровки, тем больше шансов, что после множества неудачных попыток любители копировать чужой код оставят ваш сайт в покое.
Зашифровка кода на примере JavaScript-калькулятора
Не так давно я разработал JavaScript-калькулятор для расчёта стоимости услуг, с большим количеством взаимосвязанных параметров. Руководство поставило задачу защитить данный скрипт от копирования, чтобы конкуренты не смогли использовать его на своих сайтах. Искал различные решения, ничего подходящего не нашёл, поэтому начал писать собственное. Представляю его ниже.
Обращаю ваше внимание на то, что любой код можно расшифровать, просто для этого нужно время. Поэтому данное решение, разумеется, не идеально. Тем не менее, чтобы его раскрыть, требуется время, внимательность и усидчивость. И это может оттолкнуть ваших конкурентов от идеи скопировать ваш скрипт. Большинство из них после нескольких неудачных попыток просто будут искать аналог похожего скрипта на других ресурсах.
По итогам работ в браузере вы увидите нечто такое:
При этом все зашифрованные скрипты будут работать корректно. Опытный взгляд программиста сразу визуально определит кодирование через base64. Но при попытке расшифровать строку любым base64 декодером, будет ошибка. Если вставить скрипт в alert (такой метод также рекомендуют на форумах для дешифровки кода), то результат также будет нулевым.
При этом никто ведь не знает, что здесь зашифрован именно скрипт. Это может оказаться какой-то параметр, текст или изображение. Через base64 можно зашифровать всё что угодно.
На этом месте многие закончат попытки расшифровки и оставят ваш сайт в покое.
Рассмотрим алгоритм подробнее.
Как защитить JavaScript от копирования на своём сайте
Первым делом указываем в футере сайта путь на скрипт и тут же кодируем его:
Добавление строки ‘K’ (это может быть любая латинская буква или комбинация букв или цифр) защищает нас от того, что желающий скопировать ваш скрипт расшифрует его с помощью alert() или онлайн-дешифратора. Ведь с дополнительными символами скрипт не будет работоспособен.
Затем где-то дальше в коде вызываем скрипт:
Пусть этот скрипт вызывается отдельно, подальше от других скриптов и ссылок на скрипты.
Далее где-то в файле с общими скриптами сайта, отдельно от других скриптов, вставляем вызов функций дешифровки. Вставлять можно независимо от других функций и библиотек.
Разбираем подробно что здесь происходит.
[] (это равно 1 в зашифрованном виде), которая извлекает из s строку начиная с первого символа и до конца. Следовательно, если мы в PHP-коде в качестве строки прибавляли более одного символа, скажем три, то нам нужно будет в функции substring() указать 2+(-
Пример замены цифр через побитовый оператор
Попробуйте ввести это в консоли браузера и вы увидите, что на самом деле делает эта функция. Например, вы увидите:
Вы уже догадались, что нужно сделать? 🙂 Выполните в консоли браузера и вы увидите:
Здесь, думаю, уже объяснять ничего не надо. Все мы знаем, что функция eval() выполняет скрипт, полученный из строки. «Плохая практика», как сказали бы многие, для обычного кода, но в нашем случае это безопасная и нужная функция для реализации нашей идеи. К тому же напрямую к этой функции пользователь не сможет получить доступ.
Наверное, вы задались вопросом, а каким же образом функции зашифрованы в наборе символов? Очень просто: набор символов — это текст, преобразованный в шестнадцатеричную систему счисления. Т.е. это текст в формате hex (hexadecimal), в котором можно зашифровать любые символы.
Таким образом, наша расшифрованная функция выглядит так (специально разбил по строчкам, чтобы было наглядно):
Всё будет работать как и раньше, но собьёт с толку нехороших копипастеров.
За материал благодарим нашего подписчика Дениса Лисогорского
Техники обфускации кода при помощи LLVM
Введение
Статья несет в себе больше теории, чем практической составляющей и предполагает наличия определенных знаний у читателя, а так же желание решать интересные задачи самому, не получая готовых решений. Большинство инструкций в LLVM IR базируется на трехадресном коде, это значит, что они принимают два аргумента и возвращают одно значение и что количество доступных нам инструкций ограничено.
Что возможно реализовать при помощи LLVM?
1) Cлучайный CFG
Данный метод модифицирует граф исполнения программы дополняя ее базовыми блоками, оригинальный стартовый блок может быть перемещен, разбавлен мусором.
Оригинальный граф 
Обфускация 1 запуск, функция main
Обфускация 2 запуск, функция main
Обфускация 3 запуск, функция main
Первый раз.
Второй раз.
8) Создание из кода псевдоциклов.
Применимо относительно функций, берется базовый блок конкретной функции, к нему добавляется еще несколько блоков для организации цикла, цикл исполняется только один раз.
9) Создается случайная виртуальная машина, весь существующий код трансформируется под нее, для меня этот пункт возможен пока что только в теории.
С чего начать изучение?
FIRST_TERM_INST ( 1)
HANDLE_TERM_INST ( 1, Ret, ReturnInst)
HANDLE_TERM_INST ( 2, Br, BranchInst)
HANDLE_TERM_INST ( 3, Switch, SwitchInst)
HANDLE_TERM_INST ( 4, IndirectBr, IndirectBrInst)
HANDLE_TERM_INST ( 5, Invoke, InvokeInst)
HANDLE_TERM_INST ( 6, Resume, ResumeInst)
HANDLE_TERM_INST ( 7, Unreachable, UnreachableInst)
LAST_TERM_INST ( 7)
// Standard binary operators…
FIRST_BINARY_INST( 8)
HANDLE_BINARY_INST( 8, Add, BinaryOperator)
HANDLE_BINARY_INST( 9, FAdd, BinaryOperator)
HANDLE_BINARY_INST(10, Sub, BinaryOperator)
HANDLE_BINARY_INST(11, FSub, BinaryOperator)
HANDLE_BINARY_INST(12, Mul, BinaryOperator)
HANDLE_BINARY_INST(13, FMul, BinaryOperator)
HANDLE_BINARY_INST(14, UDiv, BinaryOperator)
HANDLE_BINARY_INST(15, SDiv, BinaryOperator)
HANDLE_BINARY_INST(16, FDiv, BinaryOperator)
HANDLE_BINARY_INST(17, URem, BinaryOperator)
HANDLE_BINARY_INST(18, SRem, BinaryOperator)
HANDLE_BINARY_INST(19, FRem, BinaryOperator)
// Logical operators (integer operands)
HANDLE_BINARY_INST(20, Shl, BinaryOperator) // Shift left (logical)
HANDLE_BINARY_INST(21, LShr, BinaryOperator) // Shift right (logical)
HANDLE_BINARY_INST(22, AShr, BinaryOperator) // Shift right (arithmetic)
HANDLE_BINARY_INST(23, And, BinaryOperator)
HANDLE_BINARY_INST(24, Or, BinaryOperator)
HANDLE_BINARY_INST(25, Xor, BinaryOperator)
LAST_BINARY_INST(25)
// Memory operators…
FIRST_MEMORY_INST(26)
HANDLE_MEMORY_INST(26, Alloca, AllocaInst) // Stack management
HANDLE_MEMORY_INST(27, Load, LoadInst ) // Memory manipulation instrs
HANDLE_MEMORY_INST(28, Store, StoreInst )
HANDLE_MEMORY_INST(29, GetElementPtr, GetElementPtrInst)
HANDLE_MEMORY_INST(30, Fence, FenceInst )
HANDLE_MEMORY_INST(31, AtomicCmpXchg, AtomicCmpXchgInst )
HANDLE_MEMORY_INST(32, AtomicRMW, AtomicRMWInst )
LAST_MEMORY_INST(32)
// Other operators…
FIRST_OTHER_INST(45)
HANDLE_OTHER_INST(45, ICmp, ICmpInst ) // Integer comparison instruction
HANDLE_OTHER_INST(46, FCmp, FCmpInst ) // Floating point comparison instr.
HANDLE_OTHER_INST(47, PHI, PHINode ) // PHI node instruction
HANDLE_OTHER_INST(48, Call, CallInst ) // Call a function
HANDLE_OTHER_INST(49, Select, SelectInst ) // select instruction
HANDLE_OTHER_INST(50, UserOp1, Instruction) // May be used internally in a pass
HANDLE_OTHER_INST(51, UserOp2, Instruction) // Internal to passes only
HANDLE_OTHER_INST(52, VAArg, VAArgInst ) // vaarg instruction
HANDLE_OTHER_INST(53, ExtractElement, ExtractElementInst)// extract from vector
HANDLE_OTHER_INST(54, InsertElement, InsertElementInst) // insert into vector
HANDLE_OTHER_INST(55, ShuffleVector, ShuffleVectorInst) // shuffle two vectors.
HANDLE_OTHER_INST(56, ExtractValue, ExtractValueInst)// extract from aggregate
HANDLE_OTHER_INST(57, InsertValue, InsertValueInst) // insert into aggregate
HANDLE_OTHER_INST(58, LandingPad, LandingPadInst) // Landing pad instruction.
LAST_OTHER_INST(58)
Cтоит посмотреть публичные реализации обфускации кода для ознакомления.
1) Obfuscator-llvm
Реализована замена инструкций, уплотнение графа исполнения.
2) Kryptonite
Реализована замена инструкций аналогами / разложение инструкций.
Сниппеты
Для того чтобы вставить асм инструкции можно использовать llvm::InlineAsm или MachinePass, через машинные проходы можно изменять, добавлять инструкции. Неплохой пример есть тут.
Как прочесть байткод файл?
Как сделать итерацию функций в модуле?
Как проверить на принадлежность к какой-то инструкции?
Как заменить терминатор другой инструкцией?
Как сделать приведение одной инструкции к другой?
Как получить первую не phi инструкцию в базовом блоке?
Как итерировать инструкции в функции?
Как узнать используется ли инструкция где то еще?
Как получить/изменить базовые блоки на которые ссылается InvokeInst и другие?
Обфускация кода 1С
Для тех, кто «не в курсе», для чего используется обфускация:
Обфускация помогает в ситуации, когда сложному клиенту необходимо передать «Полнофункциональную разработку» с некоторыми ограничениями (до момента оплаты, например):
— у клиента не должно быть возможности править модуль;
— затруднено сопровождение/изменение/тиражирование;
— легко спрятать в модуле любые функции ограничения по сроку, среде исполнения, осуществить простую привязку к «железу»;
— должен оставаться стимул оплатить работу.
Конечно, 100% защиту даст только механизм внешних компонент 1С. Но трудоемкость обфускации минимальна по отношению к созданию внешней компоненты (достаточно обфусцировать несколько ключевых функций). После оплаты восстанавливаем исходный модуль, сопровождение идет в штатном режиме. Трудоемкость восстановления исходных модулей в ручном режиме на основании обфусцированных сопоставима по трудоемкости с разработкой аналогичных.
ПРИМЕР
Исходный код: 
Результат:
Обфускация — имя переменной случайное число + шифрование строк 
или
Обфускация — имя переменной УИД + шифрование строк 
1.Обфускация модуля/модуля формы/функции – приложения по заданным параметрам. Обфусцируются переменные:
— описанные в конструкции переменные
— описанные как параметры функции/процедуры
— анализ контекста выполнения НЕ выполняется
2. Реализована разбивка/шифрование строк по заданным параметрам.
3. При шифровании строк «По умолчанию» функция возврата пароля шифрования «прячется» в обрабатываемом модуле. Ее можно заменить своей функцией, возвращающей аппаратно-зависимый пароль (метка диска, имя машины, наличие сетевого адреса и все, что подскажет Ваша фантазия), тем самым исключить хранение пароля в модуле, реализовать простейшую защиту от несанкционированного использования защищенного модуля.
Соответственно без пароля/неправильном пароле функционал модуля будет недоступен/потерян (в случае шифрования строк).
Порядок работы:
1. В поле «Текст модуля исходный» копируем преобразуемый модуль
2. На вкладке «Параметры шифрования» определяем параметры шифрования строк, при необходимости свою функцию получения пароля
3. Нажимаем кнопку «Обработать»
4. Забираем обфусцированный модуль, заменяем «исходный».
Особенности/ограничения:
1. Обфусцированный модуль в режиме шифрования строк/разбивки может выполняться МЕДЛЕННЕЙ исходного в НЕСКОЛЬКО РАЗ, если зашифрованные строки находятся внутри циклов. ( время обработки тестового модуля обработкой «обфускации» увеличилось примерно в 2-3 раза, по отношению к «чистому» коду)
По умолчанию, новый модуль генерируется универсально. Вычисление пароля происходит при КАЖДОМ вызове расшифровки строки.
Поскольку при обфускации нет возможности автоматически определить, что обрабатываем — модуль формы/модуль приложения, то пока этот нюанс обрабатываем самостоятельно. Правка минимальна.
2. При установке режима шифрования строк разбиваются/шифруются ВСЕ строковые переменные модуля.
3. Имена функций НЕ обрабатываются.(если не указано явное переименование функций)
4. Перенос директив препроцессора, обработка областей модуля НЕ ТЕСТИРОВАЛАСЬ. Вероятно есть ошибки переноса.
6. Подготовка кода.
Может для кого-то не очевидные моменты, связанные с шифровкой строк.
Код вида : ЭтаФорма.Элементы.ИмяЭлемента.Свойство=НекоеЗначение обработка оставит «как есть»
но, если обращение к реквизитам\свойствам использовать строки: переменнаяЭтаФорма[«Элементы»][«ИмяЭлемента»][«Свойство»]=переменная
будет преобразован в: NNN***[FFF***()][FFF***()][FFF***()]=NNN****
будет преобразован в: NNN***[FFF***()]=FFF***()+FFF***()+FFF***();
NNN*** Обфусцированная переменная
«Автоматом» данное преобразование НЕ делается. Все на откуп пользователя, исходя из соображений «быстродействия» и степени «защиты» кода
7. Публикую обработку в состоянии «как есть». В моем случае, свою задачу она решила успешно. Но ошибки, конечно есть 🙂
Функцию шифровки строки, с некоторыми изменениями использовал из публикации: //infostart.ru/public/95662/
«+» нет необходимости использовать внешние компоненты
Тестировалось: 1С:Предприятие 8.3 (8.3.10.2299).
Изменения версии 0.42 от 2017.11.04
2. При обработке функций/процедур с содержимым более 500 строк возникали ошибки
2. Корректное исключение строк с комментарием из текстов запросов.
3. В некоторых случаях «терялись» логические операции в конце строки- (например логическое И)
4. При пустом значении пароля генерировался «не корректный» код. Добавлена авто-генерация пароля.
Обфускация программ
Обфускация программ — это прорывная, самая горячая сегодня, область криптографии. За последние два года написано свыше 70ти статей по этой теме, она вызывает жаркие дискуссии, создает настоящие гонки между исследовательскими группами, открывает полигон для научных изысканий. Более того, оказывается, что обфускация — фундаментальный, образующий примитив, который порождает практически всё, что мы имеем в криптографии сегодня. Разберемся, с тем что же это такое.
Давая пользователям доступ к установочным файлам программ, компании неизбежно раскрывают свои профессиональные секреты и наработки, и ничто не останавливает злобонравных конкурентов от беззастенчивого копирования и воровства чужих алгоритмов. Обратим внимание и на другой пример, это важные обновления (патчи), исправляющие ошибки в операционных системах. Почти мгновенно очередное обновление анализируется хакерами, они выявляют проблему которую это обновление чинит, и атакуют несчастных, не успевших вовремя обновиться, пользователей. 
Эти две ситуации связывает одна фундаментальная проблема, а именно: написанная человеком программа может быть человеком же и понята, проанализирована, разобрана. А что если существовал бы алгоритм, который бы мог до неузнаваемости, необратимо переделать программу при этом сохраняя ее функциональность? Так чтобы программу совершенно невозможно было бы понять, но при этом она работала бы ничуть не хуже исходной? Такой алгоритм и называется «обфусцирующий» или «обфускатор».
В распоряжении разработчиков на данный момент не существует хороших обфускаторов, а те обфускаторы, которые широко используются сегодня, весьма примитивны — они могут переставлять инструкции, заменять имена переменных, вставлять куски кода, которые на самом деле имеют нулевой эффект и делать аналогичные вещи, которые в целом можно назвать «безопасность через непонятность». Но такие обфускации при небольшом усердии легко деобфусцировать, а потому это не преграда для хороших хакеров.
Но что же конкретно мы хотим от обфускатора? «Невозможность понять программу» которую он выдает звучит весьма туманно…
В 2013 [2] году в этой области был совершен прорыв, теоретиками было вытащено на свет другое определение и предложена настоящая конструкция для него. Этот новый вид обфускатора называется «Обфускация Неразличимости» («Indistinguishability Obfuscation» — «iO»), формально: если имеются две разные программы, но с абсолютно идентичными функциональностями, то обфускации этих двух программ будут неотличимы друг от друга. То есть, если я имею программы P1, P2, такие что для любого входа x, P1(x) = P2(x), а O — это обфускатор неразличимости, который принимает на вход программу P и возвращает новую программу O(P), то невозможно будет отличить O(P1) и O(P2). То есть вы не сможете сказать, какая обфускация какой изначальной программе принадлежит, то ли O(P1) — это обфускация P1, то ли это обфускация P2. (Обфускатор O — вероятностный алгоритм). На первый взгляд, не понятно, на сколько хорош такой обфускатор. Ответ на этот вопрос, о котором рассказывается в следующих двух параграфах, сотряс сообщество криптографов.
В 2007 [3] году был исследован «лучший» обфускатор. Было предложено называть обфускатор «лучшим», если обфусцированная программа сообщает не больше информации, чем любая другая программа с той же функциональностью. И было показано, что Обфускатор Неразличимости — это и есть «лучший» обфускатор. Таким образом конструкция-кандидат лучшего обфускатора на свете уже у нас в кармане! И скоро не надо будет изощряться в перепутывании инструкций и переименовании переменных.
То есть фактически, Обфускатор Неразличимости это примитив, образующий чуть ли не всю криптографию, с помощью которого можно построить практически всё, что мы имеем в криптографии сегодня. Конечно, требуется еще много работы прежде чем обфускатор станет доступен для широкого использования, но фундамент для этого уже заложен.
