Как запустить отладку dll windows 7

В Windows 2000 вместо кнопки No следует щёлкнуть по кнопке Cancel .

Повторный запуск оболочки

Чтобы снова запустить оболочку по окончании сеанса отладки, достаточно запустить explorer.exe из любой оболочки или из командной строки. Если ни оболочки, ни командной строки под рукой нет, можно использовать следующие приёмы.

Под Windows NT/2000:

Отладка расширений в Windows NT/2000

В Windows NT/2000 можно запускать каждый новый экземпляр Проводника (Windows Explorer) в отдельном процессе (по умолчанию рабочий стол, панель задач и все Проводники запускаются в отдельных потоках одного процесса Explorer.exe). Благодаря этому можно обойтись без постоянных перезапусков оболочки. Чтобы включить этот режим работы оболочки, необходимо открыть в редакторе реестра ключ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer , добавить в него параметр DesktopProcess (типа REG_DWORD ) и назначить ему значение «1». Изменения вступят в силу после выхода и повторного входа в систему.

Выгрузка DLL

В обычном режиме работы оболочка выгружает DLL не сразу, а по истечении некоторого промежутка времени. Это может помешать линкеру перезаписывать файл DLL. Чтобы оболочка выгружала DLL немедленно, нужно создать в реестре ключ HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDLL и записать «1» в его параметр по умолчанию.

Отладка Add-in’ов к Visual C++

При отладке add-in’ов отладчику Visual C++ приходится отлаживать самого себя. Лучше всего запустить экземпляр среды Visual C++ без add-in’а, а затем использовать этот экземпляр для отладки. Иначе возможны весьма тонкие и неочевидные ошибки, на исправление которых уйдёт уйма времени. Другая возможность для отладки add-in’ов – удалённая отладка (о ней мы поговорим в следующем разделе).

Отладка ISAPI-расширений

Данные в этом разделе относятся к IIS5

ISAPI-расширение – это DLL, которая загружается веб-сервером IIS для обработки запросов. В зависимости от настроек защиты веб-приложения (application protection) они могут загружаться как главным файлом IIS inetinfo.exe (режим Low (IIS Process)), так и отдельным процессом dllhost.exe (режимы Medium (Pooled) и High (Isolated)). Чуть позже мы увидим, как отлаживать ISAPI-расширение в том и в другом случае. Но сначала несколько слов о подготовке расширения к отладке.

Подготовка к отладке

Прежде чем начинать отладку, рекомендуется проделать следующие шаги.

В MSDN упоминается альтернативный способ отключить кэширование: открыть в редакторе реестра ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters и добавить в него параметр (REG_DWORD)CacheExtensions=0. Но мне не удалось заставить этот метод работать.

Если веб-сервер ещё не запущен, запустите его. После этого можно переходить непосредственно к отладке.

В процессе отладки ISAPI-расширений довольно часто приходится запускать и останавливать веб-сервер. Для этого можно использовать команды net start w3svc и net stop w3svc соответственно. При желании можно добавить эти команды в меню Tools , чтобы они всегда были под рукой.

Отладка расширения в режиме in-process

В этом режиме DLL загружается процессом inetinfo.exe . Чтобы к нему присоединиться, можно использовать любую из описанных в предыдущем разделе методик (команду Attach To Process , команду Debug в Task Manager или функцию DebugBreak , которую в данном случае следует вставить в GetExtensionVersion расширения). После этого можно действовать по сценарию, описанному в подразделе «Общие принципы отладки», чтобы загрузить отладочные символы (если это необходимо) и расставить точки останова.

Чтобы DLL получила управление, необходимо послать ей запрос. Это можно сделать из Internet Explorer. Запрос будет выглядеть примерно так: http://localhost/test/MyISAPI.dll .

Запуск IIS в режиме обыкновенного приложения

Если объем отладки велик, и часто приходится запускать и останавливать сервис, проще запускать IIS из отладчика, как обыкновенное приложение.

