::: Cracking Part II: Crack WinZip SR-1 (1285) :::


Приветствую любители крякинга! Думаю после прочтения моей статьи об этом не лёгком ремесле вы поумнели (надеюсь не наоборот =). Теперь же я хочу показать вам, как ломается WinZip (1 пример я уже вам привел в прошлой статье)!
Итак мы имеем продукт WinZip 7.0 SR-1 (1285). Генерилка серийных номеров к нему прилагается, но нам она не нужна! Мы сами добьёмся от проги любви и согласия =). Итак...я установил её на диск, после чего решил запустить. Мне показали окошечко, где напомнили, что она не зарегистрированная и предложили зарегистрироваться. Я, как правильный пользователь, нажал на пимпу "Enter Registration Code...". Там ввёл от балды UserName и Password. После чего вывесилось ERROR'ное диологовое окошко с надписью: "Incomplete or incorrect information.". Я его запомнил и пошёл грузить URSoft W32Dasm Ver 8.93 Program Disassembler/Debugger, где задал проге искать эту строку. После 1 сек. прога нашла данную строку в районе 004080B7 (это адрес уже дезассемблированной программы, а вот смещение (Offset) 000074B7h - это реальный адрес откомпилированной программы). Я загрузил IDA375 (IDA - The Interactive Disassembler Pro) (очень удобный инструмент) и после чего пошёл по этому адресу: 004080B7, после чего я оказался в некой функции, которую я тут же переименовал (IDA это позволяет, что улучшает жизнь) для удобства в INCOMPLETE (после этого IDA сама метки всех переходов на данную функцию (loc_4080B2 - это наша метка до переименовывания..фиг запомнишь =) переименовывает на наше INCOMPLETE), чтоб было легче ориентироваться среди всяких переходов и т.д. =) Тааак...что это всё значит? А очень просто! Мы нашли строку, выводимую при неправильном заполнении формы...после чего запомнили адрес, откуда она вызывается и оказалось, что выводом данной строки занимается функция, которую мы и переименовали, как INCOMPLETE для удобства. Далее мы поднимаемся вверх на первый попавшийся адрес, который вызывает данную функцию...Как мы видим этих адресов там целых 3, т.е. есть 3 варианта неправильного заполнения формы..Первое, что я предлоположил - это то, что первые 2 обращения на INCOMPLETE зависят от длинны вводимых данных: UserName & Password. Т.е. сначала идёт проверка того, что мы ввели в поле UserName: длина введённого. Если она равна 0, то прыгаем на ошибку! Логично?! =) Тогда второе обращение к INCOMPLETE касается нулевой длины поля Password, а вот 3-е обращение уже из-за неправильно введённых нами данных. Вот кусок кода наших проверок:

00408044 call sub_4296C2 ;процедура проверки наших полей на заполненность
00408049 cmp byte_47D928, 0 ;сравнение поля UserName с 0
00408051 pop ecx
00408051 jz short INCOMPLETE ;если длина поля UserName = 0, то ошибка
00408053 cmp byte_47D958, 0 ;сравнение поля Password с 0
0040805A jz short INCOMPLETE ;если длина поля Password = 0, то ошибка
0040805C call sub_407B4B ;вот она..процедура проверки того, что мы ввели
00408061 test eax, eax ;сравнение результатов
00408063 jz short INCOMPLETE ;если ввели неправильно, то ошибка

Все действия программы видны выше =). С первыми 2-мя вызовами мы разобрались: с 00408051 и с 0040805A. Теперь нас интересует процедура проверки: 0040805C. Прыгаем туда. Там-то нам нужно немного помыслить, чтоб понять как ведёт себя программка =). И вот я мыслю..мыслю...и дохожу до следующей строчки:

00407C3B jnz short loc_407CA6

Почему я из всех строчек перехода, находящихся выше, выбрал именно эту? Логика, интуиция и знания ассемблера =). Если вы посмотрите на этот код как-нибудь сами, то думаю поймёте. Ну так вот..Эта вот строчка (а ниже 00407C3B такая строчка ещё раз встретится) вела нас к проигрышу:

..........
jmp short loc_407CA6
loc_407C9F:
and dword_47B07C, 0

loc_407CA6: ;мы прыгаем сюда при неправильном заполнении
push 12Ch
lea eax, [ebp+var_140]
..........

Хмм...несколько переходом на loc_407CA6. Вряд ли нам бы предлагали прыгать несколько раз на "правильную ветку" =))..следовательно - эти прыжки на "неправильную ветку", которая и влияет на исход регистрации...и всего лишь 1 переход (безусловный) на loc_407C9F, который находится в конце всех проверок. Это наводит на мысль, что это и есть ТО, ЧТО НАМ НАДО! Теперь мы знаем как ведёт себя программа..можно теперь занопить те переходы на неправильный путь...но это не по нашему =))..мы должны заменить минимальное кол-во байт, а не переписывать код программы..в этом суть хакерства (ну или крякерства..если хотите =). И я меняю строчку jnz short loc_407CA6 по адресу 00407C3B на jmp short loc_407C9F. Во как! Теперь при регистрации мы будем всегда регистрироваться =). Круто да? Теперь дело за малым...поменять байтики по адресу 0000703B: 75 08 на EB 58 в файле winzip32.exe. Вот и всё, товарищи...защита взломана..враг повержен! Кряк как всегда доступен всем =). На сегодня всё..до новых встреч!

AcidFalz

[an error occurred while processing this directive]