![DWH-Форум по обмену приватной информацией [VPN+]](https://dwh.su/styles/prisma/prisma/logotip_2.png)
LeSora
Как известно, не существует защиты, которую нельзя было бы сломать. Любое программное обеспечение рано или поздно подвергается взлому. Затем во Всемирной сети появляются левые серийные ключи, специальные патчи, а порой и просто модифицированные файлы, с помощью которых можно заставить программу работать, не приобретая ее у разработчика. Наверное, всего наберется не больше сотни программ, которые никогда не были взломаны, и то только потому, что являются узкоспециализированными и надежно защищенными, причем от взлома их спасает именно узкая специализация, а отнюдь не надежная защита.
Прежде всего рассмотрим понятие «крэк» (крак, кряк), представляющее собой кальку с английского слова crack, которое имеет множество значений, но ближе всего к теме нашей статьи значения «решать трудную задачу» и «раскалываться, давать трещину, ломаться». Впоследствии в Интернете так стали называть программы для взлома защиты, а крэкингом — сам процесс взлома.
Дзен-крэкинг
Существуют различные варианты взлома, и в зависимости от ситуации крэкер пользуется тем или иным подходом. В целом существуют два способа взлома. Большинство прибегает к так называемому дзен-крэкингу, в основе которого лежит принцип: «я не знаю, как это работает, но я могу это сломать». Другой же метод заключается в детальном изучении программы и ее функционала.
Кроме того, необходимо знание команд ассемблера, способов передачи параметров в процедуры и функции, системных вызовов ОС, различных компиляторов и т.п. Без этого изучать крэкинг - бесполезно. Поскольку для взлома не всегда необходимо все об этой программе, во многих случаях можно обойтись приблизительным пониманием и анализом встроенной защиты. Первый метод позволяет намного быстрее получить готовый результат. Второй же требует усилий и времени. Безусловно, когда происходит взлом по второму методу, количество ошибок, а также багов при работе с программой будет значительно меньше. Первый метод — наиболее распространен среди крэкеров. В этом случае крэкер сначала строит предположения о том как это может быть реализовано. Как ни странно, при использовании этого метода успех зависит не только от знаний, но и от того, насколько богато у крэкера воображение. Поэтому в данном случае эффективность дзен-крэкинга зависит прежде всего от наблюдательности и смелости предположений.
Необходимо собрать как можно больше информации о программе. Необходимо выяснить, упакована она или нет, какие ограничения содержатся в незарегистрированной программе и как выглядит процесс регистрации. Кроме того, следует проанализировать, какие текстовые строки и ресурсы содержатся внутри программы; поинтересоваться, к каким файлам и ключам реестра программа обращается при запуске, и многое другое. Как это ни странно, полезно заглянуть в справочную систему программы — там можно найти описание различий между зарегистрированной и незарегистрированной версиями. Вполне возможно, будет не особо полезна, однако быть во всеоружии всегда лучше.
Представим, что есть программа, которая выполняет некое действие. К примеру, она отказывается запускаться по истечении 15 дней с момента ее первого запуска. При этом появляется окошко с предупреждением — это и есть первое наблюдение. Если при переводе системной даты назад программа все равно не запускается, вывод: программа каким-то образом проверяет текущую дату, но при этом не основывается на показаниях часов операционной системы. Можно предположить, что программа либо сделала пометку о том, что запуск больше невозможен, либо все-таки определяет время другим способом. Здесь есть два пути: подумать какие варианты определения времени можно использовать, или искать в системном реестре либо в исполняемых файлах ссылку на запрет запуска. Однако сначала необходимо понаблюдать за производимыми программой действиями, которые являются признаками защиты. Если программа не просто «задумывается» при запуске, но еще и шуршит винчестером, вероятность того, что она проверяет файлы на дату/время создания — увеличивается. В противном случае необходимо разбирать, какие условные переходы, связанные с этим окном происходят, и к каким функциям в это время происходит обращение.
Любые встроенные защиты имеют уязвимости. Их уязвимость может быть спрятана глубоко в недрах кода, распределена по нескольким десяткам процедур или же совершенно неочевидна — однако она есть. Залог успешного взлома — в отыскании уязвимых мест в защите.
Наиболее подходящими для крэкеров дырами являются глобальные переменные, в которых хранятся сведения о состоянии программы. функции, возвращающие критичное для защиты значение и процедуры, выводящие сообщение об успешной или неуспешной попытке регистрации, а также об истечении триального срока программы. В некоторых случаях изменение 0 на 1 делает программу зарегистрированной и полностью работоспособной, что и является главной задачей крэкера. Поэтому поиск констант и их изменение — наиболее оптимальное решение.
Другая уязвимость, которая сильно облегчает жизнь крэкерам, — это проблема условного перехода, заключающаяся в том, что реализовать проверку какого-либо условия, не использовав напрямую команду условного перехода, не так-то просто. Чем же отличаются команды условных переходов? А тем, что любой такой переход очень легко превратить в такой же, но с противоположным условием — обычно для этого достаточно исправить всего один бит. Несмотря на техническую простоту, правка условных переходов все-таки менее предпочтительна, чем модификация функций. Это объясняется тем, что условных переходов, имеющих отношение к защите, в программе может быть довольно много и их поиск требует особой внимательности.
Однако при правке условных переходов возникают проблемы, поскольку не всегда следует доверять тому, что происходит в программе после изменения данных. Первой ошибкой является неверная интерпретация собранной информации. Защитные функции могут находиться перед самым носом у крэкера. Изменение условного перехода тоже не всегда приводит к желаемому результату — во многих случаях программа продолжает вести себя как незарегистрированная из-за нескольких слоев защиты. При этом эффект может быть совершенно противоположный: изменение условного перехода приводит к регистрации программы, но окна регистрации все еще вылазят.
Описанные выше приемы взлома применяются в большинстве случаев, однако в некоторых ситуациях защита встроена в установщик, которым инсталлируется программа. В нем, кроме файлов, которые требуется установить содержится сценарий инсталляции. Поскольку написание собственного инсталлятора — дело трудоемкое, для большинства небольших программ используется один из готовых продуктов. Инсталляционный скрипт описывает, в каком режиме устанавливается тот или иной файл, какие данные необходимо внести в реестр и многое другое. В это «многое другое» могут входить и проверка серийных номеров, создание записей в реестре, а также распаковка и запуск программ. Поэтому защиту от запуска незарегистрированной со сроком действия версии следует искать именно в инсталляционном файле. При этом реализация защиты может быть совершенно различной — от простых меток в реестре до создания точки отсчета времени от системной библиотеки самой операционной системы. В качестве метки, по которой программа будет проверять ограничения по времени, может использоваться какой-либо файл, создаваемый в процессе инсталляции, особенно если этот файл спрятан где-нибудь глубоко в системных директориях. Самый надежный способ нахождения подобных функций защиты — декомпиляция инсталляционного файла и последующий разбор его по байту. В случае, если инсталляционная программа произведена сторонним разработчиком, можно написать универсальный патч для обхода защиты всех программ, которые используют эту версию инсталляционного пакета. В этом случае, не углубляясь в код инсталляционного файла, можно обнаружить запросы к файлам, а также создание ключей в реестре. Подобные утилиты мониторинга за ОС позволяют делать слепки системы на разных этапах ее инсталляции, а путем сравнивания исходных значений с полученными можно выяснить результат действия инсталляционного пакета.
Иногда инсталлятор может содержать сериальные ключи если при установке необходимо ввести ключ. С помощью нехитрых манипуляций с инсталляционным файлом можно получить список или хотя бы хэш-функцию, защиты серийного ключа. Существуют три основных метода проверки серийного ключа: сравнение с эталонными значениями, проверка серийного ключа по его хэшу и сверка хэшей серийных ключей. Но, поскольку в инсталлятор может быть включено несколько номеров, это упростит задачу.
Вспомогательные программы
Инструменты — это одно из главных орудий крэкера, без них он как без рук. Но сами по себе такие инструменты не более чем программа, главное — уметь их использовать. Будет ли полезен лучший в мире отладчик, если человек не знает, что означают те цифры и буквы, которые появляются на его экране? Поэтому, прежде чем задать программе вопрос, необходимо быть уверенным, что вы сможете понять ответ. Тем не менее от качества инструментов во многом зависит скорость и эффективность действий крэкера. Инструментарий должен регулярно обновляться, поскольку программы тоже постоянно совершенствуются, наращивают мощность, обрастают новыми полезными и бесполезными функциями, к тому же их защита и реализация тоже постоянно улучшаются. Инструментов для крэкинга существует великое множество, главное — отбирать из них самые эффективные, быстрые и удобные. Некоторые крэкеры возражают против использования готовых решений, поскольку это чрезмерно упрощает процесс взлома и «некрасиво». Но, поскольку в крэкинге необходим конечный результат, а не красота, большинство пользуется всеми подручными средствами, дописывая уже готовые программы для собственных нужд.
Существует несколько типов программ, активно применяемых для взлома защиты программы:
Отладчики и дизассемблеры
Данные инструменты традиционно используются в паре, поскольку дизассемблер выдает лишь «чистый код», хотя современные дизассемблеры способны также распознавать вызовы стандартных функций, выделять локальные переменные в процедурах и предоставлять прочие подобные услуги. Пользуясь дизассемблером, можно лишь догадываться, какие данные получает та или иная функция в качестве параметров и что они означают. Чтобы выяснить это, чаще всего требуется изучение если не всей программы, то довольно значительной ее части.
Отладчики выполняют принципиально иные функции: они позволяют анализировать код в процессе его работы, отслеживать и изменять состояние регистров и стека, править код на лету — в общем, наблюдать за «личной жизнью» программы и даже активно в нее вмешиваться. Оборотной стороной медали является «неинтеллектуальность» многих отладчиков — их врожденные способности к анализу кода редко простираются дальше определения направления перехода.
Шестнадцатеричные редакторы и редакторы ресурсов
Это, несомненно, наиболее древние (по идее, но необязательно по исполнению) из программистских инструментов, ведущие свою историю с тех времен, когда программисты еще умели читать и править исполняемый код, не прибегая к помощи дизассемблеров. Редакторы ресурсов, в принципе, занимаются тем же самым, но по отношению к прилинкованным к исполняемому файлу ресурсам. Именно при помощи редакторов ресурсов выполняется значительная часть работ по «независимой» русификации программ и доработке интерфейсов. Наряду с редакторами используются всевозможные патчеры, которые позволяют создать небольшой исполняемый файл, автоматически вносящий изменения в оригинальный файл программы либо в код этой программы непосредственно в памяти.
Прочие утилиты
Существует также огромное количество утилит, не вписывающихся в рассмотренные выше категории или попадающих в несколько категорий сразу. Поскольку крэкинг — занятие весьма многогранное, столь же многогранны используемые для него инструменты. Более того, некоторые утилиты, которые могут быть полезны для крэкера, создавались для совершенно иных целей (хорошим примером может служить программа GameWizard32, которая, вообще-то, предназначена для того, чтобы мухлевать в компьютерных играх, но оказалась полезной при вскрытии программы с ограничением на максимальное число вводимых записей). Как невозможно объять необъятное, так и нельзя описать все программы, которые применяются для крэкинга.
Заключение
Напоследок отметим, что крэкеры делятся на три группы: на тех, для кого крэкинг — хобби, на тех, кто занимается этим в качестве самообразования, и на тех, кто зарабатывает на взломе защиты программ. Поскольку в России пиратство распространено широко, во многих случаях крэкинг обеспечивает неплохой доход.
Однако крэкинг — это палка о двух концах: хотя само по себе это действие незаконно, оно способствует развитию систем защиты, которые совершенствуются изо дня в день, а если изучать методы крэкинга и опробовать их на практике, то можно получить хороший опыт в написании систем защиты программ. Создать же абсолютную защиту невозможно — любая программа рано или поздно будет взломана.
Прежде всего рассмотрим понятие «крэк» (крак, кряк), представляющее собой кальку с английского слова crack, которое имеет множество значений, но ближе всего к теме нашей статьи значения «решать трудную задачу» и «раскалываться, давать трещину, ломаться». Впоследствии в Интернете так стали называть программы для взлома защиты, а крэкингом — сам процесс взлома.
Дзен-крэкинг
Существуют различные варианты взлома, и в зависимости от ситуации крэкер пользуется тем или иным подходом. В целом существуют два способа взлома. Большинство прибегает к так называемому дзен-крэкингу, в основе которого лежит принцип: «я не знаю, как это работает, но я могу это сломать». Другой же метод заключается в детальном изучении программы и ее функционала.
Кроме того, необходимо знание команд ассемблера, способов передачи параметров в процедуры и функции, системных вызовов ОС, различных компиляторов и т.п. Без этого изучать крэкинг - бесполезно. Поскольку для взлома не всегда необходимо все об этой программе, во многих случаях можно обойтись приблизительным пониманием и анализом встроенной защиты. Первый метод позволяет намного быстрее получить готовый результат. Второй же требует усилий и времени. Безусловно, когда происходит взлом по второму методу, количество ошибок, а также багов при работе с программой будет значительно меньше. Первый метод — наиболее распространен среди крэкеров. В этом случае крэкер сначала строит предположения о том как это может быть реализовано. Как ни странно, при использовании этого метода успех зависит не только от знаний, но и от того, насколько богато у крэкера воображение. Поэтому в данном случае эффективность дзен-крэкинга зависит прежде всего от наблюдательности и смелости предположений.
Необходимо собрать как можно больше информации о программе. Необходимо выяснить, упакована она или нет, какие ограничения содержатся в незарегистрированной программе и как выглядит процесс регистрации. Кроме того, следует проанализировать, какие текстовые строки и ресурсы содержатся внутри программы; поинтересоваться, к каким файлам и ключам реестра программа обращается при запуске, и многое другое. Как это ни странно, полезно заглянуть в справочную систему программы — там можно найти описание различий между зарегистрированной и незарегистрированной версиями. Вполне возможно, будет не особо полезна, однако быть во всеоружии всегда лучше.
Представим, что есть программа, которая выполняет некое действие. К примеру, она отказывается запускаться по истечении 15 дней с момента ее первого запуска. При этом появляется окошко с предупреждением — это и есть первое наблюдение. Если при переводе системной даты назад программа все равно не запускается, вывод: программа каким-то образом проверяет текущую дату, но при этом не основывается на показаниях часов операционной системы. Можно предположить, что программа либо сделала пометку о том, что запуск больше невозможен, либо все-таки определяет время другим способом. Здесь есть два пути: подумать какие варианты определения времени можно использовать, или искать в системном реестре либо в исполняемых файлах ссылку на запрет запуска. Однако сначала необходимо понаблюдать за производимыми программой действиями, которые являются признаками защиты. Если программа не просто «задумывается» при запуске, но еще и шуршит винчестером, вероятность того, что она проверяет файлы на дату/время создания — увеличивается. В противном случае необходимо разбирать, какие условные переходы, связанные с этим окном происходят, и к каким функциям в это время происходит обращение.
Любые встроенные защиты имеют уязвимости. Их уязвимость может быть спрятана глубоко в недрах кода, распределена по нескольким десяткам процедур или же совершенно неочевидна — однако она есть. Залог успешного взлома — в отыскании уязвимых мест в защите.
Наиболее подходящими для крэкеров дырами являются глобальные переменные, в которых хранятся сведения о состоянии программы. функции, возвращающие критичное для защиты значение и процедуры, выводящие сообщение об успешной или неуспешной попытке регистрации, а также об истечении триального срока программы. В некоторых случаях изменение 0 на 1 делает программу зарегистрированной и полностью работоспособной, что и является главной задачей крэкера. Поэтому поиск констант и их изменение — наиболее оптимальное решение.
Другая уязвимость, которая сильно облегчает жизнь крэкерам, — это проблема условного перехода, заключающаяся в том, что реализовать проверку какого-либо условия, не использовав напрямую команду условного перехода, не так-то просто. Чем же отличаются команды условных переходов? А тем, что любой такой переход очень легко превратить в такой же, но с противоположным условием — обычно для этого достаточно исправить всего один бит. Несмотря на техническую простоту, правка условных переходов все-таки менее предпочтительна, чем модификация функций. Это объясняется тем, что условных переходов, имеющих отношение к защите, в программе может быть довольно много и их поиск требует особой внимательности.
Однако при правке условных переходов возникают проблемы, поскольку не всегда следует доверять тому, что происходит в программе после изменения данных. Первой ошибкой является неверная интерпретация собранной информации. Защитные функции могут находиться перед самым носом у крэкера. Изменение условного перехода тоже не всегда приводит к желаемому результату — во многих случаях программа продолжает вести себя как незарегистрированная из-за нескольких слоев защиты. При этом эффект может быть совершенно противоположный: изменение условного перехода приводит к регистрации программы, но окна регистрации все еще вылазят.
Описанные выше приемы взлома применяются в большинстве случаев, однако в некоторых ситуациях защита встроена в установщик, которым инсталлируется программа. В нем, кроме файлов, которые требуется установить содержится сценарий инсталляции. Поскольку написание собственного инсталлятора — дело трудоемкое, для большинства небольших программ используется один из готовых продуктов. Инсталляционный скрипт описывает, в каком режиме устанавливается тот или иной файл, какие данные необходимо внести в реестр и многое другое. В это «многое другое» могут входить и проверка серийных номеров, создание записей в реестре, а также распаковка и запуск программ. Поэтому защиту от запуска незарегистрированной со сроком действия версии следует искать именно в инсталляционном файле. При этом реализация защиты может быть совершенно различной — от простых меток в реестре до создания точки отсчета времени от системной библиотеки самой операционной системы. В качестве метки, по которой программа будет проверять ограничения по времени, может использоваться какой-либо файл, создаваемый в процессе инсталляции, особенно если этот файл спрятан где-нибудь глубоко в системных директориях. Самый надежный способ нахождения подобных функций защиты — декомпиляция инсталляционного файла и последующий разбор его по байту. В случае, если инсталляционная программа произведена сторонним разработчиком, можно написать универсальный патч для обхода защиты всех программ, которые используют эту версию инсталляционного пакета. В этом случае, не углубляясь в код инсталляционного файла, можно обнаружить запросы к файлам, а также создание ключей в реестре. Подобные утилиты мониторинга за ОС позволяют делать слепки системы на разных этапах ее инсталляции, а путем сравнивания исходных значений с полученными можно выяснить результат действия инсталляционного пакета.
Иногда инсталлятор может содержать сериальные ключи если при установке необходимо ввести ключ. С помощью нехитрых манипуляций с инсталляционным файлом можно получить список или хотя бы хэш-функцию, защиты серийного ключа. Существуют три основных метода проверки серийного ключа: сравнение с эталонными значениями, проверка серийного ключа по его хэшу и сверка хэшей серийных ключей. Но, поскольку в инсталлятор может быть включено несколько номеров, это упростит задачу.
Вспомогательные программы
Инструменты — это одно из главных орудий крэкера, без них он как без рук. Но сами по себе такие инструменты не более чем программа, главное — уметь их использовать. Будет ли полезен лучший в мире отладчик, если человек не знает, что означают те цифры и буквы, которые появляются на его экране? Поэтому, прежде чем задать программе вопрос, необходимо быть уверенным, что вы сможете понять ответ. Тем не менее от качества инструментов во многом зависит скорость и эффективность действий крэкера. Инструментарий должен регулярно обновляться, поскольку программы тоже постоянно совершенствуются, наращивают мощность, обрастают новыми полезными и бесполезными функциями, к тому же их защита и реализация тоже постоянно улучшаются. Инструментов для крэкинга существует великое множество, главное — отбирать из них самые эффективные, быстрые и удобные. Некоторые крэкеры возражают против использования готовых решений, поскольку это чрезмерно упрощает процесс взлома и «некрасиво». Но, поскольку в крэкинге необходим конечный результат, а не красота, большинство пользуется всеми подручными средствами, дописывая уже готовые программы для собственных нужд.
Существует несколько типов программ, активно применяемых для взлома защиты программы:
Отладчики и дизассемблеры
Данные инструменты традиционно используются в паре, поскольку дизассемблер выдает лишь «чистый код», хотя современные дизассемблеры способны также распознавать вызовы стандартных функций, выделять локальные переменные в процедурах и предоставлять прочие подобные услуги. Пользуясь дизассемблером, можно лишь догадываться, какие данные получает та или иная функция в качестве параметров и что они означают. Чтобы выяснить это, чаще всего требуется изучение если не всей программы, то довольно значительной ее части.
Отладчики выполняют принципиально иные функции: они позволяют анализировать код в процессе его работы, отслеживать и изменять состояние регистров и стека, править код на лету — в общем, наблюдать за «личной жизнью» программы и даже активно в нее вмешиваться. Оборотной стороной медали является «неинтеллектуальность» многих отладчиков — их врожденные способности к анализу кода редко простираются дальше определения направления перехода.
Шестнадцатеричные редакторы и редакторы ресурсов
Это, несомненно, наиболее древние (по идее, но необязательно по исполнению) из программистских инструментов, ведущие свою историю с тех времен, когда программисты еще умели читать и править исполняемый код, не прибегая к помощи дизассемблеров. Редакторы ресурсов, в принципе, занимаются тем же самым, но по отношению к прилинкованным к исполняемому файлу ресурсам. Именно при помощи редакторов ресурсов выполняется значительная часть работ по «независимой» русификации программ и доработке интерфейсов. Наряду с редакторами используются всевозможные патчеры, которые позволяют создать небольшой исполняемый файл, автоматически вносящий изменения в оригинальный файл программы либо в код этой программы непосредственно в памяти.
Прочие утилиты
Существует также огромное количество утилит, не вписывающихся в рассмотренные выше категории или попадающих в несколько категорий сразу. Поскольку крэкинг — занятие весьма многогранное, столь же многогранны используемые для него инструменты. Более того, некоторые утилиты, которые могут быть полезны для крэкера, создавались для совершенно иных целей (хорошим примером может служить программа GameWizard32, которая, вообще-то, предназначена для того, чтобы мухлевать в компьютерных играх, но оказалась полезной при вскрытии программы с ограничением на максимальное число вводимых записей). Как невозможно объять необъятное, так и нельзя описать все программы, которые применяются для крэкинга.
Заключение
Напоследок отметим, что крэкеры делятся на три группы: на тех, для кого крэкинг — хобби, на тех, кто занимается этим в качестве самообразования, и на тех, кто зарабатывает на взломе защиты программ. Поскольку в России пиратство распространено широко, во многих случаях крэкинг обеспечивает неплохой доход.
Однако крэкинг — это палка о двух концах: хотя само по себе это действие незаконно, оно способствует развитию систем защиты, которые совершенствуются изо дня в день, а если изучать методы крэкинга и опробовать их на практике, то можно получить хороший опыт в написании систем защиты программ. Создать же абсолютную защиту невозможно — любая программа рано или поздно будет взломана.