Здравствуйте, nen777w, Вы писали:

N>>>Вопрос ALL.
N>>>Как бы вы построили защиту будь у вас следующий инструментарий:

DM>>У меня как раз такой есть уже несколько лет.
N>Круто, спасибо почитаю! Я кстати читал вашу статью об этом.

На сайте там совсем старинное решение описано, в ЖЖ более свежее, с другой ВМ и компилятором. Потом к нему еще и JIT прикрутил, но не для использования в защите.

N>Но у меня язык более низкоуровневый, фактически ассемблер для VM и да, писать на нем большие программы сложновато, зато x32/x64, win/linux/osx.

Я тоже на всех этих платформах использовал. ВМ с байткодом тем и хороша, что элементарно переносится.

DM>>проверка регистрационных ключей,
N>Я правильно понимаю что речь идет о способе который вы когда то тут советовали Ax=b?

У меня сделано чуть сложнее, но смысл тот же, да.

N>Хотел кстати спросить относительно этого способа и его надежности.
N>Ведь по сути встраивая пару уравнений из A остальные можно сгенерировать (если взломщик поймет что решается СЛАУ) т.к. x- вектор преобразовывания каких-то пользовательских данных и b-ключ (в котором для совместимости по версиям присутсвуют все решения уравнения) у ломающего есть.
N>Сгенерить A вроде бы не представляет никакого труда.
N>Или может я что то упускаю?

Пусть А — матрица 2х2, взломщику известен ее первый ряд, вектора x и b,

(a_00 a_01)   (x0)   (b0)
(a_10 a_11) * (x1) = (b1)

Тогда у него остается уравнение
a_10*х0 + a_11*х1 = b1.
В вещественных числах есть бесконечно много вариантов a_10 и a_11, которые могут подойти. Как узнать, какой из них правильный? Ведь если какой-то набор подходит для данных x и b, это не значит, что подойдет и для других. В целых числах решений поменьше (поэтому у меня не в чистом виде умножение), но в общем случае тоже дофига.
Если матрица А размером 16х16, и взломщику известны 4 ряда, то остается 12 уравнений с 12*16=192 неизвестными.

DM>>Защиту эту ломали, не вникая в байткод ВМ, а только эмулируя внешние условия, чтобы он думал, что все хорошо (подменяли определение даты, чтение файлов, чтобы при проверке проверялся оригинальный файл, а не взломанный и т.д.)
N>Тут не совсем понятно. Можно подробней откуда ожидать удара, если кончено это не много писать.

Программа получается из двух частей: нативного кода и байткода. Дизассемблера байткода у взломщика нет (и делать его лень), зато есть готовые дизассемблеры и анализаторы нативного кода. Всякое взаимодействие с ОС, вроде чтения файлов, происходит в нативном коде и хакеру видно. Если программа реагирует на модификацию себя, и видно, что она читает свой exe, то не нужно много ума, чтобы догадаться подменить этот код чтения и подсунуть ей оригинальный невзломанный exe-шник, пусть его проверяет. Аналогично с датой. Это потом уже я стал в байткоде проверять на модификацию не прочитанные из файла данные (но по-прежнему продолжал их читать для отвода глаз), а непосредственно ту область памяти, куда система загрузила работающую программу.

N>Еще кстати вопрос на счет триалов. Я тут много прочитал, но так и не понял конкретно как "красиво" его сделать.
N>Хранить где то дату, даже покриптованную не выглядит как то красиво.
N>Гараздо интереснее привязать это как то к самому бинарю. Что бы просто подменой даты, или сброса/удаление ключа не обошлось.

Тут мне самому интересно было бы узнать хорошее решение. Я просто на даты создания некоторых файлов смотрю.

Вопрос ALL.
Как бы вы построили защиту будь у вас следующий инструментарий:
— виртуальная машина (статическая библиотека линкуется с вашим приложением) определенной архитектуры
— компилятор позовляющий писать и компилировать программы в байткод виртуальной машины
— инструмент/SDK для встраивания байткода в ваше приложение (что бы виртуальная машина могда его исполнить)

