Теоретические основы крэкинга: Глава 13. Заключение — Архив WASM.RU

Не было начала - не было конца…
Е. Летов

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

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

Впрочем, иногда нужный крэк находится: крэкерские группы и просто собиратели серийников исправно снабжают общественность средствами нетрадиционной регистрации программ. И все-таки большинство крэкеров - одиночки, не ищущие громкой славы, и потому их релизы редко выходят за рамки круга личных знакомых. Но и у крэкеров жизнь - не сахар. Чем популярнее платформа - тем больше под нее программ, а чем больше программ - тем больше среди них программ защищенных. Да и сами защиты отнюдь не стоят на месте: если в конце 90-х годов упакованная программа под Win32 была редким гостем на "операционном столе", то сейчас сжатый EXE - скорее правило, чем исключение. Хорошо, если какая-нибудь добрая душа поделится с обществом распаковщиком, да этот распаковщик еще окажется работающим. А если не поделится или не окажется? Тогда одна дорога - дампить, править, восстанавливать или же сооружать launcher. И все же рано или поздно приходит понимание того, что как ни старайся, все программы не переломать. Так что если какую-то программу все еще не сломали, это отнюдь не повод превозносить сложность и надежность ее защиты. Возможно, просто эта программка не попалась на глаза умелому крэкеру. А может случиться и так, что программу эту сломали, причем не один раз, но исключительно для домашнего пользования. Но никто об этом не узнает.

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

Многообещающим направлением видится создание программ, позволяющих пользователю самостоятельно устранять проблемы, связанные с ограничениями в программах. Проще говоря, обходить всевозможные триальные механизмы, причем по возможности - в полностью автоматическом режиме. "Первыми ласточками" в этой области были многочисленные утилиты, менявшие системное время перед запуском программы и через некоторое время возвращавшие его обратно. По вполне понятным причинам такой подход не всегда приемлем, но до недавнего времени ничего другого не предлагалось. В теории одним из путей, позволяющих "двигать" время внутри одной программы, не затрагивая все остальные, является перехват функций Windows API, так или иначе возвращающих локальное или системное время, и модификация возвращаемых значений, возвращаемых этими функциями. Однако путь от теории к практике оказался неблизким: долгое время эта идея не получала практической реализации, по крайней мере, готовые программные продукты, пригодные для использования рядовым пользователем, автору не встречались. И лишь сравнительно недавно появилась программа Hall of the Mountain King, которая позволяет не только менять значение "внутренних часов" для любого процесса, но и "закольцовывать" течение времени внутри программ.

Весьма многообещающе выглядят и инструменты, которые позволяют скрывать и защищать те или иные ключи реестра от доступа из определенных процессов, используя технику перехвата вызовов WinAPI. В настоящее время автору не известны программы такого рода, которые могли бы использоваться для борьбы с триальными ограничениями, но сама по себе эта идея выглядит заманчиво: запретив, к примеру, чтение из ключей HKEY_LOCAL_MACHINE\Software\Classes\CLSID и HKEY_CURRENT_USER\Software\ASProtect для программ, защищенных ASProtect, можно добиться того, что защита "не увидит" собственные триальные метки и будет считать каждый запуск первым.

Если довести идею "учета и контроля", на которой основаны две описанных выше технологии, до логического завершения, мы в итоге придем к мысли о создании "firewall'а для системных вызовов", то есть программы, надзирающей за обращениями к функциям WinAPI, ведущей журнал этих вызовов и блокирующей либо корректирующей "неправильные" обращения к системе. Максимальную гибкость такого инструмента можно было бы обеспечить встраиванием быстрого скрипт-интерпретатора, при помощи которого пользователь мог бы программировать логику работы с системными вызовами. Возможности, предоставляемые такой программой, совмещающей в себе возможности API-шпиона и DLL-враппера, было бы трудно переоценить. К примеру, вместо того, чтобы долго выламывать nag screen из строптивой программы (почти наверняка столкнувшись при этом с необходимостью ее распаковки), можно было бы просто запустить программу в режиме снятия лога системных вызовов, чтобы понять, каким образом формируется и отображается nag screen. После чего, основываясь на полученной информации, выяснить в какой точке программы производится вывод nag screen'а и написать скрипт, который бы отказывал этому вызову в праве на создание окна, но при этом "пропускал" все остальные. Подобным же образом можно было бы неограниченно продлять триальные сроки, "доработав" функции работы с реестром так, чтобы в действительности запись в некоторые ключи реестра не производилась, но при этом подопытная программа пребывала в полной уверенности, что триальные метки успешно расставлены. Нужно отметить, что такая программа будет уже не орудием исключительно крэкинга, но инструментом двойного назначения, который может быть использован для обнаружения утечек ресурсов или как средство автоматизации.

