Метка «obfuscation»

Неявные предикатыРечь здесь пойдёт о некоторых аспектах компьютерной безопасности, связанных с запутыванием кода программы. Именно это мне было интересно в связи с разработкой обфускатора .NET приложений – программы для защиты .NET кода от взлома. Есть и другая – тёмная сторона: запутыванием кода очень интересуются разработчики вирусов и других нехороших штук, но нам они неинтересны.

Эмуляторы

Итак, Вы придумали супер алгоритм для запутывания кода программы. При декомпиляции код выглядит просто вырвиглазно и никто точно такое анализировать не будет. Казалось: победа! Но нет. Естественно обфусцированный код никто анализировать не будет… руками. Хакер поймёт как вы код запутывали и напишет «распутывалку». Если Ваш алгоритм был достаточно силён, то хакеру придётся писать собственный эмулятор, но и это не такая проблема как может показаться на первый взгляд – в сети есть доступные эмуляторы и даже специально написанные именно для целей взлома.

Из теории компьютерных наук известно, что не существует и никогда не будет существовать алгоритма, определяющего остановится ли программа или будет работать вечно – так называемая «проблема останова». Это гарантирует, что хакерский эмулятор, распутывающий обфусцированную программу, будет делать это как бы «локально»: он не сможет узнать состояние и значение всех переменных, задействованных в каждом участке кода и поэтому в точках условного ветвления часто будет полагать, что возможны все варианты хода программы. Вот тут-то на ум и приходит решение: запутанный код будет наполнен переходами по условиям, которые будут всегда истинны, но проэмулировать и понять это будет трудно. Примерно вот так:

if ((x*x & 1) == 0)
  good_code
else
  мусор

«Но это же как раз одна из тех запутывалок, которые хакер и собирается обходить с помощью эмулятора» — скажете Вы и будете правы. А что если придумать тысячу подобных фокусов? О, это решение, если у Вас есть легион программистов, каждый из которых придумывает трюки не похожие на трюки других. В реальности это не так. В реальности Вы думаете неделю и придумываете тридцать трюков, а хакер смотрит на код один день и находит все тридцать трюков, потому что тридцать – это не так уж много.

Читать полностью »

enigma
Представьте, что Ваше приложение нагло крадут и выкладывают в сеть. И никак не понять, кто из честнейших клиентов допускает утечку. Выход ясен: достаточно просто выдавать клиентам приложения с различными версиями и по версии определять утечку.

Но что если ситуация усложнилась, и Вашу программу на этот раз крадёт хакер, и он уж позаботится, чтобы вычистить все следы, идентифицирующие программу. На такой случай разработаны универсальные методы внедрения в приложение секретных данных, так называемых водяных знаков или вотермарок (калька с английского watermark).

Мы рассмотрим здесь только Watermark'и предназначение которых – ни при каких условиях не быть удалёнными, чтобы создатель приложения имел возможность считать их после любых атак потенциального злоумышленника, а пользователи приложения о них не догадывались. Есть и другие виды вотермарок, предназначенные, например, для отслеживания изменений в приложении, эдакие скрытые чексуммы, и они также должны быть сложно удаляемы, но это уже другая история.

Самый лучший Watermark

Прекрасный способ внедрения Watermark в приложение – это пофантазировать и придумать место, где никакой хакер Вашу вотермарку искать не будет: просто побоится потонуть в тоннах кода и забросит это дело. Если Вы разрабатываете визуальное приложение, то ничего не мешает менять цвет пикселя спрятанного в углу какой-нибудь кнопки в Богом забытом диалоговом окне. Цвет пикселя и будет вотермаркой. К сожалению такой случай не всегда приемлем и разработчикам удобнее воспользоваться каким-нибудь универсальным решением для внедрения вотермарки в уже скомпилированное приложение. Традиционно такую функцию встраивают в обфускаторы.
Читать полностью »

Как всё начиналось

Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.

Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.

Проект являлся библиотекой, функции которой использовались в одном из модулей расширения в крупном программном комплексе. Программный комплекс был написан на C++, являлся коммерческим продуктом, имел защиту с аппаратным ключом и поставлялся клиентам без предоставления исходных кодов.

Здесь сразу обозначилась новая проблема: как защитить исходные коды нашей Python-библиотеки? Может быть, в ином случае никто бы не стал этим заниматься, я бы уж точно, но в библиотеке были реализованы некоторые ноу-хау, и руководители проекта не хотели, чтобы данные наработки попали к конкурентам. Так как я был одним из исполнителей, мне пришлось озаботиться данной проблемой. Далее я постараюсь рассказать об основной идее, что из этого вышло, и как нам удалось скрыть Python-исходники от лишних глаз.
Читать полностью »

Stringer Java Obfuscation Toolkit - Android ProtectionУважаемое Хабр-сообщество, хотел бы рассказать об одном из продуктов, который мы разрабатываем — Stringer Java Obfuscation Toolkit (https://jfxstore.com/stringer). Думаю многим Android и Java-разработчикам будет интересно, особенно, в свете подобных публикаций: habrahabr.ru/post/141522/.

Сразу скажу, что решение коммерческое, чтобы сэкономить кому-то, из читающих этот пост, время.

За прошлый, почти полный, год, мы сделали довольно много интересных вещей:


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js