Т.е. это виртуализация, но не автоматическая как например в VMProtect.

Из за особеностей и возможностей архитектуры, ЯП к сожалению на данный момент времени не совместим с C.
Т.е. взять например алогритм RSA написанный на С и попробовать скомпилировать его для VM не получится, пока.

Я пока что вижу следующие опции:
— микропрограмма для проверки целостности критических участков кода
— микропрограмма преобразующая пользовательские данные например e-mail в какой то ключ и т.д.

Что хочется: Скомбинировать этот метода защиты (ручная виртуализация некоторых алогоритмов) с допустим тем же RSA для более "хитрой" проверки ЦП.
Будут какие то идеи?

N>Что хочется: Скомбинировать этот метода защиты (ручная виртуализация некоторых алогоритмов) с допустим тем же RSA для более "хитрой" проверки ЦП.
N>Будут какие то идеи?

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

Здравствуйте, nen777w, Вы писали:

N>Как бы вы построили защиту будь у вас следующий инструментарий:
N>- виртуальная машина (статическая библиотека линкуется с вашим приложением) определенной архитектуры
N>- компилятор позовляющий писать и компилировать программы в байткод виртуальной машины
N>- инструмент/SDK для встраивания байткода в ваше приложение (что бы виртуальная машина могда его исполнить)


N>Будут какие то идеи?

Мой любимый ответ последние несколько лет — на сервер вынеси виртуальную машину, или что-то вроде того.

Здравствуйте, nen777w, Вы писали:

N>Вопрос ALL.
N>Как бы вы построили защиту будь у вас следующий инструментарий:

У меня как раз такой есть уже несколько лет.
В код, исполняемый на ВМ, вынесено:
проверка регистрационных ключей,
проверка целостности exe-шника,
генерация важных для программы данных (параметры главного алгоритма), если все ок,
восстановление важных данных во время работы, которые намеренно портятся в основном коде.

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

N>>Вопрос ALL.
N>>Как бы вы построили защиту будь у вас следующий инструментарий:

DM>У меня как раз такой есть уже несколько лет.
Круто, спасибо почитаю! Я кстати читал вашу статью об этом.
Но у меня язык более низкоуровневый, фактически ассемблер для VM и да, писать на нем большие программы сложновато, зато x32/x64, win/linux/osx.
Сейчас занят как раз С-подобной реализацией которая по замыслу должна стать фронт-эндом для существующего ассемблерного
компилятора. Т.е. C -> vpasm_source > compiler -> bytecode

DM>В код, исполняемый на ВМ, вынесено:
DM>проверка регистрационных ключей,
Я правильно понимаю что речь идет о способе который вы когда то тут советовали Ax=b?
Хотел кстати спросить относительно этого способа и его надежности.
Ведь по сути встраивая пару уравнений из A остальные можно сгенерировать (если взломщик поймет что решается СЛАУ) т.к. x- вектор преобразовывания каких-то пользовательских данных и b-ключ (в котором для совместимости по версиям присутсвуют все решения уравнения) у ломающего есть.
Сгенерить A вроде бы не представляет никакого труда.
Или может я что то упускаю?

DM>проверка целостности exe-шника,
DM>генерация важных для программы данных (параметры главного алгоритма), если все ок,
DM>восстановление важных данных во время работы, которые намеренно портятся в основном коде.
Да, это интересная идея, нужно будет подумать. Спасибо!

DM>Защиту эту ломали, не вникая в байткод ВМ, а только эмулируя внешние условия, чтобы он думал, что все хорошо (подменяли определение даты, чтение файлов, чтобы при проверке проверялся оригинальный файл, а не взломанный и т.д.)
Тут не совсем понятно. Можно подробней откуда ожидать удара, если кончено это не много писать.
Если много, то ладно.

Еще кстати вопрос на счет триалов. Я тут много прочитал, но так и не понял конкретно как "красиво" его сделать.
Хранить где то дату, даже покриптованную не выглядит как то красиво.
Гараздо интереснее привязать это как то к самому бинарю. Что бы просто подменой даты, или сброса/удаление ключа не обошлось.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, nen777w, Вы писали:

N>>Вопрос ALL.
N>>Как бы вы построили защиту будь у вас следующий инструментарий:

DM>У меня как раз такой есть уже несколько лет.
DM>В код, исполняемый на ВМ, вынесено:
DM>проверка регистрационных ключей,
DM>проверка целостности exe-шника,
DM>генерация важных для программы данных (параметры главного алгоритма), если все ок,
DM>восстановление важных данных во время работы, которые намеренно портятся в основном коде.

DM>Защиту эту ломали, не вникая в байткод ВМ, а только эмулируя внешние условия, чтобы он думал, что все хорошо (подменяли определение даты, чтение файлов, чтобы при проверке проверялся оригинальный файл, а не взломанный и т.д.)

У меня тоже самое. Сделано было как показал и разжевал D. Mon, за что ему большое спасибо. Но конечно по своему всё сделал. Что то типа С-языка с поддержкой подпрограмм даже.
И примерно таким же способом ломали, но не поломали до конца. У меня обрезанный функционал сидит внутри ВМ, и ему нужно скармливать входные данные, которые конечно всегда разные и тут эмуляция не спасет хакера. Дата тоже ведь должна меняться и если она не меняется, то ВМ считает что сломали и правильный результат не выдает.

Спасибо за детальное объяснение! <проскипал что бы не забанили>.

N>>Еще кстати вопрос на счет триалов. Я тут много прочитал, но так и не понял конкретно как "красиво" его сделать.
N>>Хранить где то дату, даже покриптованную не выглядит как то красиво.
N>>Гараздо интереснее привязать это как то к самому бинарю. Что бы просто подменой даты, или сброса/удаление ключа не обошлось.

DM>Тут мне самому интересно было бы узнать хорошее решение. Я просто на даты создания некоторых файлов смотрю.
А если так:
— зашиваем в ключ дату окончания триала. Делаем это так:
key = hash(data)^data || hash(data); ||-это конкотенация
hash() — это наша функция для взятия хеша, например модифицированный md5/sha1, написанная для виртуальной машины.

Теперь взломщик если поймет что первая часть ключа (hash(data)^data) это дата поксоренная со второй частью hash(data),
то просто взять другую дату и поксорить ее с хешом не получится т.к. виртуальная машина пересчитает хеш для даты и он не совпадет со второй половиной. Нужно будет разобраться с алгоритмом хеша.
Есдинственое что можно выкусить машину из кода с ее микропрограммой, тогда будет возможность сделать кейген для триала.

Кстати вот наше интересную статью о самопальной реализации наномитов, но сам подход проще и защищает от патчинга.
В конце там есть архив с сырками, но скачать его не получится. Я связывался с автором он сказал что сырки убрал намеренно потому что пилит комреческий продукт.
Самое ценное в этих сырках это скрипты которые он написал, в интернете даже в веб-архиве этого фафлика тоже нет .
Вот время немного есть думаю попробовать запилить свою реализацию для gcc и cl.
Потом это можно будет накатить на тот же движок VM и отсечь еще больше хрякеров от затеи отреверсить движок.

Здравствуйте, nen777w, Вы писали:

N>А если так:
N>- зашиваем в ключ дату окончания триала.

Т.е. для запуска триала недостаточно просто скачать, надо еще ключ получать? Боюсь, это усложнение часть потенциальных клиентов может отсеять. Хотя, может и зря боюсь.

N>Теперь взломщик если поймет что первая часть ключа (hash(data)^data) это дата поксоренная со второй частью hash(data),
N>то просто взять другую дату и поксорить ее с хешом не получится т.к. виртуальная машина пересчитает хеш для даты и он не совпадет со второй половиной. Нужно будет разобраться с алгоритмом хеша.

Но он по-прежнему может заставить программу думать, что дата истечения триала еще не настала?

N>Кстати вот наше интересную статью о самопальной реализации наномитов, но сам подход проще и защищает от патчинга.

Занятно, но для меня оверкилл, я лучше развитием продуктов буду заниматься, чем столько усилий на защиту тратить.

