Леонид, дело в том, что например для меня написать "обращальщик" для конкретно вот этого алгоритма скорее всего не составит большого труда - во многом потому что внутренние смещения в объектнике для декомпилятора совершенно неважны - это для рантайма они играют роль (т.е. "расшифровщик" может быть существенно проще "шифровальщика"). Более того, мне почему-то кажется, что написать исправлялку для "испорченной" таблицы методов (которая вроде как ломает даже корсо, не говоря уж о рефоксе) будет даже более сложно чем эти байтики схлопнуть (во многом потому я и не стал объектник восстанавливать до "приемлемого" рефоксу или ещё кому вида). Вот если они будут закрыты ВНЕШНИМ ключом, и за этим ключом придётся лезть в другой модуль - это будет совсем другая песня! Если бы не "необоримая" инъекция злобного дамп-кода, то именно эта зависимость от ключа хранящегося в другом месте делает сложным (по крайней мере достаточно трудоёмким) распаковку собственно exe-ника закрытого дефоксом, и возможно что во многом по этой причине (ну о более мощной и печальной причине я промолчу) не видно нигде "офлайн распаковщиков" закрытых дефоксом программ. Так что если алгоритм будет более изуверским и, главное, зависимым от внешнего, хорошо спрятанного ключа (желательно с хорошей долей динамики - т.е. не 1 единственный ключ на всю прогу и большим размером - т.к. 16-бит это несерьёзно - перебором ищется на раз) - то это IMHO повысит степень защиты. Хотя... Мне кажется что в любом объектнике (даже этом, из 15 строк) можно найти Known PlainText - т.е. "угадать" какой же там опкод должен быть - и на этой основе провести атаку (возможно даже перебором) на ключ. А уж зная сам аглоритм и ключ...
Ну да ладно, не буду больше расстраивать

P.S. Совсем забыл, хотя думаю что ты и так в курсе. Эта версия не дружит с DEP-ом.

Жаль что я не в курсе ваших дебатов, тема обфускации весьма интересна, но я совершенно не знаю фоксовские внутренности. Хочу предложить, вернее обсудить одну идею. Пусть защита переводит фоксовый байт-код в свой формат виртуальной машины. Эта виртуальная машина навешивается на экзешник и в экзешнике хранится только код виртуальной машины. При выполнении экзешника виртуальная машина переводит из своего формата в фоксовский байт-код и этот код отдает уже фоксовскому рантайму. Т.е. речь идет по сути о том, чтобы "спрятать" преобразование "исходник - байт-код" под преобразованием "исходник - байт-код фокса- байт-код неизвестной виртуальной машины".

Igor Korolyov
Ну да ладно, не буду больше расстраивать

Игорь, ты меня этим вовсе не расстраиваешь. Я специально выставил этот пример еще не написав никакого алгоритма зашифровки, чтобы обсудить, как лучше это сделать.

Цитата:

Леонид, дело в том, что например для меня написать "обращальщик" для конкретно вот этого алгоритма скорее всего не составит большого труда - во многом потому что внутренние смещения в объектнике для декомпилятора совершенно неважны - это для рантайма они играют роль (т.е. "расшифровщик" может быть существенно проще "шифровальщика").

Да, Игорь, это все конечно так, но согласись, что "обращальщик" нужно все-таки писать зная кое-что о внутренностях fxp, да и использование dvfp тоже не так уж просто. А вот написать "обращальщик", который доводит до уровня Рефокса уже совсем нетривиально.

Цитата:

Более того, мне почему-то кажется, что написать исправлялку для "испорченной" таблицы методов (которая вроде как ломает даже корсо, не говоря уж о рефоксе) будет даже более сложно чем эти байтики схлопнуть

А мне кажется, что это совеошенно то же самое, разница только в способе, каким определяется замененный байт. При "испорченной" таблице нужно просто найти соответствие, что при одной таблице не так уж трудно, а потом уже все будет ничуть не сложнее, даже проще.

Цитата:

Так что если алгоритм будет более изуверским и, главное, зависимым от внешнего, хорошо спрятанного ключа (желательно с хорошей долей динамики - т.е. не 1 единственный ключ на всю прогу и большим размером - т.к. 16-бит это несерьёзно - перебором ищется на раз) - то это IMHO повысит степень защиты.

Ключ должен быть единственным во всех модулях, которые вызываются из данного экзешника. Во время расшифровки никак не определить, какой ключ использовать. А вот сделать его побольше - нет проблем. Я предполагал его сделать 4 байта, но можно сделать 5 или 6.

Цитата:

Хотя... Мне кажется что в любом объектнике (даже этом, из 15 строк) можно найти Known PlainText - т.е. "угадать" какой же там опкод должен быть - и на этой основе провести атаку (возможно даже перебором) на ключ. А уж зная сам аглоритм и ключ...

А теперь насчет алгоритма. Допустим у нас есть общий n-байтный ключ и каждый op-код шифруется n-байтным кодом. При расшифровке ключ и шифр xor-ятся и полученные n байт используются для получения нужного байта с помощью какого-нибудь нелинейного алгоритма. Допустим хакер знает алгоритм, но не знает ключ. Допустим также, что он смог угадать несколько op-кодов, т.е. он знает несколько шифров и результат, который должен для них получиться. Сдается мне, что если правилино подобрать алгоритм, то при такой раскладке ключ можно будет найти только полным перебором, что при n=6 уже становится совершенно нереальным. В этом случае добывать ключ хакеру придется копаясь в каждом конкретном приложении. А если его хорошо спрятать, то это практически исключит написание какой-нибудь общей утилиты.


P.S. Насчет DEP. С удивлением обнаружил, что у меня на компьютере DEP был отключен, поэтому я ничего и не заметил. Сейчас включил, и у меня он тоже стал ругаться, но пока не понял почему. Вроде я все запихивал в ту же кучу, что и все остальное. В общем буду еще копаться.

leonid
да и использование dvfp тоже не так уж просто

В "чистом" виде он прост как валенок, но и ограничен (автор пишет что это нарочно - дескать ежели кто-то шифровал исходник, то я его не собираюсь "ломать"),но я имел в виду использовать часть его codebase для декодирования внутренней части объектных модулей - собственно их парсер у меня свой имеется, и даже местами чуть более "точный" чем в dvfp.

leonid
А вот написать "обращальщик", который доводит до уровня Рефокса уже совсем нетривиально.

Почему это вдруг? Если объектник "разложен" до уровня голых процедур/описаний классов, то "собрать" всё обратно, прописав полностью с нуля все таблицы-блоки (модулей, процедур и т.п.) не составляет труда. корсо даже имеет вкладочку для "навешивания" некоторых из таких структур на "обрезанный" объектник.

leonid

Цитата:

Более того, мне почему-то кажется, что написать исправлялку для "испорченной" таблицы методов будет даже более сложно

А мне кажется, что это совеошенно то же самое

Ну это если оно портится "статически" - т.е. единообразно для всех модулей, если же там есть "динамика" - где-то после первой процедуры вставляется "мусорный" блок, где-то после 5-й... Т.е. нужен более сложный анализ - где корректный блок а где "левак".

leonid
Ключ должен быть единственным во всех модулях, которые вызываются из данного экзешника. Во время расшифровки никак не определить, какой ключ использовать.

Не определить какой fxp используется? Но это не есть препятствие - прямо в шифро-байтиках можно индекс ключа держать

leonid
А теперь насчет алгоритма.

Ну n не сделаешь же "достаточно большим" - вот в чём проблема. Впрочем, как не математик, и тем более не криптоаналитик я могу сильно заблуждаться насчёт устойчивости сотен тысяч мелких шифротекстов, закрытых одним ключом... Возможно действительно есть такой алгоритм - при том, конечно, желательно чтобы он был криптостоек - т.е. его знание не помогало бы (без перебора) подобрать ключ по известному PlainText. Ну или как минимум требовало знания больше чем 2-3 кусочков PlainText-а.

