[защита ПО с полощью электронного ключа] Нужна хоть какаято идея(((

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

П.С. наверное то о чем я говорил уже кемтокакто разработано, я особо не смотрел в сторону уже существующих решений... вобщем я просто на вопрос из цитаты ответил )

 

100gold

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

а вот встроить такую защиту в уже скомпиленную дллю будет не так сложно.

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

а если вы таки хотите транслировать х86 бинарь на авр/арм, то дерзайте

это вам обеспечено. причем уже на стадии встраивания защиты.

---------------------------------------------------------
есть еще такой вариант (дорогой, не такой простой, но проще, надежнее и быстрее перетрансляции х86 -> авр)

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


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

 

a9d == 100gold ? как ваши дела с трансиверами? ато я начитался той ветки и уже даже себе захотел

 

qqwe

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

 

Y_Mur

гы. "маленькая простая утилита взламывающая без вмешательства человека".
окромя того, вы ж не утиль на 100кб защищать хард-ключами собрались? или да?

элементарно 3 не настолько корректных запроса (вы ж по маске искать собрались, а маска не исключает ошибок. например, префикс "fs:" это буква "d") и идем в магазин совершать незапланированные покупки.

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

 

qqwe
А какие проблемы прогнать через дизасемблер 100Мб или более кода и получить асм листинг в котором все относительные адреса уже заменены абсолютными?
Затем тупо ищем все jmp и отсеиваем прыгающие не туда, затем все call и т.д. и никаких нечётких масок с их возможными ошибками. Если нужна утиль "совсем без вмешательства человека" то любой открытый движок дизасма + обычные API или CRT и т.п. функции поиска текста. Но имхо полуручной подход проще поскольку пользоваться такой утилью всё равно будет не лузер а тот кто создаёт кряк отучающий прогу обращаться к ключу.
Согласен что при этом можно найти не все обращения к ключу, но во первых без специального противодействия дизассемблированию и распознаванию обращений вероятность не найти обращение достаточно мала, а во вторых все найденные обращения будут корректными и трёх фалсей точно не вызовут.

 

Неугадал) я просто мимо проходил - идея заинтересовала.

Видимо я не понял, что именно вы хотите у ключа спрашивать. Я думал что все инструкции вида
jmp XXX
Call XXX
вы хотите заменить на jmp\Call JumpHandler. А уже из него(JumpHandler) определять с пом. ключа куда должен быть переход.

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

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

 

qqwe

И я понял это так-же т.е. задача сводится к тривиальному поиску в дизассемблированном листинге всех jmp JumpHandler затем всех Call JumpHandler возможно потом перебрать и все Jcc JumpHandler до кучи. Дизассемблирование нужно исключительно для того чтобы случайно не найти такую конструкцию в данных или при неправильной интерпретации команды, впрочем можно рискнуть и обойтись без дизассемблирования поскольку вероятность так нарваться да ещё три раза не столь велика.
Конечно сначала придётся понять суть алгоритма защиты, но потом размер проги и количество защищаемых прог уже значения не имеет.

 

Если имеется ввиду трансивер TR24A, то я перевожу код под арм. Препод на халяву предоставил контроллер ADuC7024 и я его прилепил к роботу.

Себестоимость ключа у меня вышла в пределах 50 грн. Все компоненты использовались дешёвые. Код полностью написан на С++, поэтому правообладателю даже не нужны навыки в программировании МК.
Также я использовал бутлоадер с поддержкой шифрования AES, любезно предоставленный фирмой Atmel. Поэтому с помощью одного и того же электронного ключа можно защищать совершенно разное ПО. Для этого нужно всего лишь залить прошивку-ключ. Эта операция элементарная. Но с помощью одного ключа можно защитить до 15ти продуктов. EEPROM память не резиновая. В случае повреждения EEPROM памяти имеется программный механизм ее восстановления.
Общаться с ключом очень легко. Т.к. все происходит через виртуальный ком-порт, номер которого определяется автоматически. В качестве переходника использовал микросхему cp2103.

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

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

 

Если без этого, то "универсальный решатель" получается )

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

 

100gold
Если просто "заменить на jmp\Call JumpHandler" без всяких дополнительных мер защиты то дизасмить всю прогу необязательно, достаточно раскопать этот JumpHandler (в его анализе конечно без дизассемблирования никак, но тут достаточно посмотреть то что показывает отладчик) а дальше искать опкоды call/jmp/jcc и проверять адрес перехода исходя из гипотезы что это действительно опкод. Вероятность случайно встретить в данных именно такую комбинацию "ложный опкод + нужный адрес" весьма мала, если конечно её туда специально не добавили )

 

Ладно, со статическим анализом всё более-менее ясно, но вот самая первая проблема "Можно взять и сохранить все ответы от ключа в процессе работы проги с реальным ключом, а потом отвечать проге используя закешированные значения. Вариант, когда запрос к ключу делается в виде DES(RealData+RandomData) конечно актуален, но и методы борьбы с этим известны. А если вернутся к jmp\call\jcc , то можно ещё предложить такую вещь.
1. Строим граф переходов изначального кода.
2. Клонируем часть вершин. Например у нас была функция
Func:
add eax,ecx
ret
в графе она будет представлена одной вершиной, т.к. нет внутри никаких переходов. Клонирование будет означать, что код будет находится в двух местах ( по разным адресам т.е.) и вызываться будет либо по одному адресу, либо по другому
3. Теперь нужно в проге по определённому алгоритму выбирать какой из вариантов вызвать. Причём если сделать так, чтобы на одной и той же системе алгоритм отрабатывал одинаково, а на разных системах по разному, то ...

Теперь правда самое время вспомнить о том, что легальному пользователю прога ещё и показывать чтото должна кроме "песочных часов" ))

 

пысал длиинный ответ, но некие самодеятельные электрики его прибанили.

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

например вставление ложных переходов, что отнюдь не сложно

или замена/вынесение не одной команды, а целого блока, если внутрь него нет прыжков

или замена перехода не шаблоном, а с фантазией, напр, коссвенной ссылкой (или ссылками колвом -> oo), куда адреса таргета будут устанавливаться динамически.

или вопросом с моментами наподобе

push ebp
mov ebp,esp

jmp/call [ebp+8]

кои мсвс вставляет местами и без пинков почти, а ида разжовывает не всегда корректно и с пинками

да и "метод 3 фалсев" это просто для понимания. прога в нормальном состоянии не сделает ни одного фалса. те первая же ошибка и велкам то шопинг. я б тут даже поощрял хакеров к взлому. скажем, $2000 первому взломавшему (при цене продукта $500). вполне неплохо жуниоры поднять продажи могут.

если вы пропустите некоторые варианты, то при их встрече прога не заглючит, а просто рухнет.
но даже и полному скану (переходов мноого. можно еще и с переменными нечто подобное утворить) вполне можно противостоять.

----------------------------------------------------------------
ну а для полной надежности, я ж говорю, фпга с важным расчетом зашитым в ней. дорого, но надежно. для продукта ценой > $1000/установка самое то

думаю, вы преувеличиваете.


----------------------------------------
еще раз повторюсь - это макет идеи. ее можно использовать так, а можно развить. как развить дело вкуса и фантазии.