N>>А если так:
N>>- зашиваем в ключ дату окончания триала.
DM>Т.е. для запуска триала недостаточно просто скачать, надо еще ключ получать? Боюсь, это усложнение часть потенциальных клиентов может отсеять. Хотя, может и зря боюсь.
Ну вроде бы стандартная схема. Хотите триал? Качайте, вбивайте мыло куда слать ключик.

N>>Теперь взломщик если поймет что первая часть ключа (hash(data)^data) это дата поксоренная со второй частью hash(data),
N>>то просто взять другую дату и поксорить ее с хешом не получится т.к. виртуальная машина пересчитает хеш для даты и он не совпадет со второй половиной. Нужно будет разобраться с алгоритмом хеша.
DM>Но он по-прежнему может заставить программу думать, что дата истечения триала еще не настала?
Не не может.
Вот наш ключ: Key = hash(data) ^ data || hash(data), в первой части дата окончания поксоренная с хешом от нее же, во второй части тот же хеш.
Программа берет втроую часть ключа hash(data) и делает ^ с первой. Получает дату окончания.
Теперь программа проверяет а это та же дата? т.е. берет полученную дату и делает hash(data) == втрой половине ключа?
Если нет, то значит у нас хитропопый ключ. Если же крякер отреверсит функцию hash() то тогда действительно будет проблема.
Но можно этот метод скомбинировать еще с другим местом хранения ключа. Как то так...

N>>Кстати вот наше интересную статью о самопальной реализации наномитов, но сам подход проще и защищает от патчинга.
DM>Занятно, но для меня оверкилл, я лучше развитием продуктов буду заниматься, чем столько усилий на защиту тратить.
Я общался с автором он говорит что это заняло у него не больше 40 часов.
Интересно сколько займет у меня если я возьмусь.

Здравствуйте, nen777w, Вы писали:

DM>>Но он по-прежнему может заставить программу думать, что дата истечения триала еще не настала?
N>Не не может.
N>Вот наш ключ: Key = hash(data) ^ data || hash(data), в первой части дата окончания поксоренная с хешом от нее же, во второй части тот же хеш.
N>Программа берет втроую часть ключа hash(data) и делает ^ с первой. Получает дату окончания.

Я немного не об этом. Вот программа узнала, что триал истекает 10 октября. Вопрос: как она узнает, что сегодня уже 13?

DM>>>Но он по-прежнему может заставить программу думать, что дата истечения триала еще не настала?
N>>Не не может.
N>>Вот наш ключ: Key = hash(data) ^ data || hash(data), в первой части дата окончания поксоренная с хешом от нее же, во второй части тот же хеш.
N>>Программа берет втроую часть ключа hash(data) и делает ^ с первой. Получает дату окончания.

DM>Я немного не об этом. Вот программа узнала, что триал истекает 10 октября. Вопрос: как она узнает, что сегодня уже 13?
Да тут фигня... Это можно спрятать, но вот 100% защиты без стороннего сервера наверно не получится.
Вон для армадилы даже есть TrashReg пользуйся триальным VASisst-ом сколько хочешь.

Здравствуйте, nen777w, Вы писали:

N>Вон для армадилы даже есть TrashReg пользуйся триальным VASisst-ом сколько хочешь.

Может быть TrialReset? Все протекторы, которая хранят триальные метки на стороне пользователя будут "ломаться" банальным удалением этих самых меток. Единственный вариант — это хранение "триальных меток" на своей стороне посредством онлайн активации.

N>>Кстати вот наше интересную статью о самопальной реализации наномитов, но сам подход проще и защищает от патчинга.
DM>Занятно, но для меня оверкилл, я лучше развитием продуктов буду заниматься, чем столько усилий на защиту тратить.

Я вот всетаки выделил немного время и набросал простенький пример реализации наномитов (пока под Linux).
Суть такая (остальное в файлах):
— пишем тестовый пример: test_app.cpp
— компилируем в ассемблерный output:

gcc -S -test_app.cpp