Чтобы заставить IIS работать в таком режиме, нужно изменить учетную запись, под которой запускаются сервисы IIS Admin, World Wide Web Publishing и FTP Publishing, на запись, под которой будет производится отладка. Физически при запуске всех этих сервисов запускается один и тот же исполняемый файл – inetinfo.exe . DLL-библиотеки загружаются в сервис World Wide Web Publishing, но он зависит от IIS Admin-сервиса, поэтому сервис IIS Admin должен быть запущен первым. Учетная запись, под которой теперь будут запускаться сервисы, должна иметь довольно высокие привилегии. Проще всего использовать для этого учетную запись администратора, добавив ей привилегию «Act as part of the operating system» (программистам известную как SE_TCB_NAME ). Будьте осторожны, так как эта привилегия предоставляет широчайшие возможности. Теперь нужно настроить отладчик Visual C++, задав в качестве отлаживаемого проекта путь к файлу inetinfo.exe (по умолчанию он размещается в каталоге %SystemRoot%\System32\inetsrv\ ), а в качестве параметров строку «-e w3svc». Теперь при запуске проекта на отладку IIS будет загружаться автоматически. В начале очередного сеанса отладки не помешает убедиться, что сервис World Wide Web Publishing не был загружен именно как сервис (например, при перезагрузке системы).

Отладка расширения в режиме out-of-process

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

В системе может быть несколько процессов с именем dllhost.exe . Необходимо выяснить, какой из них загружает DLL-расширения. Сделать это можно различными способами. Один из возможных вариантов – вставить в саму DLL код, сообщающий идентификатор процесса, в который она загружена. Например:

Обратите внимание на флаг MB_SERVICE_NOTIFICATION . Он необходим, чтобы сообщение из ISAPI-расширения было видно на экране.

Как установить DLL файлы на Windows?

Файл DLL – компонент динамически подключаемой библиотеки, чьи элементы используют практически все программы. Библиотека DLL файлов расположена в корневой папке системы. Компоненты должны быть все в наличии, иметь цифровую подпись, правильно работать и быть актуальными по версии. Если одно из требований не соблюдено, при запуске программы пользователь получит информационное уведомление: ошибка DLL. Неисправность свидетельствует о том, что отсутствует DLL файл, поврежден или устарел.

Как установить DLL файл

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

Помещение и регистрация файлов библиотеки

Перед тем как установить DLL файл на Windows 7,8,10, их нужно скачать, причем точно под разрядность системы.

Давайте определим, какая разрядность у Вашей системы (если вы точно знаете, может пропустить этот шаг)

Шаг 1. Кликаем правой кнопкой мыши по «Мой компьютер» и выбираем «Свойства»

Шаг 2. В открывшемся окне, мы может прочитать свойства компьютера, версию операционной системы и её разрядность 32 (х86) или 64 бит. В нашем случаи стоит 64-разрядная операционная система Windows 10.

·

Шаг 3. После скачивания файлов их нужно поместить в корневую папку, зарегистрировать

для х32 (х86) систем компонент необходимо заменить или поместить в папку C:\Windows\System32;

для х64 необходимо выполнить замену или переместить в папку C:\Windows\ SysWOW64;

Шаг 4. Файл нужно зарегистрировать в системе.

Сделать это можно, открыв командную строку комбинацией «Win» + «R», или нажать «Пуск» и «Выполнить»;

в открывшемся окне ввести через пробел следующее: regsvr32 имя файла.dll – где, «regsvr32» ─ команда для регистрации, а «имя файла.dll» – полное имя вставленного компонента;

или же можно прописать расположение файла вручную — regsvr32.exe + путь к файлу

Шаг 5. Нажмите «ОК», и перезагрузите компьютер, и новые параметры вступят в силу.

Сразу хочется отметить, что при регистрации возможны появления ошибок. Например: «Не удалось загрузить модуль». Обычно они возникают по 3 причинам

