Проверка аутентичности
Проверка аутентичности (от греч. authentikos — подлинный) — «сердце» подавляющего большинства защитных механизмов. Должны же мы удостовериться, то ли лицо, за которое оно себя выдает, работает с программой и разрешено ли этому лицу работать с программой вообще!
В качестве «лица» может выступать не только пользователь, но и его компьютер или носитель информации, хранящий лицензионную копию программы. Таким образом, все защитные механизмы можно разделить на две основные категории:
Если защита базируется на одном лишь предположении, что ее код не будет изучен и/или изменен, — это плохая защита. Отсутствие исходных текстов отнюдь не служит непреодолимым препятствием для изучения и модификации приложения. Современные технологии обратного проектирования позволяют автоматически распознавать библиотечные функции, локальные переменные, стековые аргументы, типы данных, ветвления, циклы и прочее. А в недалеком будущем дизассемблеры, вероятно, вообще научатся генерировать листинги, близкие по внешнему виду к языкам высокого уровня.
Но даже сегодня анализ двоичного кода не настолько трудоемок, чтобы надолго остановить злоумышленников. Огромное количество постоянно совершаемых взломов — лучшее тому подтверждение. В идеальном случае знание алгоритма работы защиты не должно влиять на ее стойкость, но это достижимо далеко не всегда. Например, если разработчик серверной программы решит установить в демонстрационной версии ограничение на количество одновременно обрабатываемых соединений (как часто и случается), злоумышленнику достаточно найти инструкцию процессора, выполняющую такую проверку, и удалить ее. Модификации программы можно воспрепятствовать постоянной проверкой ее целостности, но опять-таки код, проверяющий целостность, может быть найден и удален.
Продолжение следует?
Пятнадцать лет назад эпический труд Криса Касперски «Фундаментальные основы хакерства» был настольной книгой каждого начинающего исследователя в области компьютерной безопасности. Однако время идет, и знания, опубликованные Крисом, теряют актуальность. Редакторы «Хакера» попытались обновить этот объемный труд и перенести его из времен Windows 2000 и Visual Studio 6.0 во времена Windows 10 и Visual Studio 2017.
Проверка аутентичности
Проверка аутентичности (от греч. authentikos — подлинный) — «сердце» подавляющего большинства защитных механизмов. Должны же мы удостовериться, то ли лицо, за которое оно себя выдает, работает с программой и разрешено ли этому лицу работать с программой вообще!
В качестве «лица» может выступать не только пользователь, но и его компьютер или носитель информации, хранящий лицензионную копию программы. Таким образом, все защитные механизмы можно разделить на две основные категории:
Если защита базируется на одном лишь предположении, что ее код не будет изучен и/или изменен, — это плохая защита. Отсутствие исходных текстов отнюдь не служит непреодолимым препятствием для изучения и модификации приложения. Современные технологии обратного проектирования позволяют автоматически распознавать библиотечные функции, локальные переменные, стековые аргументы, типы данных, ветвления, циклы и прочее. А в недалеком будущем дизассемблеры, вероятно, вообще научатся генерировать листинги, близкие по внешнему виду к языкам высокого уровня.
Но даже сегодня анализ двоичного кода не настолько трудоемок, чтобы надолго остановить злоумышленников. Огромное количество постоянно совершаемых взломов — лучшее тому подтверждение. В идеальном случае знание алгоритма работы защиты не должно влиять на ее стойкость, но это достижимо далеко не всегда. Например, если разработчик серверной программы решит установить в демонстрационной версии ограничение на количество одновременно обрабатываемых соединений (как часто и случается), злоумышленнику достаточно найти инструкцию процессора, выполняющую такую проверку, и удалить ее. Модификации программы можно воспрепятствовать постоянной проверкой ее целостности, но опять-таки код, проверяющий целостность, может быть найден и удален.
Шаг первый. Разминочный
Алгоритм простейшего механизма аутентификации состоит в посимвольном сравнении введенного пользователем пароля с эталонным значением, хранящимся либо в самой программе (как часто и бывает), либо вне ее, например в конфигурационном файле или реестре (что встречается реже).
Достоинство такой защиты — крайне простая программная реализация. Ее ядро состоит фактически из одной строки, которую на языке С можно записать так:
Давайте дополним этот код процедурами запроса пароля и вывода результатов сравнения, а затем испытаем полученную программу на прочность, то есть на стойкость к взлому:
Листинг 1. Пример простейшей системы аутентификации
В популярных кинофильмах крутые хакеры легко проникают в любые жутко защищенные системы, каким-то непостижимым образом угадывая искомый пароль с нескольких попыток. Почему бы не попробовать пойти их путем?
Не так уж редко пароли представляют собой осмысленные слова наподобие Ferrari, QWERTY, имена любимых хомячков или названия географических пунктов. Угадывание пароля сродни гаданию на кофейной гуще — никаких гарантий на успех нет, остается рассчитывать на одно лишь везение. А удача, как известно, птица гордая — палец в рот ей не клади. Нет ли более надежного способа взлома?
Давайте подумаем. Раз эталонный пароль хранится в теле программы, то, если он не зашифрован каким-нибудь хитрым образом, его можно обнаружить тривиальным просмотром двоичного кода программы. Перебирая все встретившиеся в ней текстовые строки, начиная с тех, что более всего смахивают на пароль, мы очень быстро подберем нужный ключ и откроем им программу! Причем область просмотра можно существенно сузить — в подавляющем большинстве случаев компиляторы размещают все инициализированные переменные в сегменте данных (в PE-файлах он размещается в секции .data или .rdata). Исключение составляют, пожалуй, ранние багдадские (Borland’овые) компиляторы с их маниакальной любовью всовывать текстовые строки в сегмент кода — непосредственно по месту их вызова. Это упрощает сам компилятор, но порождает множество проблем. Современные операционные системы, в отличие от старушки MS-DOS, запрещают модификацию кодового сегмента, и все размещенные в нем переменные доступны лишь для чтения. К тому же на процессорах с раздельной системой кеширования они «засоряют» кодовый кеш, попадая туда при упреждающем чтении, но при первом же обращении к ним вновь загружаются из медленной оперативной памяти (кеша второго уровня) в кеш данных. В результате — тормоза и падение производительности.
Что ж, пусть это будет секция данных! Остается только найти удобный инструмент для просмотра двоичного файла. Можно, конечно, нажать клавишу F3 в своей любимой оболочке (FAR, например) и, придавив кирпичом клавишу Page Down, любоваться бегущими цифирьками до тех пор, пока не надоест.
Можно воспользоваться любым hex-редактором (QView, Hiew…) — кому какой по вкусу, — но в статье, по соображениям наглядности, приведен результат работы утилиты DUMPBIN из штатной поставки Microsoft Visual Studio. DUMPBIN запускается из Developer Command Prompt.
Натравим утилиту на исполняемый файл нашей программы, в котором лежит пароль, и попросим ее распечатать содержащую инициализированные только для чтения данные секцию rdata (ключ /SECTION:.rdata) в «сыром» виде (ключ /RAWDATA:BYTES), указав значок > для перенаправления вывода в файл (ответ программы занимает много места, и на экране помещается один лишь «хвост»).
Листинг 2
Среди всего прочего тут есть одна строка, до боли похожая на эталонный пароль (в тексте она выделена жирным шрифтом). Испытаем ее? Впрочем, какой смысл — судя по исходному тексту программы, это действительно искомый пароль, открывающий защиту, словно золотой ключик. Слишком уж видное место выбрал компилятор для его хранения — пароль не мешало бы запрятать и получше.
Один из способов сделать это — насильно поместить эталонный пароль в собственноручно выбранную нами секцию. Такая возможность не предусмотрена стандартом, и потому каждый разработчик компилятора (строго говоря, не компилятора, а линкера, но это не суть важно) волен реализовывать ее по-своему или не реализовывать вообще. В Microsoft Visual C++ для этой цели предусмотрена специальная прагма data_seg, указывающая, в какую секцию помещать следующие за ней инициализированные переменные. Неинициализированные переменные по умолчанию располагаются в секции .bss и управляются прагмой bss_seg соответственно.
В листинг 1 перед функцией main добавим новую секцию, в которой будем хранить наш пароль:
Внутри функции main проинициализируем массив:
Немного изменилось условие сравнения строк в цикле:
Натравим утилиту DUMPBIN на новый исполняемый файл:
Ага, теперь в секции данных пароля нет и хакеры «отдыхают»! Но не спешите с выводами. Давайте сначала выведем на экран список всех секций, имеющихся в файле:
Нестандартная секция .kpnc сразу же приковывает к себе внимание. А ну-ка посмотрим, что там в ней?
Вот он, пароль! Спрятали, называется… Можно, конечно, извратиться и засунуть секретные данные в секцию неинициализированных данных (.bss) или даже секцию кода (.text) — не все там догадаются поискать, а работоспособность программы такое размещение не нарушит. Но не стоит забывать о возможности автоматизированного поиска текстовых строк в двоичном файле. В какой бы секции ни содержался эталонный пароль, фильтр без труда его найдет (единственная проблема — определить, какая из множества текстовых строк представляет собой искомый ключ; возможно, потребуется перебрать с десяток-другой потенциальных «кандидатов»).
Шаг второй. Знакомство с дизассемблером
О’кей, пароль мы узнали. Но как же утомительно вводить его каждый раз с клавиатуры перед запуском программы! Хорошо бы ее хакнуть так, чтобы никакой пароль вообще не запрашивался или любой введенный пароль программа воспринимала бы как правильный.
Хакнуть, говорите? Что ж, это несложно! Куда проблематичнее определиться, чем именно ее хакать. Инструментарий хакеров чрезвычайно разнообразен, чего тут только нет: и дизассемблеры, и отладчики, и API-, и message-шпионы, и мониторы обращений к файлам (портам, реестру), и распаковщики исполняемых файлов, и… Сложновато начинающему кодокопателю со всем этим хозяйством разобраться!
Впрочем, шпионы, мониторы, распаковщики — второстепенные утилиты заднего плана, а основное оружие взломщика — отладчик и дизассемблер.
Итак, дизассемблер применим для исследования откомпилированных программ и частично пригоден для анализа псевдокомпилированного кода. Раз так, он должен подойти для вскрытия парольной защиты passCompare1.exe. Весь вопрос в том, какой дизассемблер выбрать.
Не все дизассемблеры одинаковы. Есть среди них и «интеллектуалы», автоматически распознающие многие конструкции, как то: прологи и эпилоги функций, локальные переменные, перекрестные ссылки, а есть и «простаки», чьи способности ограничены одним лишь переводом машинных команд в ассемблерные инструкции.
Логичнее всего воспользоваться услугами дизассемблера-интеллектуала (если он есть), но… давайте не будем спешить, а попробуем выполнить весь анализ вручную. Техника, понятное дело, штука хорошая, да вот не всегда она оказывается под рукой, и неплохо бы заранее научиться работе в полевых условиях. К тому же общение с плохим дизассемблером как нельзя лучше подчеркивает «вкусности» хорошего.
Воспользуемся уже знакомой нам утилитой DUMPBIN, настоящим «швейцарским ножиком» со множеством полезных функций, среди которых притаился и дизассемблер. Дизассемблируем секцию кода (как мы помним, носящую имя .text), перенаправив вывод в файл, так как на экран он, очевидно, не поместится:
Заглянем еще раз в секцию данных (или в другую — в зависимости от того, где хранится пароль): см. листинг 2.
Запомним найденный пароль: myGOODpassword. В отличие от Visual C++ 6.0, которой пользовался Крис, Visual C++ 2017 не обращается к инициализированным переменным по шестнадцатеричному смещению, а подставляет значение прямо в секцию кода. Таким образом, попробуем найти выявленный ранее пароль в дизассемблированном листинге тривиальным контекстным поиском с помощью любого текстового редактора.
Смотрите, центральная часть этого листинга отвечает за сравнение значений регистров EAX и ECX. В последний, как мы видим, в первой строке листинга записывается эталонный пароль, следовательно, в первом — введенный пользователем. Затем происходит сравнение и выполняются переходы почти в одну и ту же точку: 0x4010A2 и 0x40109E. Заглянем, что там:
Здесь центральную роль играет инструкция test eax,eax, расположенная по смещению 0x4010A7. В случае если eax равен 0, следующая за ней команда JE совершает прыжок на 0x40110E. В противном же случае на вершину стека выталкивается строка Wrong password:
а следом — вызов функции с говорящим названием:
Значит, ненулевое значение EAX свидетельствует о ложном пароле, а ноль — об истинном.
О’кей, тогда переходим к анализу валидной ветви программы, что делается после прыжка на 0x40110E. А тут притаилась инструкция, которая помещает строку Password OK на вершину стека, после чего вызывается процедура _printf, которая, очевидно, выводит строку на экран:
Оперативные соображения следующие: если заменить команду JE на JNE, то программа отвергнет истинный пароль как неправильный, а любой неправильный пароль воспримет как истинный. А если заменить TEST EAX,EAX на XOR EAX,EAX, то после исполнения этой команды регистр EAX будет всегда равен нулю, какой бы пароль ни вводился.
Дело за малым — найти эти самые байтики в исполняемом файле и слегка подправить их.
Шаг третий. Хирургический
Внесение изменений непосредственно в исполняемый файл — дело серьезное. Стиснутым уже существующим кодом, нам приходится довольствоваться только тем, что есть, и ни раздвинуть команды, ни даже сдвинуть их, выкинув из защиты «лишние запчасти», не получится. Ведь это привело бы к сдвигу смещений всех остальных команд, тогда как значения указателей и адресов переходов остались бы без изменений и стали бы указывать совсем не туда, куда нужно!
Ну, с «выкидыванием запчастей» справиться как раз таки просто — достаточно забить код командами NOP (опкод которой 0x90, а вовсе не 0x0, как почему-то думают многие начинающие кодокопатели), то есть пустой операцией (вообще-то NOP — это просто другая форма записи инструкции XCHG EAX,EAX — если интересно). С «раздвижкой» куда сложнее! К счастью, в PE-файлах всегда присутствует множество «дыр», оставшихся от выравнивания, в них-то и можно разместить свой код или свои данные.
Но не проще ли просто откомпилировать ассемблированный файл, предварительно внеся в него требуемые изменения? Нет, не проще, и вот почему: если ассемблер не распознает указатели, передаваемые функции (а как мы видели, наш дизассемблер не смог отличить их от констант), он, соответственно, не позаботится должным образом их скорректировать, и, естественно, программа работать не будет.
Приходится резать программу вживую. Легче всего это делать с помощью утилиты Hiew, «переваривающей» PE-формат файлов и упрощающей тем самым поиск нужного фрагмента. Подойдет любая версия этого hex-редактора. Например, я использовал далеко не самую новую версию 6.86, прекрасно уживающуюся с Windows 10. Запустим ее, указав имя файла в командной строке hiew32 passCompare1.exe, двойным нажатием клавиши Enter, переключимся в режим ассемблера и при помощи клавиши F5 перейдем к требуемому адресу. Как мы помним, команда TEST, проверяющая результат на равенство нулю, располагалась по адресу
Чтобы Hiew мог отличить адрес от смещения в самом файле, предварим его символом точки:
Ага, как раз то, что нам надо! Нажмем клавишу F3 для перевода Hiew в режим правки, подведем курсор к команде TEST EAX,EAX и, нажав клавишу Enter, заменим ее на XOR EAX,EAX.
С удовлетворением заметив, что новая команда в аккурат вписалась в предыдущую, нажмем клавишу F9 для сохранения изменений на диске, а затем выйдем из Hiew и попробуем запустить программу, вводя первый пришедший на ум пароль:
>passCompare1
Enter password:Привет, шляпа!
Password OK
Получилось! Защита пала! Хорошо, а как бы мы действовали, не умей Hiew «переваривать» PE-файлы? Тогда пришлось бы прибегнуть к контекстному поиску. Обратим свой взор на шестнадцатеричный дамп, расположенный дизассемблером слева от ассемблерных команд. Конечно, если пытаться найти последовательность
Опп-с! Найдено только одно вхождение, что нам, собственно, и нужно. Давайте теперь попробуем модифицировать файл непосредственно в hex-режиме, не переходя в ассемблер. Попутно возьмем себе на заметку — инверсия младшего бита кода команды приводит к изменению условия перехода на противоположное, то есть 74 JE -> 75 JNE.
Работает? В смысле защита свихнулась окончательно — не признает истинные пароли, зато радостно приветствует остальные. Замечательно!
Проверка аутентичности (от греч. authentikos — подлинный) — «сердце» подавляющего большинства защитных механизмов. Должны же мы удостовериться, то ли лицо, за которое оно себя выдает, работает с программой и разрешено ли этому лицу работать с программой вообще!
В качестве «лица» может выступать не только пользователь, но и его компьютер или носитель информации, хранящий лицензионную копию программы. Таким образом, все защитные механизмы можно разделить на две основные категории:
- защиты, основанные на знании (пароля, серийного номера);
- защиты, основанные на обладании (ключевым диском, документацией).
Но даже сегодня анализ двоичного кода не настолько трудоемок, чтобы надолго остановить злоумышленников. Огромное количество постоянно совершаемых взломов — лучшее тому подтверждение. В идеальном случае знание алгоритма работы защиты не должно влиять на ее стойкость, но это достижимо далеко не всегда. Например, если разработчик серверной программы решит установить в демонстрационной версии ограничение на количество одновременно обрабатываемых соединений (как часто и случается), злоумышленнику достаточно найти инструкцию процессора, выполняющую такую проверку, и удалить ее. Модификации программы можно воспрепятствовать постоянной проверкой ее целостности, но опять-таки код, проверяющий целостность, может быть найден и удален.
Продолжение следует?
Пятнадцать лет назад эпический труд Криса Касперски «Фундаментальные основы хакерства» был настольной книгой каждого начинающего исследователя в области компьютерной безопасности. Однако время идет, и знания, опубликованные Крисом, теряют актуальность. Редакторы «Хакера» попытались обновить этот объемный труд и перенести его из времен Windows 2000 и Visual Studio 6.0 во времена Windows 10 и Visual Studio 2017.
Проверка аутентичности
Проверка аутентичности (от греч. authentikos — подлинный) — «сердце» подавляющего большинства защитных механизмов. Должны же мы удостовериться, то ли лицо, за которое оно себя выдает, работает с программой и разрешено ли этому лицу работать с программой вообще!
В качестве «лица» может выступать не только пользователь, но и его компьютер или носитель информации, хранящий лицензионную копию программы. Таким образом, все защитные механизмы можно разделить на две основные категории:
- защиты, основанные на знании (пароля, серийного номера);
- защиты, основанные на обладании (ключевым диском, документацией).
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Основные типы защитЕсли защита базируется на одном лишь предположении, что ее код не будет изучен и/или изменен, — это плохая защита. Отсутствие исходных текстов отнюдь не служит непреодолимым препятствием для изучения и модификации приложения. Современные технологии обратного проектирования позволяют автоматически распознавать библиотечные функции, локальные переменные, стековые аргументы, типы данных, ветвления, циклы и прочее. А в недалеком будущем дизассемблеры, вероятно, вообще научатся генерировать листинги, близкие по внешнему виду к языкам высокого уровня.
Но даже сегодня анализ двоичного кода не настолько трудоемок, чтобы надолго остановить злоумышленников. Огромное количество постоянно совершаемых взломов — лучшее тому подтверждение. В идеальном случае знание алгоритма работы защиты не должно влиять на ее стойкость, но это достижимо далеко не всегда. Например, если разработчик серверной программы решит установить в демонстрационной версии ограничение на количество одновременно обрабатываемых соединений (как часто и случается), злоумышленнику достаточно найти инструкцию процессора, выполняющую такую проверку, и удалить ее. Модификации программы можно воспрепятствовать постоянной проверкой ее целостности, но опять-таки код, проверяющий целостность, может быть найден и удален.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Шаг первый. Разминочный
Алгоритм простейшего механизма аутентификации состоит в посимвольном сравнении введенного пользователем пароля с эталонным значением, хранящимся либо в самой программе (как часто и бывает), либо вне ее, например в конфигурационном файле или реестре (что встречается реже).
Достоинство такой защиты — крайне простая программная реализация. Ее ядро состоит фактически из одной строки, которую на языке С можно записать так:
if (strcmp(введенный пароль, эталонный пароль)) {/* Пароль неверен */} else {/* Пароль ОK*/}Давайте дополним этот код процедурами запроса пароля и вывода результатов сравнения, а затем испытаем полученную программу на прочность, то есть на стойкость к взлому:
Листинг 1. Пример простейшей системы аутентификации
C:
#include "stdafx.h"
// Простейшая система аутентификации —
// посимвольное сравнение пароля
#include <stdio.h>
#include <string.h>
#define PASSWORD_SIZE 100
#define PASSWORD "myGOODpassword\n"
// Этот перенос нужен затем, чтобы
// не выкусывать перенос из строки,
// введенной пользователем
int main()
{
// Счетчик неудачных попыток аутентификации
int count=0;
// Буфер для пароля, введенного пользователем
char buff[PASSWORD_SIZE];
// Главный цикл аутентификации
for(;;)
{
// Запрашиваем и считываем пользовательский
// пароль
printf("Enter password:");
fgets(&buff[0],PASSWORD_SIZE,stdin);
// Сравниваем оригинальный и введенный пароль
if (strcmp(&buff[0],PASSWORD))
// Если пароли не совпадают — «ругаемся»
printf("Wrong password\n");
// Иначе (если пароли идентичны)
// выходим из цикла аутентификации
else break;
// Увеличиваем счетчик неудачных попыток
// аутентификации и, если все попытки
// исчерпаны, завершаем программу
if (++count>3) return -1;
}
// Раз мы здесь, то пользователь ввел правильный
// пароль
printf("Password OK\n");
}Не так уж редко пароли представляют собой осмысленные слова наподобие Ferrari, QWERTY, имена любимых хомячков или названия географических пунктов. Угадывание пароля сродни гаданию на кофейной гуще — никаких гарантий на успех нет, остается рассчитывать на одно лишь везение. А удача, как известно, птица гордая — палец в рот ей не клади. Нет ли более надежного способа взлома?
Давайте подумаем. Раз эталонный пароль хранится в теле программы, то, если он не зашифрован каким-нибудь хитрым образом, его можно обнаружить тривиальным просмотром двоичного кода программы. Перебирая все встретившиеся в ней текстовые строки, начиная с тех, что более всего смахивают на пароль, мы очень быстро подберем нужный ключ и откроем им программу! Причем область просмотра можно существенно сузить — в подавляющем большинстве случаев компиляторы размещают все инициализированные переменные в сегменте данных (в PE-файлах он размещается в секции .data или .rdata). Исключение составляют, пожалуй, ранние багдадские (Borland’овые) компиляторы с их маниакальной любовью всовывать текстовые строки в сегмент кода — непосредственно по месту их вызова. Это упрощает сам компилятор, но порождает множество проблем. Современные операционные системы, в отличие от старушки MS-DOS, запрещают модификацию кодового сегмента, и все размещенные в нем переменные доступны лишь для чтения. К тому же на процессорах с раздельной системой кеширования они «засоряют» кодовый кеш, попадая туда при упреждающем чтении, но при первом же обращении к ним вновь загружаются из медленной оперативной памяти (кеша второго уровня) в кеш данных. В результате — тормоза и падение производительности.
Что ж, пусть это будет секция данных! Остается только найти удобный инструмент для просмотра двоичного файла. Можно, конечно, нажать клавишу F3 в своей любимой оболочке (FAR, например) и, придавив кирпичом клавишу Page Down, любоваться бегущими цифирьками до тех пор, пока не надоест.
Можно воспользоваться любым hex-редактором (QView, Hiew…) — кому какой по вкусу, — но в статье, по соображениям наглядности, приведен результат работы утилиты DUMPBIN из штатной поставки Microsoft Visual Studio. DUMPBIN запускается из Developer Command Prompt.
Натравим утилиту на исполняемый файл нашей программы, в котором лежит пароль, и попросим ее распечатать содержащую инициализированные только для чтения данные секцию rdata (ключ /SECTION:.rdata) в «сыром» виде (ключ /RAWDATA:BYTES), указав значок > для перенаправления вывода в файл (ответ программы занимает много места, и на экране помещается один лишь «хвост»).
Листинг 2
Код:
> dumpbin /RAWDATA:BYTES /SECTION:.rdata passCompare1.exe > rdata.txt
004020E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
004020F0: 18 30 40 00 68 30 40 00 45 6E 74 65 72 20 70 61 [email protected]@.Enter pa
00402100: 73 73 77 6F 72 64 3A 00 6D 79 47 4F 4F 44 70 61 ssword:.myGOODpa
00402110: 73 73 77 6F 72 64 0A 00 57 72 6F 6E 67 20 70 61 ssword..Wrong pa
00402120: 73 73 77 6F 72 64 0A 00 50 61 73 73 77 6F 72 64 ssword..Password
00402130: 20 4F 4B 0A 00 00 00 00 00 00 00 00 00 00 00 00 OK.............
00402140: 00 00 00 00 90 0A C1 5B 00 00 00 00 02 00 00 00 ......A[........
00402150: 48 00 00 00 24 22 00 00 24 14 00 00 00 00 00 00 H...$"..$.......Один из способов сделать это — насильно поместить эталонный пароль в собственноручно выбранную нами секцию. Такая возможность не предусмотрена стандартом, и потому каждый разработчик компилятора (строго говоря, не компилятора, а линкера, но это не суть важно) волен реализовывать ее по-своему или не реализовывать вообще. В Microsoft Visual C++ для этой цели предусмотрена специальная прагма data_seg, указывающая, в какую секцию помещать следующие за ней инициализированные переменные. Неинициализированные переменные по умолчанию располагаются в секции .bss и управляются прагмой bss_seg соответственно.
В листинг 1 перед функцией main добавим новую секцию, в которой будем хранить наш пароль:
C:
// С этого момента все инициализированные переменные будут
// размещаться в секции .kpnc
#pragma data_seg(".kpnc")
#define PASSWORD_SIZE 100
#define PASSWORD "myGOODpassword\n"
char passwd[] = PASSWORD;
#pragma data_seg()
C:
// Теперь все инициализированные переменные вновь будут
// размещаться в секции по умолчанию, то есть .rdata
char buff[PASSWORD_SIZE]="";
C:
if (strcmp(&buff[0],&passwd[0]))
Код:
> dumpbin /RAWDATA:BYTES /SECTION:.rdata passCompare2.exe > rdata.txt
004020C0: D3 17 40 00 00 00 00 00 D8 11 40 00 00 00 00 00 [email protected].@.....
004020D0: 00 00 00 00 2C 11 40 00 D0 11 40 00 00 00 00 00 ....,.@.?.@.....
004020E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
004020F0: 18 30 40 00 68 30 40 00 45 6E 74 65 72 20 70 61 [email protected]@.Enter pa
00402100: 73 73 77 6F 72 64 3A 00 57 72 6F 6E 67 20 70 61 ssword:.Wrong pa
00402110: 73 73 77 6F 72 64 0A 00 50 61 73 73 77 6F 72 64 ssword..Password
00402120: 20 4F 4B 0A 00 00 00 00 00 00 00 00 00 00 00 00 OK.............
00402130: 00 00 00 00 6F CB C4 5B 00 00 00 00 02 00 00 00 ....oEA[........
00402140: 48 00 00 00 14 22 00 00 14 14 00 00 00 00 00 00 H...."..........
00402150: 6F CB C4 5B 00 00 00 00 0C 00 00 00 14 00 00 00 oEA[............
Код:
> dumpbin passCompare2.exe
Summary
1000 .data
1000 .kpnc
1000 .rdata
1000 .reloc
1000 .rsrc
1000 .text
Код:
> dumpbin /SECTION:.kpnc /RAWDATA passCompare2.exe
RAW DATA #4
00404000: 6D 79 47 4F 4F 44 70 61 73 73 77 6F 72 64 0A 00 myGOODpassword..Шаг второй. Знакомство с дизассемблером
О’кей, пароль мы узнали. Но как же утомительно вводить его каждый раз с клавиатуры перед запуском программы! Хорошо бы ее хакнуть так, чтобы никакой пароль вообще не запрашивался или любой введенный пароль программа воспринимала бы как правильный.
Хакнуть, говорите? Что ж, это несложно! Куда проблематичнее определиться, чем именно ее хакать. Инструментарий хакеров чрезвычайно разнообразен, чего тут только нет: и дизассемблеры, и отладчики, и API-, и message-шпионы, и мониторы обращений к файлам (портам, реестру), и распаковщики исполняемых файлов, и… Сложновато начинающему кодокопателю со всем этим хозяйством разобраться!
Впрочем, шпионы, мониторы, распаковщики — второстепенные утилиты заднего плана, а основное оружие взломщика — отладчик и дизассемблер.
Итак, дизассемблер применим для исследования откомпилированных программ и частично пригоден для анализа псевдокомпилированного кода. Раз так, он должен подойти для вскрытия парольной защиты passCompare1.exe. Весь вопрос в том, какой дизассемблер выбрать.
Не все дизассемблеры одинаковы. Есть среди них и «интеллектуалы», автоматически распознающие многие конструкции, как то: прологи и эпилоги функций, локальные переменные, перекрестные ссылки, а есть и «простаки», чьи способности ограничены одним лишь переводом машинных команд в ассемблерные инструкции.
Логичнее всего воспользоваться услугами дизассемблера-интеллектуала (если он есть), но… давайте не будем спешить, а попробуем выполнить весь анализ вручную. Техника, понятное дело, штука хорошая, да вот не всегда она оказывается под рукой, и неплохо бы заранее научиться работе в полевых условиях. К тому же общение с плохим дизассемблером как нельзя лучше подчеркивает «вкусности» хорошего.
Воспользуемся уже знакомой нам утилитой DUMPBIN, настоящим «швейцарским ножиком» со множеством полезных функций, среди которых притаился и дизассемблер. Дизассемблируем секцию кода (как мы помним, носящую имя .text), перенаправив вывод в файл, так как на экран он, очевидно, не поместится:
Код:
> dumpbin /SECTION:.text /DISASM passCompare1.exe > code-text.txtЗапомним найденный пароль: myGOODpassword. В отличие от Visual C++ 6.0, которой пользовался Крис, Visual C++ 2017 не обращается к инициализированным переменным по шестнадцатеричному смещению, а подставляет значение прямо в секцию кода. Таким образом, попробуем найти выявленный ранее пароль в дизассемблированном листинге тривиальным контекстным поиском с помощью любого текстового редактора.
Код:
0040107D: B9 08 21 40 00 mov ecx,offset ??_C@_0BA@PCMCJPMK@myGOODpassword?6?$AA@
00401082: 8A 10 mov dl,byte ptr [eax]
00401084: 3A 11 cmp dl,byte ptr [ecx]
00401086: 75 1A jne 004010A2
00401088: 84 D2 test dl,dl
0040108A: 74 12 je 0040109E
Код:
0040109E: 33 C0 xor eax,eax
004010A0: EB 05 jmp 004010A7
004010A2: 1B C0 sbb eax,eax
004010A4: 83 C8 01 or eax,1
004010A7: 85 C0 test eax,eax
004010A9: 74 63 je 0040110E
004010AB: 0F 1F 44 00 00 nop dword ptr [eax+eax]
004010B0: 68 18 21 40 00 push offset ??_C@_0BA@EHHIHKNJ@Wrong?5password?6?$AA@
004010B5: E8 56 FF FF FF call _printf
Код:
push offset ??_C@_0BA@EHHIHKNJ@Wrong?5password?6?$AA@
Код:
call _printfО’кей, тогда переходим к анализу валидной ветви программы, что делается после прыжка на 0x40110E. А тут притаилась инструкция, которая помещает строку Password OK на вершину стека, после чего вызывается процедура _printf, которая, очевидно, выводит строку на экран:
Код:
0040110E: 68 28 21 40 00 push offset ??_C@_0N@MBEFNJID@Password?5OK?6?$AA@
00401113: E8 F8 FE FF FF call _printfДело за малым — найти эти самые байтики в исполняемом файле и слегка подправить их.
Шаг третий. Хирургический
Внесение изменений непосредственно в исполняемый файл — дело серьезное. Стиснутым уже существующим кодом, нам приходится довольствоваться только тем, что есть, и ни раздвинуть команды, ни даже сдвинуть их, выкинув из защиты «лишние запчасти», не получится. Ведь это привело бы к сдвигу смещений всех остальных команд, тогда как значения указателей и адресов переходов остались бы без изменений и стали бы указывать совсем не туда, куда нужно!
Ну, с «выкидыванием запчастей» справиться как раз таки просто — достаточно забить код командами NOP (опкод которой 0x90, а вовсе не 0x0, как почему-то думают многие начинающие кодокопатели), то есть пустой операцией (вообще-то NOP — это просто другая форма записи инструкции XCHG EAX,EAX — если интересно). С «раздвижкой» куда сложнее! К счастью, в PE-файлах всегда присутствует множество «дыр», оставшихся от выравнивания, в них-то и можно разместить свой код или свои данные.
Но не проще ли просто откомпилировать ассемблированный файл, предварительно внеся в него требуемые изменения? Нет, не проще, и вот почему: если ассемблер не распознает указатели, передаваемые функции (а как мы видели, наш дизассемблер не смог отличить их от констант), он, соответственно, не позаботится должным образом их скорректировать, и, естественно, программа работать не будет.
Приходится резать программу вживую. Легче всего это делать с помощью утилиты Hiew, «переваривающей» PE-формат файлов и упрощающей тем самым поиск нужного фрагмента. Подойдет любая версия этого hex-редактора. Например, я использовал далеко не самую новую версию 6.86, прекрасно уживающуюся с Windows 10. Запустим ее, указав имя файла в командной строке hiew32 passCompare1.exe, двойным нажатием клавиши Enter, переключимся в режим ассемблера и при помощи клавиши F5 перейдем к требуемому адресу. Как мы помним, команда TEST, проверяющая результат на равенство нулю, располагалась по адресу
0x4010A7.Чтобы Hiew мог отличить адрес от смещения в самом файле, предварим его символом точки:
.4010A7.
Код:
004010A7: 85 C0 test eax,eax
004010A9: 74 63 je 0040110E
Код:
004010A7: 33 C0 xor eax,eax
004010A9: 74 63 je 0040110EС удовлетворением заметив, что новая команда в аккурат вписалась в предыдущую, нажмем клавишу F9 для сохранения изменений на диске, а затем выйдем из Hiew и попробуем запустить программу, вводя первый пришедший на ум пароль:
>passCompare1
Enter password:Привет, шляпа!
Password OK
Получилось! Защита пала! Хорошо, а как бы мы действовали, не умей Hiew «переваривать» PE-файлы? Тогда пришлось бы прибегнуть к контекстному поиску. Обратим свой взор на шестнадцатеричный дамп, расположенный дизассемблером слева от ассемблерных команд. Конечно, если пытаться найти последовательность
85 C0 — код команды TEST EAX,EAX, ничего хорошего из этого не выйдет — этих самых TEST’ов в программе может быть несколько сотен, а то и больше. А вот адрес перехода, скорее всего, во всех ветках программы различен, и подстрока TEST EAX,EAX/JE 0040110E имеет хорошие шансы на уникальность. Попробуем найти в файле соответствующий ей код: 85 C0 74 63 (в Hiew для этого достаточно нажать клавишу F7).Опп-с! Найдено только одно вхождение, что нам, собственно, и нужно. Давайте теперь попробуем модифицировать файл непосредственно в hex-режиме, не переходя в ассемблер. Попутно возьмем себе на заметку — инверсия младшего бита кода команды приводит к изменению условия перехода на противоположное, то есть 74 JE -> 75 JNE.
Работает? В смысле защита свихнулась окончательно — не признает истинные пароли, зато радостно приветствует остальные. Замечательно!
Последнее редактирование модератором:
