Алгоритм действий при взломе ShareWare программы, защищённой паролем
1. Исследуем язык, на котором написана программа. Я обычно использую Restorator 2.50 [1024 Kb], либо Exescope’ом [409 Kb] можно посмотреть. Сразу же узнаём запакована программа или нет.
1.1 Тип языка я определяю по размеру файла и по ресурсам:
- Assembler — размер файла меньше 40 Kb (если не использует картинок), присутствует раздел Dialog в ресурсах. На ассемблере обычно пишут перцы, так что шанс взломать резко снижается (скорее будет патч, нежели подбор номера).
- Visual C++ — размер файла — разный, если меньше 40 Kb и файл импортирует функции из модуля MFC42.DLL или больше 40 + присутствуют ресурсы Dialog, тогда это С++, по моему опыту ломается лучше всего, так как структура программы более менее линейна (наглядна)+ запрашиваются WinAPI функции, на которые всегда можно поставить брейкпойнт.
- Delphi — определется легче всего — в ресурсах присутствует раздел «RCDATA» или «DATA» — кто как показывает, в котором обязательно есть ресурс PACKAGEINFO + почти всегда ресурс типа TFORM1 (или другой, но обязательно с буквы T). Ломаются такие программы не очень сложно, учитывая то, что множество программистов Delphi — любители (новички), однако сам код, откомпилированный в Дельфе очень не нагляден — бесконечные джампы и процедуры + не используютcя «наши» API функции (но зато железно работает hmemcpy)
- Visual Basic — что касается самого Бэсика, так я его не уважаю, потому что программы работают только при наличии VBRUNxxx.DLL или другой (в зависимости от версии) ботвы в системных папках (в PATH-папках) + код не скомпилирован по человечески (до версии 5) и можно ломать только декомпилятором. Начиная с версии 5 стал создаваться некоторый скомпилированный код (вообщем SoftIce’ом можно поломать). Отличить VB программу от других легко — открываем в Exescope и видим, что импортируется библиотека вида VB######.dll или MSVBVM##.dll.
1.2 Запакована или нет?
КАК ВЗЛОМАТЬ ПК ИГРУ НА ДЕНЬГИ ПРИ ПОМОЩИ ПРОГРАММЫ CHEAT ENGINE
Самый простой способ это проверить — открыть программу в Restorator’e и посмотреть все ресурсы, если вместо ресурсов высвечивается надпись «Ресурс повреждён» — значит файл пожат, а это в свою очередь означает, что путь патча нам уже закрыт.
Комментарий от 22 мая 2002 года: наконец-то до меня дошла (или я дошёл) версия компрессора UPX (1.20) [117 Kb], которая может разжимать сжатые любыми версиями UPX программы, теперь бы ещё распаковщик Aspack’а.
Комментарий от 17 августа 2002 года: Распаковшик AsPack тоже был найден, может быть скоро можно будет его здесь скачать (называется AspackDie у меня — v1.4).
Также нашёлся распаковщик PECompact (моего любимого) — называется UnPECompact 1.31 (написал тот же чувак, что и AspackDie).
2. Ищем в программе куда нужно вводить код (ну, я думаю сами найдёте).
3. Вводим код в соответствующее окно и, не нажимая Enter, вызываем SoftIce и ставим брейкпойнты bpx getdlgitemtexta, bpx windowtexta — для любой программы + bpx hmemcpy — для Delphi- программы, затем нажимаем на «ОК»-кнопку и мы должны попасть в SofIce по одному из этих брейкпойнтов.
Взлом Shareware программы в OllyDbg Lesson8 часть 1
4. Что же далее: вот мы в SoftIce’е, я обычно первый раз гоню программу по F10, смотрю и запоминаю, пока не вылезет окно сообщения о неправильном рег. номере (назовём его окно «обломис»). Вы скажете, ну и что же ты запоминаешь: а вот что — я плевать хотел на всякие Call и прочие умные вещи, я запоминаю долго ли я гоню по F10, а также все условные переходы (jz, jnz, jne, je . ). Когда вам вылезло окно «обломис», возвращаемся в SoftIce, смотрим вверх и ищем то место, где есть условный переход, который так или иначе может увести нас от вызова «обломиса», а теперь ищем процедуру, которая может изменить флаг, на который реагирует этот переход (для jz, jnz, jne, je — это флаг Z). Могу с уверенностью сказать, что если вы уже на этом месте и всё вышесказанное получается, то большая половина дела уже сделана (похоже программисты забыли поставить шлагбаум, хотя такой как я программист мог бы приколоться — поставить пустышку).
5. Теперь надо начать ковырять процедуру, да не очень усердно — вдруг пустышка. Да вот тут то я могу вам ничем не помочь все они сделаны по разному, ну признаюсь на этом этапе я обычно ставлю брейк на процедуру, выхожу и пробую ввести рег. данные заново, а потом, как тупой америкос, попав в SoftIce начинаю тупо смотреть содержимое регистров и вот что самое интересное в не более 50% случаев — помогает и я рано или поздно вижу правильный рег. номер в каком-нибудь регистре. Ну, я представляю что сейчас подумал обо мне профессионал, случайно забредший на эту страницу, что ж, лень, как известно, двигатель прогресса, а я ужасно ленивый, просто иногда даже злюсь на себя. Да, кстати, надо иметь чутьё на рег. номер — иногда они бывают вот такие: $ufs — и если до процедуры, на которую мы поставили брейк вы его не нашли, то поищите внутри неё.
Вообще надо действовать по ситуации, потому что не один крэкер не даст вам супер оптимальной и в то же время простой инструкции по взлому, а для того, чтобы заниматься крэком, нужно немногое — настойчивость, голова на плечах (знающая немного ассемблера), а также мания величия (ну этого, я заметил, почти у всех компьютерщиков хватает, даже у меня, иначе вы это сейчас бы не читали, а я бы не писал).
Программа и Интерфейс — Исследование программ
9 live by DuoMark SETUP
Источник: delphibaza.ru
Исследование защит shareware-программ
Множество программистов занимаются разработкой shareware (платных) программ и создают поистине замечательные продукты, но механизм регистрации пишут обычно на последнем этапе, и нередко — «на скорую руку». В этом кроется большая ошибка, которой могут воспользоваться исследователи защит программ, или попросту крэкеры, к коим отношусь и я. В этой статье будут рассмотрены типовые методы защиты программ и способы их «обхода», однако поскольку статья рассчитана на широкую аудиторию читателей, я не буду приводить программных кодов — тех, кому интересна эта область, отсылаю к специализированным сайтам.
Один из самых распространенных способов защиты программы — написание этой защиты собственными руками, и именно в таком способе проявляются крайности: защита либо очень надежна, либо, наоборот, очень слаба. Объясняется это, по-видимому, степенью образованности автора в данной области.
Приведу простой пример: вы написали компьютерную игру и ничего не знаете про крэкеров, дизассемблеры, отладчики… Вы создаете окошко, в котором написано «Введите имя пользователя», «Введите регистрационный код», затем, нажав «OK», складываете коды всех символов в регистрационном имени и сравниваете это число с введенным регистрационным кодом, а потом, в зависимости от результатов сравнения, выдаете пользователю окошко: либо «Спасибо за регистрацию!», либо «Неверный регистрационный код». Теперь расскажу, как легко снять эту защиту: понадобится отладчик (самый популярный — SoftIce).
Когда исследователь защиты вводит свое «имя пользователя» и произвольное число в качестве «регистрационного кода», он ставит в отладчике прерывание, которое остановит вашу программу при считывании данных из тех самых полей ввода. Отладчик покажет текст дизассемблированного кода программы в этом месте, далее программа пошагово исполняется под отладчиком, контролируемая крэкером. Рано или поздно, независимо от хитрости превращения имени пользователя в регистрационный код, крэкер увидит место, где сгенерированный программой правильный код будет сравниваться с введенным неправильным кодом. Теперь достаточно записать на бумажку правильный регистрационный код и ввести его в окошке регистрации. Весь описанный процесс занимает от 30 секунд до 10 минут.
Самый же надежный на сегодняшний день способ защиты — это шифрование правильным регистрационным кодом тех процедур, которые работают только в зарегистрированной версии программы. Такой способ защиты осуществить чрезвычайно тяжело, даже я не до конца знаю, как это сделать. Однако его слабость в том, что код (или его часть) будет одним и тем же для каждого пользователя, то есть при распространении такого кода на крэк-сайтах автор не будет знать, какой пользователь его распространил. Соответственно, он будет продолжать посылать коды для новых версий своей программы, в частности и этому пользователю. Совсем не обязательно даже покупать программу, для получения кода есть два других способа: один из них противозаконный — его я рассматривать не буду, потому что всегда действую в рамках закона, другой менее действенный, но законный — это социальная инженерия.
Социальная инженерия пришла в крэкерство из хакерства (в Рунете — во многом благодаря стараниям автора этой статьи), в хакерство же она пришла из жизни, где существовала с незапамятных времен. Как ни странно, многие и по сей день не знают, что это такое, поэтому специально для разработчиков и исследователей программ рассказываю.
Социальная инженерия — это некоторые действия над человеческим сознанием с целью получения желаемого результата, поэтому скорее речь идет не о том, как взломать программу, а о том, как «взломать» ее автора. Суть метода такова: надо уверить автора, что вам очень нужна зарегистрированная версия его программы, но у вас нет денег на ее приобретение. Таким образом можно получить коды к shareware-программам, не пользуясь ничем, кроме электронной почты. Разработчики программ должны знать о подобном способе «взлома», чтобы не допускать влияния «человеческого фактора» на надежность защиты (подробнее см. статью «Социальная инженерия в реверс-инженеринге» на сайте автора).
Второй способ защиты программы, ставший недавно весьма популярным, — использование специального протектора исполняемых файлов, то есть после компиляции своего творения автор берет программу-протектор и запаковывает ею собственную программу. Протекторы пишутся профессионалами в области защиты и обеспечивают неплохой уровень противодействия взлому, с которым большинству исследователей программ не справиться. Но поскольку некоторые из протекторов становятся очень популярными, их начинают исследовать все больше и больше не самых безграмотных крэкеров, которые впоследствии пишут программы-анпротекторы (распаковщики защиты). Подобные средства быстро и автоматически снимают защиту, хотя некоторые варианты приходится снимать вручную — это высший пилотаж крэкерства, доступный не каждому.
Третий способ — защита через Интернет. Если ваша программа работает с Сетью (это может быть менеджер закачки файлов, браузер, FTP-клиент и пр.), можно применить проверку введенного в программу кода через Интернет, используя базу данных пользователей на сайте программы. Однако проверять нужно какие-либо косвенные данные, чтобы исследователь не мог получить с сайта программы, например, базу данных с серийными номерами. Для того чтобы снять защиту, нужно найти, где в программе идет обращение к сайту и возвращается результат проверки, а затем подменить результат, например, с помощью пропатчивания программы в нужном месте. Сложность взлома этой защиты в том, что весьма непросто найти в коде программы место, где идет обращение к Интернет-серверу именно с целью проверки регистрационного кода.
Четвертый способ — аппаратные ключи. Этот метод защиты доступен только крупным разработчикам программного обеспечения, потому что приходится поставлять пользователю нечто материальное: диск с программой и сам ключ; кроме того, стоит такой метод недешево. Снятие этой защиты — задача достаточно сложная, но выполнимая. Уже существуют эмуляторы аппаратных ключей, однако из-за редкости применения указанного способа крэкеров, снимающих подобную защиту, мало — многие ею просто не занимаются.
Безусловно, я упомянул не все способы защиты программ, а лишь наиболее популярные.
В помощь российским разработчикам программного обеспечения, как профессионал-исследователь защит программ, могу дать несколько полезных советов.
На мой взгляд, в первых версиях своей shareware-программы не стоит серьезно заниматься механизмом защиты. Во-первых, можно переоценить практическую ценность программы — вдруг она так плоха, что ее никто не купит, и тогда смысл в защите пропадает. Во-вторых, зачем убивать на разработку защиты то время, которое можно с успехом потратить на раскрутку программы.
Допустим, ваш продукт стал пользоваться спросом, и вы получили первый гонорар. Теперь начинайте заходить на всевозможные крэк-сайты и ищите там крэк к своей программе. Пока вы его не найдете, не пытайтесь улучшить защиту — улучшайте саму программу, это принесет больше прибыли.
Как только вы найдете в Интернете крэк к своей программе, сразу подумайте о другой защите, именно другой — меняйте сам принцип. Если вы не умеете самостоятельно писать защиту и не имеете средств на оплату услуг профессионала, воспользуйтесь каким-нибудь коммерческим протектором программ. Разумеется, придется заплатить за его регистрацию порядка сотни долларов, но ведь ваша программа принесла уже больше… или нет?
Можно предложить еще один альтернативный способ: обратитесь к крэкеру, дабы он помог разработать алгоритм защиты. Конечно, это тоже не бесплатно, но наверняка меньше тех самых ста долларов, ведь большинство крэкеров — обычные студенты. Желательно знать такого человека лично, иначе при общении только через Сеть вас могут запросто обмануть.
Вполне возможно, что, прочитав эту статью, вы решите заняться исследованием защит программ или присоединиться к когорте крэкеров. Что для этого нужно? Как минимум неплохое знание программирования на любом высокоуровневом языке (Pascal, C и др.), базовое знание ассемблера (достаточно знать его функции), также полезно знать архитектуру какого-нибудь более или менее используемого процессора (очень хорош для понимания Intel 486), нужно найти отладчик SoftIce, ну и еще пару статей для крэкеров-новичков. На первых порах — не лениться, не пугаться, проявлять настойчивость и уверенно действовать, тогда вы рано или поздно станете замечательным крэкером, а может даже, и профессионалом по защите программ.
Источник: argon.pro