Розбираємося з підтримкою x64 у WPE Pro
Завантажили? Тепер давайте перевіримо, чи не накритий він якимсь паковником або протектором:
Схоже, цього разу знімати нам нічого не доведеться. Тоді беремо до рук OllyDbg і завантажуємо "WpePro.net.exe". Давайте для прикладу запустимо 64-бітну версію Dependency Walker'а і дізнаємося, чому WPE Pro не може відобразити його у списку доступних для перехоплення процесів.
Отримати список поточних процесів у WinAPI можна двома основними шляхами:
- За допомогою зв'язування функцій CreateToolhelp32Snapshot, Process32First і Process32Next (приклад можна знайти, наприклад, тут)
- За допомогою функції EnumProcesses (приклад можна знайти, наприклад, тут)
Якщо натискати F9, то побачимо, що цей же бряк спрацьовує ще кілька разів, перш ніж нарешті з'явиться вікно зі списком поточних процесів. Давайте подивимося, чому в ньому не було Dependency Walker'а. Закриваємо вікно, знову натискаємо на кнопку «Target program» і виконуємо покрокове налагодження, починаючи з того ж бряка. Незабаром після дзвінківGetProcAddressми потрапляємо в цикл, в якому послідовно викликаються такі функції - OpenProcess, EnumProcessModules, що ховається за інструкцієюCALL DWORD PTR DS:[EDI+10], GetModuleFileNameEx (інструкціяCALL DWORD PTR DS:[ECX+14]) та CloseHandle:
Зверніть увагу на код помилки - 0x12B (ERROR_PARTIAL_COPY). Погляньмо, чому таке може відбуватися. Відкриваємо документацію до функціїEnumProcessModulesі бачимо таке:
Якщо ця функція називається з 32-розрядної application running on WOW64, вона може тільки вказувати на modules of 32-bit process. If theпроцес є 64-бітовим процесом, ця функція нестерпних і останній error code є ERROR_PARTIAL_COPY (299)
Так, це якраз наш випадок.
Незважаючи на те, що в документації до функціїGetModuleFileNameExне сказано нічого схожого, поводиться вона аналогічним чином, що описано, наприклад, тут. Одним із варіантів вирішення цієї проблеми є використання функції QueryFullProcessImageName, яка буде відпрацьовувати нормально навіть у разі виклику з 32-бітного програми, запущеного в WOW64, у разі застосування її до 64-бітного процесу.
Тепер ми можемо записати виклик функціїEnumProcessModules
і написати code cave для заміниGetModuleFileNameExфункцієюQueryFullProcessImageName:
Тепер WPE Pro відображає безліч нових процесів, у тому числі і наш Dependency Walker:
Однак при спробі приточитися до цього процесу WPE Pro видає неприємне для нас повідомлення:
На 64-біт Windows, а 64-біт процес може не вдаватися до 32-bit dynamic-link library (DLL). Додатково, 32-бітні процеси неможна load a 64-біт DLL
Нескладно здогадатися, що WPE Pro поставляється лише з 32-бітною бібліотекою.
Що ж робити? Писати свій перехоплювач WinSock? А чому б і ні?
Але як ми це здійснюватимемо? Перше, що спадає на думку - це скористатися Detours, проте на офіційному сайті відразу ж повідомляється, що підтримка 64-бітових додатків є тільки в Professional Edition:
Detours Express is limited to 32-bit processes x86 processors
Тоді спробуємо EasyHook. Серед усього іншого, ця бібліотека дозволяє працювати з 64-бітними додатками:
Ви будете мати змогу отримати внесення libraries and host processes compiled forБудь-який CPU, який буде дозволено вам вводити свій код в 32-і 64-бітні процеси від 64- і 32-бітових процесів, використовуючи дуже ті ж самі assembly in all cases
З невеликими змінами прикладу, продемонстрованого в офіційному туторіалі, отримуємо код, що перехоплює виклики функцій recv і send з WinSock і виводить перехоплені повідомлення побайтово в шістнадцятковому вигляді:
Код програми, що здійснює DLL-ін'єкцію
Код самої DLL, яка інжектиться в цільовий процес
Звичайно, тут ще є над чим попрацювати:
- По-перше, відсутнє перехоплення WSARecv, WSASend та деяких інших функцій, які можуть використовуватися в цільових програмах
- По-друге, відсутність GUI та «рядкового» подання перехоплених повідомлень
- etc
Післямова
Хардкорна конфа за С++. Ми запрошуємо лише профі.