Какие методы?

самы распространёный:

Код

unit Unit1; interface type   FileShareType = (DenyCompatibility, DenyAll, DenyWrite, DenyRead, DenyNone);   FileAccessType = (ReadOnly, WriteOnly, ReadWrite);   procedure SetFileAccess(AccessMode: FileAccessType; ShareMode: FileShareType); implementation uses Windows, SysUtils; procedure SetFileAccess(AccessMode: FileAccessType; ShareMode: FileShareType); begin FileMode:=ord(AccessMode) or (ord(ShareMode) shl 4); end; function Otlad95:boolean; var HF:THandle; begin result:=false; HF:=CreateFile('\\.\SICE',GENERIC_READ or GENERIC_WRITE,                FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,                FILE_ATTRIBUTE_NORMAL,0); if (HF<>INVALID_HANDLE_VALUE) then     begin     CloseHandle(HF);     result:=true;     end; end; function OtladNT:boolean; var HF:THandle; begin result:=false; HF:=CreateFile('\\.\NTICE',GENERIC_READ or GENERIC_WRITE,                FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,                FILE_ATTRIBUTE_NORMAL,0); if (HF<>INVALID_HANDLE_VALUE) then     begin     CloseHandle(HF);     result:=true;     end; end; initialization   if Otlad95 or OtladNT then      begin     {здесь необходимые действия}      halt;      end; end.

На 100% не выйдет.
Этот способ легко обходится при помощи банального патча софтайса.
Кому нужно, все равно выломает либо защиту, либо просто имена подкорректирует.
Защита от софтайса может только маленького неграмотного крякера отпугнуть.
Хотя, если этот код чуть подправить... Убрать функции (чтобы по трэйсу не обойти), закодить имена файлов (чтоб не так явно светиться), повторить в нескольких местах кода в разных вариациях (надежней будет), то это может доставить до часа головной боль непропатченому софтайсеру.
В текущем виде код способен только насмешить. Он рабочий, но банальный и давно известный.
Гарантировано защититься нельзя. Но можно усложнить процедуру взлома. Чем больше времени будет затрачено на взлом, тем больше вероятность того, что крякер бросит эту затею...

Для определения SoftIce'а существует куча freeware dll-библиотек(anti-SoftIce) которые можно легко найти на хакерских сайтах, но существует так и куча патчей, заплаток, плюгинов направленных на скрытие и расширение возможностей отладчика. Как говорится: против лома нет приёма, если нет другого лома.
Народные способы защиты:
1. Поиск файлов SoftIce'а.
2. Проверка времени выполнения кода.
3. Тест отладоных регистров проца.
4. Реал-тайм крипторы-запаковщики портящие жизнь хакеру.
5. Выполнение защитного кода в стеке.
В остальном полностью согласен со Snowy.

Это сообщение отредактировал(а) Vadim999 - 1.8.2005, 20:25

Цитата(Snowy @ 1.8.2005, 17:09)

Убрать функции (чтобы по трэйсу не обойти)

SI - отладчик уровня ядра, функцию открытия файла от него никак не спрятать.

Цитата(Snowy @ 1.8.2005, 17:09)

повторить в нескольких местах кода в разных вариациях

Нет гарантии, что компилятор не проведет оптимизацию, сделав код одинаковым.

Цитата(Vadim999 @ 1.8.2005, 22:23)

2. Проверка времени выполнения кода.

rdtsc? Хм, в принципе неплохо, особенно если малость (хотя бы xor'ом) пошифровать ее...

Цитата(Vadim999 @ 1.8.2005, 22:23)

3. Тест отладоных регистров проца.

Доступно только на уровне ядра.

Цитата(Vadim999 @ 1.8.2005, 22:23)

4. Реал-тайм крипторы-запаковщики портящие жизнь хакеру.

Большинство наиболее известных крипторов уже изучены.

Цитата(Vadim999 @ 1.8.2005, 22:23)

5. Выполнение защитного кода в стеке.

Тоже неплохая идея, особенно если при отладке не следить за содержимым стека.

Кстати, вы не подумали о том, что SI может быть установлен совершенно легально, для работы?

Цитата(Snowy @ 1.8.2005, 17:09)

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

Золотое правило баланса мощности защиты, трудоемкости ее взлома и стоимости программы.

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

Цитата

SI - отладчик уровня ядра, функцию открытия файла от него никак не спрятать.

но можно проверить на ее перехват

Цитата

rdtsc? Хм, в принципе неплохо, особенно если малость (хотя бы xor'ом) пошифровать ее...

ниче хорошего так как на разных процах инструкции выполняются за разное кол-во тиков

Цитата

Доступно только на уровне ядра.

напишем драйвер

Цитата

Большинство наиболее известных крипторов уже изучены.

не верно на 90 процентов

Цитата

5. Выполнение защитного кода в стеке.

сп2 вроде как запретил такое делать

Цитата(oleg1973 @ 3.8.2005, 02:27)

но можно проверить на ее перехват

Можно, однако это не поможет - API слишком многослойный, просто залезем "поглубже".

Цитата(oleg1973 @ 3.8.2005, 02:27)

ниче хорошего так как на разных процах инструкции выполняются за разное кол-во тиков

В принципе это можно скорректировать. Но тогда не будет 100% уверенности в отладке.

Цитата(oleg1973 @ 3.8.2005, 02:27)

напишем драйвер

Среди программеров-прикладников есть много тех, кто сможет написать драйвер?

Цитата(oleg1973 @ 3.8.2005, 02:27)

не верно на 90 процентов

И тем не менее программы распаковывают и юзают.

Цитата(oleg1973 @ 3.8.2005, 02:27)

сп2 вроде как запретил такое делать

ОК, отметаем этот способ.

Цитата

Можно, однако это не поможет - API слишком многослойный, просто залезем "поглубже".

ну почему не поможет?
мы знаем что почти все (не все но почти) функции винды начинаются стандартно

Код

push ebp mov ebp,esp

при установке бряка софтайс заменяет это на jmp xxxx кудато
тоесть после загрузке прога должна проверить на остутствие джампов в начале функций , канешно тоже не панацея как способ, но все же )))

Цитата(oleg1973 @ 3.8.2005, 12:36)

при установке бряка софтайс заменяет это на jmp xxxx кудато

Не совсем так. SI заменяет первый байт начала функции на команду отладочного прерывания INT3 (0ССh) и при срабатывании прерывания вставляет обратно извлеченный ранее байт. Обнаружить это достаточно просто - нужно прочитать первый байт пролога функции и если он равен 0CCh, значит вызов функции отслеживается отладчиком.
Данный способ контроля обходится путем установки точек прерываний на недоступные из пользовательского уровня функции уровня ядра. Например, для CreateFile это будет NtCreateFile (или, как вариант, IoCreateFile).

я проверял на MessageBoxA
гдето на форуме была тема уже там я файлик выкладывал он при наличии бряка на месадж бокс выдавал аларм )
и там именно джамп был
хотя инт3 логичней

Цитата(oleg1973 @ 3.8.2005, 14:43)

там я файлик выкладывал

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

А каким образом данный выше код можно адаптировать под другие взломщики?

Это делается элементарно


Защита - это задача не для прикладника


В сайсе можно и dr-регистры юзать 

А что, если попробовать отловить отсутствие ошибки при вызове INT3?
Или воспользваться kernel32.IsDebuggerPresent 

Обычно сайсу запрещают ставить int3, а ещё можно запретить его обрабатывать. Вобщем, здравый смысл есть, сработает примерно в 15% случаев 


Дохлый номер