1. Не правильно прописан путь к файлу, или файл не был перемещен в каталог System32 или SysWOW64
2. Не все файлы DLL вообще нуждаются в регистрации, иногда достаточно просто скопировать их в каталок System32 или SysWOW64 или поместить в корень проблемной игры или программы
3. Файлы уже были зарегистрированы ранее

Второй способ регистрации

Шаг 1. Зарегистрировать файл можно с помощью командой строки, которую нужно запустить от имени администратора.

Шаг 2. Пишем команду regsvr32.exe + путь к файлу и жмём «Enter»

Шаг 3. Появится сообщение что «Всё прошло удачно», и просто перезагружаем компьютер

Вот и всё, файл зарегистрирован, можете пробовать запускать вашу игру или программу

А вот, некоторые советы, которые могут вам пригодиться.

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

Регистрируем файл DLL в ОС Windows

После установки различных программ или игр можно столкнуться с ситуацией, когда при включении возникает ошибка «Запуск программы произвести невозможно, так как требуемой DLL нет в системе». Несмотря на то, что ОС семейства Windows обычно регистрируют библиотеки в фоновом режиме, после того, как вы скачаете и поместите ваш DLL файл в соответствующее место, ошибка все равно возникает, и система просто его «не видит». Чтобы это исправить, нужно зарегистрировать библиотеку. Как это можно сделать, будет рассказано далее в этой статье.

Варианты решения проблемы

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

Способ 1: OCX/DLL Manager

OCX/DLL Manager – это маленькая программа которая может помочь зарегистрировать библиотеку или файл OCX.

Для этого вам нужно будет:

1. Нажать на пункт меню «Register OCX/DLL».
2. Выбрать тип файла, который будете регистрировать.
3. При помощи кнопки «Browse» указать местоположение DLL.
4. Нажать на кнопку «Register» и программа сама зарегистрирует файл.

OCX/DLL Manager также умеет отменять регистрацию библиотеки, для этого понадобится выбрать в меню пункт «Unregister OCX/DLL» и в последствии проделать все те же операции, как и в первом случае. Функция отмены может вам понадобиться для сравнения результатов при активированном файле и при отключенном, а также в процессе удаления некоторых компьютерных вирусов.

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

Способ 2: Меню «Выполнить»

Можно зарегистрировать DLL, используя команду «Выполнить» в стартовом меню операционной системы Windows. Для этого нужно будет произвести следующие действия:

1. Нажать клавиатурную комбинацию «Windows + R» или выбрать пункт «Выполнить» из меню «Пуск».

Ввести имя программы, которая будет регистрировать библиотеку — regsvr32.exe, и путь, по которому размещен файл. В итоге должно получиться так:

где dllname — это имя вашего файла.

Этот пример подойдёт вам в том случае, если операционная система установлена на диск С. Если она находится в другом месте, то нужно будет поменять букву диска или воспользоваться командой:

В таком варианте программа сама находит папку где у вас установлена ОС и запускает регистрацию указанного DLL файла.

В случае с 64-разрядной системой у вас будет две программы regsvr32 — одна находится в папке:

Это разные файлы, которые используются раздельно для соответствующих ситуаций. Если у вас 64-битная ОС, а файл DLL 32-битный, тогда сам файл библиотеки должен быть помещен в папку:

и команда будет выглядеть уже так:

Способ 3: Командная строка

Регистрация файла через командную строку не сильно отличается от второго варианта:

1. Выберите команду «Выполнить» в меню «Пуск».
2. Впишите в открывшемся поле для ввода cmd.
3. Нажмите «Enter».

Перед вами появится окно, в котором нужно будет вводить те же команды, что и во втором варианте.

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

Способ 4: Открыть с помощью

1. Откройте меню файла, который будете регистрировать, нажав по нему правой кнопкой мыши.
2. Выберите «Открыть с помощью» в появившемся меню.

