Comments 14
Ну вот что это за ерунда? Это первый пост компании на хабре?
ИМХО не совсем верный способ привлечь аудиторию — слишком сухо и абстрактно.
Есть же конкретный шикарный продукт Guardant Code. Напишите про то, как можно защитить таким ключом обычное приложение — вот это будет лучшая вводная в технологии актива.
ИМХО не совсем верный способ привлечь аудиторию — слишком сухо и абстрактно.
Есть же конкретный шикарный продукт Guardant Code. Напишите про то, как можно защитить таким ключом обычное приложение — вот это будет лучшая вводная в технологии актива.
Я думаю, такая статья появится. А это, так сказать, общее введение.
Спасибо за коммент!
Мы данной статьей хотели в принципе показать слабые места разных электронных ключей, тут действительно Guardant Code стоит особняком и позволяет делать весьма интересную защиту. Обязательно про него напишем в следующий раз.
Мы данной статьей хотели в принципе показать слабые места разных электронных ключей, тут действительно Guardant Code стоит особняком и позволяет делать весьма интересную защиту. Обязательно про него напишем в следующий раз.
Наоборот, компания, в отличие от всяких интел, майкрософт и HP не занимается копипастой маркетинговых буклетов для умственно отсталых лиц, принимающих решения, а пишет на Хабре про технические подробности. Пожалуйста, не слушайте Bobos и продолжайте в том же духе.
А вы, уважаемый хабраюзер, если не понимаете, что такое mov eax, dword_6dfb4c, что забыли на Хабре?
А так, непонятно, как сделан этот момент:
> При вызове функций Guardant API защищенное приложение автоматически проверяет подпись драйвера в оперативной памяти. Поскольку закрытый ключ не известен, создать драйвер-эмулятор с правильной подписью невозможно.
Что мешает взять существующий драйвер, и посмотреть какая у него подпись, и выдавать ту же подпись драйвером-эмулятором? Ведь программа не может прочесть область памяти, в которой лежит драйвер, и проверить, что он настоящий? Или я что-то не понял?
А также, вопрос, будут ли статьи с разбором недостатков технологий-конкурентов, если они конечно у них есть?
А вы, уважаемый хабраюзер, если не понимаете, что такое mov eax, dword_6dfb4c, что забыли на Хабре?
А так, непонятно, как сделан этот момент:
> При вызове функций Guardant API защищенное приложение автоматически проверяет подпись драйвера в оперативной памяти. Поскольку закрытый ключ не известен, создать драйвер-эмулятор с правильной подписью невозможно.
Что мешает взять существующий драйвер, и посмотреть какая у него подпись, и выдавать ту же подпись драйвером-эмулятором? Ведь программа не может прочесть область памяти, в которой лежит драйвер, и проверить, что он настоящий? Или я что-то не понял?
А также, вопрос, будут ли статьи с разбором недостатков технологий-конкурентов, если они конечно у них есть?
Guardant API может (и читает) область памяти с загруженным туда драйвером, и проверяет подпись, так сказать, по полной программе.
Касательно конкурентов: недостатки есть у всех, у нас в том числе. Но мы не считаем корректным упирать не недостатки конкурентов — гораздо интереснее опираться на достоинства собственной продукции, хотя при этом сравнение с конкурентами в какой то степени подразумевается.
Касательно конкурентов: недостатки есть у всех, у нас в том числе. Но мы не считаем корректным упирать не недостатки конкурентов — гораздо интереснее опираться на достоинства собственной продукции, хотя при этом сравнение с конкурентами в какой то степени подразумевается.
+100500
Перехватив IoCallDriver мы будем контролировать irp пакеты передаваемые драйверу приложением. Тем самым проанализировать и отвязать защиту
Для прошлых поколений ключей это вполне актуальный комментарий. И там сложность отвязывания защиты упиралась именно в сложность анализа трафика между драйвером и приложением. К слову сказать, и на Stealth II делались защиты которые не ломались годами! Если достойно пользоваться возможностями ключа (шифрование, хеширование,...) и завязать на них логику приложения, а также сделать нетривиальные зависимости от условий анализа, даты, времени, и прочего — то на сбор информации для эмуляции ключа может уйти уйма времени, причем без гарантий что эмулятор не даст сбой через месяц только потому, что «с 25 по 28 число каждого месяца» защита работает совершенно по другому :)
Для новых ключей садиться на драйвер бессмысленно — они сделаны на мощном микропроцессоре который позволяет сквозным образом шифровать трафик между ключом и приложением. Шифрование производится на сеансовых 15-минутных ключах алгоритмом AES. Этот трафик анализировать бессмысленно. И в статье описано что при этом нужно ломать и как защититься.
Для новых ключей садиться на драйвер бессмысленно — они сделаны на мощном микропроцессоре который позволяет сквозным образом шифровать трафик между ключом и приложением. Шифрование производится на сеансовых 15-минутных ключах алгоритмом AES. Этот трафик анализировать бессмысленно. И в статье описано что при этом нужно ломать и как защититься.
Немного поправлюсь. Для старых поколений ключей Stealth 2 и Stealth 3 простой перехват Irp пакетов между приложением и драйвером ничего не даст. Для создания эмулятора потребуется реверсировать Guardant API и драйвер, которые защищены нашим псевдокодом.
Эмулировать на уровне драйвера USB-шины, конечно, заметно проще — собственно о том, в том числе, и статья.
Эмулировать на уровне драйвера USB-шины, конечно, заметно проще — собственно о том, в том числе, и статья.
Сдаётся мне, что если защита станет массовой, то вскоре после этого появятся скрипты для олли для её снятия.
Sign up to leave a comment.
Эволюция систем защиты на электронных ключах