Другой подход к решению проблемы триалов, окончательно оформившийся сравнительно недавно, заключается в автоматизации поиска и удаления "меток", по которым программы определяют количество запусков или промежуток времени, оставшийся до истечения срока пробного использования. О технологиях выявления таких меток мы уже говорили в третьей главе, однако там делался упор на "ручную работу" по поиску лишних ключей в реестре и аккуратное с ними обращение, чего весьма трудно добиться при работе с большим количеством защищенных программ. Такой подход неприемлем для рядового пользователя, которого совсем не прельщает необходимость перед каждым запуском делать снимки реестра и потом долго их сравнивать, размышляя о том, за какое из изменений в реестре ответственна защита. Современный стиль жизни таков, что любая проблема должна решаться "в два клика", без многочасовых медитаций над снимками реестра и отчетами RegMon'а. Но есть ли пути к достижению этого идеала? Разумеется, есть! Широкое распространение навесных защит, реализующих триальные ограничения, привело к тому, что способы нанесения триальных меток тоже "унифицировались". Каждый тип навесных защит имеет свои собственные "предпочтения" в том, где эти метки создавать и каким образом их генерировать. Следовательно, если собрать достаточно большую коллекцию программ, защищенных одним и тем же инструментом, и как следует погонять их во всех возможных режимах, можно собрать некоторую статистику. К примеру, ASProtect традиционно мусорит в ветке реестра HKEY_LOCAL_MACHINE\Software\Classes\CLSID, причем старые версии этой защиты создавали ключи с одним-единственным текстовым значением длиной 4, 8 или 16 байт; главная надежда разработчика, видимо, заключалась в том, что огромное количество ключей в этой ветке помешает найти среди них "лишние". Как показала практика, это мнение было глубоко ошибочным и более новые версии этой же защиты пытаются имитировать полезные ключи гораздо более тщательно, что, впрочем, тоже не слишком хорошо помогает, потому что исследователи защит тоже не сидят сложа руки.

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

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

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

Однако "пользовательским" уровнем грядущие возможности отнюдь не исчерпываются. Уже сейчас можно видеть, как возвращаются в новом обличье старые, но до времени не актуальные идеи. Около десяти лет назад была весьма популярна концепция эмулирующих отладчиков, которые практически полностью имитировали работу центрального процессора (исключение делалось разве что для команд вызова прерываний) и позволяли исполнить программу так, как она исполнялась бы на настоящем процессоре, но при этом иметь абсолютный контроль над состоянием отлаживаемой программы. Следы работы такого отладчика было практически невозможно обнаружить, не прибегая к ухищрениям; многие приемы, направленные на нарушение стабильности отладчика, также оставались не у дел. Однако с наступлением эры многозадачных ОС этот род отладчиков как-то тихо канул в Лету. Долгие годы эмуляция была не в почете, однако некоторые признаки указывают на то, что в ближайшем будущем возможен ренессанс эмулирующих отладчиков. Эмуляция длинных кусков кода, не содержащего обращений к WinAPI, освоена довольно давно: одних только плагинов для Interactive Disassembler, позволяющих имитировать исполнение кода, насчитывается уже несколько штук. Главная проблема, ожидающая своего решения - организация взаимодействия между эмулятором и вызовами "неудобных" функций системного API внутри эмулируемой программы (попробуйте поразмыслить над тем, как можно эффективно проэмулировать обращение к функции, порождающей новый поток или вызывающей callback-функцию, чтобы представить уровень сложности задачи).

