Как сделать хорошую защиту от трещин?

Я начну с высказывания Я знаю, что невозможно предотвратить обратное проектирование вашего программного обеспечения.

Но, когда я смотрю crackmes.de, есть трещины со степенью сложности 8 и 9 (по шкале от 1 до 10). Эти трещины взламываются гениальными мозгами, которые пишут учебник, как взломать его. В некоторых случаях такие учебные пособия длится 13 страниц! Когда я пытаюсь сделать crackme, они взламывают его через 10 минут. Далее следует учебник "How-to-crack" с длиной 20 строк.

Итак, вопросы:

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

Ответ 1

Отказ от ответственности. Я работаю для поставщика средств защиты программного обеспечения (Wibu-Systems).

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

Наиболее сильное анти-растрескивание зависит от шифрования (симметричный или открытый ключ). Шифрование может быть очень сильным, но если ключевое хранилище/поколение не будет одинаково сильным, его можно атаковать. Также возможно множество других методов, даже с хорошим шифрованием, если вы не знаете, что делаете. Программному единственному решению придется хранить ключ в доступном месте, легко найти или подвергнуть атаке "человек в середине". То же самое происходит с ключами, хранящимися на веб-сервере. Даже при хорошем шифровании и безопасном хранении ключей, если вы не можете обнаружить отладчиков, взломщик может просто взять снимок памяти и построить exe из этого. Поэтому вам никогда не нужно полностью дешифровать в памяти в любой момент времени и иметь некоторый код для обнаружения отладчика. Обфускация, мертвый код и т.д. Не замедлит их, потому что они не взламываются, начиная с самого начала и работая через ваш код. Они гораздо умнее этого. Просто взгляните на некоторые из практических трещин в сети, чтобы узнать, как найти код обнаружения безопасности и взломать там.

Краткое бесстыдное продвижение: наша аппаратная система НИКОГДА не была взломана. У нас есть один крупный клиент, который использует его исключительно для антиреверсивной инженерии. Поэтому мы знаем, что это можно сделать.

Ответ 2

Языки, такие как Java и С#, слишком высокоуровневые и не предоставляют эффективных структур для взлома. Вы можете сделать это тяжело для script kiddies через обфускацию, но если ваш продукт стоит, он все равно будет сломан.

Ответ 3

Я бы слегка обернулся и подумал:

(1) ввести простые (ish) меры, чтобы ваша программа не была тривиальной для взлома, так, например, в Java:

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

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

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

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

Ответ 4

Personaly Я поклонник проверки на стороне сервера. Это может быть так же просто, как аутентификация приложения или пользователя при каждом запуске. Однако это можно легко взломать. Или добавив часть кода на сервер, и это потребует гораздо больше работы.

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

Больше логики вы перейдете на серверную сторону, более сложную для взлома. Но это будет, если это того стоит. Даже крупные компании, такие как Blizzrd, не могут предотвратить обратную обработку серверной части theyr.

Ответ 5

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

После нескольких месяцев борьбы с множеством методов борьбы с растрескиванием, с 2009 года я мог бы создать метод, который оказался эффективным, по крайней мере, в моем случае: мое приложение не было взломанным с тех пор.

Мой метод состоит в использовании комбинации из трех реализаций:

1 - Множество проверок в исходном коде (размер, CRC, дата и т.д.: используйте свое творчество. Например, если мое приложение обнаруживает инструменты, подобные исполнению OllyDbg, это заставит машину завершить работу)

2 - Вирутализация CodeVirtualizer в чувствительных функциях в исходном коде

3 - Шифрование EXE

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

Но когда вы использовали в целом, они будут причинять БОЛЬШУЮ боль любому крекеру.

Это не идеально, хотя: столько проверок делает приложение медленнее, и EXE-шифрование может привести к ложному срабатыванию в некоторых антивирусных программах.

Даже в этом случае нет ничего похожего на не растрескивание;)

Удачи.

Ответ 6

Я назначаю следующее:

Создайте в доме ключ с именем KEY1 с N байтами случайным образом.
Продайте пользователю "Номер лицензии" с помощью Программного обеспечения. Обратите внимание на его/ее имя и фамилию и сообщите ему, что эти данные необходимы для активации Программного обеспечения, а также для интернет-соединения.
Загрузите в течение следующих 24 часов на ваш сервер "Номер лицензии", а также имя и фамилию, также KEY3 = (KEY1 XOR hash_N_bytes (License_number, имя и фамилия))
Установщик запрашивает "Licese_number" и имя и фамилию, затем он отправляет эти данные на сервер и загружает ключ с именем "KEY3", если эти данные соответствуют действительной продаже.
Затем установщик делает KEY1 = KEY3 XOR hash_N_bytes (License_number, имя и фамилия)
Установщик проверяет KEY1 с помощью "Хэша" из 16 бит. Приложение зашифровано ключом KEY1. Затем он расшифровывает приложение с помощью ключа и готов.
Оба установщика и приложения должны иметь проверку содержимого CRC.
Оба могут проверить, что отлаживается.
Оба могут иметь зашифрованные части кода во время выполнения.

Что вы думаете об этом методе?