leonid
В этом случае добывать ключ хакеру придется копаясь в каждом конкретном приложении.

Именно так - в этом и состоит сложность оффлайн дешифрации дефоксовой программы. Для этого приходится как минимум пошагово оттрассировать защитный блок.

2 medstraxКак это ни странно, но именно такой способ защиты и применён в новой версии. Шифровка уже не только "блоков" fxp/scx и прочего, а прямо байт-кода внутри блока. Т.е. даже наличие "расшифрованного" fxp (что, к сожалению, слишком уж просто получается используя инъекцию своего кода в защищённую программу) не позволяет напрямую скормить его тому-же рефоксу - он банально не увидит существенной части команды, т.к. её p-код зашифрован.

Igor Korolyov

leonid

Цитата:

Более того, мне почему-то кажется, что написать исправлялку для "испорченной" таблицы методов будет даже более сложно

А мне кажется, что это совеошенно то же самое

Ну это если оно портится "статически" - т.е. единообразно для всех модулей, если же там есть "динамика" - где-то после первой процедуры вставляется "мусорный" блок, где-то после 5-й... Т.е. нужен более сложный анализ - где корректный блок а где "левак".

Игорь, похоже здесь я тебя просто неверно понял, и говорил о чем-то другом.

Цитата:

leonid
Ключ должен быть единственным во всех модулях, которые вызываются из данного экзешника. Во время расшифровки никак не определить, какой ключ использовать.

Не определить какой fxp используется? Но это не есть препятствие - прямо в шифро-байтиках можно индекс ключа держать

Но ведь это можно считать, что имеется один ключ, только более длинный, а индексы - это элементы шифра. Т.е. в принципе это то же самое. Может быть удлинить ключ имеет смысл. Надо подумать.

Цитата:

Ну n не сделаешь же "достаточно большим" - вот в чём проблема.

По-моему, делать n (длина кода для каждого op-кода) больше 6 не имеет смысла, а 6 сделать не проблема.

Цитата:

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

Допустим у нас есть таблица длиной 64 Kb содержащая каждый байт 0 - 255 по 256 штук и перемешанная случайным образом. Пусть также n=6 и для кода op-кода и для ключа. Сначала xor-им ключ и код. Из полученного результата берем первые два байта, считаем их индексом в таблице и находим по ним новый байт. Берем этот байт и третий байт результата, считаем эти два байта индексом, и по ним находим еще один байт. И так, пока не дойдем до конца результата. Последний байт и используем в качестве op-кода. Допустим хакер знает и алгоритм, и таблицу, и несколько >6 кодов и соответсвующих им op-кодов. По идее такая задача должна иметь математическое решение, но не имею ни малейшего представления, как такую задачу даже пробовать решать. Полный перебор - это 2^48 значений, не дождешься. Возможно, есть какие-нибудь математические хитрости, позволяющие существенно сократить перебор. Не знаю. Сразу в голову тоже ничего не приходит. Еще одно преимущество этого способа - шифрование тоже осуществляется достаточно просто. Конечно, не охота таскать с каждым файлом лишние 64 Kb, но наверное, нетрудно придумать простенький алгоритм, который будет таблицу с такими свойствами генерить.

leonid
Но ведь это можно считать, что имеется один ключ, только более длинный

В приницпе да - я исходил и того, что успешный взлом 1-го опкода в таком случае деёт лишь 1 маленький кусочек ключа. Хотя, это лишь мои ничем не обоснованные предположения

leonid

Цитата:

Ну n не сделаешь же "достаточно большим" - вот в чём проблема.

По-моему, делать n (длина кода для каждого op-кода) больше 6 не имеет смысла, а 6 сделать не проблема.