Другой приметой времени следует признать все более и более широкое распространение виртуальных машин, более или менее точно воспроизводящих поведение настоящих, "железных" ЭВМ. Из программных продуктов этого рода, эмулирующих платформу x86, наибольшей популярностью пользуются Virtual PC и VMWare, причем VMWare существует не только в Windows-, но и в Linux-версии, что позволяет крэкеру не ограничивать себя в выборе основной операционной системы. Думаю, что многие уже оценили удобства, предоставляемые этим инструментом: отладку внутри гостевой ОС параллельно с работой в хост-системе, возможность в любой момент восстановить систему вместе со всеми необходимыми инструментами, защищенность хост-системы от действий деструктивного кода (некоторые разработчики все еще встраивают в свое ПО такие закладки, не считаясь с возможными последствиями) и другие полезные мелочи вроде возможности снятия скриншотов окна SoftIce. Однако потенциально виртуальные машины способны дать крэкеру гораздо больше, чем предлагают существующие инструменты. В первую очередь я имею в виду возможность интеграции отладчика с виртуальным процессором. Разработчикам SoftIce пришлось немало потрудиться, чтобы создать почти полностью "прозрачный" для системы отладчик, но даже этот замечательный инструмент имеет немало ограничений. Одни из них накладываются самим устройством процессора (например, невозможность установки более четырех аппаратных точек останова), другие заключаются отсутствии поддержки того или иного "железа", третьи кроются в недрах программного кода отладчика (проявляющаяся иногда нестабильность в работе, "дыры", позволяющие обнаружить присутствие SoftIce, невозможность просматривать тексты в национальных кодировках и т.п.). Корнем всех этих бед является то, что отладчик работает на той же самой программно-аппаратной системе, что и отлаживаемая программа. Вот если бы каким-то образом удалось вынести отладчик за пределы компьютера... Если подойти к решению этой проблемы "в лоб", мы придем к идее аппаратной приставки, берущей под контроль все процессы, протекающие внутри системного блока. И такой подход действительно иногда используется, но не для взлома, а для тестирования всевозможного встраиваемого ПО - от новых версий BIOS до управляющих программ бортовых ЭВМ космических спутников. Гонять такие "железки" (надо отметить, в настоящее время весьма не дешевые) исключительно в целях крэкинга - это, пожалуй, явный перебор. Но вот если реализовать такой комплекс исключительно программно, да подключить его к виртуальному же процессору не менее виртуального PC, то можно будет получать любую информацию о состоянии нашей эмулированной машины. Это было бы очень изящное и практичное решение: Вас не волновали бы ограничения на число отладочных регистров, не нужно было бы думать о том, поддерживается ли Ваша видеокарта отладчиком, а сам отладчик смог бы предоставить такие сервисные возможности, какие невозможны в SoftIce, "завязанном" на работу исключительно в текстовых режимах. Аналогичный же вариант можно было бы проделать и с прочим оборудованием, например, предоставив API для создания собственных программных модулей, эмулирующих внутренние и внешние устройства. Разумеется, это породило бы виток соревнования "брони и снаряда", и к бесчисленным антикрэкерским пособиям "как определить наличие отладчика" добавились бы изыскания о проверке обрудования, с которым работает программа, на виртуальность (а защиты с такими механизмами уже существуют, правда, направлены они в основном против эмуляторов CD-ROM), но тут уж ничего не поделаешь - таковы законы жанра. Собственно, отладчики, интегрированные с виртуальными машинами, не являются чем-то ранее невиданным: наиболее продвинутые эмуляторы машин линейки Spectrum, БК и Atari позволяют не только запускать программы, но и отлаживать их "по живому" со всеми удобствами. Возможно, в эпоху 128-разрядных ЭВМ эмуляторы PC обретут такие же возможности, но современному ПО в этой области пока похвалиться нечем.

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

И, наконец, последние направление, обещающее огромные возможности, связано с появлением open-source ОС, совместимой с Windows. Если Вы уже пытались применить свои знания на практике, Вы не могли не заметить ограниченность либо нестабильность многих крэкерских инструментов. Зависания отладчиков, вызовы API, которые в упор не замечают API-шпионы, невозможность нормально снять дамп памяти - такова объективная реальность, с которой приходится сражаться крэкеру. Все это можно было бы списать на ограниченность и недостаточное качество используемого программного обеспечения, тем более, что авторы многих из этих программ изначально не ориентировались на потребности крэкеров и потому было бы странно требовать от них возможностей, которые не были заявлены в проекте. Однако если рассматривать вопрос с точки зрения архитектора, нам откроется, что "корень зла" лежит не в несовершенстве программ (хотя наличие такового несовершенства нельзя отрицать), но в способах, при помощи которых эти программы взаимодействуют с ОС. А взаимодействие это нередко осуществляется "с черного хода", при помощи приемов, работоспособность которых держится на многочисленных "авось". И в этом нет ничего удивительного: при разработке ОС штатные механизмы перехвата системных вызовов не были запроектированы в принципе, поэтому единственным методом удовлетворения возникших потребностей оказался метод "грязного хака" (который, впрочем, впоследствии был санкционирован самим производителем ОС). Образно говоря, система "ОС+отладчик" или "ОС+API-шпион" с высоты птичьего полета выглядит не как готический замок, в котором каждая башенка является частью единого целого, а как глинобитный сарай, прилепленный к стене суперсовременного небоскреба. Неудивительно, что прочность такой конструкции - совершенно никакая, и рушится она чаще всего именно в месте, где "небоскреб" соединяется с "сараем". Наиболее естественным выходом из сложившейся ситуации была бы интеграция средств наблюдения за взаимодействием между пользовательскими программами и операционной системой непосредственно в ядро ОС, но по вполне понятным причинам корпорация Microsoft на такой шаг не пойдет. Однако в последнее время появилось несколько весьма интересных проектов с доступными исходными текстами - от эмуляторов Windows (Wine/WineX/Cedega) до разработки полноценной "другой Windows" (проект ReactOS). Наличие исходных текстов позволяет встраивать непосредственно в ядро ОС практически любые механизмы слежения за пользовательскими программами и самой ОС, а также API для управления этими механизмами. Причем такие "усовершенствования" ОС совершенно необязательно внедрять в код жестко, их можно оформить как патчи, накладываемые на исходные тексты ядра и применяемые при необходимости. Возможности же, предоставляемые отладчиком или API-шпионом, интегрированным в ядро операционной системы, трудно переоценить.

Однако изменятся не только орудия крэкерского труда - изменится и сам крэкинг, и, изучая предмет, этот факт не стоит сбрасывать со счетов. Уже сейчас очевидны две тенденции: с одной стороны, продвижение наиболее простых крэкерских технологий в массы (о чем я говорил выше), и с другой стороны - нарастание специализации, сначала - в областях знаний, а затем - и во взломе конкретных продуктов. Десять-пятнадцать лет назад крэкер вынужден был становиться "мастером на все руки" и не только уметь разбираться в кодах чужих программ, но и обеспечивать себя необходимыми инструментами для этой деятельности - Интернета в современном его виде, откуда всегда можно выкачать свежий отладчик или распаковщик, тогда просто не существовало. Разумеется, такая ситуация сложилась не от хорошей жизни - в отсутствие Интернета свободный обмен информацией и, тем более, инструментами был крайне затруднителен - всевозможные BBS и "флоппинеты" мало чем способны были помочь, да и существовали далеко не везде. Разработчикам защит, впрочем, было не легче: "навесные" защиты не то, чтобы совсем отсутствовали, но были не слишком популярны, и в итоге каждая защищенная программа была единственной в своем роде, но с другой стороны набор защитных приемов был куда более ограничен по причине простоты процессоров и операционных систем того времени. Нынешняя ситуация отличается в корне: с одной стороны, количество программ выросло на порядки но с другой - сами авторы ПО обычно идут одним из двух проторенных путей: либо читают всевозможные руководства "как защитить программу" и затем более или менее успешно воспроизводят книжные схемы, либо покупают готовый продукт и "в два клика" прикручивают защиту, нимало не интересуясь, что они прилепили к своему коду. Следствием такой защитной стратегии стало то, что знание о том, как ломается та или иная типовая защита, является ключом не к единственной программе, но к множеству. Итогом всего этого становится ярко выраженная ориентация на изучение именно типовых, популярных защит (потому как это - способ минимальными силами "разобраться" с максимумом программ и ломать их конвейерным методом), а это есть ни что иное, как специализация. Впрочем, какой бы путь Вы для себя не выбрали, существуют области, в которых необходимо разбираться каждому, кто так или иначе собирается уделить время крэкингу, и на изучение именно этих вещей и стоит делать упор в первую очередь. Не стоит совершенно игнорировать и малопонятную или неактуальную информацию: даже если сейчас Вы не можете применить эти знания, постарайтесь усвоить их хотя бы в общих чертах - возможно, в будущем именно эти "заметки на полях памяти" лягут в основу изящного подхода к какой-нибудь проблеме. Многие из старых пособий по крэкингу сейчас видятся пыльным антиквариатом, поскольку те программы, которые в них описаны, давно и бесповоротно канули в прошлое. Но первое впечатление обманчиво: хотя коды из этих статей устарели, иные решения, приведенные в этих статьях, вызывают восхищение и сейчас. Помните, что не стоит зацикливаться на одних лишь крэкерских материалах; очень часто бывает полезно взглянуть на проблемы защиты и взлома с "другой стороны баррикад". Так уж исторически сложилось, что авторы защит не слишком охотно предоставляют информацию о своих изделиях, однако даже беглое изучение содержимого соответствующих руководств и форумов даст Вам представление, чем дышит "вероятный противник", какие идеи сейчас популярны в среде разработчиков ПО и - если повезет - в чем заключаются огрехи и недоработки популярных защитных схем. Знание о новом защитном приеме, кроме всего прочего, представляет собой отличный повод поразмыслить о том, как соответствующий код может быть идентифицирован в реальной программе и нейтрализован. Я уже давал этот совет в одной из первых глав, но повторю его еще раз в завершении: во всяком источнике информации нужно искать не столько приемы, сколько идеи, а знакомство с оригинальными идеями в свою очередь стимулирует способность находить решения самостоятельно. И какой бы Вы ни избрали путь - скромного разработчика инструментов, кующего "оружие Победы" или "бойца невидимого фронта", раскалывающего особо прочные защиты, потрошителя двадцатидолларовых утилит или мирного исследователя недр операционной системы - не бойтесь отойти от канонов и проявить неоправданную оригинальность. В конце-концов, изящные решения - это те нити, из которых соткано будущее. И это будущее обещает быть интересным - так почему бы не добавить в него что-то от себя? © CyberManiac