Исследование исполняемого файла можно разделить на три этапа: поверхностный, глубокий, хирургический. На первом мы малыми силами собираем информацию о подопытном файле. Под «малыми силами» я подразумеваю легкие в использовании и широко распространенные средства анализа. В этой статье мы поговорим о них и для наглядности взломаем несложную защиту.

Пят­надцать лет назад эпи­чес­кий труд Кри­са Кас­пер­ски «Фун­дамен­таль­ные осно­вы хакерс­тва» был нас­толь­ной кни­гой каж­дого начина­юще­го иссле­дова­теля в области компь­ютер­ной безопас­ности. Одна­ко вре­мя идет, и зна­ния, опуб­ликован­ные Кри­сом, теря­ют акту­аль­ность. Редак­торы «Хакера» попыта­лись обно­вить этот объ­емный труд и перенес­ти его из вре­мен Windows 2000 и Visual Studio 6.0 во вре­мена Windows 10 и Visual Studio 2019. Результатом стал цикл статей.

Мы публикуем эту статью в честь начала предзаказов обновленной версии книги Криса, получившей новый подзаголовок: «Анализ программ в среде Win64». Оставить предзаказ на книгу, чтобы приобрести ее со скидкой 25%, вы можете на сайте издательства «Солон-пресс».

Этап 1

Если работа ведется в Linux, среди инструментов поверхностного анализа можно отметить такие приложения:

• file определяет тип файла, анализируя его поля;

• readelf отображает информацию о секциях файла;

• ldd выводит список динамических библиотек, от которых зависит данный исполняемый файл;

• nm выводит список декорированных имен функций, которые создаются компиляторами языков, поддерживающих перегрузку функций. Затем утилита может декодировать эти имена;

• c++filt преобразует декорированные имена функций в первоначальные с учетом передаваемых и получаемых аргументов;

• strings выводит строки, содержащиеся в файле, с учетом заданного шаблона.

В Windows со многими из этих задач справляется утилита dumpbin, входящая в поставку Visual Studio.

Если мы получили общее представление о файле и не нашли ничего полезного для взлома, есть смысл переходить к следующему этапу.

Этап 2

Второй этап — это дизассемблирование. Его цель — обнаружить защитный механизм. Существует два вида дизассемблирования: статическое и динамическое (более известное как отладка или трассировка). В первом случае изучается дизассемблерный код, полученный с помощью автоматического анализа дизассемблером исполняемого файла без его запуска.

Динамическое дизассемблирование предполагает запуск программы и ее пошаговое исполнение. Обычно отладка проходит в специальной и обособленной среде. Это нужно на случай, если программа представляет какую-то угрозу для системы.

В качестве отладчика в Linux можно воспользоваться старым добрым GDB либо средствами трассировки в Radare2. В Windows выбор тоже невелик: OllyDbg постепенно устаревает и не обновляется. В нем отлаживать приложения можно только в режиме пользователя. После смерти SoftICE единственным нормальным отладчиком в Windows стал WinDbg. В нем можно отлаживать драйверы на уровне ядра.

Статические дизассемблеры тоже делятся на две группы: линейные и рекурсивные. Первые перебирают все сегменты кода в двоичном файле, декодируют и преобразуют их в мнемоники языка ассемблера. Так работает большинство простых дизассемблеров, включая objdump и dumpbin. Может показаться, что так и должно быть. Однако, когда среди исполняемого кода встречаются данные, возникает проблема: их не надо преобразовывать в команды, но линейный дизассемблер не в состоянии отличить их от кода! Мало того, после того как сегмент данных завершится, дизассемблер будет рассинхронизирован с текущей позиции кода.

С другой стороны, рекурсивные дизассемблеры, такие как IDA Pro, Radare2 и Ghidra, ведут себя иначе. Они дизассемблируют код в той же последовательности, в которой его будет исполнять процессор. Поэтому они аккуратно обходят данные, и в результате большинство команд благополучно распознается.

Но и здесь есть ложка дегтя. Не все косвенные переходы легко отследить. Следовательно, какие-то пути выполнения могут остаться нераспознанными. Помогает то, что современные дизассемблеры применяют разные эвристические приемы с учетом конкретных компиляторов.

