Что такое application verifier

Отлаживаем ошибки доступа к памяти с помощью Application Verifier

Хабраюзер burdakovd задал в Q&A задачку про C++, vector и запись в чужую память. Задачка, кроме всего прочего, хороша тем, что на ней можно удобно продемонстрировать, как пользоваться инструментом Application Verifier и находить, кто же портит память.

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

Инструменты

Кроме Application Verifier нам понадобится WinDBG — бесплатный отладчик, входящий в Microsoft Debugging Tools for Windows. Debugging Tools раньше можно было скачать отдельно, а сейчас почему-то только в составе Windows SDK или Windows Driver Kit. Но всё ещё можно скачать отдельно Previous Version, которая для наших задач отлично подойдёт. Ну или вот я выложил свежие версии (6.12.2.633), чтобы не качать весь SDK: dbg_x86.msi, dbg_amd64.msi.

Ещё понадобится Visual C++ (любой версии, новее, пожалуй, VS2003, можно Express) либо компилятор C++ из Windows SDK. Нужен именно компилятор от Microsoft, а не MinGW, потому что нам понадобится отладочная информация в формате PDB, которую понимает WinDBG.

Собираем пример

Исходник берем в упомянутой выше задачке (копия на pastie). Собираем обязательно с отладочной информацией (ключи /Zi или /ZI для компилятора и /DEBUG для компоновщика) и отключенной оптимизацией. Командная строка для сборки из консоли будет выглядеть примерно так:
cl /D_DEBUG /Zi /Od /EHsc /DEBUG /MDd vector_misuse.cpp

Настраиваем Application Verifier

Настраиваем отладчик

Находим причину падения

После того, как мы запустим программу, она упадёт с Access Violation.

Смотрим стек — View Call Stack (или Alt+6 или kp в приглашении) и видим, что упало в функции f, на втором уровне вложенности. Чтобы в окошке Call Stack было видны аргументы функций жмём кнопку Source args. Чтобы было видно ссылки на строки кода жмём кнопку Source. Команда kp выведет эту информацию в окошко Command отладчика. Также должно открыться окошко с исходным текстом и в нём подсветиться текущая строка.

Отладчик вывалит нам простыню текста, из которой нам интересны следующие вещи:
DEFAULT_BUCKET_ID: INVALID_POINTER_READ — попытка прочитать по невалидному указателю
READ_ADDRESS: 060a0ff4 — собственно сам адрес, по которому мы пытались прочитать.

Также будет распечатан коллстек, который мы уже видели и даже кусок исходника с помеченной строкой, где случилось исключение.

Это всё конечно очень интересно, но хотелось бы узнать, а почему эту память нельзя читать? Благодаря настройкам, которые мы сделали в AppVerifier, система при каждом выделении и освобождении памяти собирала коллстеки и бережно сохраняла, чтобы потом по нашей просьбе любезно предоставить.

Итого

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

Источник

Application Verifier (Windows 7 and Windows Server 2008 R2 Application Quality Cookbook)

Affected Platforms

Description

Promote and enforce Application Verifier as a quality gate for all development. It includes several improvements:

These changes should have no negative impact on users who do not enable the Thread Checks; those who do should receive additional support in discovery and diagnosis of existing thread-pool usage problems. Whether or not you enable Thread Checks, you will benefit from the other improvements and bug fixes in this service.

While there is a slight performance penalty when using this service, the performance levels should remain acceptable because it does not typically run in retail environments.

Usage

General Information

To deliver reliable Windows applications:

Thread-pool checks are enabled by default under the «Basics» check heading. As this is included in the default setting, users need only to run Application Verifier on their code with the default settings to leverage the new checks.

Details

At a minimum, you should run Application Verifier with the Basics setting selected. This is required for WinLogo and WinQual. The Basics setting checks for the following:

If your application is migrating from a «Pre-Vista» application, you will want to leverage the «LuaPriv» (also known as UAC checks). The Limited User Account Privilege Predictor (LuaPriv) has two primary goals:

LuaPriv identifies the following types of problems:

Commonly overlooked issues are captured in the nebulous Misc Checks:

We have added a new Print Verifier. This layer helps find and troubleshoot issues that may result when an application calls the print subsystem. Print Verifier targets the two layers of the print subsystem, the PrintAPI layer and the PrintDriver layer.

Print Verifier tests the interface between a program and Winspool.drv and prntvpt.dll and tests the interfaces of those DLLs. You can review the rules for calling functions in this interface in the MSDN help section for APIs exported by winspool.drv and prntvpt.dll.

Print Driver Layer

Print Verifier also tests the interface between a core print driver such as UNIDRV.DLL, UNIDRUI.DLL, PSCRIPT5.DLL, PS5UI.DLL, or MXDWDRV.DLL, and the print driver plug-ins. You can find information about this interface in the MSDN and the WDK.

Note that some of these checks are for Windows 7 only, and others will simply perform better under Windows 7.

Typically, only debug versions run the Application Verifier, so performance is not generally an issue. If performance issues arise from the use of this, or any other Application Verifier check, run one check at a time until you have performed all needed checks.

Nearly 10% of application crashes on Windows systems are due to heap corruption. These crashes are nearly impossible to debug after the fact. The best way to avoid these issues is to test with the Page Heap features found in Application Verifier. There are two flavors of Page Heap: «Full» and «Light.» Full is the default; it will force a debugger stop instantly upon detecting corruption. This feature MUST be run while under the debugger. However, it is also the most resource demanding. If a user is having timing issues and has already run a scenario under «Full» Page Heap, setting it to «Light» will likely address these issues. Additionally, Light Page Heap does not crash until the process exits. It does provide a stack trace to the allocation, but can take considerably longer to diagnose than leveraging its Full counterpart.

Monitor the reliability status of the applications via the Winqual web portal. This portal shows the error reports collected via Windows Error Reporting, so it is easy to identify the most frequent failures. Learn about this at Windows Error Reporting: Getting Started. Microsoft does not charge for this service.

To take advantage of WinQual, you must:

One further note: Application Verifier is only as good as the code paths you run it against. The value of combining this tool with a code coverage tool cannot be overstated.

Links to Other Resources

Debugging Tools for Windows:

Application Verifier:

Note: the Application Verifier version that ships in Visual Studio is quite dated. If possible, use the standalone package instead. For this reason, future versions of Visual Studio will no longer have embedded Application Verifier.

Источник

Application Verifier для программиста: тестирование Windows-приложений

Возможно в Вашем проекте и не пишут try < /* code */ >catch (. ) < >для того чтобы избежать исключений при работе с памятью, умеют закрывать хендлы и знают о виртуализации Windows Vista, а программы никогда не падают по непонятным и редко повторяемым причинам.

Тогда Вам повезло, можете переходить к следующему топику.

Но иногда происходят, казалось бы, странные вещи. Программа «падает» на ровном месте, память куда-то утекает, а еще один раз вам звонили с жалобой на странное поведение программы, работающей на сервере 24/7, но вы конечно «завернули» их проблему, убедив, что она аппаратно-зависимая, и ладно. Всё-таки разработка программ под Windows дело нередко хитрое, и от ошибок по невнимательности или из-за незнания архитектуры никто не застрахован. Я не буду учить, как этих ошибок не допускать — сам не знаю. Но вот одно средство для эффективной отладки могу посоветовать.

Речь пойдет о Microsoft Application Verifier. Но это не отладчик. Напротив, без отладчика, сама по себе, штука относительно бесполезная. А вот в совокупности с ним позволяет детектировать ряд важных платформо-зависимых проблем. Кроме того, не удастся получить сертификат «Сompatible with windows 7» без прохождения тестирования с использованием AppVerifier (собственно для “Vista Certified” так же, но об этом, видимо, говорить не принято). А этот сертификат — для пользователя некоторая гарантия, что получившая его программа, может лучше и не сделает, но хотя бы не навредит. Ладно, «вода» закончилась, приступим к делу.

Способ применения

Скачать и установить AppVerifier для Хаброчеловека, уверен, не сложность. Запустим (из под real-администратора, под Vista+ по-другому и не выйдет) его графическую оболочку:

Слева список приложений для тестирования; справа – список секций на проверку для выбранного приложения. В MSDN утверждается, что AppVerifier предназначен для тестирования программ на C++, но в целом применим для любого native кода.

Графическая оболочка не производит никаких тестов, только дает возможность выбора нужных пунктов. Сами проверки реализуются благодаря так называемым «слоям», динамически подключаемым библиотекам vfbasics, vfcompat, vfLuaPriv, vfprint (на них можно полюбоваться в папке system32 ). При запуске тестируемого приложения они подключаются к нему и перехватывают вызов системных функций, таких как HeapAlloc, GetTickCount, CloseHandle и многих других. Перехватчик производит ряд дополнительных проверок, затем вызывает оригинальную функцию, и поэтому, за исключением нескольких рассматриваемых далее случаев, это не скажется на работе тестируемого приложения. Разве что будет заметна некоторая потеря производительности. Субъективно в худшем случае программа «замедлится» в пять раз, а нужны ли какие-нибудь конкретные цифры или нет – оставлю на ваше усмотрение.

Здесь есть важная особенность: несмотря на то, что мы при добавлении выбираем файл тестируемого приложения, проверки привязываются только к его имени без пути. С одной стороны, можно не беспокоиться в какой конфигурации (и в какую папку) собирать проект (обычно папки для Debug и Release разные), но с другой – можно забыть об установленных проверках, и запуская программу с рабочего стола, удивляться, что она «не работает».

Про смысл тест-пунктов поговорим чуть позже, а сейчас добавим, к примеру notepad.exe и установим все галки. Запустим блокнот, добавим пару строчек, попробуем сохранить. О-па, неудача:

Не единственный исход ситуации, возможно, вы получите другое окно предупреждения, или вообще обойдется без него. Что же случилось? Обратимся снова к графической надстройке AppVerifier. На сей раз выберем пункт Logs из главного меню, увидим список лог-файлов ассоциированных с тестируемыми приложениями. По логу на запуск.

Физически эти лог файлы находятся в папке AppVerifierLogs в корне пользовательского профайла. Прочитать их голыми руками будет трудно (бинарный формат), поэтому тыкаем кнопочку “View” для соответствующего лога. Произойдет его дамп в xml и открытие дефолтной программы просмотра для xml:

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

Тут и краткое описание проблемы, и stack trace. И от меня подсказка, как искать ошибки, а не предупреждения. Кстати сказать, если ошибки присутствуют, то программа не получает сертификации на совместимость с Vista/Win7. Постойте, но это же блокнот?! Ну да, только тссс.

Лечение больного

Теперь запускаем отладчик. Пусть это будет отладчик, встроенный в студию, или бесплатный WinDbg из состава Debugging Tools for Windows (он конечно более навороченный, но сейчас это не имеет значения).

А вот и наш больной:

int _tmain( int argc, _TCHAR* argv[])
<
int *p = new int ();
delete p;
*p = 0; // p = 0 will be OK, but *p = 0 is error!
>

Потенциальную опасность этого фрагмента легко оценить, если бы строки с delete и перезаписью памяти были растянуты по времени. Но ни в дебажной, ни в релизной сборке такая проблема не детектируется (Visual Studio, конфигурация по умолчанию).

Теперь добавляем программу на тестирование группы Basics в Application Verifier. И запускаем её из под отладчика (из студии по F5, например). AppVerifier заговорил с нами голосом студии:

А в Debug Output показывается соответствующее структурное исключение:

=======================================
VERIFIER STOP 00000013: pid 0xB54: First chance access violation for current stack trace.

02B59FF8 : Invalid address causing the exception.
0082142F : Code address executing the invalid access.
0013F670 : Exception record.
0013F68C : Context record.

Оно рассказывает, что за исключение (00000013), с каким адресом памяти (02B59FF8) и по какому адресу кода (0082142F) произошло. Счастливчикам, скачавшим Windows Debug Symbols покажут и место в исходном коде, где произошла проблема и Stack Trace, который привел к исключению.

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

Детектируемые проблемы

