Форум АНТИЧАТ - Простейшие приемы антиотладки...

Простейшие приемы антиотладки...

11.06.2007, 17:37

Jes

Постоянный

Регистрация: 16.04.2007

Сообщений: 398

Провел на форуме:
3371897

Репутация: 1462

Простейшие приемы антиотладки...

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

Интернет становится всё более привлекательной средой для заработка. Простейшая програмка, которую можно написать за 20 минут стоит около 20 баксов.При такой мысли так и хочется начать кодить за деньги...

Даешь опен соурс!
Если же последняя фраза выхвала у тебя отвращение и твоим рассудком правит алчность ...вобщем читай...
Поскольку Dream CD можно купить повсюду ,программа должна иметь хотя бы элементарные алгоритмы самозащиты....
Здесь я опишу как приемы, так и идеи для реализации...

Простейшие приемы защиты своего приложения от взлома...

Как правило , крякер ставит breakpoint на какую-нибудь API (зависит от интерфейса). Чаще всего это бывает MessageBoxA или GetWindowTextA, GetWindowTextw, GetDlgItemTexta, GetDlgItemTextW. За что они отвечают? MessageBox вылезает, присообщении "Вы ввели неправильный пароль" , а остальные четыре могут вызываться, когда вы читаете содержимое Edit'а или чего-нибудь еще.

Список использованных функций можно посмотреть в дизассемблированном файле; чтобы этого не было видно: можно использовать вызов необъявленных API (темя для отделоной статьи) Теперь посмотрим, как хранить информацию о том, зарегистрирован пользователь или нет. Если сделать в реестре пометку Registered=1, то понятно, к чему это приведет. Наилучший вариант - Писать данные пользователя в отдельный файл или ветку реестра (еще лучше туда и туда) и при каждом запуске проверять эту информацию. Можно также во время загрузки перед считыванием (и после) обращаться к "левым" веткам реестра и файлам. Это затруднит поиск.
Так же (для 'дорогих' приложений) я посоветовал бы шифровать данные пользователя собственным шифром (необращаясь к известным алгоритмам) , это может серьёзно осложнить написания кряка...

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

Очень интересный способ - считывать информацию сразу при их вводе, а затем считывать информацию просто "для отвода глаз"...

Еще вариант:
"Кто сказал, что пользователю нужна моментальная реакция??? Считайте данные и скажите, что пароль проверится через несколько секунд, и пусть весь мир подождет" (цитата , уже не помню откуда , но толк есть) . Тоесть можно пароль считывать и сравнивать посимвольно, опять же через таймер.

Так же кодеры Borland C++ заметно осложнить декомпилятцию своего приложения ,используя набор функций CodeGuard и оптимизации кода,одноименного компилятора...

Так же , дабы защитить свою программу от модифицирования в бинарном редакторе , следует регулярно подщитывать CRC файлов приложения...
При этом многие большие проэкты используют свои собственные алгоритмы определения и проверки CRC...

Далее предположим , информацию считали , но настоящего крякера ничто не остановит ... Там где не поможет диассемблирование , победным маршем пройдет отладчик.
Вооружимся же знаниями:

Первым же помошником нам будет API и функция kernel : IsDebuggerPresent
вот пример её использования на дельфях...

Код:

function DebuggerPresent:boolean;
type
  TDebugProc = function:boolean; stdcall;
var
   Kernel32:HMODULE;
   DebugProc:TDebugProc;
begin
   Result:=false;
   Kernel32:=GetModuleHandle('kernel32.dll');
   if kernel32 <> 0 then
   begin
      @DebugProc:=GetProcAddress(kernel32, 'IsDebuggerPresent');
       if Assigned(DebugProc) then
        Result:=DebugProc;
end;
end;

Код:

if DebuggerPresent then
  ShowMessage('Go to Disneyland, cracker...')
else
 Showmessage('welcome');

Далее заметим: отладчик , анализируя приложение ,частично выполняет его код...
но в большинстве отладчиков нереализованна обработка множества функций, которые может выполнить прграмма.
Например банальные обработчики ошибок,которые вместо вылета возвращают программе управление. Тоесть достаточно разделить сичтанную информацию на ноль , и дешифровать её где-нибуть в обработчике ошибок.Большенство дебагеров , наткнувшись на такой финт, вылетят или проигнорируют обработчик ошибок...
Так-же полезно считывать информацию по частям,в несколько потоков.Велика вероятность ,что один из потоков останется для отладчика незамеченным...
Еще можно создать второе "мини" приложение , которому передавать часть 'пароля' для обработки...
Это заставит кракера отлаживать каждое приложение отдельно...

Есть еще очень интересный способ тут нам помогут замечательные приемы вирусостроения: запись в чужое адресное пространство и скрытие его процесса.Очень полезный способ против отладки "в реальном времени"
на 98% помогает против таких программ, как АртМани...

И наконец существует множество упаковщиков и готовых компонентов для защиты своего приложения.Но хочу заметить ,что для большинства из них есть свои распаковщики и crack tools.Так же всем известное детище AVP очень часто принимает подобного рода упакованные программы ,как вирусы ,что резко снижает доверие к программе и к её разработчику...

Но >Эпилог< настоящего кракера ничто не остановит.Приктически невозможно написать программы, которая могла бы противостоять опытному взломщику.Описанные мной приёмы позволят лишь затруднить(иногда очень значительно осложнить) его работу...а так же защитить программу от кракеров-"дилетантов". Велика вероятность что у взломщика просто не хватит терпения и он забьёт на взлом вашей софтины...
И вообще , только благодаря нелегкому труду крякеров мы ежедневно насладаемся использованием наших компилятовов , игр , софтом, операционными системыми...честь и хвала им. вперед, парни!Так держать!

Последний раз редактировалось Jes; 12.06.2007 в 15:17..