Этап 3

Когда адрес защитного механизма найден, можно приступать к третьему этапу — хирургическому. Существует несколько видов непосредственного взлома. Самый простой вариант — воспользоваться шестнадцатеричным редактором.

Существует множество HEX-редакторов на любой вкус и цвет, например 010 Editor, HexEdit, HIEW. Вооружайся одним из них, и тебе останется только перезаписать команду по найденному адресу. Но в двоичном файле сильно не разбежишься! Существующий код не дает простора для манипуляций, поэтому нам приходится умещаться в имеющемся пространстве.

Противопоказано раздвигать или сдвигать команды, даже выкидывать имеющиеся конструкции можно только с большой осторожностью. Ведь подобные манипуляции с кодом приведут к сдвигу смещений остальных команд, а указатели в таком случае будут указывать в космос!

Этим способом, однако, можно хакнуть большое количество защитных механизмов. А как быть, если надо не просто взломать программу, а добавить или заменить в ней какие-то функции? Понятно, что HEX-редактор тут тебе не друг.

Здесь на помощь приходит техника оснащения двоичного файла. Оно позволяет вставить почти неограниченный блок кода в почти любое место файла. Понятно, что без посторонних средств этого не добиться. Оснащение реализуют специальные библиотеки, предоставляющие гибкие API.

С помощью статического оснащения производится модификация файла непосредственно на диске. То есть бинарный файл сначала надо дизассемблировать, найти подходящее место, обладающее достаточным пространством для включения полезной нагрузки, и, внедряя потусторонний код, уследить, чтобы не поломались существующие указатели на код и данные. В этом деле призваны помочь такие инструменты, как Dyninst и PEBIL. После модификации файла он записывается в измененном виде обратно на диск.

Динамическое оснащение работает по другому принципу. Подобно отладчикам движки динамического оснащения следят за выполняемыми процессами и вносят код прямо в память. Поэтому при динамическом оснащении не нужно ни дизассемблирование, ни изменение бинарника, от чего одним махом исчезают все негативные последствия.

Однако во время динамического оснащения, так как программа выполняется «под наблюдением», ее производительность заметно падает. Для динамического оснащения используются системы DynamoRIO (совместный проект HP и MIT) и Pin (Intel).

Может показаться, что динамическое оснащение лучше во всех отношениях. А вот и нет! Такую программу нельзя будет исполнить на другом компьютере, где нет никаких специальных средств. Тогда как в процессе статического оснащения мы заранее готовим бинарник и передаем его пользователю. Теми же средствами могут пользоваться и злоумышленники, желающие заразить программу вирусом или снабдить какой-то подлой функцией.

Практический взлом

Чтобы поупражняться на практике, проведем анализ и раскусим элементарную защиту.

Алгоритм простейшего механизма аутентификации заключается в посимвольном сравнении введенного пользователем пароля с эталонным значением, хранящимся либо в самой программе (как часто и бывает), либо вне ее, например, в конфигурационном файле или реестре (что встречается реже).

Достоинство такой защиты — крайне простая программная реализация. Ее ядро состоит фактически из нескольких строк, которые на языке С/C++ можно записать так:

if (strcmp(введенный пароль, эталонный пароль)) 
{/* Пароль неверен */} 
else 
{/* Пароль ОК*/}

Давай дополним этот код процедурами запроса пароля и вывода результатов сравнения, а затем испытаем полученную программу на прочность, т. е. на стойкость к взлому.

Пример простейшей системы аутентификации:

     #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, DOS Navigator) и, придавив кирпичом Page Down, любоваться бегущими циферками до тех пор, пока не надоест.

Можно воспользоваться любым HEX-редактором (QVIEW, HIEW... — кому какой по вкусу), но в данном случае, по соображениям наглядности, приведен результат работы утилиты dumpbin из штатной поставки Microsoft Visual Studio.

Натравим утилиту на исполняемый файл нашей программы, содержащей пароль, и попросим ее распечатать содержащую только для чтения инициализированные данные секцию — rdata (ключ /SECTION:.rdata) в «сыром» виде (ключ /RAWDATA:BYTES), указав значок > для перенаправления вывода в файл (ответ программы занимает много места, и на экране помещается один лишь «хвост»).

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  .0@.h0@.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 соответственно.

