Форум РадиоКот

Добрый мяю всем!
Требуется сделать USB ключ
Соответственно интересует вопросы:
Почему часто делают емуляторы а не взламывают ПО использующие ключ? Гораздо проще вскрыть защиту - криптор исполняемого файла и занопить, как правило, всего один условный переход. Ведь, в конце концов, вся защита сводиться к проверке условия - есть ключ или нет? соответственно это всего 1 условие. Но почему то делают именно эмуляторы аппаратуры. Даже в том ПО которое даже особо не защищено - например Компас.
Неужели сами эти электронные ключи настолько топорно сделаны что оказалось проще скопировать 1 в 1 поток байт в эмулятор?
Какие ещё фишки таких ключей, Уважаемые Коты, Вы знаете?

Ну и просто мнения послушать интересно.

Просто занопить это совсем уж никакая защита. Почитайте Криса Касперски. очень интересно пишет о методах защиты и взлома защит

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

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

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

Или у Вас есть какие либо совсем другие предложения? Только желательно без гуглизма и прочих отсылок.

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

и опять таки. РАЗРАБОТЧИКИ обнаружили в программе баг. исправили и получили новый экзешник, в котором ХАКЕРУ опять нужно очень долго и печально искать этот самый волшебный условный переход.

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

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

и опять таки. РАЗРАБОТЧИКИ обнаружили в программе баг. исправили и получили новый экзешник, в котором ХАКЕРУ опять нужно очень долго и печально искать этот самый волшебный условный переход.

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

спасибо, теперь ясно,

Но тогда такой вопрос: почему всё таки так легко взламываются ключи и подставляется эмулятор, неужели никак не проверить программно на хуки хотя-бы функции чтения LPT или USB - если эти хуки легко видны касперычем, вебом. avz и прочим по работающим даже не под администратором. Эти хуки ставятся в наглую и в явном виде (на всех 5 видах донглов, хаспов и прочих устройств что попадались под руки). А так же имена эмуляторов никто не шифрует, как и их тело. Они лежат порой рядом с защищаемой программой и спокойно работают.

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

А так же неужели протокол обмена с ключом не шифруется или вообще никак не защищается?

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

Smirnov писал(а):Ну так или иначе всё сводится к одной проверке, всего одной, от этого не уйдёшь.

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

Smirnov писал(а):И я ещё сразу учитывал что исполняемый файл будет покрыт защитой превращающий понятный код в кашу - т.е. криптором.

Нормальные протекторы тоже снять непросто - приходится вручную разбирать весь код загрузки протектора только для того чтобы запустить программу под отладчиком. Я уже не говорю о таких вещах как CopyMem армадиллы и Ring0-протекторах(самый известный из которых - StarForce) - они даже дамп сделать не дадут.

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

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

Smirnov писал(а):Но тогда такой вопрос: почему всё таки так легко взламываются ключи и подставляется эмулятор, неужели никак не проверить программно на хуки хотя-бы функции чтения LPT или USB - если эти хуки легко видны касперычем, вебом. avz и прочим по работающим даже не под администратором. Эти хуки ставятся в наглую и в явном виде (на всех 5 видах донглов, хаспов и прочих устройств что попадались под руки).

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

Smirnov писал(а):И почему не могут сделать защиту например с открытым и закрытым ключом? Так чтоб открытым ключом шифрования проверялось наличие аппаратного ключа и он был каждый раз разный.

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

почему обязательно закрытый и открытый ключ должен сильно тормозить? Неужели там так всё запущено? Насколько понимаю тот же PGP алгоритм образует только лишь два числа котороые являются наименьшими общими делителями некоего большего числа? Его же использовали активно ещё во времена 386 компов с 20мгц, даже на тот же дрвеб и прочие в письмах предлагалось шифровать открытым ключом чтоб вирусописатели не перехватили, что то я не верю чтоб там генерация ключей сутками работала, даже если сутки то сейчас должна за секунды. Ладно, даже если известные криптостойкие алгоритмы тормозят, то что мешает свой сделать, тогда вообще о нём никто знать не будет и стандартные атаки типа Rainbow как например для мд5 не подойдут.

Во-первых "взять из памяти или потока между ключом и компом расшифрованный файл" не так то просто

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

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

Какие ещё есть способы взлома? Где о них можно почитать?

Лично я знаю, как сделана защита аппаратная (ключ) в одной программулине. Так вот, там 13 потоков. В каждом из них находится кусочек кода, работающий с ключом. Путем синхронизации этих потоков добиваемся правильного алгоритма работы. И эти кусочки разбросаны повсюду. Я думаю, вы согласитесь, что взломать такое крааайне сложно. Проще ключ сделать.

Smirnov писал(а):...Ну и просто мнения послушать интересно.

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

взломать можно ВСЁ. на это влияет только деньги-время. защищаться можно очень долго. на это влияет время-опыт. посему задача защит не супер-пупер защита, а сделать взлом НЕ рентабельным. Например если Ваша защищённая программа будет стоить 1 рубль, то зачем тратить на взлом 10 тысяч рублей? или покупать взломанную у какого то хакера, если у вас с тех. поддержкой это будет стоить на год вперёд?

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

где то так
(круглый)

промежуточный вывод:
Делаю всё по-своему, самое главно не использовать ниодного готового алгоритма.

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

Делаю двойной ключ, закрытый и открытый, естественно по своему алгоритму. Ключи будут окончательно кодировать содержимое и выдаваться в ПК будет только открытый. Закрытый будет только внутри ключа и будет сеансовым и вырабатываться каждый раз разным.

Делаю несколько версий структур и ответов, например три версии опроса ключа, чтоб ПО на ПК опрашивало тремя способами, один встречается в 95% случаях, второй в 5% случаях, третий в 0.1% случаях, это придаст жуткую нестабильность если сделают емуль и добавит ведро гемора.

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

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

это не в обиду сказано. я серьёзно. с матчастью СТОИТ ознакомиться.

Smirnov писал(а):Ладно, даже если известные криптостойкие алгоритмы тормозят, то что мешает свой сделать, тогда вообще о нём никто знать не будет и стандартные атаки типа Rainbow как например для мд5 не подойдут.

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

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

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

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

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

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

а аппаратный ключ из чего, кстати, делать будете?

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

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

Ну пару слов и пример трафика я выложу (в тз необходима поддержка удалённой перепрошивки содержимого ключа по инету), они обязаны быть публичными ибо драйвер усб необходимо будет менять хотябы для поддержки следующих сервис паков и версий винды. И обосную защищённость и почему так выбрано. У меня вышло что необходимо около 10 милиардов умножений в секунду для онлайн работы с ключём, это реально сделать на компе, и по другому нельзя, но простой рядовой програмист вряд ли потянет влоб сделать эмуль - он подвешает все 8 напрочь или сколько там ядер есть у коре i7. Осталось реализовать. Уйти от этого алгоритма невозможно - это простая сигнальная обработка от неё никуда не денешся.

Аппаратный ключ будет из фтди + простенькая атмега.

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

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

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

Перепрошивка программатором, мега не усб а простая.