Испробуем? MCP туляга. "nt5src Docs": { "url": "https://gitmcp.io/tongzx/nt5src" }, Вместо репо можно любой подставить. диаграмма последовательности UML, описывающая процесс загрузки исполняемого файла PE в память при запуске EXE-файла в системе Windows, на основе информации из process.c: (использовался для анализа gemini 2.5 flash) Код (Text): sequenceDiagram Actor User Participant App as Calling Application Participant K32 as Kernel32.dll (Win32 API) Participant CSRSS as CSRSS (Client-Server Runtime Subsystem) Participant Ntkrn as NT Kernel (Executive/Memory Manager) Participant FS as File System User->>App: Runs/Launches Executable (e.g., double-clicks .exe) App->>K32: CreateProcessW(...) K32->>K32: SearchPathW (locates .exe) K32->>Ntkrn: NtOpenFile(FilePath, ...) Ntkrn->>FS: Reads file metadata FS-->>Ntkrn: Returns file metadata Ntkrn-->>K32: Returns FileHandle K32->>Ntkrn: NtCreateSection(FileHandle, ..., SEC_IMAGE) Ntkrn->>Ntkrn: Maps PE file as image section (lazy loading) Ntkrn-->>K32: Returns SectionHandle K32->>Ntkrn: NtCreateProcessEx(..., SectionHandle, ...) Ntkrn->>Ntkrn: Creates new Process Object & Virtual Address Space Ntkrn-->>K32: Returns ProcessHandle K32->>Ntkrn: NtQueryInformationProcess(ProcessHandle, ProcessBasicInformation) Ntkrn-->>K32: Returns PEB Base Address K32->>K32: BasePushProcessParameters(PEB, CommandLine, Environment...) K32->>K32: BaseCreateStack & BaseInitializeContext (for initial thread) K32->>Ntkrn: NtCreateThread(ProcessHandle, ..., InitialTeb, Context) Ntkrn->>Ntkrn: Creates initial Thread Object Ntkrn-->>K32: Returns ThreadHandle K32->>CSRSS: CsrClientCallServer(BasepCreateProcess) CSRSS->>CSRSS: Performs server-side process setup (e.g., console) CSRSS-->>K32: Returns status K32->>Ntkrn: NtResumeThread(ThreadHandle) Ntkrn->>Ntkrn: Schedules new process's initial thread Ntkrn-->>App: Execution of new process begins Thread Local Storage (TLS), основанный на нашем анализе ldrinit.c и ldrp.h Код (Text): sequenceDiagram Actor Application as Приложение (пользовательский режим) Participant K32 as Kernel32.dll (API) Participant NTDLL as ntdll.dll (Загрузчик) Participant Kernel as NT Kernel (Диспетчер памяти) Participant PEB as PEB (Блок среды процесса) Participant TEB as TEB (Блок среды потока) Participant ImageTLS as PE Header (IMAGE_TLS_DIRECTORY) Application->>NTDLL: Запуск процесса / Создание первого потока (через K32/ядро) NTDLL->>NTDLL: LdrpInitializeProcess() (для первого потока) NTDLL->>NTDLL: LdrpInitializeTls() NTDLL->>PEB: Инициализировать Peb->Ldr->InLoadOrderModuleList loop Для каждого загруженного модуля (EXE/DLL) NTDLL->>ImageTLS: RtlImageDirectoryEntryToData (найти IMAGE_TLS_DIRECTORY) alt Если модуль имеет TLS NTDLL->>Kernel: RtlAllocateHeap (выделить _LDRP_TLS_ENTRY) Kernel-->>NTDLL: Возврат указателя на _LDRP_TLS_ENTRY NTDLL->>NTDLL: Добавить _LDRP_TLS_ENTRY в LdrpTlsList NTDLL->>ImageTLS: Обновить Tls.AddressOfIndex (назначить TLS-индекс) end end NTDLL->>NTDLL: LdrpAllocateTls() (для текущего потока) NTDLL->>TEB: NtCurrentTeb() (получить указатель на TEB) TEB-->>NTDLL: Возврат TEB NTDLL->>Kernel: RtlAllocateHeap (выделить TlsVector [PVOID*] на основе LdrpNumberOfTlsEntries) Kernel-->>NTDLL: Возврат TlsVector NTDLL->>TEB: Установить Teb->ThreadLocalStoragePointer = TlsVector loop Для каждой записи в LdrpTlsList NTDLL->>Kernel: RtlAllocateHeap (выделить память для TLS-данных модуля) Kernel-->>NTDLL: Возврат указателя на TLS-данные NTDLL->>NTDLL: RtlCopyMemory (копировать необработанные TLS-данные в выделенную память) NTDLL->>NTDLL: Сохранить указатель на TLS-данные в TlsVector по индексу end NTDLL->>NTDLL: Возврат (LdrpInitializeTls завершено) Application->>K32: CreateThread() (создание нового потока) K32->>NTDLL: LdrpInitializeThread() (для нового потока) NTDLL->>NTDLL: LdrpAllocateTls() (вызов для нового потока, как описано выше) NTDLL->>NTDLL: LdrpCallTlsInitializers(DllBase, DLL_THREAD_ATTACH) loop Для каждой записи в Tls.AddressOfCallBacks NTDLL->>Application: LdrpCallInitRoutine(InitRoutine, DllBase, DLL_THREAD_ATTACH, NULL) end NTDLL->>NTDLL: Возврат (LdrpInitializeThread завершено) Application->>K32: ExitThread() / Поток завершается K32->>NTDLL: LdrShutdownThread() NTDLL->>NTDLL: LdrpCallTlsInitializers(DllBase, DLL_THREAD_DETACH) loop Для каждой записи в Tls.AddressOfCallBacks NTDLL->>Application: LdrpCallInitRoutine(InitRoutine, DllBase, DLL_THREAD_DETACH, NULL) end NTDLL->>NTDLL: LdrpFreeTls() NTDLL->>Kernel: RtlFreeHeap (освободить все TLS-данные в TlsVector) NTDLL->>Kernel: RtlFreeHeap (освободить сам TlsVector) NTDLL->>NTDLL: Возврат (LdrShutdownThread завершено) Application->>NTDLL: Завершение процесса NTDLL->>NTDLL: LdrShutdownProcess() NTDLL->>NTDLL: LdrpCallTlsInitializers(DllBase, DLL_PROCESS_DETACH) loop Для каждой записи в Tls.AddressOfCallBacks NTDLL->>Application: LdrpCallInitRoutine(InitRoutine, DllBase, DLL_PROCESS_DETACH, NULL) end NTDLL->>NTDLL: Очистка ресурсов процесса (не TLS) NTDLL--xKernel: Процесс завершается, память освобождается ядром. Изменение контекста выполнения через EIP в ядре Ключевые функции, участвующие в манипулировании контекстом в exceptn.c, это KeContextFromKframes и KeContextToKframes. KTRAP_FRAME: Эта структура создается в стеке ядра при переходе из пользовательского режима в режим ядра (например, из-за прерывания, исключения или системного вызова). Она сохраняет состояние ЦП пользовательского режима или предыдущего режима ядра, включая Eip, Ebp, Esp, SegCs и EFlags. CONTEXT: Это стандартная структура Win32, представляющая полное состояние ЦП потока. Основные механизмы изменения EIP: KeContextToKframes: Эта функция принимает структуру CONTEXT и применяет ее содержимое к KTRAP_FRAME. Прямая установка EIP: Ключевым моментом является строка TrapFrame->Eip = ContextFrame->Eip;. Это место, где значение EIP из структуры CONTEXT записывается непосредственно в TrapFrame. Когда управление возвращается из ядра в предыдущий контекст выполнения, ЦП возобновит выполнение по адресу, указанному новым EIP. Любые изменения, внесенные в ContextFrame->Eip до вызова KeContextToKframes, напрямую повлияют на то, где поток возобновит выполнение. KiDispatchException: Это основная подпрограмма диспетчеризации исключений. Обработка точек останова: В случае исключения STATUS_BREAKPOINT функция уменьшает ContextFrame->Eip на 1 (ContextFrame->Eip--;). Это сделано для того, чтобы EIP указывал на инструкцию точки останова, а не после нее, что удобно для отладчиков. Диспетчеризация исключений пользовательского режима: Если исключение произошло в пользовательском режиме, ядро настраивает стек пользовательского режима для вызова диспетчера исключений пользовательского режима (KeUserExceptionDispatcher). TrapFrame->Eip = (ULONG)KeUserExceptionDispatcher; явно устанавливает EIP на адрес KeUserExceptionDispatcher. Это перенаправляет выполнение в эту подпрограмму пользовательского режима после возврата из ядра. KeRaiseUserException: Эта функция используется для программного вызова исключения в контексте пользовательского режима вызывающего потока. Она изменяет TrapFrame напрямую для перенаправления выполнения. Код (Text): PreviousEsp = KiEspFromTrapFrame (TrapFrame) - sizeof (ULONG); *(PLONG)PreviousEsp = TrapFrame->Eip; // Помещаем старый EIP в стек KiEspToTrapFrame (TrapFrame, PreviousEsp); // Обновляем ESP TrapFrame->Eip = (ULONG)KeRaiseUserExceptionDispatcher; // Устанавливаем EIP на трамплин Эта функция фактически "отматывает" стек пользовательского режима и устанавливает TrapFrame->Eip на трамплин, предоставленный ядром (KeRaiseUserExceptionDispatcher). Этот трамплин затем выполняет необходимые операции для вызова исключения в пользовательском режиме. Сводка манипуляций EIP в ядре Ядро изменяет контекст выполнения, включая EIP, в нескольких ключевых сценариях: Диспетчеризация исключений: При возникновении исключения или прерывания ядро захватывает текущий контекст в KTRAP_FRAME. Затем оно может изменить EIP в этом фрейме (или в структуре CONTEXT, производной от него) для перенаправления выполнения на обработчик исключений, отладчик или диспетчер пользовательского режима. Системные вызовы / Возвраты из прерываний: После обработки системного вызова или прерывания ядро восстанавливает сохраненный контекст из фрейма ловушки. Если EIP во фрейме ловушки был изменен, поток пользовательского режима возобновит выполнение по новому адресу. Создание потоков / Переключение контекста: Механизмы создания потоков и переключения контекста (например, KiSwapContext) также сильно зависят от манипулирования CONTEXT (или аналогичными низкоуровневыми структурами) для установки начального EIP для нового потока или для сохранения/восстановления EIP во время переключения контекста между потоками. Таким образом, изменение EIP (и других регистров) в ядре обычно включает: Захват текущего контекста: Использование таких функций, как KeContextFromKframes, для получения текущего состояния ЦП в структуру CONTEXT или KTRAP_FRAME. Изменение поля Eip: Прямая установка ContextFrame->Eip на желаемый новый адрес выполнения. Восстановление контекста: Использование таких функций, как KeContextToKframes, для применения измененной структуры CONTEXT обратно к KTRAP_FRAME, которая затем определяет, где будет возобновлено выполнение. Эта низкоуровневая манипуляция имеет решающее значение для управления потоком ядра, обработки исключений и управления процессами/потоками. --- Сообщение объединено, 4 июл 2025 в 02:40 --- Векторизованные Обработчики Исключений (VEH) в Windows XP (NT5) Введение Векторизованные обработчики исключений (Vectored Exception Handlers, VEH) — это мощный механизм в операционных системах Windows, включая Windows XP (NT5), который позволяет приложениям перехватывать и обрабатывать исключения до того, как они будут переданы традиционным структурированным обработчикам исключений (Structured Exception Handling, SEH) или отладчикам. Это дает разработчикам более гибкий контроль над потоком обработки исключений на раннем этапе. Наш анализ исходного кода nt5src, в частности файла Код (Text): Source/XPSP1/NT/base/ntdll/vectxcpt.c , раскрывает внутреннюю работу этого механизма. Ключевые структуры и функции 1. Структура Код (Text): _VECTXCPT_CALLOUT_ENTRY Эта структура используется для хранения информации о каждом зарегистрированном векторизованном обработчике исключений. Код (Text): typedef struct _VECTXCPT_CALLOUT_ENTRY { LIST_ENTRY Links; // Элементы списка для связного списка обработчиков PVECTORED_EXCEPTION_HANDLER VectoredHandler; // Указатель на функцию обработчика } VECTXCPT_CALLOUT_ENTRY, *PVECTXCPT_CALLOUT_ENTRY; * Links: Это поле является частью стандартного связного списка Код (Text): LIST_ENTRY в ядре NT, что позволяет добавлять и удалять обработчики из списка. * VectoredHandler: Это указатель на фактическую функцию обратного вызова, предоставленную приложением, которая будет вызываться для обработки исключения. 2. Функция Код (Text): RtlAddVectoredExceptionHandler Эта функция используется приложением для регистрации векторизованного обработчика исключений. Код (Text): PVOID RtlAddVectoredExceptionHandler( IN ULONG FirstHandler, IN PVECTORED_EXCEPTION_HANDLER VectoredHandler ) * FirstHandler: Этот параметр определяет порядок, в котором будут вызываться обработчики: * Если FirstHandler ненулевой, новый обработчик добавляется в начало списка. Это означает, что он будет вызываться первым среди всех зарегистрированных VEH. Если несколько обработчиков запрашивают быть "первыми", то самый последний зарегистрированный "первый" обработчик будет вызван первым. * Если FirstHandler равен нулю, обработчик добавляется в конец списка. * VectoredHandler: Адрес функции обработчика, которая будет вызываться при возникновении исключения. * Внутренняя работа: Функция выделяет память для новой структуры Код (Text): VECTXCPT_CALLOUT_ENTRY из кучи процесса, сохраняет указатель на функцию обработчика и добавляет запись в глобальный список Код (Text): RtlpCalloutEntryList , который защищен мьютексом Код (Text): RtlpCalloutEntryLock для обеспечения синхронизированного доступа. * Возвращаемое значение: Возвращается указатель на созданную Код (Text): VECTXCPT_CALLOUT_ENTRY , который можно использовать для отмены регистрации обработчика. 3. Функция Код (Text): RtlRemoveVectoredExceptionHandler Эта функция используется для отмены регистрации ранее зарегистрированного векторизованного обработчика исключений. Код (Text): ULONG RtlRemoveVectoredExceptionHandler( IN PVOID VectoredHandlerHandle ) * VectoredHandlerHandle: Указатель, возвращенный Код (Text): RtlAddVectoredExceptionHandler при регистрации обработчика. * Внутренняя работа: Функция перебирает Код (Text): RtlpCalloutEntryList , ищет соответствующую запись Код (Text): VECTXCPT_CALLOUT_ENTRY по предоставленному VectoredHandlerHandle. Если запись найдена, она удаляется из списка и освобождается память. * Возвращаемое значение: Ненулевое значение, если обработчик успешно удален; ноль в противном случае. 4. Функция Код (Text): RtlCallVectoredExceptionHandlers Это критическая функция, которая вызывается подсистемой диспетчеризации исключений пользовательского режима (трамплином диспетчера исключений) до выполнения поиска обработчиков исключений на основе фреймов (SEH). Код (Text): BOOLEAN RtlCallVectoredExceptionHandlers( IN PEXCEPTION_RECORD ExceptionRecord, IN PCONTEXT ContextRecord ) * ExceptionRecord: Указатель на структуру Код (Text): EXCEPTION_RECORD , содержащую подробную информацию о произошедшем исключении. * ContextRecord: Указатель на структуру Код (Text): CONTEXT , представляющую состояние процессора на момент возникновения исключения. * Порядок вызова: Функция перебирает Код (Text): RtlpCalloutEntryList . Поскольку новые "первые" обработчики добавляются в начало списка ( Код (Text): InsertHeadList ), они вызываются в обратном порядке регистрации для "первоочередных" обработчиков, а затем в порядке регистрации для "последних" обработчиков. То есть, самый последний зарегистрированный "первый" обработчик вызывается первым, затем предыдущий "первый" и так далее, пока не будут вызваны все "первые" обработчики, после чего вызываются "последние" обработчики в порядке их регистрации. * Результат обработчика: Каждый зарегистрированный VectoredHandler вызывается с ExceptionInfo (структурой Код (Text): EXCEPTION_POINTERS , содержащей ExceptionRecord и ContextRecord). * Если какой-либо обработчик возвращает Код (Text): EXCEPTION_CONTINUE_EXECUTION , это означает, что исключение было обработано. Код (Text): RtlCallVectoredExceptionHandlers немедленно завершает цикл, возвращает TRUE, и диспетчеризация исключений прекращается, а контекст потока восстанавливается, позволяя выполнению продолжиться. * Если обработчик возвращает Код (Text): EXCEPTION_CONTINUE_SEARCH , поиск обработчиков продолжается (то есть вызывается следующий зарегистрированный VEH, или, если VEH закончились, начинается поиск SEH). * Возвращаемое значение: TRUE, если какой-либо VEH обработал исключение (вернул Код (Text): EXCEPTION_CONTINUE_EXECUTION ); FALSE, если ни один из VEH не обработал исключение, и поиск обработчиков на основе фреймов (SEH) должен продолжиться. Как VEH обрабатывается (Сводка процесса) 1. Регистрация: Приложение вызывает Код (Text): RtlAddVectoredExceptionHandler , чтобы добавить свою функцию обратного вызова в глобальный список VEH. 2. Возникновение исключения: Когда в процессе возникает исключение (например, нарушение доступа, деление на ноль и т. д.), операционная система перехватывает его. 3. Диспетчеризация исключений пользовательского режима: Подпрограмма диспетчеризации исключений пользовательского режима (в Код (Text): ntdll.dll ) получает управление. 4. Вызов VEH: Перед тем как искать структурированные обработчики исключений (SEH), эта подпрограмма вызывает Код (Text): RtlCallVectoredExceptionHandlers . 5. Последовательный вызов: Код (Text): RtlCallVectoredExceptionHandlers вызывает зарегистрированные VEH в определенном порядке (сначала "первые", затем "последние", в порядке их регистрации, но обратном порядку добавления для "первых"). 6. Обработка исключения: * Если один из VEH обрабатывает исключение (возвращая Код (Text): EXCEPTION_CONTINUE_EXECUTION ), выполнение возобновляется с того места, где оно было прервано (возможно, с измененным контекстом). * Если ни один из VEH не обрабатывает исключение, система продолжает поиск структурированных обработчиков исключений (SEH) или, в конечном итоге, завершает процесс, если исключение остается необработанным. Таким образом, Vectored Exception Handlers предоставляют приложениям гибкий и мощный способ перехватывать и потенциально обрабатывать исключения на очень раннем этапе процесса диспетчеризации, до того как будут рассмотрены традиционные обработчики SEH или отладчики. Это делает их полезными для мониторинга, отладки и внедрения определенных функций безопасности или совместимости. --- Сообщение объединено, 4 июл 2025 в 02:46 --- Код (Text): sequenceDiagram Actor Application as Приложение (пользовательский режим) Participant CPU as Процессор Participant Kernel as NT Kernel (KiDispatchException) Participant KD as Отладчик Ядра Participant KM_SEH as Ядерные SEH Обработчики Participant UserStack as Пользовательский Стек Participant NTDLL as ntdll.dll (KeUserExceptionDispatcher) Participant VEH as Vectored Exception Handlers Participant UM_SEH as Пользовательские SEH Обработчики Participant Debugger as Пользовательский Отладчик Application->>CPU: Происходит исключение (e.g., Access Violation) CPU->>Kernel: Аппаратный переход в режим ядра (сохранение KTRAP_FRAME) Kernel->>Kernel: KiDispatchException(ExceptionRecord, ..., PreviousMode=UserMode, FirstChance=TRUE) Kernel->>Kernel: KeContextFromKframes (KTRAP_FRAME -> CONTEXT) Kernel->>Debugger: DbgkForwardException (Отправить отладчику пользовательского режима) alt Отладчик обрабатывает исключение Debugger-->>Kernel: Исключение обработано Kernel->>Application: Возврат управления (EIP может быть изменен) else Отладчик не обрабатывает исключение Kernel->>UserStack: Выделение места для EXCEPTION_RECORD и CONTEXT Kernel->>UserStack: Копирование EXCEPTION_RECORD и CONTEXT на пользовательский стек Kernel->>Kernel: Изменение EIP в KTRAP_FRAME на KeUserExceptionDispatcher Kernel-->>Application: Возврат из ядра (передача управления в NTDLL) NTDLL->>VEH: Вызов зарегистрированных VEH (через KeUserExceptionDispatcher) alt Один из VEH обрабатывает исключение VEH-->>NTDLL: Исключение обработано NTDLL->>Application: Возврат управления (EIP может быть изменен) else Все VEH не обрабатывают исключение NTDLL->>UM_SEH: Вызов зарегистрированных пользовательских SEH alt Один из UM_SEH обрабатывает исключение UM_SEH-->>NTDLL: Исключение обработано NTDLL->>Application: Возврат управления else Все UM_SEH не обрабатывают исключение NTDLL->>Kernel: NtRaiseException (FirstChance=FALSE, для второй попытки) Kernel->>Kernel: KiDispatchException(..., FirstChance=FALSE) Kernel->>Debugger: DbgkForwardException (Вторая попытка отладчику) alt Отладчик обрабатывает исключение (второй шанс) Debugger-->>Kernel: Исключение обработано Kernel->>Application: Возврат управления else Отладчик не обрабатывает (второй шанс) Kernel->>Kernel: PsGetCurrentProcess()->SubsystemPort (Если есть, отправить подсистеме) alt Подсистема обрабатывает исключение Kernel-->>Application: Возврат управления else Подсистема не обрабатывает Kernel->>Application: ZwTerminateThread (Поток завершается) end end end end end Как по мне анализируется нормально)
Proof of Concept (PoC) на C++ для демонстрации механизма загрузки исполняемого файла через отладчик, используя ключ реестра "Image File Execution Options" (IFEO) в Windows XP (NT5). Этот PoC состоит из трех отдельных программ: `target_app.cpp`: Простая "целевая" программа, которую мы будем пытаться запустить. `my_debugger.cpp`: Программа-"отладчик", которая будет запускаться вместо `target_app.exe` благодаря настройкам IFEO. Она выведет информацию о своем запуске и затем попытается запустить оригинальную `target_app.exe`. `ifeo_manager.cpp`: Управляющая программа, которая устанавливает и удаляет ключ реестра IFEO, а затем запускает `target_app.exe` для демонстрации перехвата. ### **Файл 1: `target_app.cpp`** Это простая программа, которая предназначена для "перехвата" отладчиком. Код (C++): #include <iostream> #include <windows.h> int main() { std::cout << "Target application (target_app.exe) is running." << std::endl; // Это окно не должно появиться, если IFEO настроен и my_debugger.exe успешно перехватывает запуск MessageBoxA(NULL, "Target application (target_app.exe) has finished its operation.", "Target App", MB_OK | MB_ICONINFORMATION); return 0; } ### **Файл 2: `my_debugger.cpp`** Это программа, которая будет действовать как "отладчик". Она будет запущена операционной системой вместо `target_app.exe` благодаря IFEO. Она выведет полученные аргументы командной строки и затем попытается запустить оригинальную `target_app.exe`. Код (C++): #include <iostream> #include <windows.h> #include <string> #include <vector> #include <shellapi.h> // Для CommandLineToArgvW // Вспомогательная функция для замены первого аргумента в строке командной строки. // Это необходимо, потому что CreateProcessW ожидает, что первым токеном будет путь к исполняемому файлу, // а IFEO изменяет это, помещая путь к отладчику. std::wstring ReplaceFirstArgument(const std::wstring& cmdLine, const std::wstring& newFirstArg) { std::wstring result; size_t firstQuote = cmdLine.find(L'\"'); if (firstQuote == 0) { // Строка командной строки начинается с пути в кавычках size_t secondQuote = cmdLine.find(L'\"', 1); if (secondQuote != std::wstring::npos) { // Найдена вторая кавычка, заменяем путь в кавычках result = L"\"" + newFirstArg + L"\"" + cmdLine.substr(secondQuote + 1); } else { // Неправильный формат, или присутствует только путь в кавычках. Просто используем newFirstArg. result = L"\"" + newFirstArg + L"\""; } } else { // Строка командной строки начинается с пути без кавычек size_t firstSpace = cmdLine.find(L' '); if (firstSpace != std::wstring::npos) { // Заменяем путь без кавычек result = newFirstArg + cmdLine.substr(firstSpace); } else { // Присутствует только путь без кавычек. Просто используем newFirstArg. result = newFirstArg; } } return result; } int main() { std::wcout << L"My Debugger (my_debugger.exe) запущен!" << std::endl; std::wcout << L"Полученная командная строка: " << GetCommandLineW() << std::endl; int argc; LPWSTR* argv = CommandLineToArgvW(GetCommandLineW(), &argc); if (argc < 2) { std::wcout << L"Ошибка: Недостаточно аргументов. Этот отладчик ожидает путь к оригинальной целевой программе в качестве второго аргумента." << std::endl; MessageBoxW(NULL, L"My Debugger (my_debugger.exe) столкнулся с ошибкой: Недостаточно аргументов.", L"My Debugger Error", MB_OK | MB_ICONERROR); if (argv) LocalFree(argv); return 1; } std::wstring originalTargetAppPath = argv[1]; // Путь к оригинальной целевой программе std::wcout << L"Идентифицирована оригинальная целевая программа: " << originalTargetAppPath << std::endl; // Реконструируем командную строку для оригинальной целевой программы. // Первый аргумент для CreateProcessW должен быть путем к оригинальной целевой программе, // а остальные аргументы должны быть ее оригинальными аргументами. // Мы используем полную командную строку, полученную my_debugger.exe, и заменяем ее собственный путь (argv[0]) // на путь к оригинальной целевой программе (argv[1]). std::wstring newCmdLineStr = ReplaceFirstArgument(GetCommandLineW(), originalTargetAppPath); STARTUPINFOW si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); // CreateProcessW требует изменяемую строку для lpCommandLine std::vector<wchar_t> cmdLineBuf(newCmdLineStr.begin(), newCmdLineStr.end()); cmdLineBuf.push_back(L'\\0'); // Завершаем строку нулевым символом std::wcout << L"My Debugger пытается запустить оригинальную целевую программу с командной строкой: " << cmdLineBuf.data() << std::endl; if (CreateProcessW( NULL, // Явное имя приложения (NULL для использования первого токена lpCommandLine) cmdLineBuf.data(), // Командная строка для оригинальной целевой программы NULL, // Атрибуты процесса NULL, // Атрибуты потока FALSE, // Наследование дескрипторов 0, // Флаги создания (например, CREATE_NO_WINDOW для фонового режима) NULL, // Среда NULL, // Текущий каталог &si, // STARTUPINFO &pi // PROCESS_INFORMATION )) { std::wcout << L"Успешно запущена оригинальная целевая программа (PID: " << pi.dwProcessId << L")" << std::endl; // В реальном отладчике вы бы теперь присоединились к этому процессу, // обрабатывали события отладки и т.д. Для этого PoC мы просто закрываем дескрипторы. CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } else { std::wcerr << L"Не удалось запустить оригинальную целевую программу. Код ошибки: " << GetLastError() << std::endl; } if (argv) LocalFree(argv); MessageBoxW(NULL, L"My Debugger (my_debugger.exe) завершил свою работу. Нажмите OK для выхода.", L"My Debugger", MB_OK | MB_ICONINFORMATION); return 0; } ### **Файл 3: `ifeo_manager.cpp`** Эта программа будет управлять настройкой и очисткой ключа реестра IFEO и запускать демонстрацию. Код (C++): #include <iostream> #include <windows.h> #include <string> #include <vector> // Функция для установки ключа реестра Image File Execution Options bool SetIfeoDebugger(const std::wstring& targetExeName, const std::wstring& debuggerPath) { HKEY hKey; LONG lResult; std::wstring subKeyPath = L"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" + targetExeName; // Создаем или открываем ключ реестра lResult = RegCreateKeyExW(HKEY_LOCAL_MACHINE, subKeyPath.c_str(), 0, NULL, REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL, &hKey, NULL); if (lResult != ERROR_SUCCESS) { std::wcerr << L"Ошибка при создании/открытии ключа реестра '" << subKeyPath << L"'. Код ошибки: " << lResult << std::endl; return false; } // Устанавливаем значение "Debugger" lResult = RegSetValueExW(hKey, L"Debugger", 0, REG_SZ, (LPBYTE)debuggerPath.c_str(), (DWORD)((debuggerPath.length() + 1) * sizeof(wchar_t))); if (lResult != ERROR_SUCCESS) { std::wcerr << L"Ошибка при установке значения реестра 'Debugger'. Код ошибки: " << lResult << std::endl; RegCloseKey(hKey); return false; } RegCloseKey(hKey); std::wcout << L"Успешно установлен отладчик для " << targetExeName << " на " << debuggerPath << std::endl; return true; } // Функция для удаления ключа реестра Image File Execution Options bool DeleteIfeoDebugger(const std::wstring& targetExeName) { std::wstring subKeyPath = L"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" + targetExeName; LONG lResult = RegDeleteKeyW(HKEY_LOCAL_MACHINE, subKeyPath.c_str()); if (lResult != ERROR_SUCCESS) { std::wcerr << L"Ошибка при удалении ключа реестра '" << subKeyPath << "'. Код ошибки: " << lResult << std::endl; return false; } std::wcout << L"Успешно удален ключ отладчика для " << targetExeName << std::endl; return true; } int main() { std::wcout << L"--- Менеджер PoC отладчика IFEO ---" << std::endl; std::wstring targetExe = L"target_app.exe"; // Получаем путь к текущему исполняемому файлу, чтобы определить путь к my_debugger.exe wchar_t currentExePath[MAX_PATH]; GetModuleFileNameW(NULL, currentExePath, MAX_PATH); std::wstring currentDir = currentExePath; size_t lastSlash = currentDir.rfind(L'\\'); if (lastSlash != std::wstring::npos) { currentDir = currentDir.substr(0, lastSlash + 1); } else { currentDir = L".\\"; // По умолчанию используем текущий каталог, если не найден слэш } std::wstring debuggerExe = currentDir + L"my_debugger.exe"; std::wcout << L"Целевое приложение: " << targetExe << std::endl; std::wcout << L"Приложение отладчика: " << debuggerExe << std::endl; std::wcout << L"ВНИМАНИЕ: Эта программа требует права администратора для изменения реестра." << std::endl; std::wcout << L"Убедитесь, что '" << targetExe << "' и '" << debuggerExe << "' находятся в том же каталоге, что и этот исполняемый файл." << std::endl; if (!SetIfeoDebugger(targetExe, debuggerExe)) { std::wcerr << L"Не удалось установить отладчик IFEO. Выход." << std::endl; return 1; } std::wcout << L"\nПопытка запустить '" << targetExe << "'. Вместо этого должен запуститься 'my_debugger.exe'." << std::endl; std::wcout << L"Нажмите любую клавишу, чтобы запустить target_app.exe (или запустите его вручную из проводника)..." << std::endl; std::wcin.get(); // Ждем ввода пользователя перед запуском STARTUPINFOW si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); // Запускаем целевое приложение. Из-за IFEO должен запуститься my_debugger.exe. // CreateProcessW требует изменяемую строку для lpApplicationName std::wstring targetExePath = currentDir + targetExe; std::vector<wchar_t> targetExePathBuf(targetExePath.begin(), targetExePath.end()); targetExePathBuf.push_back(L'\\0'); if (CreateProcessW( targetExePathBuf.data(), // Имя приложения NULL, // Командная строка (может быть NULL, или передать аргументы здесь) NULL, // Атрибуты процесса NULL, // Атрибуты потока FALSE, // Наследование дескрипторов 0, // Флаги создания NULL, // Среда NULL, // Текущий каталог &si, // STARTUPINFO &pi // PROCESS_INFORMATION )) { std::wcout << L"Успешно предпринята попытка запустить '" << targetExe << "'. Если настройка выполнена правильно, должно было появиться 'my_debugger.exe'." << std::endl; // В этом PoC PID будет принадлежать "my_debugger.exe", который был запущен вместо target_app.exe. // А уже my_debugger.exe может запустить target_app.exe. std::wcout << L"PID процесса (фактически my_debugger.exe): " << pi.dwProcessId << std::endl; CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } else { std::wcerr << L"Не удалось запустить '" << targetExe << "'. Код ошибки: " << GetLastError() << std::endl; } std::wcout << L"\nНажмите любую клавишу, чтобы очистить реестр и выйти." << std::endl; std::wcin.get(); // Ждем, пока пользователь понаблюдает за отладчиком, а затем очищаем if (!DeleteIfeoDebugger(targetExe)) { std::wcerr << L"Не удалось очистить ключ отладчика IFEO." << std::endl; return 1; } std::wcout << L"Очистка завершена. Выход." << std::endl; return 0; } ### **Инструкции по компиляции и запуску:** **Сохраните файлы**: Сохраните приведенные выше коды в трех отдельных файлах: `target_app.cpp`, `my_debugger.cpp` и `ifeo_manager.cpp`. **Компиляция**: Откройте командную строку (например, PowerShell или CMD) и перейдите в каталог, где вы сохранили файлы. Используйте следующий компилятор (MinGW g++ или Microsoft Visual C++ `cl`): * **MinGW (g++)**: ```bash g++ target_app.cpp -o target_app.exe -s -luser32 g++ my_debugger.cpp -o my_debugger.exe -s -luser32 -lshell32 g++ ifeo_manager.cpp -o ifeo_manager.exe -s -luser32 -ladvapi32 ``` * **Microsoft Visual C++ (cl)**: Откройте "Developer Command Prompt for VS" и выполните: ```bash cl target_app.cpp /Fe:target_app.exe cl my_debugger.cpp /Fe:my_debugger.exe /link shell32.lib cl ifeo_manager.cpp /Fe:ifeo_manager.exe /link advapi32.lib ``` **Запуск (с правами администратора)**: Запустите `ifeo_manager.exe` от имени администратора, так как он будет изменять реестр HKLM. ```bash .\ifeo_manager.exe **Ожидаемый результат:** Консольное окно `ifeo_manager.exe` запросит права администратора (если не запущено с ними). Оно установит ключ реестра IFEO для `target_app.exe`, указывающий на `my_debugger.exe`. Оно предложит нажать любую клавишу, чтобы запустить `target_app.exe`. После нажатия клавиши, вместо `target_app.exe`, вы увидите, что запускается `my_debugger.exe` (появится новое консольное окно `my_debugger.exe`). `my_debugger.exe` выведет информацию о том, что он был запущен, и затем попытается запустить оригинальную `target_app.exe`. После закрытия окон `my_debugger.exe` и `target_app.exe`, `ifeo_manager.exe` очистит ключ реестра IFEO. **Важное замечание:** Манипуляции с ключами реестра в `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options` могут повлиять на стабильность системы, если они выполнены некорректно или не очищены. Этот PoC предназначен исключительно для образовательных и исследовательских целей.