Именно так - а заодно ещё и саму функцию наверное не сделаешь мега-защищённой - всё-же вызываться она будет очень часто - вот частично полиморфной - это да, это неплохо было бы (дабы не так просто было написать подключаемый к работающей проге "модуль извлечения ключа"). Я вообще думаю, что лучше всего оставить её суть открытой - использовать какой-то общеизвестный криптоалгоритм - а защищать только ключ (код его распаковки, и место хранения в памяти - так что таблица на 64К сразу отпадает - он должен быть небольшим - 256 бит по идее уже даёт неплохой результат. Как минимум без "живой" отладки тогда его будет сложно достать что из файла, что из дампа памяти, а количество владеющих тем-же OllyDbg фоксовиков пренебрежимо мало

leonid
Допустим у нас есть таблица длиной 64 Kb ... нетрудно придумать простенький алгоритм, который будет таблицу с такими свойствами генерить.

Такая "таблица" по сути есть простая "оптимизация" алгоритма шифрования - т.е. результат зависит исключительно от шифротекста и "задающего числа", которое по сути и есть ключ... Да, надо почитать теорию насчёт применимости тех или иных алгоритмов шифрования к такой задаче - с массой очень мелких "сообщений" без их взаимосвязи... Как помнится алгоритмы то в основном блочные, и размер их блока несколько великоват, по сравнению с 4-6 нашими байтами - а "потоковый" шифр тут неприменим т.к. порядок поступления на обработку шифроблоков неопределён... Возможно стоит попробовать для начала DES, как наиболее простой/быстрый из более-менее "серьёзных" алгоритмов.

Да, кстати, если ещё сам не нашёл
Ошибка DEP вызвана не машинным кодом в куче, а строчкой
В месте "новой" инъекции. Т.к. это .text секция - основной код рантайма - то с неё нельзя снимать атрибут EXECUTE, и при том продолжать выполнять фоксовый код до точки "возврата" атрибутов в прежнее состояние

Да, Игорь, за DEP спасибо. У меня как-то времени не было, даже не посмотрел. Конечно же так писать нельзя было. Зато исправить легко: всего-то 4 на 0х40 заменить. Насчет алгоритма, попробую за недельку чего-нибудь наклепать. Если все пойдет нормально, на следующие выходные чего-нибудь покажу.

Игорь, в этом варианте реализован новый алгоритм, а код пока еще никак не спрятан. Глянь, легко ли восстановить код, если считать, что его подсмотреть нельзя. Пример абсолютно тот же самый, что и в прошлый раз.

Леонид, чес слово - не знаю. Не владею я криптоанализом Понял что тут только замены идут (нет перестановок, шифротекст не обрабатывается "блоком" а побайтно), таблицу увидел - функцию её генерации даже не искал... Полагаю что она генерится на основе части ключа (т.е. разная для разных exe-ников). Ключик 6-байтный увидел, но он банально XOR-ится с шифротекстом... Повышает ли это существенно его "значимость" или нет - даже не знаю.
Очевидно если бы я ломал программу, то в силу отсутствия навыков просто в отладчике снял таблицу (абсолютно невероятно чтобы она генерировалась при каждом обращении к декодеру - т.к. тогда каждая фоковая команда будет по пол-секунды работать) и искал потом 6 байт ключа для XOR-а (в замудрённом "антиотладочном" коде, как я понимаю) - но это никак не говороит в пользу надёжности самого алгоритма - просто играет роль моя тупость в этой области... Я так полагаю, что именно этого результата ты и добивался - но не стоит ориентироваться на меня как на какой-то "критерий простоты/сложности" - у меня даже нету математического образования





Исправлено 1 раз(а). Последнее : Igor Korolyov, 15.09.10 00:32

Igor Korolyov
Леонид, чес слово - не знаю. Не владею я криптоанализом

Ну, я, по большому счету, тоже.

Цитата:

таблицу увидел - функцию её генерации даже не искал... Полагаю что она генерится на основе части ключа (т.е. разная для разных exe-ников).

Вот как раз нет. Таблицу я собираюсь сделать одну и ту же всегда во все времена. Особобого смысла прятать ее нет - по любому ее достать будет намного проще, чем ключ, а если бы она генерилась на основе ключа, то в ней бы содержалась дополнительная информация для определения этого самого ключа.

Цитата:

Ключик 6-байтный увидел, но он банально XOR-ится с шифротекстом... Повышает ли это существенно его "значимость" или нет - даже не знаю.

Алгоритм такой, что он из 48-битной строки делает один байт, причем, существует 2^40 строк, из которых заданый байт можно получить. Допустим мы знаем один 6-байтный шифротекст и соответствующий ему байт. Мы легко можем найти 2^40 ключей, которые после xor-а с шифротекстом и применения алгоритма дают нужный байт. Но такое количество возможных ключей даже на винчестер записать будет трудно. Если у нас есть несколько шифрокодов и соответствующие им байты, то совершенно не видно, как их можно использовать совместно, чтобы снизить число 2^40. По крайней мере, я бы как и ты лучше полез отладчиком искать ключ.

Цитата:

Я так полагаю, что именно этого результата ты и добивался - но не стоит ориентироваться на меня как на какой-то "критерий простоты/сложности" - у меня даже нету математического образования

Да, именно этого я и стараюсь добиться. По крайней мере на данный момент у меня нет информации, что кто-то кроме тебя залез внутрь предыдущего Defox-а, а здесь вряд ли будет проще. Кстати, насчет математического образования, по некоторым твоим постам я думал, что у тебя такое есть.

leonid
Вот как раз нет. Таблицу я собираюсь сделать одну и ту же всегда во все времена.

Н-да, я понимаю что у неё имеются "особые" свойства распределения, и, вероятно, сложно сделать функцию формирования "подходящей" таблицы.

leonid
если бы она генерилась на основе ключа, то в ней бы содержалась дополнительная информация для определения этого самого ключа.

Я думал что у тебя 64 битный ключ, из которого 48 бит идут прямо на XOR а по первым 16 и строится эта таблица

leonid
Алгоритм такой, что он из 48-битной строки делает один байт

Да сам этот алгоритм то не вызывает трудностей в понимании...

leonid
Если у нас есть несколько шифрокодов и соответствующие им байты, то совершенно не видно, как их можно использовать совместно

Именно над этим я и думаю сейчас. Разворачивая шифротекст "с хвоста", мне стало казаться что число вариантов-кандидатов не растёт и составляет не более 256 (постоянно отбрасывается существенная часть) но пока я даже сформулировать не могу метод анализа...
Кроме того возникла совершенно безумная идея - попытка угадать опкод по незашифрованной части команды (по параметрам/выражениям/опциям) - но т.к. я совершенно не в курсе деталей реализации этой части в фоксовом компиляторе, то идея может действительно быть не более чем глупостью

Igor Korolyov
Н-да, я понимаю что у неё имеются "особые" свойства распределения, и, вероятно, сложно сделать функцию формирования "подходящей" таблицы.

Нет Игорь, ничего особого, просто случайное распределение с условием, что каждый байт встречается ровно 256 раз.

Цитата:

Я думал что у тебя 64 битный ключ, из которого 48 бит идут прямо на XOR а по первым 16 и строится эта таблица

Это можно сделать, и даже наверное не очень трудно, но я не вижу большого смысла это делать, ведь хорошо спрятать ее все равно не получится.

Цитата:

Именно над этим я и думаю сейчас. Разворачивая шифротекст "с хвоста", мне стало казаться что число вариантов-кандидатов не растёт и составляет не более 256 (постоянно отбрасывается существенная часть)

Нет Игорь, там при зашифровке выбирается случайная 40-битная строка и применяется "обратный" алгоритм а потом xor-ится с кодом. Если я правильно понимаю при разных строках будут получаться разные шифро-коды. Даже если это не так, случайных совпадений будет не очень много, так что число будет заведомо большое.

Цитата:

Кроме того возникла совершенно безумная идея - попытка угадать опкод по незашифрованной части команды (по параметрам/выражениям/опциям) - но т.к. я совершенно не в курсе деталей реализации этой части в фоксовом компиляторе, то идея может действительно быть не более чем глупостью

Некоторые опкоды так действительно можно угадать, но думаю, что никак не больше половины. А некоторые угадать заведомо нельзя. Так, ты никогда не отличишь clear от skip, или skip 1 от go 1, ну и т.п. А декомпиляция модуля, у которого известна половина опкодов на мой взгляд достаточно бессмыслена.

leonid
там при зашифровке выбирается случайная 40-битная строка

Все равно приходите к инициализатора ранодомайзера который будет генерять сам ключ, как не верти так и получается

Вадим, не понял я к чему это ты? Хочешь сказать что ключ в любом случае "неслучайный"? Или что эти примешиваемые байты неслучайны? Первое легко устранить простыми "источниками энтропии" (банально мышку 5 секунд повозюкать и на основе трека/координат получить более чем хорошее "случайное число"), второе возможно и приводит к уязвимости, если особенности (та-же периодичность) ГПСЧ неблагоприятно накладываются на особенности алгоритма шифрования - но напрямую это не поможет, т.к. изначально я исхожу из того что можно "угадать" лишь 1 байт опкода, но никак не 5 байт "примешанного" к нему мусора...
Пока не нашёл подтверждения идеи, попытки "урезать" массив вариантов ключей не проходят - т.е. "известный конечный байт" лишь сокращает брутфос с 2^48 до 2^40. Но я ж не криптоаналитик вовсе - могу и очевидное пропустить Надо попробовать анализ на 2-х идентичных опкодах с разным шифротекстом...

Видимо я не до конца понял. Извиняюсь

У меня для генерации случайных строк используется SystemFunction036. Ей инициализации не надо, да и рандомизацию она дает значительно лучшую, чем фоксовский rand().

А вот это очень ценная информация! Во-первых не знал что можно так просто получить криптографически стойкий ГПСЧ, во-вторых теперь даже не буду пытаться найти уязвимость по части "предсказуемости" и "периодичности" этих самых невидимых задающих бит... Кстати, что они при кодировании выбирают? "порядковый номер" (один из 256-ти возможных) требуемого байта в массиве?

А теперь из неприятного - т.к. этот кусочек кода является абсолютно критичным ко времени исполнения, то я боюсь что "как следует" спрятать ключ не получится - "антиотладка" применяемая в 3-й версии для защиты той-же "таблицы ключей модулей" (в принципе достаточно быстро взламываемая даже нубом в ассемблере и машкодах - эт я про себя ) для такой функции IMHO не подойдёт А из-за "статической" природы иньекции этой функции, я думаю будет возможно нарисовать программку прямо из памяти работающей проги снимающую и всю ключевую таблицу (действительно нет особого смысла её "разнообразить", хотя примитивное "перемешивание" блоков скажем по 256 байт для каждого нового exe не так уж и сложно сделать - как я понимаю это не ухудшит статистические параметры всей таблицы - она довольно "равномерна") и сам этот 6-байтный ключ (даже без использования собственно отладчика, просто через ReadProcessMemory)... Не знаю, возможно от этого помогает CryptProtectMemory (и обратная "когда надо"), и как работает отладчик с памятью таким макаром защищённой - но я опасаюсь что по скорости это может оказаться неприемлемым - но тут только тестирование покажет.

Igor Korolyov
Кстати, что они при кодировании выбирают? "порядковый номер" (один из 256-ти возможных) требуемого байта в массиве?

Ну конечно.

Цитата:

в принципе достаточно быстро взламываемая даже нубом в ассемблере и машкодах - эт я про себя

Игорь, а кроме тебя, мо-моему, туда так никто и не залез. По крайней мере у меня на этот счет нет никакой информации.

Цитата:

А из-за "статической" природы иньекции этой функции, я думаю будет возможно нарисовать программку прямо из памяти работающей проги снимающую и всю ключевую таблицу

Вот это я не сомневаюсь.

Цитата:

и сам этот 6-байтный ключ (даже без использования собственно отладчика, просто через ReadProcessMemory)...

А вот это я и постараюсь пресечь.

Цитата:

но я опасаюсь что по скорости это может оказаться неприемлемым - но тут только тестирование покажет.

К сожалению, такие опасения у меня тоже есть, так что буду пробовать и искать компромисс.