kernal32.dll图像下的EIP - 新创建的暂停进程的EIP仅在Windows XP失败？ [英] Newly created suspended process's EIP is failing only on Windows XP - EIP under kernal32.dll image?

问题描述

我的程序完美的作品在Windows Vista Ultimate和Windows 7中，但它不能在Windows XP上。

首先，我的应用程序创建一个系统文件的过程中，它调用GetThreadContext（remote_thread），并设置一个LPVOID值的值上下文>出Eip，然后检查在从VirtualQueryEx设置结构MEMORY_BASIC_INFORMATION值。

下面是调用时VirtualQueryEx返回值：

的Windows XP

• 0 - 调拨基地


• 0 - 分配保障


• 2088828928 - 基址


• 1 - 保护


• 983040 - 区域大小


• 65536 - 状态


• 0 - 型

Windows 7中

• 2003959808 - 调拨基地


• 128 - 分配保障


• 2004025344 - 基址


• 32 - 保护


• 876544 - 区域大小


• 4096 - 状态


• 16777216 - 类型

的Windows Vista

• 2006122496 - 调拨基地


• 128 - 分配保障


• 2006536192 - 基址


• 32 - 保护


• 389120 - 区域大小


• 4096 - 状态


• 16777216 - 类型

为什么当我在Windows XP上运行我的应用程序已经没有分配的基础，没有分配保护，以及对Windows 7和Windows Vista中完全不同的价值观。

我打算使用VirtualProtectEx上的地址（上下文> EIP），所以如果这是在XP中的值，然后VirtualProtectEx必然失败，因为我将访问不可访问的内存。

下面是如何创建我的过程：

 如果（CreateProcessW（m_pwszCont​​ainerPath，NULL，NULL，NULL，FALSE，DETACHED_PROCESS | CREATE_SUSPENDED，NULL，NULL，＆安培; m_stStartInfo，＆安培; m_stProcessHandles）== TRUE）
    {
    //获取线程上下文
    m_stContext.ContextFlags = CONTEXT_FULL;
    如果（GetThreadContext（m_stProcessHandles.hThread，＆安培; m_stContext）== FALSE）
        转到_CLEANUP;
    //抓斗，出Eip
    m_pvLdrInitEip =（LPVOID）m_stContext.Eip;
        }
 

的事实是：这完美可以在Windows 7和Windows Vista

有我丢失的东西吗？
感谢您的任何帮助。

编辑 - 这里所说的画面：

这里是奥利运行可执行文件，一个在XP虚拟机一外两个实例的照片。从我所看到的画面XP（下一个）有它的EIP设置成ModuleEntryPoint而Windows 7实例有它设置为NTDLL ..

我进一步调查，并发现EIP是，实际上在kernel32.dll中的图像（在Windows XP），而不是ntdll.dll中理所应当的。

解决方案

创建过程与 CREATE_SUSPENDED 表示主要过程将无法完成它的初始化运行您的$之前C $℃。装载机的实现方式会导致XP和Vista / 7之间的不同效果，因为 CREATE_SUSPENDED 文档不承批人进程初始化你真的不能在该算方法。在 CREATE_SUSPENDED 标记只状态的过程与悬挂在主线程创建的。
结果
这不完全清楚的OP希望实现的目标，但有几个方法才达到类似目标浮现在脑海中：

1. 写一个调试器，而不是远程操纵其他进程。一个简单的教程和code的例子可以发现这里。调试器将获取每一个线程产生了一个事件，你很可能使用它。




2. 修改PE通过创建您code一个新的部分，并把一个TLS条目的PE执行进程的内存空间内code之前，其他任何以执行code 。你是那么code将进程的入口点之前运行，但它被初始化后。




3. 修改PE，并与自己的code PE头替换入口点，只要确保你执行原来的入口点自己。一些initalization将丢失，但所有的PE code部分将被载入。




4. 通过创建它悬浮并从不同的线程，或者任何其他方法DLL载入注入一个DLL到进程的存储器地址。 这文章列出了一些你可以谷歌更多。我不知道这会在所有情况下工作，如果你想获得，因为类似问题初始化过程，但我不认为调用调用LoadLibrary会得到你想要的效应。这也是一个干净的方式来获得code到另一个进程，并操纵它，而比使用调试器的更多秘密。




5. 您也可以尝试扫描整个内存要处理，而进程被挂起了code块，也可以在XP上运行。




6. 您可以尝试创建复权的过程中，并让它运行挂起线程之前的短时间内。定时和几个测试后，你会得到大概需要多少时间来初始化一个合理的feelling。这是一个有点冒险，但可能工作。

创建一个调试器将是最简单，最稳健的/通用的方法，但将有被容易地检测disadvtange（虽然你可以使用防反调试技巧）。加载DLL将是最好的方式，如果你想通过操纵过程中保持检测不到（如果有任何反调试技巧），如果你想要更多的建议或recomendations您的特定需求，请编辑并详细描述正是你想要什么完成，因为它不是从你的问题清楚。关于程序的一个小的详细信息（它是原生或.NET为例）也将是有益的。