— получеам test_app.s
— открываем в текстовом редакторе, находим две инструкции jmp и заменяем их на прерывания отладчика: int $3
— добавляем в конце файла еще одну секцию с нашими метками

.section .nano
.long .L2, .nano_lbl_0
.long .L1, .nano_lbl_1

— компилируем в бинарь:

gcc test_app.s -o -fpic test_app.elf

— пишем программу отладчик: debuger.cpp
— запускаем утилиту objdump для дампа нашей секции:

objdump -s -j .nano test_app.elf

— дописываем в дебагер в массив структур offset_info адреса меток:

offset_info jumps_table[] = {
        //offset      cmd_addr    flags
        { 0x00400572, 0x00400570, 0x0 }
    ,     { 0x004005a8, 0x00400599, 0x0 }
};

— компилируем наш отладчик:

gcc debuger.cpp -lstdc++ -o debuger.elf

Тестируем.
Если мы запустим приложение без отладчика, получим:

ruslan@rteliuk:~/NanomitesTest$ ./test_app.elf
Trace/breakpoint trap (core dumped)

Теперь под отладчиком:

ruslan@rteliuk:~/NanomitesTest$ ./debuger.elf
1) This output mean taht nanomites is work!

Что нужно допилить что бы это стало утилитой:
— скрипт для автоматического парсинга полученного ассемблерного output-а который бы автоматически заменял все переходы jmp, je, jg, ... на int $3 предворяя их метками и запоминая метки куда переходить + тип инструкции (что бы знать какие флаги проверять в случае условного перехода).
— посмотреть в справочнике по языку ассемблер какие флаги при этом влияют на условные переходы что бы правильно их прописать в таблице флагов (мой пример пока что только для jmp)
— скрпит который будет парсить objdump и генерировать таблицы для отладчика
— скрипт который будет проходить по бинарю (сециям кода) и везде где встретит 0xcc (int $3) сгенерирует в таблицу мусор (в адрес перехода), исключая наши.
Что бы обеспечить полноту таблиц.
— все то же самое только под Windows.

Кто готов помочь?
з.ы.
Если я где то шибаюсь поправьте plz.

deleted

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

Ну вы нам тут прямо всем глаза открыли
Триалы можно превратить в Demo, обломайся сколько хош, но если программа не умеет документы сохранять, звыняйта бананiв немаэ.
Ворованные/чарджбекнутые/валяющиеся в интернетах ключи попадают в баню и в следующих обновлениях уже не работают.
Речь больше идет о защите от страшного сна шароварщика — кейгена.
Да, есть RSA, да кейген не сделать просто так, надо патчить "вшивать свой ключ" и делать кейген. Но это не так гибко как хотелось бы, на самом деле.

deleted

Здравствуйте, rean, Вы писали:

R>А что в нем такого страшного? Любая, даже не криптографическая хэш функция с длиной ключа больше 100 бит убивает идею делать ключегенератор.

У хеш функций есть ключи???

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, rean, Вы писали:

R>>А что в нем такого страшного? Любая, даже не криптографическая хэш функция с длиной ключа больше 100 бит убивает идею делать ключегенератор.

V>У хеш функций есть ключи???

я думаю он имел ввиду длину самого хеша

deleted

Здравствуйте, necr0n0mic0n, Вы писали:

V>>У хеш функций есть ключи???

N>я думаю он имел ввиду длину самого хеша

Даже если так, то использовать хеш функцию для генерации серийников — это бред.

Здравствуйте, rean, Вы писали:

R>Для тех, кто не понял или просто троллит, предложение читать как:
R>Любая, даже не криптографическая хэш функция, работающая с числами разрядностью больше 100 бит, лежащая в основе регистрационного ключа, убивает идею делать ключегенератор.

Можете привести реальный пример такой функции чтобы не рассуждать о сферическом коне в вакууме?

deleted

Здравствуйте, rean, Вы писали:

V>>Можете привести реальный пример такой функции чтобы не рассуждать о сферическом коне в вакууме?
R>А в википедию сложно зайти? FNV, Хеш функция Дженкинса, любая самодельная, использующая перемешивание битов, или на основе генераторов псевдослучайных чисел.

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

