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