В примере аутентификации выше перед функцией main добавим новую секцию, в которой будем хранить наш пароль:

     // С этого момента все инициализированные 
     // переменные будут размещаться в секции .kpnc
     #pragma data_seg(".kpnc") 
     #define PASSWORD_SIZE 100
     #define PASSWORD "myGOODpassword\n"
     char passwd[] = PASSWORD;
     #pragma data_seg()

Внутри функции main проинициализируем массив:

     // Теперь все инициализированные переменные 
     // вновь будут размещаться в секции по умолчанию, 
     // т. е. .rdata 
     char buff[PASSWORD_SIZE]="";

Немного изменилось условие сравнения строк в цикле:

     if (strcmp(&buff[0],&passwd[0]))

Натравим утилиту dumpbin на новый исполняемый файл:

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  O.@.....O.@.....
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  .0@.h0@.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

Нестандартная секция .kpnc сразу же приковывает к себе внимание. А ну-ка посмотрим, что там в ней.

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..

Вот он, пароль! Спрятали, называется... Можно, конечно, извратиться и засунуть секретные данные в секцию неинициализированных данных (.bss) или даже секцию кода (.text) — не все там догадаются поискать, а работоспособность программы такое размещение не нарушит. Но не стоит забывать о возможности автоматизированного поиска текстовых строк в двоичном файле. В какой бы секции ни содержался эталонный пароль, фильтр без труда его найдет (единственная проблема — определить, какая из множества текстовых строк представляет собой искомый ключ; возможно, потребуется перебрать с десяток-другой потенциальных кандидатов).

Знакомство с дизассемблером

Пароль мы узнали. Но как же утомительно вводить его каждый раз с клавиатуры перед запуском программы! Хорошо бы ее хакнуть так, чтобы никакой пароль вообще не запрашивался или любой введенный пароль программа воспринимала как правильный.

Хакнуть, говорите?! Что ж, это несложно! Куда проблематичнее определиться, чем именно ее хакать. Инструментарий хакеров чрезвычайно разнообразен, чего тут только нет: и дизассемблеры, и отладчики, и API-, и message-шпионы, и мониторы обращений к файлам (портам, реестру), и распаковщики исполняемых файлов, и... Сложновато начинающему кодокопателю со всем этим хозяйством разобраться!

Впрочем, шпионы, мониторы, распаковщики — второстепенные утилиты заднего плана, а основное оружие взломщика — отладчик (динамический дизассемблер) и дизассемблер (статический).

Итак, дизассемблер применим для исследования откомпилированных программ и частично пригоден для анализа псевдокомпилированного кода. Раз так, он должен подойти для вскрытия парольной защиты passCompare1.exe. Весь вопрос в том, какой дизассемблер выбрать.

Не все дизассемблеры одинаковы. Есть среди них и «интеллектуалы», автоматически распознающие многие конструкции, как то: прологи и эпилоги функций, локальные переменные, перекрестные ссылки и т. д., а есть и «простаки», чьи способности ограничены одним лишь переводом машинных команд в ассемблерные инструкции.

Логичнее всего воспользоваться услугами дизассемблера-интеллектуала (если он есть), но... давай не будем спешить, а попробуем выполнить весь анализ вручную. Техника, понятное дело, штука хорошая, да вот не всегда она оказывается под рукой, и неплохо бы заранее научиться работе в полевых условиях. К тому же общение с плохим дизассемблером как нельзя лучше подчеркивает «вкусности» хорошего.

Воспользуемся уже знакомой нам утилитой dumpbin, настоящим «швейцарским ножиком» со множеством полезных функций, среди которых притаился и дизассемблер. Дизассемблируем секцию кода (как мы помним, носящую имя .text), перенаправив вывод в файл, так как на экран он, очевидно, не поместится:

 dumpbin /SECTION:.text /DISASM passCompare1.exe > code-text.txt

Заглянем еще раз в секцию данных (или в другую — в зависимости от того, где хранится пароль).

