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

Время на прочтение
14 мин

Количество просмотров 4.6K

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

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

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

В 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 версии):

INT_PTR CALLBACK DialogProc( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
  ...

  pAdder = operator new( 0x10 );          // Размер структуры для класса Adder
  if( pAdder )
  {
    sub_401870( pAdder, 0x10 );           // Метод инициализации, созданный компилятором
    pAdder = sub_401160( pAdder, hDlg );  // Вызов конструктора Adder::Adder()
  }
  else
  {
    pAdder = 0;
  }
  _pAdder = pAdder;

  ...

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

void* __thiscall sub_401160( void* this, HWND hDlg )
{
  *(_DWORD*)this = &Adder::`vftable';
  *((_DWORD*)this + 2) = GetDlgItem( hDlg, 1001 );
  *((_DWORD*)this + 3) = GetDlgItem( hDlg, 1002 );
  *((_DWORD*)this + 1) = GetDlgItem( hDlg, 1003 );
  return this;
}

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

IAdder          struc ; (sizeof=0x4)
  Add             dd ?      ; Адрес метода, выполняющего операцию сложения.
IAdder          ends

Adder           struc ; (sizeof=0x10)
  pVftable        dd ?      ; IAdder* - указатель на таблицу методов интерфейса IAdder
  _hRes           dd ?      ; HWND - идентификатор окна суммы
  _hAdd1          dd ?      ; HWND - идентификатор окна ввода для первого слагаемого
  _hAdd2          dd ?      ; HWND - идентификатор окна ввода для второго слагаемого
Adder           ends

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

INT_PTR CALLBACK DialogProc( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
  ...
  pAdder = (Adder*)operator new( sizeof( Adder ) );
  if( pAdder )
  {
    Adder:: __autoclassinit2( pAdder, sizeof( Adder ) );  // Метод инициализации, созданный компилятором
    pAdder = Adder::Adder( pAdder, hDlg );                // Конструктор
  }
  else
  {
    pAdder = 0;
  }
  _pAdder = pAdder;
  
  ...

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

Adder* __thiscall Adder::Adder( Adder* this, HWND hDlg )
{
  this->pVftable = (IAdder*)&Adder::`vftable';      // Адрес таблицы методов интерфейса IAdder
  this->_hAdd1 = GetDlgItem( hDlg, IDC_ADD_EDIT1 );
  this->_hAdd2 = GetDlgItem( hDlg, IDC_ADD_EDIT2 );
  this->_hRes = GetDlgItem( hDlg, IDC_ADD_RES );
  return this;
}

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

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

// 0x4011B0
void __thiscall Adder::Add( Adder* this )
{
  int res;
  int add2;
  int add1;
  char* pBuf;

  pBuf = (char*)operator_new( 64 );

  GetWindowTextA( this->_hAdd1, pBuf, 64 );
  add1 = itol( pBuf );

  GetWindowTextA( this->_hAdd2, pBuf, 64 );
  add2 = itol( pBuf );

  // Этот «баг» нам необходимо будет исправить в своей DLL.
  //
  if( add1 == 2 && add2 == 2 )
    res = 5;
  else
    res = add2 + add1;

  sprintf_s( pBuf, 0x40, "%ld", res );
  SetWindowTextA( this->_hRes, pBuf );

  DeleteBuf( this, pBuf )
}

// 0x401150
void __usercall Mult( HWND hMul1@<eax>, HWND hMul2@<ebx> )
{
  Mult_( hMul1, hMul2 );
}

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

void __stdcall Mult_( HWND* hMul1, HWND* hMul2 )
{
  int res;
  int mul2;
  int mul1;
  char buf[64];

  GetWindowTextA( hMul1, buf, sizeof( buf ) );
  mul1 = itol( buf );

  GetWindowTextA( hMul2, buf, sizeof( buf ) );
  mul2 = itol( buf );

  // Этот «баг» нам необходимо будет исправить в своей DLL.
  //
  if( mul1 == 2 && mul2 == 2 )
    res = 5;
  else
    res = mul2 * mul1;

  sprintf_s( buf, sizeof( buf ), "%ld", res );

  SetWindowTextA( g_hMulRes, buf );
}

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

// void __usercall Mult( HWND hMul1@<eax>, HWND hMul2@<ebx> )
__declspec( naked )
void Mult()
{
  __asm
  {
    push	ebx
    push	eax
    call	Mult_

    ret
  }
}
PATCH( 0x401150, Mult )

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

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

// 0x41B36C
HWND g_hMulRes;

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

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

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

BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason, LPVOID lpReserved )

