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

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

Здравствуйте, 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>Гараздо интереснее привязать это как то к самому бинарю. Что бы просто подменой даты, или сброса/удаление ключа не обошлось.

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

Здравствуйте, 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