Нажимаете «Обзор» и выберете программу regsvr32.exe из следующей директории:

или в случае, если вы работаете в 64-битной системе, а файл DLL 32-разрядный:

Возможные ошибки

«Файл не совместим с установленной версией Windows» — это означает, что вы, скорее всего, пытаетесь зарегистрировать 64-разрядную DLL в 32-битной системе или наоборот. Воспользуйтесь соответствующей командой, описанной во втором способе.

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

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

Отладка, модификация и устранение багов в сторонних 32-х и 64-х разрядных приложениях под ОС Windows

В этой статье я хочу поделиться практическими методами отладки, модификации и устранения багов в 32-х и 64-х разрядных приложениях под ОС Windows, разработанных на языке C/C++, исходные коды которых по тем или иным причинам не стали достоянием общественности.

Этот пробел отчасти можно попытаться устранить, например, с помощью плагина Hex-Rays для IDA Pro, и зачастую удаётся довольно качественно восстановить нужный участок исходного кода, обнаружив в нём проблемное место. Но после этого всегда возникает вопрос — что с этим исправленным кодом делать дальше, как и где его можно использовать? На данном этапе мне всегда хотелось взять этот отдельно декомпилированный фрагмент программы, поменять в нём что-нибудь и затем каким-то чудесным образом «поместить обратно» в программу.

Далее будет описан один из возможных способов реализации этой идеи на практике.

Иногда возникает необходимость исправить какой-нибудь баг в сторонней программе, добавить к ней отсутствующий функционал, изменить существующий, либо модифицировать логику некоторых процессов, особенно если нет возможности обратиться за помощью к разработчикам. Описание процедуры выявления «интересных» мест выходит за рамки данной статьи. В некоторых случаях это может быть банальная ошибка в программе, которую удаётся вылечить несложным патчем непосредственно в теле EXE или DLL файла. Но если же предстоит исправлять алгоритмы поведения некоторых функций, либо добавлять новые, обычным «байтовым» патчем здесь уже не обойтись. Устранение же некоторых на первый взгляд простых багов может в итоге вылиться в «перепахивание» доброй половины программы. Также приходится потрудиться, чтобы заставить правильно работать приложения, созданные, например, под Win XP в новых ОС Windows.

Освоив и давно применяя на практике некоторые методы модификации программного кода, самым удобным и простым на мой взгляд способом оказалась его модификация в ран-тайме с помощь метода DLL-инъекции. На эту тему существует огромное количество материала и в плане реализации самого метода DLL-инъекции данная статья не претендует ни на новизну, ни на оригинальность, но в большей степени призвана систематизировать практические наработки в области отладки, модификации, поиска и устранения багов в чужом коде с его помощью.

Описываемый здесь способ вынесения некоторых функций сторонних приложений в свою собственную программу на C/C++ позволяет отлаживать, модифицировать и при необходимости более детально изучать их работу с помощью отладчика на высокоуровневом языке, вместо того, чтобы «дебажить» их в дизассемблированном коде.

Прилагаемый к данной статье пример с помощью минимальных изменений можно использовать в своих целях в качестве готового проекта для Visual Studio (VS).

В VS при создании 32-х разрядных приложений платформа называется «x86», а 64-x разрядных «x64». Поэтому чтобы не путаться с названиями я буду для обозначения разрядности приложений использовать термины «Win32» и «Win64».

Инструментарий.

IDA Pro (файлы примеров в проекте для v7.5).

CFF Explorer или любой другой инструмент редактирования импорта.

Visual Studio С/C++ (проект примера для Platform Toolset: Visual Studio 2022 (v143)).

Практика внедрения.

Для примера рассмотрим тестовую программу SimpleCalc – простое оконное приложение (проект для VS прилагается), которое производит сложение и умножение двух чисел.
В программу намеренно внесён «баг», приводящий к тому, что для операций «2+2» и «2*2» результат получается равным 5. Заголовок диалогового окна данного приложения — «Simple Buggy Calc ( 2+2=5; 2*2=5 )».