R>Я использую вот это http://code.google.com/p/curve25519-donna/

Насколько я понимаю эта штука использует ECC и скорее всего работает как ЭЦП, а это уже ассиметричное криптование и от RSA в этом плане совершенно ничем не отличается.

R>Получаемый ключ имеет форму типа tes10-083210cq-eria8cdh-8rfyti8r-1rmprdxm
R>В нем закодированы: дата создания ключа, дата окончания действия ключа, версия и id программы,

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

deleted

Здравствуйте, rean, Вы писали:

V>>Во всех этих примерах для создания кейгена крякеру нужно будет просто идентифицировать алгоритм, которым вы "подписываете" данные серийника. Т.е. даже с ключем шифрования не надо будет замарачиваться. Если хеш функция самопальная — её можно будет выдернуть прямо из вашего ехе-ника.

R>Вы идею не поняли. Есть алгоритмы создания криптосистемы типа открытый-закрытый ключ на основе хеш функций.

А теперь откройте вики про FNV, Хеш функцию Дженкинса и посмотрите откуда у вас там вдруг взялся открытый/закрытый ключ

Здравствуйте, nen777w, Вы писали:

N>Кто готов помочь?
N>з.ы.
N> Если я где то шибаюсь поправьте plz.

Насколько я понимаю крякеру будет достаточно найти вашу таблицу, в которой закодированы флаги и адреса переходов. А дальше дело техники:
Для патча наномита достаточно будет перенести часть кода перед наномитом (будет достаточно 5-ти байт) на свободное место, на старом делаем JMP на который мы перетащили код перед наномитом, дальше после перенесенного кода вставляем правильный JMP/Jxx (по результатам реверсинга таблицы), за условным переходом делаем JMP на адрес, идущий после наномита.
Дальше выкидываем стаб от вашей защиты, который запускает сам себя для отладки. На этом все.

V>Насколько я понимаю крякеру будет достаточно найти вашу таблицу, в которой закодированы флаги и адреса переходов. А дальше дело техники:

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

V>Для патча наномита достаточно будет перенести часть кода перед наномитом (будет достаточно 5-ти байт) на свободное место, на старом делаем JMP на который мы перетащили код перед наномитом, дальше после перенесенного кода вставляем правильный JMP/Jxx (по результатам реверсинга таблицы), за условным переходом делаем JMP на адрес, идущий после наномита.
V>Дальше выкидываем стаб от вашей защиты, который запускает сам себя для отладки. На этом все.

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

Здравствуйте, nen777w, Вы писали:

N>Таблицу найти мало. Нужно еще разобраться что в ней спрятанный переход а что просто 0xCC которое встретилось в коде.
N>Для того что-бы обеспечить полноту таблицы есть скриптик оторый фигачит по бинарю и где встречает 0xCC фигачит в таблицу фейковую запись.

Начнем с того, что 0xСС в коде встречается в основном в местах выравнивания границ функций (компилер добивает дыры между концом предыдущей функции и началом следующей функции, выровненной на границу X байт), т.е. это выглядит обычно так:

...
mov esp, ebp
pop ebp
ret <- конец функции
int 03
int 03
int 03
push ebp <- начало функции
...

Таким образом нам совершенно без разницы какие именно int 03 вы закодируете в своей таблице (реальные или фейковые), т.к. (внимательно следите за руками!) в реальном коде мы НИКОГДА не попадаем на реальные "int 03", соответственно и на восстановленный фейковый наномит мы тоже НИКОГДА не попадем. Поэтому при восстановлении вашей таблицы нам совершенно нет никакой необходимости определять фейковый он или нет.

N>Т.е. что бы разобраться где правда а где нет, нужно по сути говоря подебажить это вживую и желательно по всем веткам, посмотреть какие записи в таблице используются а какие нет.

Читайте выше.

N>В принципе да, можно все сломать. Но когда защит несколько и более-менее сложных это отсеивает сразу приличный процент реверсеров.