Здесь необходимо следить за тем, чтобы длина команды перехода была не больше длины самого модифицируемого метода! Как, например, для «заглушек», содержащих единственную однобайтовую команду 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 ещё до попадания в точку входа (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().

// 0x4012C0
INT_PTR CALLBACK DialogProc( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
  _patch->Unpatch( 0x4012C0 );

  auto res = ( ( INT_PTR( CALLBACK* )( HWND, UINT, WPARAM, LPARAM ) )A( 0x4012C0 ) )( hDlg, uMsg, wParam, lParam );

  if( uMsg == WM_INITDIALOG )
  {
    ::SetWindowText( hDlg, "Simple Calc" );
  }
  else
  {
    _patch->Patch( 0x4012C0 );
  }

  return res;
}
PATCH( 0x4012C0, DialogProc )

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

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

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

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

int sub_4037B0()
{
  HWND hDlg;

  ...

  // int __cdecl sub_404800( HWND hDlg );
  int res = ((int(__cdecl*)(HWND))0x404800)( hDlg );

  ...
}

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

int __cdecl sub_404800( HWND hDlg )
{
  return ((int(__cdecl*)(HWND))0x404800)( hDlg );
}

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

int ClassA::sub_4037B0()
{
  HWND hDlg;

  ...

  // int __thiscall ClassA::sub_404800( HWND hDlg );
  int res = ((int(__thiscall*)( ClassA*, HWND ))0x404800)( this, hDlg );

  ...
}

или, опять же:

int ClassA::sub_404800(( HWND hDlg )
{
  return ((int(__thiscall*)(ClassA*, HWND))0x404800)( this, hDlg );
}

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

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

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

#define _ptr1 ((int*)0x40BEF4)

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

#define _val1 (*(int*)0x40BEF8)

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

int** pptr1 = &_ptr1; // error C2101: '&' on constant

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

int* _ptr1 = (int*)0x40BEF4;

int* _ptr1 = new((int*)0x40BEF4) int(5);

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

int* _ptr1 = (int*)0x40BEF4;

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

#define VAR(name,type,addr) \
  typedef struct { type var; } name##_; \
  auto name = (name##_*)(addr);

VAR( g_hMulRes, HWND, 0x41B36C )

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

g_hMulRes->var

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

При сборке 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.

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

Почему возникает ошибка regsvr32

Итак, утилита regsvr32.exe, являющаяся частью операционной системы Windows (начиная с версии 95), – это инструмент, основным предназначением которого является регистрация различных компонентов ОС. Прежде всего – использующих технологию OLE, а таковыми являются, например, элементы ActiveX, позволяющие интегрировать программы в среду Windows вне зависимости от того, на каком языке программирования они написаны. Разумеется, это относится и к любым другим динамическим библиотекам, использующим формат DLL.

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

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

Причины ошибки могут быть разными: от неправильного пути размещения самой утилиты до ошибочных действий пользователя. Как правило, с этой ошибкой чаще всего сталкиваются геймеры, нередко устанавливающие на компьютер пиратские копии игр. Обычно те модули, которые отвечают за обход лицензирования или взлом, требуют регистрации недостающих динамических библиотек вручную. Впрочем, иногда такие действия требуются и при установке «хороших» и даже достаточно популярных и известных программ, например, при установке Creative Cloud от компании Adobe. Программы обработки видео и графики также могут использовать незарегистрированные компоненты DLL, которые приходится устанавливать вручную. Если эта операция заканчивается неудачно, это не приговор, и сегодня мы рассмотрим, что делать, если regsvr32 не смогла найти указанный модуль и завершилась аварийно.

Способы регистрации DLL в Windows

Регистрировать недостающие компоненты можно и с использованием консоли «Выполнить», но через командную строку это будет намного надёжнее. Все регистрируемые библиотеки помещаются в системный каталог, каковым для Windows 95/98/ME является system, для Windows XP/Vista/NT и более поздних 32-битных версий – system32, для 64-разрядных ОС – либо SysWOW64, либо system32. Все эти особенности нужно знать.

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

Для этого в ранних версиях Windows (вплоть до «семёрки») необходимо кликнуть по кнопке «Пуск», выбрать пункт «Все программы», пролистать список вниз до подпункта «Стандартные» и найти там «Командную строку». Кликнуть по ней ПКМ и в появившемся контекстном меню выбрать пункт «Запуск от имени администратора».

В «восьмёрке» и «десятке» это выполняется проще, достаточно просто нажать кнопку «Пуск», найти «Командную строку» и щёлкнуть по ней ПКМ с выбором нужного аргумента.

Некоторые предпочитают запускать интерпретатор через проводник – в этом случае действия аналогичные: кликаем по файлу regsvr32.exe правой кнопкой мыши и выбираем опцию «Запуск от имени администратора».

Второй по частоте встречаемости причиной невозможности зарегистрировать нужную библиотеку или компоненту является ошибка с размещением этой компоненты. Даже опытные пользователи копируют нужный файл в каталог System32, просто по привычке. Для 64-разрядной версии Windows системной папкой, в которой размещаются все регистрируемые компоненты, является SysWOW64. Всё, что от вас потребуется, – убедиться, что вы скопировали библиотеку в нужную папку. И если это не так, исправить свою ошибку, а затем снова запустить командную строку с правами администратора и выполнить команду:

regsvr32.exe c: windows /system32/<полное имя регистрируемой библиотеки с расширением>

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

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

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

Не помешает также проверить компьютер антивирусом, запустив полное сканирование, – файл regsvr32.exe может оказаться попросту заражённым.

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