Следовательно, нам будет необходимо модифицировать его работу таким образом, чтобы в результате выполнения уникальных операций 2+2 и 2*2 получались правильные значения, а текст заголовка окна выглядел бы, как «Simple Calc».

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

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

Займёмся описанием класса Adder (имя этому классу можно задать любое).

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

Место создания класса Adder обнаруживается в методе DialogProc, откуда можно определить его размер (для Win32 версии):

Псевдокод конструктора в IDA Pro:

Теперь создим в IDA Pro структуру такого же размера с именем класса. В нашем случае структура для класса и интерфейса будет выглядеть так:

После присваивания типа вновь созданной структуры Adder соответствующим указателям и переименования методов класса, процедура его создания преобразится следующим образом:

А конструктор будет теперь выглядеть так:

Т.к. вызов реализованного метода Add интерфейса IAdder в программе происходит через таблицу адресов, найдём его в этой таблице Adder::`vftable’.

После причёсывания декомпилированного псевдокода в IDA Pro метод Adder::Add будет выглядеть примерно так:

Здесь для нас важно запомнить адрес этого метода — 0x4011B0.

Теперь перейдём к поиску и декомпиляции метода, производящего операцию умножения.
Его вызов также обнаруживается в методе DialogProc и после декомпиляции (для Win32 версии) будет выглядеть так:

А код метода Mult_() так:

В программе SimpleCalc метод Mult() намеренно был создан, как псевдо __usercall с передачей параметров через регистры EAX и EBX. Компилятор от MS для Win32 использует соглашения о вызовах __cdecl, __stdcall или __thiscall, но некоторые другие компиляторы могут использовать иные соглашения и примером такого поведения является метод Mult().

Конечно, в данном конкретном случае можно было бы ограничиться исправлением только __stdcall метода Mult_(), но для полноты картины опишем способ с нестандартным для MS соглашением о вызовах.

Для того, чтобы поместить значения регистров в стек для вызова «обычного» метода __stdcall Mult_() из метода Mult(), воспользуемся атрибутом naked. Этот атрибут указывает компилятору не создавать пролог и эпилог внутри метода, чтобы не испортить значения регистров EAX и EBX (в нашем случае) до помещения их в стек:

Можно было бы написать код метода Mult() и на чистом ассемблере, а для Win64 это единственный способ, так как в MSVC для него не поддерживается атрибут naked. Но для Win64, как правило, используется соглашение о вызове __fastcall и другие, по крайней мере среди тех приложений, которые мне приходилось «лечить», не попадались.

В методе Mult_(), реализующем операцию умножения, мы обнаруживаем использование глобальной переменной:

Адреса метода Mult() и глобальной переменной g_hMulRes нам понадобятся, поэтому их необходимо будет запомнить.

Способ изменения заголовка диалогового окна будет описан чуть позже.

Создание инжектируемой DLL.

Итак, мы обнаружили и декомпилировали интересующие нас методы и теперь перейдём к созданию собственной DLL, которую позже внедрим в тестовую программу SimpleCalc. Проект такой DLL (Win32 и Win64) для VS прилагается.

Основная идея метода DLL-Injection заключается в том, что на этапе загрузки приложения, но ещё до передачи ему управления, загрузчик ОС, среди прочих, загрузит в общее адресное пространство и нашу DLL (которую мы добавим в секцию импорта EXE файла) и вызовет из неё метод:

со значением переменной ul_reason равным DLL_PROCESS_ATTACH.

Для упрощения описания не будем рассматривать здесь частные случаи типа отложенной загрузки, LoadLibrary или TLS-коллбэков.

На данном этапе мы должны модифицировать начальную часть перехватываемых нами методов из EXE файла по адресам, полученным из IDA Pro, разместив там команды безусловных переходов на адреса наших переписанных в DLL методов.

Для Win32 команда перехода, содержащая адрес непосредственно в своём операнде (а нам нужна именно такая, чтобы не портить ни стек, ни регистры) состоит из пяти байт, первый — 0xE9, а остальные четыре знаковое смещение относительно адреса следующей команды.
Для Win64 эта команда состоит из шести байт: 0xFF, 0x25, 0x00, 0x00, 0x00, 0x00 и следом за ними восемь байт адрес перехода – итого четырнадцать байт.

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

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

При расчёте адреса перехода существует одна тонкость, заключающаяся в том, что IDA Pro по умолчанию дизассемблирует EXE файл по стандартному адресу загрузки — 0x00400000 (либо 0x140000000 для Win64). Но иногда встречаются EXE файлы, у которых в заголовке в параметре IMAGE_NT_HEADER.OptionalHeader.DllCharacteristics установлен флаг «DLL Can Move» и в этом случае ОС вправе загрузить его по любому другому адресу.

В свойствах проекта SimpleCalc в VS – за этот флаг отвечает пункт «Linker -> Advanced -> Randomize Base Address», который намеренно установлен в «Yes» для тестирования данного поведения.

Следовательно, в нашей DLL мы должны учитывать адрес, по которому загружен EXE файл, и затем использовать его в методе Patch() для расчёта смещения в команде перехода относительно адреса взятого из IDA Pro.

При работе с большими проектами, в которых используется множество классов, исходный код DLL в VS обрастает большим количеством отдельных файлов. И следить за тем, перехвачен ли тот или иной метод в DllMain с помощью вызова Patch() становится неудобным. Поэтому впоследствии был использован способ для объявления перехвата непосредственно возле нужного метода с помощью вспомогательной статической структуры. При этом оказалось возможным отказаться от использования DllMain, как места для объявления всех перехватов.

В дополнение к этому был создан вспомогательный класс CPatch.

При загрузке DLL ещё до попадания в точку входа (DllMain) инициализируются все статические объекты и таким образом, через вызов метода Patch( exeAddr, dllAdd ) происходит замена первых байт из оригинального метода в EXE на команду перехода в переписанный нами метод в DLL.

Класс CPatch содержит в себе контейнер std::map<ADDR, PATCH_DATA>, ключом в котором является адрес оригинального метода из EXE, а значением – структура PATCH_DATA, в которой хранятся оригинальные байты, заменённые на команду перехода и байты самой команды перехода. При каждом вызове метода Patch( exeAddr, dllAddr ) в этот контейнер добавляется новый элемент с соответствующим ключом – адресом оригинального метода из EXE и структурой PATCH_DATA, описанной выше.

В классе CPatch также содержатся методы Patch( exeAddr ) и Unpatch( exeAddr ), смысл использования которых состоит в следующем. Иногда бывает необходимо «попасть» в какой-нибудь метод из EXE, чтобы проконтролировать передаваемые в него аргументы, сохранив их значения, скажем, в лог файл, но весь метод для этого переписывать и декомпилировать в наши планы пока не входит.

Приведём пример использования этих методов для изменения заголовка диалогового окна программы SimpleCalc.

«Пропатчим» оконную процедуру диалогового окна DialogProc таким образом, что при попадании в наш переписанный метод DialogProc в DLL мы каждый раз будем восстанавливать оригинальные байты в EXE методе с помощью _patch->Unpatch(), вызывать оригинальный метод и после этого проверять значение аргумента uMsg. Если оно будет равным WM_INITDIALOG, для нас это может означает, что можем менять его заголовок. При всех других значениях аргумента uMsg, перед выходом из нашего метода DialogProc мы снова будем меняем начальные байты оригинального метода EXE на команду перехода на наш метод в DLL с помощью _patch->Patch().

Проверка работоспособности инжектируемой DLL.

После создания DLL, в которой описан класс Adder, метод Mul() и DialogProc() необходимо дополнительно объявить в ней один экспортируемый метод с любым именем. В нашем случае им будет пустой метод Setup(). В свойствах проекта в VS помещаем созданную DLL в ту же директорию, что и EXE файл.

Теперь настало время добавить в секцию импорта программы SimpleCalc созданную нами DLL и единственный экспортируемый из неё метод Setup(). Для этого можно воспользоваться утилитой CFF Explorer. Открываем в ней EXE файл SimpleCalc, в левой части окна выбираем пункт «Import Adder», в открывшемся окне нажимаем кнопку «Add» и выбираем наш DLL файл. После этого в окне «Exported Functions» должен отобразиться наш единственный экспортируемый метод Setup(), выделяем его мышкой и нажимаем кнопку «Import By Name» после чего он отобразится в соседнем справа окне «Imported Functions»:

Затем нажимаем кнопку «Rebuild Import Table» и перезаписываем исходный EXE файл через меню «File -> Save» или сохраняем его с новым именем «File -> Save As».

Часто возникает соблазн внедрить свой код в чужой файл без какой бы то нибыло его модификации. Обычно любой EXE файл импортирует несколько системных DLL из которых, к тому же, используются далеко не все методы. При этом можно было бы создать свою DLL с тем же именем, скажем, kernel32.dll. Описать в ней прокси переходы для всех импортируемых из этой DLL методов, добавить свои и в итоге поместить её в тот же каталог рядом с EXE файлом. Но MS об этом тоже подумала и создала список так называемых Known DLLs, куда входят все системные, чтобы они не могли загружаться из того же каталога, что и EXE.

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

Теперь в VS в свойствах DLL проекта в разделе «Debugging» в пункте «Command» прописываем путь к модифицированному EXE файлу, ставим точки останова на начало методов Add, Mult, DialogProc и стартуем отладку. Сначала мы должны попасть в метод DialogProc, а при нажатии в окне программы на кнопку «=» — в соответствующий метод вычисления суммы или произведения. Убеждаемся, что патч программы был произведен успешно.

Вызов методов EXE файла из DLL.

Как правило, из метода, который мы переписали в своей DLL, вызывается несколько других, которые на данном этапе нас не интересуют, либо мы планируем перейти к их разбору позже.

Предположим, у нас есть метод sub_4037B0, из которого вызывается другой, по адресу 0x404800. Тогда, определив из дизассемблера соглашение о вызове этого метода и тип аргументов, можно будет вызвать его таким образом:

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

Для случая, если метод является членом класса, его вызов будет выглядеть так:

Способ вызова методов с нестандартными для MSVC соглашениями о вызовах был описан выше на примере с __usercall Mult().

Доступ к данным EXE файла из DLL.

В случае, если метод сторонней программы, перехват которого производится, был написан с использованием классов и все данные, используемые в этом методе – члены этого (или другого) класса, то доступ к ним в своём переписанном методе сводится лишь к правильному описанию самого класса. Если все члены класса расположены в его описании строго на своих местах, то и доступ к ним будет осуществляться автоматически по их имени (как в классе Adder). Их значения также будут отображаться в отладчике VS через указатель this.
Но в случае использования глобальных переменных ситуация усложняется. Доступ к таким переменным можно получить лишь по их адресу в памяти основной программы, взятому из дизассемблера. В MSVC, к сожалению, невозможно объявить переменную по абсолютному адресу (даже без выделения для неё памяти), как это делается во многих Embedded системах, поэтому приходится объявлять глобальные переменные для указателей, например, таким образом:

а для переменных, используемых по значению, таким:

Но, во-первых, при этом возникает огромное неудобство при отладке программы. Дело в том, что VS не отображает в отладчике значения макросов, объявленных с помощью директивы препроцессора #define. А во-вторых, что ещё более печально, для указателя, объявленного таким образом, не удаётся получить его адрес:

Можно объявить и инициализировать указатель так:

И это будет работать для отображения его значения в отладчике и для операции разадресации «*_ptr1», но как только мы попытаемся получить адрес этого указателя, им окажется адрес нашей локальной переменной _ptr1 в адресном пространстве DLL.

Применение оператора «placement new» тоже не даёт нужного результата, т.к. непосредственно переменную с нужным именем разместить по конкретному адресу не удаётся. Так, например, конструкция типа:

действительно размещает объект типа int со значением 5 по адресу 0x40BEF4, но не переменную _ptr1 ! А она опять же находится в адресном пространстве DLL, что для нашей задачи равносильно определению:

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

Здесь мы сначала объявляем новый тип структуры, который содержит в себе единственный элемент – нашу переменную с именем var. Затем создаём указатель на эту структуру с именем нашей переменной и инициализируем его адресом этой переменной из EXE файла.

Объявление глобальной переменной g_hMulRes в этом случае будет выглядеть так:

а обращение к ней так:

Несколько «ugly», но зато с этой переменной можно производить операции взятия адреса, разадресации и, что немаловажно, её значение будет отображаться в отладчике.

Буду весьма признателен, если кто-нибудь подсказажет более изящный способ решения этого вопроса.

Управление памятью.

При сборке EXE файла использовалась та или иная версия библиотеки C/C++ (например, CRT), в которой были определены операторы и методы для управления памятью «new», «delete», «malloc», «free» и другие. И эта версия может и скорее всего будет не совпадать с версией библиотеки используемой для линковки с DLL.

Если в каком-либо из переписанных из EXE в DLL методов применяется один из этих операторов, например «new» для выделения памяти, а для её освобождения будет соответственно использоваться оператор «delete», но уже в недрах EXE модуля, то при работе программы может возникнуть исключение. Поэтому, если в переписанном методе в DLL необходимо использовать отдельный оператор «new» или «delete», предпочтительнее вызывать его по соответствующему адресу из EXE модуля, определив его предварительно в дизассемблере.

Пример такого поведения содержится в проекте DLL в методе Adder::Add() для создания массива символов.

Ведение логов.

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

Для реализации такого примера в конструкторе метода Patch тестовой DLL создаётся и открывается на запись файл SimpleCalc.log, а затем в этот файл записываются производимые пользователем операции.

Заключение.

Описанный здесь способ неоднократно помог мне в самых различных ситуациях. С его помощью были исправлены баги и недочёты в десятках программных продуктах для моей частной и профессиональной деятельности и я по сей день прибегаю к его использованию. Он одинаково хорошо применим для работы с 32-х и 64-х разрядными приложениями и апробирован на различных версиях ОС Windows, так что его смело можно рекомендовать к практическому применению при минимальных трудозатратах на внедрение.

Спасибо за проявленный интерес!

Приложение.

Архивный файл с проектом программы SimpleCalc и тестовой DLL для VS.

.NET — How to debug a DLL?

I need to debug a class library project that is provided to the main project (an ASP.NET website) as a DLL. For example, I need to put some breakpoints in order to check what’s happening during the execution.

How can I do it?

PS: I have the source code!

3 Answers 3

If you have the source code, and the .pdb files in your BIN directory, then you can debug through that code. However, You will need to enable external code debugging in Visual Studio.

You need to uncheck the «Enable Just My Code» option: menu Tools —> Options —> Debugging —> Enable Just My Code

NOTE: This will only work for .NET assemblies.

Debugging DLLs in Visual Studio (see #2 in the list) may be what you’re looking for (full disclosure: Yes, this is my personal web site).

With method #1, you can’t watch variables.

With method #2, step #2, if you can’t open the project in the same Visual Studio instance, you can run the binary of the project (that is, run it outside of Visual Studio, but make sure you run the debug version.) and attach the Visual Studio debugger to it (menu Debug -> Attach to Process).

Here are the steps for method #2 so no one has to follow the link:

Attaching a using process to the DLL project. This involved hooking the Visual Studio debugger into a running process.