Я вам по секрету скажу, что ваш метод с наномитами практически никак не защищает от реверсинга кода, т.к. основное его предназначение — это антиотладка (сторонний дебагер не сможет подключиться к процессу, т.к. дебажный порт уже будет занят). Т.е. крякеру достаточно будет разобрать всего один раз вашу таблицу с наномитами + приделать сигнатуту вашего и сделать готовую тулзень, которая будет ломать такие программы на автомате.

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

V>Начнем с того, что 0xСС в коде встречается в основном в местах выравнивания границ функций (компилер добивает дыры между концом предыдущей функции и началом следующей функции, выровненной на границу X байт), т.е. это выглядит обычно так:
V>Таким образом нам совершенно без разницы какие именно int 03 вы закодируете в своей таблице (реальные или фейковые), т.к. (внимательно следите за руками!) в реальном коде мы НИКОГДА не попадаем на реальные "int 03", соответственно и на восстановленный фейковый наномит мы тоже НИКОГДА не попадем. Поэтому при восстановлении вашей таблицы нам совершенно нет никакой необходимости определять фейковый он или нет.

Согласен. Но 0xcc может быть частью опкода команды или ее аргумента.
Тут как бы два подхода. Первый менять ассемблерный листинг обрабатывая скриптом переходы и второй это патчить бинарь как в Armadilo забивая оставшееся место мусором.
Но первым можно легко проэмулировать второй втавляя например nop-ы и только потом забивать вместо них мусор на повтороной обработке (адреса куда это вставили и сколько ведь будут известны)
Таким образом IDA уже не всегда сможет правильно сделать полное дизассемблирование кода.
Жаль я не все доделал сейчас еще, как только допилю покажу как выглядит листинг в IDA до наномитов и после.
Я еще хочу немного расширить технику включив в нее помимо call еще и loop и команды где переход происходит не на метку а по значению из регистров например jmp eax.

V>Я вам по секрету скажу, что ваш метод с наномитами практически никак не защищает от реверсинга кода, т.к. основное его предназначение — это антиотладка (сторонний дебагер не сможет подключиться к процессу, т.к. дебажный порт уже будет занят). Т.е. крякеру достаточно будет разобрать всего один раз вашу таблицу с наномитами + приделать сигнатуту вашего и сделать готовую тулзень, которая будет ломать такие программы на автомате.

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

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

Это да. Много читал об этом, но еще не пришлось столкнуться с этим.

Здравствуйте, nen777w, Вы писали:

V>>Начнем с того, что 0xСС в коде встречается в основном в местах выравнивания границ функций (компилер добивает дыры между концом предыдущей функции и началом следующей функции, выровненной на границу X байт), т.е. это выглядит обычно так:
V>>Таким образом нам совершенно без разницы какие именно int 03 вы закодируете в своей таблице (реальные или фейковые), т.к. (внимательно следите за руками!) в реальном коде мы НИКОГДА не попадаем на реальные "int 03", соответственно и на восстановленный фейковый наномит мы тоже НИКОГДА не попадем. Поэтому при восстановлении вашей таблицы нам совершенно нет никакой необходимости определять фейковый он или нет.

N>Согласен. Но 0xcc может быть частью опкода команды или ее аргумента.

Осталось понять откуда возьмется этот самый аргумент Я так понимаю, что ваш "инструмент" работает непосредственно с текстовым представлением команды, так? Если так, то совершенно непонятно как вы собираетесь по текстовому представлению определить операнды команды и определить в каком именно операнде встречается 0xCC
Ну вот к примеру: "mov [eax + 0x10cc0], ebx" сможете по этому тексту определить местоположение "0xCC"? Я чегой-то сумлеваюсь.

N>Тут как бы два подхода. Первый менять ассемблерный листинг обрабатывая скриптом переходы и второй это патчить бинарь как в Armadilo забивая оставшееся место мусором.
N>Но первым можно легко проэмулировать второй втавляя например nop-ы и только потом забивать вместо них мусор на повтороной обработке (адреса куда это вставили и сколько ведь будут известны)

Я так и не понял каким образом эти 2 подхода вас защитят от реверсинга вашей таблицы наномитов, на которой у вас все и держится?

