Методы и средства обратного проектирования. Методы и средства обратного проектирования. Понятие обратного проектирования
 Скачать 183.68 Kb.
|
|
Методы и средства обратного проектирования. 1.1. Понятие обратного проектирования Основными угрозами для программного продукта, защищенным от несанкционированного использования третьим способом (ввод ключевой информации пользователем), являются угроза нарушения функциональности модуля защиты и угроза раскрытия ключевой информации. Реализация первой угрозы может заключаться в обходе либо полном отключении модуля защиты путем модификации кода программы. Реализация второй – выяснении путем исследования программы ключевой информации, требуемой при регистрации (таблица 1.1). Таблица 1.1
Наиболее распространенные способы, используемые злоумышленником при реализации первой либо второй угрозы – использование специализированных средств исследования работы программ, а также их кода. Существует несколько задач, которые злоумышленник должен решить при реализации данных угроз. 1. Задача обнаружения в коде программы модуля защиты. Следует отметить, что без использования специализированных программных средств эта задача в принципе не решаема за приемлемое время. Это обусловлено следующими обстоятельствами. Модуль защиты занимает достаточно малый объем в общей совокупности кода программы. Задача ручного поиска блока модуля защиты размером 100 – 200 байт в общем коде программы, занимающем сотни мегабайт, без использования специализированных средств в принципе не решаема за приемлемое время. Анализ кода программы в значительной степени затрудняется тем, что производится анализ не исходного текста программы на языке высокого уровня, а анализ машинного кода, сформированного компилятором. На разборку и понимание такого кода уходит значительное время даже у специалистов высокого класса в данной области. Зачастую даже анализ исходных текстов программы, написанных другим человеком, является нетривиальной задачей. Анализ же машинного кода усложняет уже задачу в тысячи раз. Недостаточно провести анализ каждой машинной команды. Как правило, при анализе машинного кода приходится увязывать в единую последовательность действий как минимум 80 – 100 байт, чтобы понять, что действительно сокрыто за данной последовательностью кодов. Как правило, это очень усложняет анализ программы. Задача исследования модуля защиты и понимания принципов его действия. Злоумышленник должен понять, каким образом построена защита, где она хранит (если хранит) ключевую информацию, где сохраняет (если сохраняет) свои метки и ключи, на каком этапе принимается решение о регистрации программы, либо об отклонении регистрации. При этом, злоумышленник сталкивается с проблемой анализа машинного кода, что приводит к трудностям перечисленным в первой задаче. Однако, исходя их вышеперечисленных трудностей нельзя делать вывод об отсутствии необходимости защиты ПО от угрозы нарушения функциональности модуля защиты и от угрозы раскрытия ключевой информации. Большой объем взломанных программ на рынке ПО говорит об обратном – что эти угрозы вполне реальны и осуществимы. Продукты фирм, пренебрегающих защитой от реализации данных угроз оказываются в числе первых из взломанных. На самом деле, сложности, перечисленные выше, для подготовленного злоумышленника в большинстве случаев таковыми не являются. Существует множество программных продуктов, позволяющих направленных на облегчение злоумышленнику решения задач 1 и 2, их решение в отдельных случаях доводится вплоть до автоматизма. Анализ задач 1 и 2 показывает, что основная цель, решаемая злоумышленником при взломе ПО – анализ работы программы, поиск в ней участка кода, отвечающего за реализацию модуля защиты, детальное исследование принципов и механизмов работы данного модуля. При этом, ставится задача представления машинного кода на как можно более высоком уровне с целью более упрощенного его понимания. Для злоумышленника наиболее оптимальный вариант – формирование по машинному коду модуля защиты, его текста на исходном языке высокого уровня, однако данный вариант практически никогда не достижим. Под обратным проектированием (reverse engineering) понимают процесс исследования и анализа машинного кода, нацеленный на понимание общих механизмов функционирования программы, а также на его перевод на более высокий уровень абстракции (более высокий уровень языка программирования) вплоть до восстановления текста программы на исходном языке программирования. Основными методами обратного проектирования являются отладка и дизассемблирование программ. При этом используются следующие средства. Отладчики – программные средства, позволяющие выполнять программу в пошаговом режиме, контролировать ее выполнение, а также вносить изменения в ход выполнения. Данные средства позволяют проследить весь механизм работы программы на практике и являются средствами динамического исследования работы программ. Дизассемблеры – программные средства, позволяющие получить листинг программы на языке ассемблера, с целью его дальнейшего статического изучения. Дизассемблеры являются средствами статического исследования. Мониторы событий – программные средства, позволяющие отслеживать определенные типы событий, происходящие в системе. Наиболее опасными для программного обеспечения с точки зрения их защиты являются мониторы операций с реестром и мониторы файловых операций, позволяющие проследить – какая программа куда и что записывала, считывала и т.д. Редакторы кода занимают отдельное место среди средств обратного проектирования. Данные средства, как правило, включают функции дизассемблирования, но позволяют также вносить изменения в код программы. Данные средства предназначены, в основном для исследования программ, занимающих сравнительно небольшой объем. Таким образом, классификацию средств обратного проектирования ПО можно представить в виде следующей схемы (рис. 1.1).  Рис. 1.1. Классификация средств обратного проектирования Иначе говоря, средства динамического исследования ПО, позволяют исследовать работу программ в процессе их работы в реальном времени, а также вносить изменения в их работу. С другой стороны, средства статического исследования ПО предназначены для исследования кода ПО в режиме оффлайн. 1.2. Основные приемы, используемые злоумышленником при отладке и дизассемблировании программного обеспечения Следует отметить, что любую систему защиты ПО можно вскрыть за конечное время. Это следует из того, что ее команды однозначно интерпретируются процессором. Как правило, если программа защищена только от средств статического анализа, то она легко изучается динамически, и наоборот. Используя методы и средства обратного проектирования, взломщик может использовать различные уязвимости модулей защиты, которые не посчитал должным образом защитить разработчик программы. Как правило, чисто программные модули защиты ПО работают на основе следующих методов. Проверка правильности введенной ключевой информации при регистрации программного продукта. Проверка на истечение временного срока работы программы при ее запуске или ограничения по количеству ее запусков. Приемы осуществления атак взломщиком на данные методы, в общем-то, схожи, однако, имеют и свою специфику при реализации. Следует отметить, что без принятия мер к защите программных модулей защиты, последние могут быть легко обнаружены и вскрыты, либо отключены. Рассмотрим специфику атак на представленные методы. 1.2.1. Специфика атак на модули проверки корректности ключевой информации Для вскрытия данного типа защит в первую очередь необходимо найти в коде программы код модуля защиты и, а в нем – процедуру данной проверки. В большинстве программных продуктов, проверка корректности ключевой информации выполняется непосредственным образом. При этом, исходный текст программы выглядит, приблизительно, следующим образом. If (!ValidUser()) { Message (“Неверный пользователь”); Abort; } Здесь, ValidUser() – базовая процедура проверки. Ключевая информация может вводиться пользователем как в данной процедуре, так и ранее. Данный исходный текст компилируется компиляторами в код, аналогичный следующему: PUSH AX CALL IsValidUser; POP AX OR AX, AX JZ continue PUSH offset str_invalid_user CALL Message CALL Abort Continue:…… В данном коде команда CALL IsValidUser осуществляет вызов процедуры IsValidUser. Передача в данную процедуру параметров (например, ссылки на ключевую информацию) осуществляется через стек командами PUSH (занесение параметра в стек) до команды CALL и POP (вызов из стека результата, возвращенного процедурой IsValidUser) после команды CALL. В представленном примере результат выполнения процедуры IsValidUser заносится в регистр AX. В дальнейшем производится проверка на равенство нулю возвращенного результата (команды OR AX,AX). Если AX=0, то ключевая информация верна, производится ее регистрация и дальнейшее продолжение работы (JZ continue). В ином случае выводится сообщение о невозможности продолжения работы (PUSH offset str_invalid_user; CALL Message) и завершение работы программы (CALL Abort). В данной ситуации, после обнаружения представленного выше программного кода модуля защиты, взломщик может осуществить атаку следующим образом. Заменить команду условного перехода JZ continue на команду безусловного перехода JMP continue. В данном случае, регистрация программы будет осуществляться в любом случае, вне зависимости от правильности ввода ключевой информации. Изменить в процессе работы программы содержимое регистра AX после команды POP AX, либо значение регистра флагов после команды OR AX,AX. В данном случае, злоумышленник вынужденно заставляет модуль защиты работать по нужной ветке. Исследовать работу процедуры IsValidUser вручную с целью выяснения ключевой информации. Реализация первых двух типов атак называются «жестким» взломом программного продукта, так как он требует модификации кода программы. Реализация третьего типа атак называется «мягким» взломом программного продукта и во многих случаях является более предпочтительной для злоумышленника, хотя и требует от него несколько больших временных затрат. Первые два типа взлома позволяют осуществить взлом программного продукта в достаточно короткие сроки, не прилагая к этому слишком больших усилий (одна из таких защит была взломана в течение 10 секунд). Достоинством для злоумышленника третьего типа взлома заключается в том, что иногда исследовав логику работы процедуры IsValidUser, можно не только вычислить ключевую информацию, но также написать и генератор ключевой информации для последующего использования другими пользователями. Это возможно сделать, если разработчик вложил в модуль защиты непосредственную связь между идентификатором пользователя и его аутентификатором (ключевой информацией). Кроме этого, достоинством третьего типа взлома является то, что получив ключевую информацию, злоумышленник снимает все проблемы, тогда как «жесткий» взлом иногда для злоумышленника затруднителен в силу того, что проверка корректности осуществляется в нескольких местах программы и различными способами. В процессе анализа процедуры IsValidUser особое внимание уделяется следующим элементам. 1.Информации, передаваемой в процедуру IsValidUser в качестве параметров и возвращаемой из нее. 2.Содержимому регистров, передаваемых в другие процедуры, вызываемые из процедуры IsValidUser. Содержимому памяти по адресам, передаваемым в процедуру IsValidUser и процедуры, вызываемые из нее. Содержимому памяти по адресам, в которые заносятся идентификатор пользователя и введенная им ключевая информация (например, пароль), а также обращение к данным адресам из функции IsValidUser. Отслеживание обращений к этим адресам позволит более локализовать код, отвечающий за проверку адекватности ключевой информации. Довольно часто злоумышленником производится исследование содержимого ОЗУ на осмысленные последовательности символов, а также отслеживание обращений к адресам, по которым хранятся эти последовательности (например, “Invalid Registration”, “Password Fail” и т.д.). Как правило, эти сообщения находятся недалеко от модулей защиты, отвечающих за проверку корректности ключевой информации. По обращению к адресам, хранящим данные сообщения также можно локализовать код проверки адекватности ключевой информации. Как правило, передача параметров в функции и их возврат осуществляется через 32-битные регистры EAX,EBX, а также используя регистры ESI и EDI для указания на используемые данные. 1.2.2. Специфика атак на модули проверки истечения временного срока работы программы или ограничения по количеству ее запусков Взлом данных модулей во многом практически аналогичен взлому модулей проверки корректности ключевой информации. Специфика взлома здесь состоит в том, что у данных модулей появляются дополнительные уязвимости, которые могут быть использованы злоумышленником. Программные продукты, защищенные данными модулями используют, как правило, некоторые файлы конфигурации для хранения информации о числе запусков или даты установки (это, как правило, конфигурационные файлы программы, конфигурационные файлы Windows, либо реестр). В некоторых случаях взлом сводится к изменению данной информации в соответствующих файлах. В некоторых случаях, работа модулей защиты данных программ неустойчива к изменению системной даты. В данном случае, перевод системного времени на более ранний срок позволяет обойти защиту. Данные модули защиты используют специфические функции работы с файлами и с системной датой, обращение к которым можно отследить с помощью современных средств отладки. Использование первых двух уязвимостей является, по сути, обманом модуля защиты и относится к «жесткому» взлому. Третий тип уязвимостей злоумышленник может использовать точно также, как и при вскрытии модуля проверки корректности ключевой информации. 1.2.3. Отлов злоумышленником вызова WinAPI функций при взломе ПО Одна из основных задач, которую необходимо решить злоумышленнику при реализации взлома – локализовать модуль защиты в коде программы. Грубая локализация данного модуля решается без существенных затрат с помощью современных средств отладки программного обеспечения. В случае взлома Windows – приложения данная задача решается практически мгновенно путем отслеживания вызовов WinAPI функций, используемых разработчиком. Использование стандартных WinAPI функций является неотъемлемым стилем программирования Windows-приложений в настоящее время. Практически любое приложение для осуществления стандартных действий (вывод на экран сообщений, доступ к тексту редактируемого окна, доступ к файлам и т.д.) использует вызовы данных функций. Основная проблема для разработчиков средств защиты заключается в том, что современные отладчики позволяют без особых проблем установить точки прерывания по условию вызова известных им функций. Таким образом, злоумышленник может получить доступ к программному коду, находящемуся около места данного вызова, после чего продолжить изучение данного кода с помощью средств отладки. Пример 1.1 Реализация модуля защиты ПО предусматривает вывод на экран сообщения (MessageBox) о неудачной регистрации в случае неверного ввода серийного номера. В данном случае злоумышленник может установить в отладчике точку останова на вызов функции MessageBox непосредственно перед вводом серийного номера, ввести произвольный серийный номер (однозначно неверный, чтобы сработала функция выдачи сообщения о неудачной регистрации) и тем самым выйти на программный код, осуществляющий вызов данной функции, а значит и на модуль защиты. Дальнейший взлом превращается только в дело техники. Установка точки прерывания по вызову некоторой API функции в отладчике SoftIce осуществляется с помощью команды bpx адрес или bpx имя_API_функции. Удаление точки установка – с помощью команды bc имя_API_функции. Например, для установки точки прерывания по выводу стандартного окна сообщения, можно попытаться воспользоваться командой bpx MessageBoxA. Более полный перечень функций отладчика SoftIce и приемы работы с ним представлены в приложении 6.1. В коде программы вызов API функции представляется в виде CALL Имя_API_функции, ее аргументы передаются через стек в обратной последовательности. Возвращаемое значение передается, зачастую, через регистр EAX (если оно одно). Например, при вызове из программы функции MessageBoxA(hWnd,lpText,LpCaption,uType), она может откомпилироваться в следующий код. … push 20; передача аргумента uType push 00400010; передача аргумента lpCaption push 0044003E; передача аргумента lpText push ebx; передача аргумента hWnd call User32!MessageBoxA; вызов функции MessageBoxA из модуля User32 При отлове WinAPI функций необходимо учитывать тип приложения и ОС. Win32 API функции имеют, как правило, на конце приставку A, а Win16 – без A. Это позволяет злоумышленнику сократить набор отлавливаемых функций. Подчеркнем, что если даже злоумышленник не знает, с помощью какой API функции осуществляется реализация того или иного действия (например, чтение текста из окна ввода), то ограниченность возможных вариантов перебора функций, осуществляющих данное действие, значительно облегчает задачу взлома. Как правило, количество функций, которые необходимо перебрать злоумышленнику для выхода на модуль защиты не превышает 3–4. Попытка использования производителем менее распространенных API функций практически не повышает защищенность продукта. Наиболее распространенными Win32 API функциями, используемыми производителями для выполнения стандартных действий, являются следующие. 1. MessageBoxA(hWnd,lpText,LpCaption,uType) – вывод на экран стандартного окна сообщения (например, сообщения об ошибочной регистрации). 2. MessageBoxIndirectA(lpMsgBoxParams) – вывод вариантов окна, с различными кнопками (retry, abort, ignore). 3. GetDlgItemTextA(hDlg,nIDDlgItem,lpString,nMaxCount) – использует-ся для чтения информации, введенной пользователем в окне TEdit. В качестве параметров указываются дескриптор диалогового окна, идентификатор элемента управления в окне, буфер для записи читаемого сообщения, длина сообщения. 4. GetWindowTextA(hWnd,lpString,nMaxCount) – чтение информации, введенной пользователем в окне TEdit. В качестве параметра указывается дескриптор окна, буфер для чтения сообщения и его длина. Функции GetDlgItemTextA или GetWindowTextA могут использоваться разработчиком в модуле защиты для чтения ключа, введенного пользователем в окне ввода. Многие модули защиты следом за этим производят сравнение введенной информации с требуемой. В этом случае, отлов данных функций позволит злоумышленнику получить доступ к программного коду проверки ключа непосредственно. В качестве менее распространенной функции, выполняющей чтение информации из окна TEdit, можно привести следующую. 5. hmemcpy(lpMemTarget,lpMemSource,nBytes) используется Windows для копировании участков памяти, а значит может использоваться и при копировании идентификатора из введенного окна. Отлавливать и исследовать программу по вызову данной функции будет сложнее для начинающих крэкеров, но возможно, если иметь в этом навык. Сложность здесь представляет то, что, как правило, точка останова будет находиться очень глубоко в программе и потребуется потратить определенные усилия, прежде чем злоумышленник доберется собственно до места вызова процедуры проверки корректности ключа. Прежде, чем дойти до этой точки, придется выходить из очень многих вложенных процедур. Следует отметить, что точка прерывания по данной функции в отладчике ставится злоумышленником строго после ввода произвольного ключа в окне ввода, так как данная функция вызывается самой системой Windows при нажатии любой клавиши, но только самой системой Windows (для копирования информации в окно). Замечания. Установка точки прерывания на функцию hmemcpy позволяет злоумышленнику локализовать модуль защиты практически во всех случаях, однако, для облегчения взлома, им может быть использован трюк, основанный на том, что производитель выводит окно сообщения, если поле ключа оставляется пустым. Установив точку прерывания на MessageBoxA и оставив пустым поле ввода серийного номера, злоумышленник вновь выходит на модуль защиты без привязки к функции htmemcpy. В некоторых случаях, пока пользователь не введет верный код, кнопка ОК окна регистрации вообще неактивна, тогда использование прерываний по функциям MessageBoxA, MessageBoxIndirectA, GetDlgItemTextA, GetWindowTextA бесполезно. В данном случае злоумышленник вынужден пользоваться hmemcpy. 6. LoadString (hInstance,uID,lpBuffer,nBufferMax) – чтение строки из файла ресурсов и копирование ее в некоторый буфер. В качестве параметров функции указываются дескриптор модуля, номер строки в файле ресурсов, указатель на буфер, размер читаемой строки. 7. GetTickCount() – возвращает число миллисекунд со времени запуска системы. Данная функция часто используется разработчиками для реализации защиты (в демонстрационных программах и программах shareware), выражающейся в том, что в незарегистрированной версии программы через определенные промежутки времени появляется информация, убрать которую невозможно в течении некоторого время (nag screen). Отловив вызов данной функции, злоумышленник выходит на процедуру реализации данной защиты и отключает ее. 8. В некоторых незарегистрированных версиях ПО, разработчик может отключить отдельные функции и не позволять их включать вплоть до регистрации. После регистрации, данные функции включаются. В данном случае, один из методов атаки может осуществляться на процедуру, включающую отключенные опции. Как вариант этой атаки, можно привести отлов API функции EnableWindow(hWnd,bEnable). 9. GetDriveTypeA(lpRootPathName) – возвращает тип диска (например, 3- HDD, 5- CD). Разработчик ПО может использовать данную функцию для привязки своего ПО к CD (для предотвращения запуска с винчестера). Отловив вызов данной функции, злоумышленник может проставить тип диска вручную либо отключить механизм проверки. 10. RegCreateKeyEx(hKey, lpSubKey, Reserved, lpClass, dwOptions, samDesired, lpSecurityAttributes, phkResult, lpdwDisposition)– создание ключа в системном реестре. Достаточно часто используется производителями ПО для сохранения в реестре служебной информации (пароля, даты установки программы, количества запусков и т.д.). Отловив вызов данной функции, злоумышленник может раскрыть и получить доступ к конфиденциальной информации либо отключить механизм проверки ключа. 11. Функция SetTimer() и сообщения WM_Timer. Их отлавливание может использоваться злоумышленником для взлома программ, защищенных выводом nag-screen. 12. FindFirstFile(lpFileName,lpFindFileData) – осуществляет поиск в директории файла с заданным именем. Может использоваться злоумышленником для взлома программ, сохраняющих конфиденциальную информацию в служебных, системных, скрытых файлах, файлах инициализации и т.д. Для этих же целей может использоваться отлов функции FindNextFile(hFindFile,lpFindFileData) на вход данных функций передается имя (либо дескритор) файла и информация о нем. Злоумышленник отловив данные функции может вычислить информацию о файлах, где хранится ключевая информация. 1.3. Мониторинг событий Средства мониторинга событий - утилиты, отслеживающие операции, производимые программным обеспечением над файлами, реестром, портами, а также отслеживающие потоки системных сообщений. Программы, выполняющие слежение над файловыми операциями и операциями с реестром Windows, представляют собой мощный инструмент для злоумышленника при взломе программных защит. Их использование помогает ему намного быстрее понять принцип функционирования модуля защиты ПО, локализовать его в коде программы, и в дальнейшем – атаковать его. Средства мониторинга файловых операций и операций с реестром используются злоумышленником в первую очередь для решения следующих задач. Для вычисления файлов, в которых модуль защиты хранит для себя служебную, ключевую информацию, цифровые подписи, и т.д. Для вычисления секретных недокументируемых файлов, в которых модуль защиты хранит конфиденциальную информацию. Такие файлы иногда используются в слабых программных защитах и, как правило, хранятся во временных либо системных папках. Для вычисления тех файлов, в которые модуль защиты записывает информацию при установке ПО. Как правило, это бывает необходимо для снятия защит, ограничивающих функционирование во времени использования. Для вычисления записей в системном реестре Windows, в которых модуль защиты сохраняет служебную информацию при регистрации. Это также бывает необходимо, при снятии защит по времени использования. Кроме этого, некоторые разработчики защит ПО довольно часто в реестр записывают конфиденциальную информацию (например, ключи), что, вообще говоря, делать строго не рекомендуется. Как правило, злоумышленник атакует модуль защиты с помощью мониторов событий следующим образом. Запуск монитора файловых операций и монитора операций с реестром. Установка защищенного ПО при запущенном мониторе файловых операций и мониторе операций с реестром. В данном случае злоумышленник решает задачу обнаружения тех файлов и записей в реестре, в которых модуль защиты сохраняет служебную информацию в процессе установки. После выполнения данного шага злоумышленник исследует протоколы, сформированные мониторами и вычисляет необходимые файлы и записи реестра. Данный шаг используется, как правило, для атаки на защитные механизмы ограничения по времени использования и по количеству запусков. 3. Если программа обращается к реестру и файлам в процессе своей работы, то злоумышленник запускает программу при запущенных файловом мониторе и мониторе реестра и исследует ее протокол. Данный шаг используется, как правило, для атаки на защитные механизмы ограничения по времени использования, по количеству запусков, для взлома защит, хранящих ключи, пароли и другую конфиденциальную информацию во внешних файлах. 3. С использованию средств отладки или редактора кода осуществляется выход на модуль защиты, из которого выполняется обращение к файлам и к реестру. 4. Отключение защитных механизмов. Наиболее известным мониторами файловых операций и операций с реестром являются FileMon и RegMon Марка Руссиновича. Файловый монитор FileMon предоставляет широкий спектр возможностей для пользователя и позволяет протоколировать не только те файлы, к которым велось обращение, но также и функции, которые при этом использовались: FindOpen, FindFirst, FindNext и т.д., время, результат операции, детализированная информация по передаче и т.д. В утилиту включены средства фильтрации, позволяющие осуществлять поиск по фильтру в протоколируемых данных (рис. 1.2). Рис. 1.2. Диалоговое окно работы с программой Filemon  Монитор операций с реестром Regmon позволяет отслеживать приложения, выполняющие операции с реестром, выполняемые операции, путь, по которому ведется обращение, результат операции, а также детализировать выполняемый запрос (рис. 1.3). Рис. 1.3. Диалоговое окно работы с программой Regmon З  лоумышленником для взлома защит ПО могут быть эффективно использованы, также, стандартные утилиты, входящие в дистрибутивные пакеты различных продуктов. Очень эффективным средством для злоумышленника является монитор spy++, входящий в поставку Microsoft Visual C++. Данный монитор может предоставить злоумышленнику достаточно много информации о приложениях, запущенных в системе, а также об их взаимодействии. Он способен предоставить следующую информацию в хорошо структурированном виде:1. Подробную информацию об открытых окнах и о приложениях, которые открывают данные окна. При этом, для каждого окна приложения, открытого в системе, предоставляется следующая информация: описание окна, дескриптор окна, размеры, класс окна, стиль окна (CHILD, VISIBLE, …), ссылки на родительские и дочерние окна, информацию о меню, иконках курсорах в окнах и т.д. 2. Информация о запущенных в системе процессах. 3. Информация об используемых в системе потоках. 4. Отлавливать и протоколировать все сообщения, возникающие в системе (WM_GetText, WM_PAINT и т.д. (всего более 660)). При этом, можно поставить фильтр на отлавливание сообщений с множеством настроек – для каких окон, для каких приложений, какие сообщения отлавливать и т.д. Существует возможность отлавливать сообщения по их группам. Всего выделено 32 группы, наиболее важные из них для злоумышленника – группы General, KeyBoard, Dialog, AFX/MFC, Registered, Edit Field. Если злоумышленнику, например, не известно, с помощью каких функций осуществляется чтение пароля из окна ввода, то установив фильтр на все сообщения такого рода и исследовав сформированный протокол, можно достаточно быстро получить необходимую информацию, и использовать ее при реализации взлома. |