В отличие от Windows среда Linux не может похвастаться большим количеством разных трюков против отладки. Opensource и всё такое сыграли свою долю в этом. Среди дебаггеровесть gdb, но он очень легко обнаруживается простейшими техниками анти-отладки.
Соответственно не много известно протекторов способных сильно затруднить отладку бинарника, среди них можно вспомнить разве что 'shiva', но она уже давно «умерла».
Игрушкой сегодня для нас будет служить программка lincrackme3 с crackmes.de, она – не сложна и при этом, в ней имеется несколько анти-отладочных трюков. Мы будем использовать только дисассемблер – никаких отладчиков, ltracer-ов и тем более патчинга бинарника. Дисассемблером будет служить IDAPro 5.5.
Итак, загружаем… Нет никаких проблем с загрузкой: поля ELF спецификации – правильные. Далее логичней всего начать с поиска чего-нибуть интересного в string-ах или импорте или в случае небольших размеров бинарника – проглянуть ассемблерный листинг «простыней» в поисках информации о компиляторе, возможной обфускации, шифрования, т.д. Мы же пойдем первым путем и поищем в импорте. Итак, интересным для нас будет вызов ptrace — он приведет к защитному механизму.
Здесь код пытается сам себя «отладить» и если это ему не удаётся (кто-то уже это делает без него, например дебаггер), то ptace возвращает -1, возводиться флаг знака и… программа заканчивает своё выполнение. Но это еще не всё. Перекрестная ссылка на строку о дебаггере ведет также сюда:
Еще один трюк против отладки: во время выполнения программа открывает стандартные потоки STDIN=0, STDOUT1, STDERR=2, и если при этом попробовать закрыть файловый дескриптор, то, если до этого его никто не открывал (например, дебаггер), то произойдет ошибка и результатом close(3)=-1, в случае присутствия прежде открытого файлового дескриптора: close(3)=0.
Итак, с трюками против отладки - всё. Далее только проверка серийника. Перекрестные ссылки на интересные» строки нас приведут сюда:
IDA распознала runtime-functions и всё действительно становится очень просто: функция sub_804862C – просто переводит пароль формата «ХХХХ-ХХХХ-ХХХХ-ХХХХ» в «ХХХХХХХХХХХХХХХХ» и сравнивает длину полученного пароля с 0х10 =16.
Если длина пароля 16 символов то прыгаем сюда:
В этой ветке нас ждет сравнение пароля со строкой «It’s not that easy,...», но результат программу не «интересует» и следующим шагом будет игра против дизассемблера, с использованием дебаггера (после трассировки ) всё было бы намного проще, но попробуем произвести трассировку «в уме». Обратите внимание на команду сallloc_8048847, которая расположена по адресу 08048841. При её выполнении произойдет помещение адреса следующей за ней команды на
«вершину стека». Далее адрес возврата помещаем в регистр eax, добавляем смещение, обратно помещаем на вершину стека и возвращаемся. Но куда?
Вот куда: 08048846h+09Dh=080488E3h
Еще один трюк: скрытый вызов процедуры, адрес которой расположен где-то в глубинах стека. Ситуация усложняется тем фактом, что адресация ведется по средством esp регистра, значение которого изменяется по ходу выполнения программы. Если бы мы работали в дебаггере, то узнать адрес искомой процедуры – простое дело, но в данном случае (работа только с дисассемблером) надо проследить все обращения к секции стека. Ладно, будем исходить из того факта, что для правильной работы программе надо иметь сбалансированый стек. Поэтому под подозрение сразу попадает интересная команда в начале «процедуры приветствия»:
Еще один вызов проверки с ptrace().
Если всё прошло хорошо с проверкой, то прыгаем сюда:
В этом цикле идёт преобразования пароля с ASCII формата в HEX, но реализация предусматривает наличие среди символов пароля только цифровых значений. Полученные значения последовательно записываются в «глубины стека»: первая четвёрка символов серийника записывается сюда [esp+36],
вторая — сюда [esp+34], третья — [esp+32], четвёртая — [esp+30]. Далее – самое интересное проверка правильности пароля и «искомого перехода».
Как вы видите имеется 5 условных переходов на один блок, что вероятно может привести нас к сообщению о неправильном пароле. Тогда надо, поочередности, «правильно» — не прыгая пройти все проверки. Итак, начнем…
Сумма первой и второй четвёрки значений пароля должно равняется удвоенной сумме третьей и четвертой.
Значение второй четверки больше значения третьей.
Сумма первой и четвертой четвёрок – парна.
Значение первой четвёрки – больше 5-ти и меньше 24.
А вот и последний переход. На этот раз прыгать не надо. А это возможно только при условии, что значение последней (четвертой) четверки – непарное. Что, при условии, что сумма первой и четвертой четвёрок – парна,
говорит нам, что значение первой четверки – тоже непарное. Если все условия выполнены верно, то далее нас ожидает «расшифровка» (dexoring) строки информирующей о правильном пароле и лицезрение такой картины:
Думаю, написание кейгена не составит труда.
Всем спасибо за внимание.
PS: Greets fly to Alexa Nachtigal.
PPS Статья опубликована по просьбе автора, Paul H.
PPPS Простите за код в жипегах, я не виноват :-)