N>Таким образом IDA уже не всегда сможет правильно сделать полное дизассемблирование кода.
N>Жаль я не все доделал сейчас еще, как только допилю покажу как выглядит листинг в IDA до наномитов и после.

Насколько я понимаю взломщику будет вообще наплевать на листинг кода до восстановления наномитов. А после снятия листинг будет очень даже хороший.

N>Я еще хочу немного расширить технику включив в нее помимо call еще и loop и команды где переход происходит не на метку а по значению из регистров например jmp eax.

Ну посидит взломщик потом еще полчаса над вашей новой структурой и допилит свою тулзень. Где профит то?

V>>Я вам по секрету скажу, что ваш метод с наномитами практически никак не защищает от реверсинга кода, т.к. основное его предназначение — это антиотладка (сторонний дебагер не сможет подключиться к процессу, т.к. дебажный порт уже будет занят). Т.е. крякеру достаточно будет разобрать всего один раз вашу таблицу с наномитами + приделать сигнатуту вашего и сделать готовую тулзень, которая будет ломать такие программы на автомате.

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

Т.е. в итоге пришли к тому, что вместо наномитов в общем случае гораздо надежнее использовать виртуальную машину, все правильно?

N>>Согласен. Но 0xcc может быть частью опкода команды или ее аргумента.

V>Осталось понять откуда возьмется этот самый аргумент Я так понимаю, что ваш "инструмент" работает непосредственно с текстовым представлением команды, так? Если так, то совершенно непонятно как вы собираетесь по текстовому представлению определить операнды команды и определить в каком именно операнде встречается 0xCC
V>Ну вот к примеру: "mov [eax + 0x10cc0], ebx" сможете по этому тексту определить местоположение "0xCC"? Я чегой-то сумлеваюсь.

Да нет же, таблица делается в два этапа. После замены всех переходов на int 3 используется одна и та же утилита objdump для:
1) Выдираение секции с записью о наномитах (для этого у меня уже скрипты написаны)
2) Выдераются все остальные секции из которых таблица добивается всеми адресами что имеют 0xCC

N>>Тут как бы два подхода. Первый менять ассемблерный листинг обрабатывая скриптом переходы и второй это патчить бинарь как в Armadilo забивая оставшееся место мусором.
N>>Но первым можно легко проэмулировать второй втавляя например nop-ы и только потом забивать вместо них мусор на повтороной обработке (адреса куда это вставили и сколько ведь будут известны)

V>Я так и не понял каким образом эти 2 подхода вас защитят от реверсинга вашей таблицы наномитов, на которой у вас все и держится?
А как ее защитить? Выдрать да можно, ну зашифровать часть (от серийника), или несколько таблиц иметь для этого.
Если будут какие то идеи я только с удовольствием.

N>>Таким образом IDA уже не всегда сможет правильно сделать полное дизассемблирование кода.
N>>Жаль я не все доделал сейчас еще, как только допилю покажу как выглядит листинг в IDA до наномитов и после.
V>Насколько я понимаю взломщику будет вообще наплевать на листинг кода до восстановления наномитов. А после снятия листинг будет очень даже хороший.

Да.

N>>Я еще хочу немного расширить технику включив в нее помимо call еще и loop и команды где переход происходит не на метку а по значению из регистров например jmp eax.
V>Ну посидит взломщик потом еще полчаса над вашей новой структурой и допилит свою тулзень. Где профит то?

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

N>>К тому же основной механизм защиты у меня это самописная виртуальная машина, наномиты нанесенные вторым слоем просто добавят сложности.
V>Т.е. в итоге пришли к тому, что вместо наномитов в общем случае гораздо надежнее использовать виртуальную машину, все правильно?

Да виртуалка это самый нижний слой. Наномитами можно покрыть тот же движок виртуалки или пред-подготовки.

Я вообще с удовольствием начитаюсь об антиотладочные приемах и приемах про зазщиту приложений. Мне эта тема очень интересна.
Если имеете возможность поделитесь информацией.
Спасибо.