Запомним найденный пароль: myGOODpassword. В зависимости от версии и настроек дизассемблера dumpbin инициализированные переменные, к которым обращается код, могут быть представлены по-разному: на их месте могут быть или символьные константы, или непосредственно шестнадцатеричное смещение. Попробуем найти выявленный ранее пароль в дизассемблированном листинге тривиальным контекстным поиском с помощью любого текстового редактора.

 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

Центральная часть этого листинга сравнивает значения регистров EAX и ECX. В последний, как мы видим в первой строке листинга, записывается эталонный пароль, следовательно, в первом — введенный пользователем. Затем происходит сравнение и выполняются переходы почти в одну и ту же точку: 0x4010A2 и 0x40109E. Интересно, что там. Заглянем:

 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

Здесь центральную роль играет инструкция TEST EAX,EAX, размещенная по смещению 0x4010A7. Если EAX равен 0, следующая за ней команда JE совершает прыжок на 0x40110E.

В противном же случае (то есть если EAX !=0) происходит выталкивание на вершину стека строки «Wrong password».

 push       offset ??_C@_0BA@EHHIHKNJ@Wrong?5password?6?$AA@

А следом — вызов функции с говорящим названием:

 call        _printf

Значит, ненулевое значение EAX свидетельствует о ложном пароле, а ноль — об истинном.
Тогда переходим к анализу валидной ветви программы, что делается после прыжка на 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

Оперативные соображения следующие: если команду JE заменить JNE, то программа отвергнет истинный пароль как неправильный, а любой неправильный пароль воспримет как истинный. А если TEST EAX,EAX заменить XOR EAX,EAX, то после исполнения этой команды регистр EAX будет всегда равен нулю, какой бы пароль ни вводился.

Дело за малым — найти эти самые байтики в исполняемом файле и малость подправить их.

Примечание: если в секции кода эталонный пароль не находится, возможно, он скрывается за шестнадцатеричным смещением. Поэтому надо сначала заглянуть в секцию данных и узнать, по какому смещению он там находится.

 00402100: 73 73 77 6F 72 64 3A 00 6D 79 47 4F 4F 44 70 61  ssword:.myGOODpa

Очевидно, нам надо выровнять смещение, чтобы пароль начинался с начала строки. Прибавим к смещению 8 — число символов, на которые надо сместить (ssword:.). В результате будем искать итоговое смещение — 402108 в секции кода. Тем самым мы найдем ту же самую инструкцию, что и прежде:

 0040107D: B9 08 21 40 00   mov       ecx,402108h

Только вместо символьной константы мы обнаруживаем шестнадцатеричное смещение в секции данных.

Хирургическое вмешательство

Как мы обсуждали выше, внесение изменений непосредственно в исполняемый файл — дело серьезное. Стиснутым существующим кодом, нам приходится довольствоваться только тем, что есть, и ни раздвинуть команды, ни даже сдвинуть их, выкинув из защиты «лишние запчасти», не получится. Ведь это привело бы к сдвигу смещений всех остальных команд, тогда как значения указателей и адресов переходов остались бы без изменений и стали бы указывать совсем не туда, куда нужно!

Ну, с «выкидыванием запчастей» справиться как раз таки просто — достаточно забить код командами 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

Ага, как раз то, что нам надо! Нажмем клавишу F3 для перевода HIEW в режим правки, подведем курсор к команде TEST EAX, EAX и, нажав клавишу Enter, заменим ее командой XOR EAX,EAX.

 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 EAX,EAX/JE 0040110E имеет хорошие шансы на уникальность. Попробуем найти в файле соответствующий ей код: 85 C0 74 63 (в HIEW для этого достаточно нажать F7).

Оп-с! Найдено только одно вхождение, что нам, собственно, и нужно. Давай теперь попробуем модифицировать файл непосредственно в HEX-режиме, не переходя в ассемблер. Попутно возьмем себе на заметку: инверсия младшего бита кода команды приводит к изменению условия перехода на противоположное, т. е. 74 JE → 75 JNE.

Работает? В смысле защита свихнулась окончательно — не признает истинные пароли, зато радостно приветствует остальные. Замечательно!

Авторы: Крис Касперски, Юрий Язев