编辑：
经朋友建议的另一个猜测是，内核并没有按时间完成进程初始化系统调用回报，你叫 VirtualQueryEx 。他说叫 WaitForSingleObject的的进程的句柄将返回一旦这个过程完全初始化，你可以访问所有的信息和事后恢复执行。

My program works flawlessly on Windows Vista Ultimate and Windows 7, however it fails on Windows XP.

First, my application creates a process of a system file, it calls GetThreadContext(remote_thread) and sets an LPVOID value to the value context->Eip, and then checks the values in the structure MEMORY_BASIC_INFORMATION set from VirtualQueryEx.

Here are the values VirtualQueryEx returned when called:

Windows XP

• 0 - allocation base
• 0 - allocation protect
• 2088828928 - base address
• 1 - protect
• 983040 - region size
• 65536 - state
• 0 - type

Windows 7

• 2003959808 - allocation base
• 128 - allocation protect
• 2004025344 - base address
• 32 - protect
• 876544 - region size
• 4096 - state
• 16777216 - type

Windows Vista

• 2006122496 - allocation base
• 128 - allocation protect
• 2006536192 - Base address
• 32 - protect
• 389120 - region size
• 4096 - state
• 16777216 - type

Why is it that when I run my application on Windows XP it has no allocation base and no allocation protect, as well as completely different values to Windows 7 and Windows Vista.

I plan to use VirtualProtectEx on the address (context->Eip), so If those are the values on XP then VirtualProtectEx will inevitably fail, as I would be accessing unaccessible memory.

Here is how I create my process :

    if ( CreateProcessW(m_pwszContainerPath, NULL, NULL, NULL, FALSE, DETACHED_PROCESS | CREATE_SUSPENDED, NULL, NULL, &m_stStartInfo, &m_stProcessHandles) == TRUE )
    {
    // Get context of thread
    m_stContext.ContextFlags = CONTEXT_FULL;
    if ( GetThreadContext(m_stProcessHandles.hThread, &m_stContext) == FALSE )
        goto _CLEANUP;
    // Grab, Eip
    m_pvLdrInitEip = (LPVOID)m_stContext.Eip;
        }

The fact of the matter is: This works flawlessly on both Windows 7 and Windows Vista.

Is there something I am missing here? Thank you for any help.

EDIT - Here goes a picture :

Here is a picture of two instances of olly running the executable, one in the XP virtual machine, one outside. From what I notice, the XP picture (bottom one) has it's EIP set to ModuleEntryPoint while the Windows 7 Instance has it set to ntdll..

I investigated further, and found that the EIP was, in fact in kernel32.dll image (on Windows XP), rather than ntdll.dll as it should be..

解决方案

Creating a process with CREATE_SUSPENDED means the main process won't finish it's initialization before you run your code. the way the loader is implemented causes the different effects between XP and Vista/7, and since the CREATE_SUSPENDED documentation doesn't grantee any process initialization you can't really count on that method. the CREATE_SUSPENDED flag only states the process is created with the main thread suspended.
It's not exactly clear what the OP desires to accomplish, but a few methods to achive similar goals come to mind:

1. Write a debugger instead of remotely manipulating another process. a simple tutorial and code examples can be found Here. the debugger gets an event for every spawned thread, you could probably use that.

2. Modify the PE to execute your code before any other by either creating a new section for your code and placing a TLS entry in the PE to execute code inside the process's memory space. you're code will then run before the process's EntryPoint but after it was initialized.

3. Modify the PE and replace the EntryPoint in the PE header with your own code, just make sure you execute the original entry point yourself. some initalization will be missing but all the PE code sections will be loaded.

4. Inject a DLL into the process's memory address by either creating it suspended and loading a DLL from a different thread, or any other method. This article lists a few and you can Google for more. i'm not sure that'll work in all cases if you want to get the process initialized because of similar issues, but I do think that calling LoadLibrary will get you the desired efect. That is also a clean way to get code into another process and manipulate it while being more stealth than using a debugger.

5. You can also try scanning the entire memory for the code chunks you want to manipulate while the process is suspended, that might also work on XP.

6. You could try creating the process unsuspended and let it run for a short period of time before suspending the threads. after timing and a few tests you'll get a resonable feelling about how much time it takes to initialize. That's a bit risky but might work.

creating a debugger will be the easiest and most robust/generic method but will have the disadvtange of being easily detected (although you could use anti-anti-debugging tricks). loading a DLL will be the best way if you want to remain undetectable by the manipulated process (if it has any anti-debugging tricks) if you want more suggestions or recomendations for your specific needs please edit and describe in detail what exactly you want to accomplish as it is not clear from your question. a little more details about the program (is it native, or .net for example) would also be helpful.

EDIT: another speculation suggested by friend was that the kernel did not finish the process initialization by the time the syscall returns and you call VirtualQueryEx. he said calling WaitForSingleObject on the process's handle will return once the process is fully initialized and you could access all the information and resume the execution afterwards.

这篇关于kernal32.dll图像下的EIP - 新创建的暂停进程的EIP仅在Windows XP失败？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！