Comments 22
вы только что подкинули эмульмейкерам отличную идею для выпуска новых версий
Сомневаюсь в том, что это отличная идея :)
Есть множество других способов, как минимум ни один из эмуляторов (даже реализующих виртуальную шину) не воспроизводит ее поведение досконально, я уж не говорю о эмуляции целевого устройства.
Это так — ради шутки можно сказать, дабы было просто и доступно :)
Есть множество других способов, как минимум ни один из эмуляторов (даже реализующих виртуальную шину) не воспроизводит ее поведение досконально, я уж не говорю о эмуляции целевого устройства.
Это так — ради шутки можно сказать, дабы было просто и доступно :)
ну да, проще снять конверт чем эмулить весь хардварный стек)
Согласен, но использование конверта (утилит автозащиты) категорически не желательно для построения более-менее стойкой защиты. Он хорош для тех, кто абсолютно не умеет или не хочет заниматься защитой ПО.
Я по этой теме выступал на семинарах компании «Актив», но не уверен в том, что я хороший лектор, поэтому особенной заинтересованности во взглядах аудитории, за исключением пары-тройки человек, я не увидел. Увы :)
Впрочем, я описал суть данного подхода и свои рекомендации в данной статье: alexander-bagel.blogspot.ru/2012/09/blog-post.html
Я по этой теме выступал на семинарах компании «Актив», но не уверен в том, что я хороший лектор, поэтому особенной заинтересованности во взглядах аудитории, за исключением пары-тройки человек, я не увидел. Увы :)
Впрочем, я описал суть данного подхода и свои рекомендации в данной статье: alexander-bagel.blogspot.ru/2012/09/blog-post.html
Хмм а как же эмулятор HASP тот как раз виртуальное устройство создает. Вполне себе полая эмуляция.
Логичнее пользоваться ассиметричной криптографией, предоставляемой ключом.
Тогда никакие эмуляторы не помогут, только полный анализ алгоритмов.
Тогда никакие эмуляторы не помогут, только полный анализ алгоритмов.
Согласен, но это возможно только в последних поколениях ключей.
Guardant Stealth II и ниже такого не умеет.
Guardant Stealth II и ниже такого не умеет.
Guardant Stealth II, как и III, уже давно устарел, есть гораздо более инересный Guardant Code, в который можно перенести часть реальной логики программы.
Так-то оно так, но что делать со старыми ключами?
К примеру у нас сейчас в районе 230 тысяч установок, нужно потратить в районе 115 миллионов рублей, чтобы купить такое-же количество Code, забрать у пользователей старые ключи, раздать новые, и в итоге на руках останется целый вагон старых ключей с которыми не понятно что делать. В итоге прямой убыток будет в районе 230 миллионов — да меня проще уволить, когда я приду к начальству с таким предложением :)
К примеру у нас сейчас в районе 230 тысяч установок, нужно потратить в районе 115 миллионов рублей, чтобы купить такое-же количество Code, забрать у пользователей старые ключи, раздать новые, и в итоге на руках останется целый вагон старых ключей с которыми не понятно что делать. В итоге прямой убыток будет в районе 230 миллионов — да меня проще уволить, когда я приду к начальству с таким предложением :)
Интересная идея просмотра родителей устройства.
Но тем не менее всё это как-то не очень серьезно выглядит.
Чур не закидывать меня помидорами, но я всегда считал, что аппаратные ключи защиты кода (не данных) это в первую очередь психологическая защита. Мол если у тебя нет железки, то программа ворованная, если есть, то ты купил не абстрактную программу а материальную железку.
В самом деле — если мы проверяем факт наличия ключа (не важно каким образом) то взлом сводится к классической замене условного перехода на NOP или безусловный переход (утрирую, но железяка тут ничего дополнительного к программной защите не приносит).
Если мы используем железку для расшифровки кода, то код рано или поздно оказывается в памяти. Тут мы его тепленьким и берем.
Единственное что реально остается это или перенос части бизнеслогики в железяку, но тут мы упираемся как в производительность железяки (а она в свою очередь в цену), либо в шину — в результате да, такие черные ящики сильно осложняют обратный инжиниринг, но всё-же дороги и не универсальны. Что еще можно придумать? Брать пример с антипарсеров и не давать сливать ВЕСЬ код?
т.е. если ты расшифровал код для работы под х86 то зачем ты еще и ARM трогаешь? (утрирую опять, но в реальности может быть много других вариантов — клиентский и серверный код ит.д.) — тут мы либо имеем слишком высокую вероятность ложных срабатываний, либо эффективность сводится к нулю несколькими ключами.
Прошу ногами не пинать, если я не прав то объясните в чем. Спасибо.
Но тем не менее всё это как-то не очень серьезно выглядит.
Чур не закидывать меня помидорами, но я всегда считал, что аппаратные ключи защиты кода (не данных) это в первую очередь психологическая защита. Мол если у тебя нет железки, то программа ворованная, если есть, то ты купил не абстрактную программу а материальную железку.
В самом деле — если мы проверяем факт наличия ключа (не важно каким образом) то взлом сводится к классической замене условного перехода на NOP или безусловный переход (утрирую, но железяка тут ничего дополнительного к программной защите не приносит).
Если мы используем железку для расшифровки кода, то код рано или поздно оказывается в памяти. Тут мы его тепленьким и берем.
Единственное что реально остается это или перенос части бизнеслогики в железяку, но тут мы упираемся как в производительность железяки (а она в свою очередь в цену), либо в шину — в результате да, такие черные ящики сильно осложняют обратный инжиниринг, но всё-же дороги и не универсальны. Что еще можно придумать? Брать пример с антипарсеров и не давать сливать ВЕСЬ код?
т.е. если ты расшифровал код для работы под х86 то зачем ты еще и ARM трогаешь? (утрирую опять, но в реальности может быть много других вариантов — клиентский и серверный код ит.д.) — тут мы либо имеем слишком высокую вероятность ложных срабатываний, либо эффективность сводится к нулю несколькими ключами.
Прошу ногами не пинать, если я не прав то объясните в чем. Спасибо.
Теоретически, так. Только нужно править не один JZ, а 100-200. И расшифровать не пару кусков кода, а 300 функций, которые перед выполнением расшифровываются, а после выполнения стираются.
Но ведь и поставить такую защиту трудно? Достаточно держать специальный отдел на зарплате и за год-два параллельно с разработкой программы к 5-й версии они напишут 100500 обёрток, чтобы каждая расшифровка и проверка была уникальной и требовала её разбора по-новой.
Задача состоит в том, чтобы даже самому сильному хакеру объективно потребовалось 20-30 рабочих дней (8-часовых) на удаление защиты. Тогда типичный диалог: «Вась, ты же умный, посмотри тут программу...» закончится тем, что Вася вечер-другой посмотрит-посмотрит и скажет: «да пошло оно всё...»
Если вы считаете, что всё сводится к простановке NOP в нужное место (хотя и таких «взломов» предостаточно), наверное вы не разбирали серьёзные защиты. Например, StarForce, который в kernel-mode распаковывает куски кода и выполняет их.
Но ведь и поставить такую защиту трудно? Достаточно держать специальный отдел на зарплате и за год-два параллельно с разработкой программы к 5-й версии они напишут 100500 обёрток, чтобы каждая расшифровка и проверка была уникальной и требовала её разбора по-новой.
Задача состоит в том, чтобы даже самому сильному хакеру объективно потребовалось 20-30 рабочих дней (8-часовых) на удаление защиты. Тогда типичный диалог: «Вась, ты же умный, посмотри тут программу...» закончится тем, что Вася вечер-другой посмотрит-посмотрит и скажет: «да пошло оно всё...»
Если вы считаете, что всё сводится к простановке NOP в нужное место (хотя и таких «взломов» предостаточно), наверное вы не разбирали серьёзные защиты. Например, StarForce, который в kernel-mode распаковывает куски кода и выполняет их.
Мое общение с ассемблером и прочими низкоуровневыми инструментами закончилось когда закончилась эра 16-биток.
Так что да, не колупал серьезных защит. Но я примерно представляю, что там уже давно одним NOP не отделаться :)
Я потому и писал:
Утрирую — это было про NOP.
Основная мысль была в том, что проверка железки лечится програмно с такой же сложностью как и чисто програмные проверки.
Так что да, не колупал серьезных защит. Но я примерно представляю, что там уже давно одним NOP не отделаться :)
Я потому и писал:
В самом деле — если мы проверяем факт наличия ключа (не важно каким образом) то взлом сводится к классической замене условного перехода на NOP или безусловный переход (утрирую, но железяка тут ничего дополнительного к программной защите не приносит).
Утрирую — это было про NOP.
Основная мысль была в том, что проверка железки лечится програмно с такой же сложностью как и чисто програмные проверки.
«Чисто програмные проверки» не требуют анализа кода.
Достаточно скопировать окружение (в простом случае — файл лицензии), купить идентичные конфигурации ПК и сделать побитные копии дисков. Если проверка завязывается на серийные номера BIOS или HDD, это можно выяснить и перехватить системный вызов в этом месте.
Даже «тупой» ключ (у которого есть только S/N) не даёт возможность воспроизвести (скопировать) среду.
А ковыряться в запутанном драйвере, выясняя как он читает S/N, намного сложнее, чем встроиться в ATA-стек и подменять серийник HDD
То есть, плюс ключа — заставить-таки взломщика «хакать честно», а не пытаться как-то обхитрить защиту (хотя есть эмуляторы...).
Достаточно скопировать окружение (в простом случае — файл лицензии), купить идентичные конфигурации ПК и сделать побитные копии дисков. Если проверка завязывается на серийные номера BIOS или HDD, это можно выяснить и перехватить системный вызов в этом месте.
Даже «тупой» ключ (у которого есть только S/N) не даёт возможность воспроизвести (скопировать) среду.
А ковыряться в запутанном драйвере, выясняя как он читает S/N, намного сложнее, чем встроиться в ATA-стек и подменять серийник HDD
То есть, плюс ключа — заставить-таки взломщика «хакать честно», а не пытаться как-то обхитрить защиту (хотя есть эмуляторы...).
Аргумент.
Но это скорее вопрос масштаба.
В программной защите уже есть некоторый наработанный набор «заглушек». Известно как влезть в запрос серийника диска/биоса, где перехватывать низкоуровневое чтение диска и т.п.
В случае железяки это не известно. Но только до поры до времени.
Как только появляется с десяток программ (или одна популярная), так сразу же «поваренная книга» точек для перехвата пополнится рецептами по ловле запросов к ключикам этого производителя.
Итого — если решение типовое, то и отучать от него будут так-же типовыми методами.
Если решение единичное, то оно соизмеримо по сложности с единичным программным решением.
Ну разве что склепать какой-то самопальный ключ на PIC18F4550, который будет представляться HID-клавиатурой, но при этом по факту иметь отличный от стандарта стек команд будет проще, чем придумать какой-то новый источник инфы для привязки к компьютеру. Но это ведь не промышленное решение, а частный случай…
Но это скорее вопрос масштаба.
В программной защите уже есть некоторый наработанный набор «заглушек». Известно как влезть в запрос серийника диска/биоса, где перехватывать низкоуровневое чтение диска и т.п.
В случае железяки это не известно. Но только до поры до времени.
Как только появляется с десяток программ (или одна популярная), так сразу же «поваренная книга» точек для перехвата пополнится рецептами по ловле запросов к ключикам этого производителя.
Итого — если решение типовое, то и отучать от него будут так-же типовыми методами.
Если решение единичное, то оно соизмеримо по сложности с единичным программным решением.
Ну разве что склепать какой-то самопальный ключ на PIC18F4550, который будет представляться HID-клавиатурой, но при этом по факту иметь отличный от стандарта стек команд будет проще, чем придумать какой-то новый источник инфы для привязки к компьютеру. Но это ведь не промышленное решение, а частный случай…
Да-да, я понял.
1. При условии необходимости полного разбора кода зашиты разницы никакой.
2. Но без аппаратного ключа хакеру легче схалтурить, выяснив точки привязки и склонировав их, не ковыряя код.
№1 это какое-то надуманное условие, всегда идут по пути наименьшего сопротивления.
1. При условии необходимости полного разбора кода зашиты разницы никакой.
2. Но без аппаратного ключа хакеру легче схалтурить, выяснив точки привязки и склонировав их, не ковыряя код.
№1 это какое-то надуманное условие, всегда идут по пути наименьшего сопротивления.
Я согласен что в качестве дополнительного пугала, чтобы отпугнуть слабых специалистов вроде меня это эффективно. Но с этим и программная защита справляется.
На мелкосериных вещах это вполне рационально.
Но на решениях, где стоит несколько сотен тысяч копий целесообразность такого решения именно как защиты — вызывает сомнения.
На мелкосериных вещах это вполне рационально.
Но на решениях, где стоит несколько сотен тысяч копий целесообразность такого решения именно как защиты — вызывает сомнения.
Допустим, цена взлома $10000.
Цена лицензии $1000.
Обычный пользователь купит.
Пиратам в оффлайне делать нечего — это не 90-е годы, сейчас контрольная закупка и в тюрьму (если производитель не поощряет пиратство).
Взломать и выложить в интернете — возможно ради «славы», если аудитория проекта большая. Но если это специфичный бизнес-пакет — не тот случай.
Цена лицензии $1000.
Обычный пользователь купит.
Пиратам в оффлайне делать нечего — это не 90-е годы, сейчас контрольная закупка и в тюрьму (если производитель не поощряет пиратство).
Взломать и выложить в интернете — возможно ради «славы», если аудитория проекта большая. Но если это специфичный бизнес-пакет — не тот случай.
чтобы отпугнуть слабых специалистов вроде меня это эффективно.Рассматриваем только профессионалов. Если директор просит знакомого «ломани по-дружбе» и защита обходится за день, всё ок. Если через 2 дня хакер понимает, что снял 8 слоёв и сколько ещё впереди — неизвестно, то «по дружбе» уже не выйдет, и заказчику дешевле купить лицензию, чем оплатить работу (не говоря о том, что на выходные поковырять много кто возьмёт, а отказаться от основной работы и месяц разбираться с непонятно какими ожиданиями — немного).
Sign up to leave a comment.
Простой способ обнаружения эмуляторов ключа Guardant