Как защитить приложение от взлома
Я решил написать статью о том, как защитить свои программы от взлома. Оговорюсь сразу, практически невозможно создать такую защиту, которая могла бы противостоять опытному взломщику. Но можно попытаться создать такую защиту, которая окажется не по зубам около 90% взломщиков. Все мои идеи по защите основаны на личных наблюдениях, и они могут не быть достоверными, но могут быть полезными против большинства новичков и продвинутых взломщиков. Сейчас я расскажу, какие инструменты использует средний взломщик:
Во-первых, самый незаменимый инструмент это дебагер, то есть программа, которая позволяет трассировать код чужой программы в живую. Список этих программ варьируется от простого debug'а до продвинутого Soft-Ice'а.
Во-вторых, программа дизассемблер, которая превращает байты программы в команды ассемблера, тем самым позволяет просмотреть, где и как действует защита. Причем хороший дизассемблер показывает еще и где, какие строки используются в программе. Далее идут всевозможные утилиты, для мониторинга реестра, файлов, определители компилятора и упаковщика, распаковщики, дамперы памяти, генераторы кряков и т.д. Ну и конечно самое главное это мозги взломщика, ведь во многом результат взлома зависит от его сообразительности или идиотизма.
Короче наша задача, обмануть все эти средства, и самое главное запутать взломщика. И вот как мы это сделаем, я буду идти по приведенному списку и буду объяснять, как защитится от этих средств и от взломщика. Начнем с дебагеров. Вообще-то, многие взломщики недолюбливают VB, потому что он работает благодаря своим библиотекам, и естественно взломщику потребуется очень много времени, чтобы разобраться, где код программы, а где вызовы библиотечных функций (проверено на опыте). Но это случается, только тогда когда программа была скомпилирована в P-код, то есть в псевдокод. Значит первое кольцо защиты, должно быть компилирование в псевдокод. Если вы думаете, что на этом все закончилось, то глубоко ошибаетесь. На свете есть дебагер именуемый P-Code Loader, и он позволяет фильтровать вызовы библиотек и показывать непосредственно код программы. Конечно, не у всех он есть, но если есть, то не стоит слишком надеяться на то, что взломщик откажется от взлома. Поэтому P-код не должен быть главной ставкой программиста. Конечно, с псевдокодом придется таскать кучу библиотек но, как говориться здоровье дороже.
Иногда программы используют различные приемы против дебагеров, основанные на их свойстве выполнять команды до их фактического выполнения. То есть теоретически можно создать команду, которая отправит дебагер в тартарары, в то время как процессор проигнорирует эту команду из-за системы прогнозирования переходов. Я не умею это делать, поэтому упоминаю это только потому, что однажды встретился с этим приемом.
Копаясь с АПИ справочнике, я обнаружил замечательную функцию IsDebuggerPresent, которая возвращает True, если в системе стоит системный дебагер типа SofIce'а.
Функция работает, начиная с NT и Win98:
Далее, дизассемблеры. В инструментарии взломщика дисассемблер занимает почетно место. Редко взломщик изучает программу без дизассемблера. Дизассемблер дает не только информацию о коде программы, но и показывает имена используемых функций и строковые выражения, использующиеся в программе, а также предоставляет удобную навигацию по вызовам функций и прыжкам. Дизассемблер можно обмануть несколькими путями. С начала, что значит обмануть? Обмануть значить не дать дизассемблеру показать истинный код программы. Этого достигнуть можно следующим способом, программу можно упаковать каким-нибудь упаковщиком типа Aspack, UPX и т.п.
В этом случае дизассемблер сможет показать разве что код упаковщика и более ничего. Но ведь существуют и распаковщики, поэтому всегда есть вероятность того, что у взломщика найдется подходящий распаковщик, и он получит готовенький код вашей программы. Что бы предотвратить это, нет никаких способов. Разве что пользоваться несколькими упаковщиками или использовать нестандартный, мало кому известный упаковщик. Это серьезно затруднит взломщиков, но особенно настырных это не сможет остановить (ведь теоретически можно найти то место где упаковщик передает программе управление и провести кое-какие манипуляции с кодом).
Поставьте таймер, который проверяет каждые 10 минут право пользователя на работу. Причем если вы используете чистые проверки (без мусора), то взломщик может заметить это, и использовать это. Поэтому проверяйте пользователя в месте с мусором, чтобы ваша проверка не бросалась в глаза. Кстати тот же таймер (или другой с меньшим интервалом) подскажет вам, трассируют ли вашу программу или нет.
Вообще все чем я вам пудрю мозги, рассчитано на то, чтобы запутать взломщика.
Но это были цветочки, теперь ягодки.
Как вам известно, проверка пароля самая важная в защите, так как именно ей приходится выдерживать удары тяжелой артиллерии и поэтому у нее должна быть защита, как у банковского сейфа.
Кстати, я недавно прочитал книжку по хакингу, крэкингу, и фрикингу. Так вот там автор утверждал, что надежность защиты определяется надежностью её самого слабого звена. Это утверждение применимо и в нашем деле. Насколько я понимаю самая слабая точка в защите, это то место где программа решает как её вести себя дальше, то есть купили её или нет. Это является очень критической точкой, так как большинство начинающих и ленивых взломщиков, часто трассируют огромные куски кода ради вышеописанного места в программе. Значит надо внимательно следить за этим, и лучше завести несколько дублей переменной и сверять их.
Часто взломщики не просто банально меняют нужный код, а исследуют алгоритм создания пароля и пишут генераторы серийных номеров. Поэтому необходимо хорошо защитить этот алгоритм. Желательно использовать какой-нибудь криптостойкий алгоритм типа RSA или MD5. В Интернете можно найти методы работы с ними. Также, чтобы затруднить взломщика желательно разбить генерирование пароля на несколько этапов, разбить по функциям (желательно рабочим, чтобы чаще вызывались не только из-за пароля), и в промежутках между вызовами этих функций проверять на исследование вашу программу. И ещё помните что когда ваша программа под дебагером, она не может выполнять параллельно несколько вещей, то есть если она проверит на наличие дебагера, взломщик может это заметить и выключить. Поэтому не давайте никому этого шанса, относитесь к каждому пользователю как к потенциальному взломщику. Ну вот и все, что я хотел рассказать
Я написал эту статью по нескольким причинам:
Все приведенные методы используйте, как хотите. Ну и конечно тому, кому лень защищать свое детище, или он отмахивается тем, что программу все равно сломают, не стоило даже и читать эту статью.
В данной статье мы кратко расскажем о том, как можно защитить свою программу от взлома, не интегрируя стандартное решение от Google и предоставим пример рабочего кода. Интересно? Просим под кат!
В чём слабость Google Application Licensing?
Как реализовать свою собственную защиту?
Очевидно, что любую защиту можно сломать. Данный метод не является серебрянной пулей, но он имеет право на жизнь. Для проверки уникальности приложения есть смысл проверить сертификат, которым это приложение было подписано. Информацию о сертификате можно прочитать из PackageInfo:
Нулевой элемент массива будет содержать необходимую информацию о ключе, которым было подписано приложение. Сохраните сам ключ, он вам понадобится совсем скоро.
Логично, что делать такую проверку в Java не имеет смысла, так как аналогичный приём с использованием apktool похоронит вашу защиту за несколько минут. Поэтому данную проверку стоит перенести на нейтив уровень.
Что делать дальше?
Необходимо вынести часть своего функционала в ту же библиотеку и перед тем как вернуть значение проверить сертификат на подлинность. И не забываем про фантазию, которая необходима для того, чтобы сбить с толку потенциального хакера. Допустим, вы определили, что данная копия приложения — не подлинная. Нет смысла явно говорить об этом, намного веселее добавить случайный элемент в действия программы. К примеру, если у вас игра, то можно добавить силы соперникам или сделать игрока более уязвимым. Также можно добавить случайные падения, к примеру в 10% случаев (справедливое замечание от хабраюзераzagayevskiy: случайные падения испортят карму вашей программы. ). Тут всё зависит только от вас.
Вот простой пример возможной реализации:
Для начала пишем класс, который делает вызов библиотеки для получения некоторых данных.
Метод init нужен для того, чтобы не вызывать проверку подлинности сертификата каждый раз.
Реализация нейтив методов:
Данный вариант защиты также может быть взломан путём дизасемблирования, но для этого нужен совсем другой уровень знаний и намного больше времени, чем в случае с реализацией защиты на уровне Java. При наличии определённых средств есть смыл приобрести обфускатор для С кода, в этом случае взлом будет далеко не тривиальной задачей.
Защита приложения при наличии серверной части.
Если часть логики приложения реализована на сервере, есть смысл вынести проверку подлинности сертификата на сервер. Как вариант, можно использовать такой алгоритм действий:
- Сервер генерирует приватный и публичный RSA ключи;
- Клиент отправляет запрос на сервер и получает публичный ключ;
- На клиенте реализовываем нативную библиотеку с функцией вида String getInfo(String publicKey); функция должна считать сертификат, добавить к нему некоторую случайную величину, затем зашифровать полученную строку используя публичный RSA ключ;
- Клиент делает новый запрос на сервер, отправляя полученную строку. Сервер производит декодирование, отделение сертификата от случайной величины и проверку его на подлинность;
- В зависимости от результатов проверки сервер реагирует на все следующие запросы клиента.
Надеемся, данный механизм поможет читателям Хабра повысить заработок со своих Android приложений.
Уровень пиратства в экосистеме Android таков, что говорить об этом нет никакого смысла. Приложение не только легко украсть — его легко взломать, отвязать от сервисов проверки, отключить рекламу или даже внедрить в него бэкдор. Выкладывая свое творение в Play Store, ты рассчитываешь получить прибыль, а в результате даришь любителям вареза еще один хороший продукт. К счастью, с этим вполне можно бороться.— Как украсть приложение для Android?
— Берешь и крадешь.
Для рубрики «Взлом» я написал цикл статей, в которых наглядно показал, насколько на самом деле легко взламываются приложения для Android. Для этого не нужен даже дизассемблер, достаточно поверхностных знаний Java и языка Smali. Поэтому, если твое приложение будет достаточно популярно, знай: его украдут и путем нехитрых манипуляций активируют платные функции. А если ты решил монетизировать его с помощью рекламы — ее отключат.
Защитить приложение сложно, но можно. Во-первых, стоит сразу отказаться от модели распространения Pro/Lite. Приложение очень легко вытащить со смартфона, поэтому вору будет достаточно один раз купить приложение, и дальше его можно распространять as is. Во-вторых, необходимо позаботиться о защите кода от реверса. Декомпиляция Java-кода — дело простое, а изменение бинарного кода не требует каких-то особых навыков или инструментов. В-третьих, нужно сделать так, чтобы в случае даже успешного взлома приложение просто не стало работать. Тогда взломщику придется решать сразу две задачи: взломать приложение и заставить взломанную версию работать.
Итак, отказываемся от Pro-версии и начинаем борьбу.
Скрываем и запутываем код
Лучший способ защиты кода приложения от реверса — это обфускация, другими словами — запутывание байт-кода так, чтобы реверсеру было невыносимо трудно в нем разобраться. Существует несколько инструментов, способных это сделать. Наиболее простой, но все же эффективный есть в составе Android Studio. Это ProGuard.
Для его активации достаточно добавить в раздел android → buildTypes → release файла build.gradle строку minifyEnabled true :
После этого Android Studio начнет пропускать все «релизные» сборки через ProGuard. В результате приложение станет компактнее (благодаря удалению неиспользуемого кода), а также получит некоторый уровень защиты от реверса. «Некоторый» в том смысле, что ProGuard заменит имена всех внутренних классов, методов и полей на одно-двухбуквенные сочетания. Это действительно существенно затруднит понимание декомпилированного/дизассемблированного кода.
Так выглядят классы в декомпиляторе JADX после применения ProGuard
Следующий шаг — шифрование строк. Это особенно полезно в том случае, если внутри приложения ты хранишь какие-либо сенситивные данные: идентификаторы, ключи, REST API endpoints. Все это поможет взломщику сориентироваться в твоем коде или вычленить из него важную информацию.
Зашифровать строки можно разными способами, например используя инструменты Stringer или DexGuard. Преимущество: полностью автоматизированная модификация уже имеющегося кода с целью внедрения шифрования строк. Недостаток: цена, которая доступна компаниям, но слишком высока для независимого разработчика.
Поэтому мы попробуем обойтись своими силами. В простейшем случае шифрование строк средствами Java выполняется так:
А расшифровка — так:
Для генерации ключа достаточно одной строки:
Смысл в том, чтобы написать простенькое настольное/мобильное приложение на Java, которое возьмет на вход все твои строки и выдаст на выходе их зашифрованные варианты. Далее ты вставляешь эти строки в основное приложение вместо оригинальных и в местах, где происходит к ним обращение, вызываешь функцию decryptString() .
В результате взломщик просто не сможет увидеть зашифрованные строки, декомпилировав приложение. Но, конечно же, сможет написать простейший дешифратор, основанный на декомпилированном коде твоего шифратора. Другими словами, это не панацея, но еще один уровень сложности шифрование строк добавит.
Можно пойти еще дальше и воспользоваться одним из инструментов комплексной защиты Android-приложений, например AppSolid. Стоит оно опять же дорого, но позволяет зашифровать все приложение целиком. Это действительно способно отпугнуть многих реверсеров, однако есть ряд инструментов, в том числе платный Java-декомпилятор JEB, который умеет снимать такую защиту в автоматическом режиме.
Также ты можешь попытаться разбить свое приложение на множество небольших модулей, как я уже писал в статье Пишем модульные приложения для Android. Сам по себе это не метод защиты, и он почти не затруднит работу реверсера. Но зато обломает различные автоматизированные системы кракинга приложений. Они просто не смогут понять, где искать находящийся в модуле код.
Ну и последнее: из кода необходимо обязательно удалить (закомментировать) все обращения к логгеру, то есть все вызовы Log.d() , Log.v() и так далее. Иначе взломщик сможет использовать эту информацию, чтобы понять логику работы приложения.
Крашим взломанное приложение
Окей, жизнь реверсеру мы немного подпортили. Настало время сделать это еще раз! Но как узнать, было ли приложение взломано? Точнее, как оно само может это выяснить? Ведь понятия «взломанное» и «не взломанное» существуют только в наших с тобой головах, то есть это понятия достаточно высокого порядка, которые не описать алгоритмически.
Так оно, да не так. Дело в том, что внутри APK-файла есть набор метаданных, которые хранят контрольные суммы абсолютно всех файлов пакета, а сами метаданные подписаны ключом разработчика. Если изменить приложение и вновь его запаковать, метаданные пакета изменятся и пакет придется подписывать заново. А так как твоего ключа разработчика у реверсера нет и быть не может, он использует либо случайно сгенерированный, либо так называемый тестовый ключ.
Сам Android такое приложение спокойно проглотит (он не держит базу всех цифровых подписей всех возможных Android-разработчиков), но у нас-то есть своя цифровая подпись, и мы можем ее сверить!
Сверяем цифровую подпись
Собственно, метод довольно простой. Тебе необходимо вставить в приложение код, который будет получать хеш ключа текущей цифровой подписи пакета и сравнивать его с ранее сохраненным. Совпадают — приложение не было перепаковано (и взломано), нет — бьем тревогу.
Для начала вставь следующий кусок кода в приложение (чем глубже ты его запрячешь, тем лучше):
Он как раз и будет сверять сохраненный хеш с хешем ключа, которым в данный момент подписано приложение. Функция возвращает true, если цифровая подпись твоя (приложение не было пересобрано), и false — если оно подверглось модификации. Что делать во втором случае — решать тебе. Ты можешь просто завершить приложение с помощью os.exit(0) либо «уронить» его, например вызвав метод неинициализированного объекта или обратившись к несуществующему значению массива.
Но запомни: взломщик может просто вырезать твой код сверки цифровой подписи и он никогда не сработает (это справедливо и в отношении кода, приведенного далее). Поэтому спрячь его в неочевидном месте, а хеш оригинального ключа зашифруй, как было показано выше.
Искомый хеш ключа
Проверяем источник установки
Еще один метод защиты — выяснить, откуда было установлено приложение. Тут логика простая: если источник установки — Play Store, то все нормально, это оригинальное неперепакованное приложение. Если нет — варез, скачанный с форума и установленный с карты памяти или из «черного маркета».
Выяснить, откуда было установлено приложение, можно в одну строку, а сама функция, делающая это, может выглядеть так:
Как обычно: true — все нормально, false — Хьюстон, у нас проблемы.
Определяем эмулятор
Некоторые методы реверса приложений предполагают использование эмулятора. Поэтому нелишним будет внести в приложение код, проверяющий, не запущено ли оно в виртуальной среде. Сделать это можно, прочитав значение некоторых системных переменных. Например, стандартный эмулятор Android Studio устанавливает такие переменные и значения:
Поэтому, прочитав значения этих переменных, можно предположить, что код исполняется в эмуляторе:
Обрати внимание, что класс android.os.SystemProperties скрытый и недоступен в SDK, поэтому для обращения к нему мы используем рефлексию (о скрытых API Android я уже писал).
Также имей в виду, что существует огромное количество других эмуляторов Android и в них значения переменных могут отличаться. Данный код способен обнаружить только стандартный эмулятор Android.
Отладка
Еще один метод реверса — это запуск приложения под управлением отладчика. Взломщик может декомпилировать твое приложение, затем создать в Android Studio одноименный проект, закинуть в него полученные исходники и просто запустить отладку, не компилируя проект. В этом случае приложение само покажет ему свою логику работы.
Чтобы защититься от отладки, можно использовать следующий код:
Так делать не стоит: код проверок необходимо раскидать по коду и продублировать
Выводы
Создать на 100% защищенное приложение у тебя не получится, можешь даже не пытаться. Но есть достаточно простые способы существенно усложнить жизнь среднестатистическому реверсеру. Да, приложение все равно рано или поздно взломают, но так у тебя хотя бы будет время, чтобы заработать на нем. Ну и стоит почаще обновлять свое творение, чтобы реверсерам жизнь медом не казалась.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Введение
Рассмотрим некоторые тонкости организации защиты на достаточно популярном примере - предполагаем, что программа защищена некоторым кодом (серийным номером, паролем), который сообщается пользователю после соблюдения им определенных условий. До регистрации в этой программе заблокирован ряд каких либо полезных функций, используется надоедливая реклама или ограничен строк работы. После ввода этого кода производится его проверка и при положительном исходе проверки программа начинает нормально работать.
По неизвестной мне причине в большинстве современных программ данная защита сделана однообразно и для ее снятия необходимо 10-15 минут. В этой статье я постараюсь поделиться опытом в построении систем защиты. Могу сразу предупредить - хорошему хакеру противостоять практически бесполезно, да и не нужно - при желании любая защита может быть взломана, это вопрос времени.
Инструментарий хакера
Современный хакер имеет в своем арсенале набор разнообразных утилит для взлома.- Отладчики. Позволяют прерывать выполнение программы при достижении заранее заданных условий, производить пошаговое выполнение программы, изменять содержимое памяти и регистров и т.п. Наиболее популярным, удобным и мощным является отладчик SoftICE, который при достаточно примитивном интерфейсе обладает приличными возможностями и весьма стабильно работает.
- Дизассемблеры. Производят дизассемблирование программы для дальнейшего изучения полученного кода. Один из наиболее мощных и популярных - IDA. От дизассемблера достаточно легко защититься - зашифровать или заархивировать программу. Тогда дизассемблируется только архиватор или кодировщик. Однако тот-же IDA имеет мощный встроенный скриптовой язык, позволяющий производить расшифровку программы
- Средства мониторинга. Это набор утилит, отслеживающих операции с файлами, реестром, портами и сетью.
- Средства пассивного анализа программы. Показывают разную информацию о программе - извлекают ресурсы, показывают связи, используемые библиотеки. Классический пример - утилита DEPENDS.EXE из комплекта Visual Studio. Она показывает, какие библиотеки используются программой и какие функции импортируются.
- Прочие утилиты. Их великое множество (можно найти на диске типа "Все для хакера", причем в изобилии). Это разнообразные редакторы, анализаторы .
- FileMon - утилита, позволяющая вести мониторинг всех операций с файлами. Имеет удобный фильтр, может сохранять отчет в файле. Поэтому нет смысла делать "секретные" файлы где-нибудь в Windows/System - их элементарно найти.
- RegMon - аналог FileMon, только ведется мониторинг всех операций с реестром. Аналогично файлам, бессмысленно создавать в реестре "секретные" ключи - они сразу бросаются в глаза.
- PortMon - мониторинг работы с портами ввода/вывода
- TCP_VIEW - монитор соединений по TCP-IP
- RegUtils - набор утилит для контроля за реестром - делает копии реестра, позволяет сравнивать копии и просматривать изменения.
Основы построения защиты - шаг за шагом
Как ввести регистрационный код. Ввод пароля или регистрационного номера является ответственным делом - хакер постарается отловить адрес памяти, в который будет записан пароль. Затем на обращение по этому адресу ставится точка останова (команда BPM в SoftICE), что позволяет поймать начало процедуры проверки регистрационного кода. Если для ввода используются стандартные элементы ввода Windows, то алгоритм действий хакера можно формализовать и выглядит он примерно так:
- Устанавливает точку останова на считывание текста из стандартного элемента ввода (функции GetWindowText, GetGlgItemText модуля KERNEL32)
- При вызове этой функции анализируем ее параметры и таким образом определяем, по какому адресу будет размещено считываемое значение и ставим обращение к этой области памяти точку останова. А достоверности определенного адреса легко убедиться - после выполнения функции там появится введенная строка
- При срабатывании этой точки останова мы попадаем в анализатор введенного значения и либо делаем генератор регистрационных ключей, либо ломаем процедуру проверки. И то, и другое весьма просто сделать - достаточно только изучить ассемблер и API
Набор этих действий стандартен и мне не раз попадались подробные руководства типа "Взлом Windows программ - шаг за шагом", ориентированные на продвинутого пользователя.
Рассмотри несколько решений, которые могут затруднить взлом на этом этапе.
Совет _0. Старайтесь как можно меньше применять стандартные функции (особенно API-шные) и компоненты VCL. Так что Assembler, Assembler и еще раз Assembler .
Сущность этого совета надеюсь очевидна - современные дизассемблеры умеют распознавать стандартные процедуры высокоуровневых языков, а API - вообще отдельный разговор - SoftICE обладает изумительной возможностью - загружать символьные имена для любых указанных библиотек (особенно для KERNEL32.DLL) - отладка резко упрощается, т.к. мы видим имена вызываемых функций и можем ставить точки останова на вызов функций по их имени.
Совет 1. Применяйте нестандартный способ ввода пароля.
Наипростейший путь - написать свой визуальный компонент для ввода регистрационного кода. Он конечно должен будет обрабатывать события от клавиатуры, но момент считывания кода нельзя поймать избитыми методами. Это уже что-то, но есть второй способ взлома, основанный на поиске введенного кода в памяти. Для этого в SoftICE есть удобная команда "S стартовый адрес L длина 'образец'" , которая позволяет найти введенное значение в памяти.
Совет 2. Не храните введенный код в одном месте !
Если введенный код или регистрационный номер хранить в одном месте, то достаточно легко установить точку останова на эону памяти, в которой зазмещен введенный код.
Совет 3. Не храните введенный код открытым текстом !
Итак, что же следует сделать. Для начала необходимо завести в программе 5-10 переменных типа STRING и после ввода кода переписать введенное значение в них. Делать это лучше всего не в одном месте, а распределить по программе. Таким образом поиск даст кучу адресов, по которым будет находиться введенный код. Я в таком случае поступаю так - по таймеру создаю в динамической памяти новую строковую переменную, пишу в нее код. Затем на следующем срабатывании таймера создаю новую переменную, переписываю в нее код, а старую уничтожаю. При определенном навыке можно заполонить память значениями введенного кода и сделать поиск почти бесполезным. Причем такое копирование можно совместить с проверкой кода или эмуляцией этой проверки. Затем с эти строками неплохо поделать какие-либо операции - сравнить с чем-нибудь .
Советы 3 и 1 можно объединить - создать свой компонент, который позволит вводить код нестандартным способом с его одновременной шифровкой.
Анализ регистрационного кода. Итак, код введен и приняты меры для того, чтобы его было непросто найти (хотя найти то его можно, но это время, навык . ). Теперь следующий шаг - анализ. Поэтому сразу совет:
Совет 4. Ни в коем случае не анализируйте код сразу после его ввода .
Чем дальше ввод кода от его анализа, тем лучше. Самое разумное - после ввода кода поблагодарить пользователя за сотрудничество и сообщить, что со временем будет выполнена регистрация программы. А анализ кода произвести, например, через 1-2 минуты в совершенно другом месте программы.
Совет 5. Не проверяйте код только в одном месте и не пишите для проверки функцию.
Достаточно найти и отключить эту проверку, и защита взломана. Если проверок несколько, они разные и распределены по программе, то взлом затрудняется.
Совет 6. Не проверяйте пароль одним алгоритмом.
Рекомендуется разработать 2-3 алгоритма проверки, например 1-2 цифры должны делиться на 3, а 3-7 наложенные по какому-либо алгоритму на имя пользователя должны дать в сумме 4. Эти две проверки осуществляем в различных местах с достаточно большим временным разносом - взломав первый метод хакер не будет догадываться о существовании еще нескольких, которые проявятся со временем.
Совет 7. Ни в коем случае не предпринимайте никаких действий после проверки. По неизвестной причине большинство программ выглядят примерно так
Совет 8. Отвлекающие маневры.
Классический пример нарушения этого правила
Совет 10. (вытекает из 9) Не храните результатов проверки на диске или в реестре.
Выводы: мы устроим проверку кода в нескольких местах программы, при этом применим несколько алгоритмов проверки, не будем использовать API.Кроме того, стоит проделать несколько отвлекающих маневров.
- CRC - контрольные суммы. Любой файл, строку или блок данных можно защитить контрольной суммой, которую затем можно рассчитать и сравнить с эталоном. При сравнении с эталоном конечно следует весть осторожно - см. первые 11 советов. Итак, совет 12. Защищайте программы и данные контрольными суммами. Это поможет не только от взлома, но и защитит программы от вируса или внедрения троянца.
- Применяйте шифровку программ и данных. Очень неплохо сжать программу и данные. Я, например, разработал свой собственный архиватор - RAR-у и ZIP-у он конкуренции не составит, но сжатые им данные разжать очень непросто, придется изрядно повозиться. Да и изменить их проблематично - придется разжать, изменить и сжать.
- Отлов пошаговой отладки программы. Существует много способов, я в свое время провел целое исследование этого вопроса под DOS, насобирал и придумал не менее 20 методов, но они мало приемлемы под Windows. Самый простой и надежный способ - таймер. При работе программы периодически фиксируем системное время и рассчитываем время работы фрагментов кода между ними. И если 200-400 команд процессора работают 2-3 минуты, то тут есть над чем задуматься.
Совет 14.Не стоит хранить что-либо секретное в файлах или реестре. Работа с файлами или реестром может быть детально запротоколирована и проанализирована, и все тайное станет явным.
Советы по созданию меток для организации ограничения по времени
Защита "ограничение времени работы" состоит в том, что программа каким образом фиксирует момент своего первого запуска и работает установленное время (обычно 20-30 дней). После истечения этого срока программа отказывается запускаться. Как проверить текущую дату я уже где-то тут писал - нестандартным способом, например по дате на файлах реестра или свежесозданном своем файле. Весь фокус в другом - как зафиксировать на компьютере дату первого запуска (естественно так, чтобы изничтожение программы и ее повторная установка не давали эффекта). Использование "секретных" файлов в системных папках или изменения в существующих файлах легко отловить при помощи FILEMON. Реестр то же отпадает из-за REGMON. Прочие методы (типа записи в ВООТ сектор . ) тоже неприемлемы - не те времена, по Windows все это не пройдет. Наиболее оригинально (на мой взгляд) прошить дату в саму программу и постоянно обновлять ее на своем сайте (естественно, автоматически). Таким образом отсчет неявно идет от момента скачивания программы с сайта. Есть тут правда и минус - после завершения срока можно повторно скачать эту программу и получить еще 15-20 дней . . С другой стороны это оригинально - пользователю рано или поздно надоест скачивать эту программу и он или откажется от нее, или купит. Но при этом стоит помнить, что программу можно скачать несколько раз и сравнить варианты, выявив, где лежит дата. Поэтому стоит позаботиться о том, чтобы изменился почти весь файл (например, изменить пару опций компилятора)
Советы по формированию регистрационных кодов
Рекомендовать тут что-либо бесполезно, но я например использую разновидности метода 3.
Читайте также: