Впервые сталкиваясь с проблемой защиты ПО от взлома, удивляюсь многогранности как методов взлома, так и методов защиты.
Процесс дизассемблирования позволяет превращать машинный код программы в текст на языке ассемблера. Процесс отладки позволяет выяснить, по какому пути выполняется программа, а также подделать ее переменные в необходимые значения. Процесс трассировки позволяет пошагово выполнить какой-то участок программы. Эти процессы взаимосвязаны: отладчик может содержать в себе дизассемблер, а возможность трассировки в отладчике присутствует в каждой среде программирования. Итак, изначально для взломщика сам код программы и данные, создаваемые ей в RAM, представляют большую кашу. Он ее мешает (анализирует, выстраивает логику), отделяя зерна, шелуху и молоко (точки входа функций, их указателей, отличий данных от машинного кода). Задача защитника ПО максимально усложнить взломщику эти задачи, что сводится не только к активным элементам защиты, но и к пассивным (усложнение процесса анализа и понимания). Методы активной защиты: - поиск кода программы, который выполняется часто и с примерно одинаковым временем. Поставить проверку этого времени, и если время выполнения кода больше, то программу ломают в отладчике - принудительно закрыть программу; - установка высокочастотного таймера (или нескольких), делающих бессмысленную работу (желательно, с большими объемами данных). Бессмысленная работа должна быть хаотичной: то период таймера изменится, то Randomize + Rnd сработают, то куча информации откуда-нибудь читается и записывается. В итоге взломщику будет очень сложно отличить полезные данные от мусора, т.к. мусор генерируется хаотично; - обеспечение одновременного выполнения мусорных таймеров и полезных функций. Это смешает мусор с полезной информацией; - блокировка отладочных прерываний процессора; - блокировка прерываний с клавиатуры. Методы пассивной защиты: - упаковка выходного EXE-файла (а лучше - его частей) каким-нибудь упаковщиком (а лучше - его частной модификацией), чем сильнее сжатие - тем лучше; - составление EXE-файла таким образом, что он полностью автономен и не использует внешних библиотек (кроме API, конечно); - увеличение объема программы, наполняя ее объемным мусорным исходным кодом (желательно, чтобы он ещё и выполнился пару раз); - компиляция в P-Code, а не в Native Code наоборот. P-Code легче декомпилируется, но сложнее отлаживается. Native Code легче отлаживается, но тяжелее декомпилируется; - больше глобальных переменных внутри важных функций. Компилятор их в регистры не заносит (правда, код медленнее работает). Взломщику постоянно придется думать, что это какие-то важные переменные, ещё кому-то нужные, - процесс взлома идёт труднее. И это я прочитал всего лишь пару десятков статей. Разобравшись с другими способами защиты, можно заставить взломщика кирпичами кидаться от негодования. (добавлено 27.07.2014): дополнительные активные методы защиты: - если в программе используются функции всплывающих сообщений (MessageBox, ShowMessage и другие), то для защиты программы это плохо. Всплывающее сообщение заставляет программу "замереть" (в том числе останавливаются все активные методы защиты), а данные массивов остаются висеть в памяти в свободном доступе. В этом случае нужно писать свою функцию всплывающих сообщений, с очисткой (как минимум) глобальных переменных до выдачи сообщения. Или полностью отказаться от такого рода функций, записывая ошибки в текстовые поля формы или в файл; - очищать массивы и присваивать им размерность 1 сразу после окончания их использования в больших функциях. Очищать - чтобы физически удалить данные из памяти, присвоить размерность - чтобы не сохранять информацию о размере массива. Дополнительные пассивные методы защиты: - использование программ обфускации (запутывание кода программы, скрытие имен переменных), закрывает некоторые дыры при декомпиляции программы из P-Code. Применять ее нужно как к выходному файлу, так и к упакованному. |