Давайте теперь разберемся, какие проблемы позволит выявить нам AppVerifier. Все опции тестирования разделены на группы. Исключая группу «Low Resource Simulation» и тестов «TimeRollOver» и «HighVersionLie» проверки не меняют поведения приложения (в случае, если не будет обнаружено ошибок).

1. Искажающие проверки

1.1. Low Resource Simulation

Вот она причина падения блокнота. Тесты этой группы позволяют смоделировать поведение системы при нехвате ресурсов. Приложению запросто могут отказать (по датчику случайных чисел) в выделении памяти, создании файла, Event’а, окна, записи в реестр. Обычно есть некоторое «спокойное» время около 2-5 секунд, когда приложению разрешается пользоваться ресурсами в полную силу; сделано это, чтобы приложение вообще смогло запуститься (это придумали не так давно, раньше было грустнее). Нормальным поведением программы является стабильность; показ предупреждающих диалогов, но не «падения». Так что в коде нужно бы предусматривать данные ситуации.

1.2. TimeRollOver в группе Misc

DWORD time_end = GetTickCount() + 1000; // 1s timelimit
do < action(); >while (GetTickCount()

И это не единственный случай, что Вы скажете про следующий фрагмент?

Для диагностики подобных проблем проверка TimeRollOver «прогоняет» значение функции GetTickCount() быстрее. Полный цикл до обнуления значения проходит за 5 минут.

1.3. HighVersionLie в группе Compatibility

OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof (OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
GetVersionEx(&osvi);

BOOL bIsWindowsXP_or_Later = (osvi.dwMajorVersion >= 5) && (osvi.dwMinorVersion >= 1);
if (!bIsWindowsXP_or_Later)
printf( «Windows XP or later required.\n» );

В данном фрагменте допущена явная ошибка; с целью отсечь Windows 2000 (5.0) вводится дополнительная проверка на minor версию XP (5.1), но код также отбрасывает и Windows Vista (6.0). На Windows 7 (6.1) работать будет. Неужели это и есть причина плохой совместимости с Windows Vista? Microsoft утверждает, что 70% несовместимых с Vista программ не работают в том числе и из-за этой проблемы.

Но диагностика такой ситуации на компьютере разработчика затруднительна — у него одна, фиксированная версия ОС. Можно воспользоваться виртуальной машиной с другой версией ОС, а можно просто ткнуть галку HighVersionLie. Тогда значение GetVersionEx будет модифицировано (обычно по правилу dwMajorVersion += 3; dwMinorVersion = 0 ).

2. Немодифицирующие проверки

2.1. Memory в группе Basics

Проверка корректности вызовов HeapAlloc, GlobalAlloc и других API Windows Heap Manager. За утечками памяти не следит, но это можно решить другими способами.

2.2. TLS в группе Basics

Следит за корректностью вызовов Thread Local Storage API.

2.3. Exceptions в группе Basics

Следит за уместностью перехвата исключений, в частности попытки «заглушить» исключения Access Violation, «демаскирует» исключения в заглушках вида try < >catch (. ) < >.

2.4. Handles в группе Basics

Следит за допустимостью операций над хендлами, корректностью хендлов и их временем жизни. Чуть подробнее на английском.

2.5. Locks в группе Basics

Проверяет корректность использования критических секций, не допускает сброс критической секции из другого потока относительно установки критической секции.

2.6. DirtyStacks в группе Misc

Периодически заполняет неиспользуемую часть стека паттерном 0xCD, что позволяет обнаруживать неинициализированные переменные или параметры функций.

2.7. DangerousAPIs в группе Misc

2.8. LuaPriv

Limited-user-account privileges test. Проверяет, нужны ли программе административные привилегии, не выполняет ли программа действий, которые допустимы только для real-администратора.

Состоит из двух частей: предсказывающей (перечисляет все действия программы, которые может выполнить только администратор) и диагностической (отказывает программе в административных действиях с ошибкой ACCESS_DENIED ). Таким образом, программисту не обязательно тестировать программу отдельно логинясь гостем. Также проверяет ряд особенностей связанных с виртуализацией под Windows Vista и старше.

Заключение

AppVerifier — интересный инструмент, позволяющий выявить и решить ряд «плавающих» и «скрытых» (а иногда и специально спрятанных) проблем. Пользоваться им в целом не сложно, при определнных навыках — удобно. А если вы хотите получить сертификат «Windows compatible», то знакомства с ним не избежать. Лично мне помог уже на двух проектах, надеюсь будет полезен и Вам.

Источник

UPD. Microsoft Application Verifier может заставить антивирусы выполнять вредоносные действия

Linux для хакера

Специалисты компании Cybellum разработали новую технику атак, получившую имя «Двойной агент» (DoubleAgent). Этот метод позволяет обмануть защитные решения и другие приложения, заставив их выполнять вредоносные действия. Причем главным инструментом для реализации атаки выступает абсолютно легитимный инструмент Microsoft Application Verifier.

Как не трудно догадаться, Microsoft Application Verifier был создан специалистами самой Microsoft и предназначен для разработчиков: с его помощью они могут протестировать свои приложения и обнаружить ошибки. Инструмент поставляется вместе со всеми версиями Windows, начиная со времен Windows XP. Исследователи Cybellum объясняют, что Application Verifier в частности создан для поиска багов, связанных с нарушением целостности памяти и других критических уязвимостей, а проблема заключается в том, как инструмент работает с DLL.

Во время работы Application Verifier загружает так называемый «verifier provider DLL» в процесс тестируемого приложения. После создания DLL добавляется в реестр Windows, как provider DLL, после чего Windows автоматически осуществляет инъекцию DLL в соответствующие процессы. По данным Cybellum, всё это злоумышленник может обратить в свою пользу, заменив стандартный verifier своим собственным. Так, после простых манипуляций с реестром и предоставления своего собственного DLL, атакующий может внедриться в работу любого легитимного приложения.

Данный трюк работает и против ряда антивирусов. Исследователи пишут, что сообщили о проблеме всем производителям уязвимых защитных решений, выждали положенные 90 дней и до сих пор работают с некоторыми из них над устранением проблемы. Патчи пока представили только Malwarebytes, AVG и Trend Micro. Cybellum предупреждает, что перед атакой DoubleAgent уязвимы продукты следующих компаний:

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

«Эта техника может использоваться для атаки на ЛЮБОЕ приложение, даже на приложения самой операционной системы, — рассказывают исследователи. — Нет нужды как-то изменять наш POC-код, достаточно просто выполнить его для нужного приложения, и оно будет автоматически атаковано, и не важно, антивирус это или нечто другое».

Proof-of-concept эксплоит исследователи выложили на GitHub, где он доступен всем желающим. Также специалисты Cybellum продемонстрировали «Двойного агента» в действии, опубликовав видеоролик, который можно увидеть ниже.

Также исследователи советуют разработчикам антивирусов использовать механизм Microsoft Protected Processes, который был представлен в Windows 8.1 и как раз призван защитить приложения от подозрительных инъекций кода. В настоящий момент только Windows Defender использует Protected Processes.

Эксперт по безопасности Windows Алекс Ионеску (Alex Ionescu) обвинил Cybellum в плагиате и лжи. Специалист уверяет, что компания выдает за собственное исследование его доклад с конференции Recon 2015, к тому же искажает факты, называя функции Application Verifier незадокументирвоанными. По словам Ионеску, это просто PR.

Shocking news. Another «next gen» cyber company takes my research (Recon 2015: Hooking Nirvana) and creates FUD https://t.co/88eVz9vzE5

«Our researchers discovered an undocumented ability of Application Verifier that gives an attacker [. ]»» Discovered» == attended a talk.

1. Attend someone’s talk at Recon. 2. Start a next-gen cybersecurity company. 3. File CVEs. 4. Come up with fancy marketing bullshit.

Cyberbellum’s «»»Zero-Day»»» uses such an «»»undocumented»»» Windows feature that even Microsoft blogged about it: https://t.co/4Ll3auSVaE

Представители Comodo, в свою очередь, заявили, что Comodo Internet Security не уязвим пред атаками DoubleAgent, несмотря на заявления Cybellum. В ответ исследователи создали proof-of-concept эксплоит для решения Comodo и опубликовали видеодемострацию его работы.

Источник