VirtualAlloc C++ 、注入dll、asm
我想在应用程序中为我的代码库预留空间。 我使用 VirtualAlloc 函数来保留这个空间。 我有 X 个问题。
我应该使用哪些参数（sllocation类型和保护）来为code-cave分配内存？
作为返回值，我得到了我的 codecave 的地址。在程序的其他部分，我想 JMP 到该 codecave。怎么做呢？我知道（如果我错了，请纠正我）JMP 将其作为从当前位置偏移的参数数。但我想 JMP 到 ma codecave。如何计算这个偏移量。
I want to reserve space for my codecave in application.
I use VirtualAlloc function to reserve this space.
I have X questions.
What parameters (sllocation type and protection) should I use to allocate memory for code-cave?
As return value I get address of my codecave. In other part of the program I want to JMP to that codecave. How to do it? I know (correct me if I'm wrong) that JMP takes as agument nuber that is offset from current location. But I want to JMP to ma codecave. How to calculate this offset.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
刚刚偶然发现。为了让我们其他人弄清楚这个主题：计算 Codecave 补丁的相对 JMP 偏移量的方法是用当前程序计数器地址减去补丁地址：
注意：current_len 是 JMP 指令的字节数需要。这取决于它是短跳转（EB）还是长跳转（E9）。在您的示例中为 2 个字节，但常规 JMP (E8 0x12345678) 需要 5 个字节。
因此，在这里我们看到您的示例不会轻松工作，因为您必须覆盖属于以下 MOV 甚至 CALL 指令的下一个字节。这依赖于这样一个事实：您的 codecave 与当前指令偏移量的距离更大，因为它分配在地址空间中的不同区域中。
所以你能做的就是将覆盖的 7 个字节复制到你的洞穴中。只有当您不弄乱补丁中的 EDI 寄存器时，这才有效（因为“MOV ECX，EDI”）。并且您必须更正您要覆盖的 CALL 地址。因此，这可能不是放置 Codecave 的最佳位置，但它是可行的。
我编写了自己的挂钩库，该库负责通用寄存器参数、堆栈清理和覆盖的 asm 填充，但我建议使用上述框架。
问候，
迈克尔
Just stumbled across. To clearify this topic for the rest of us: Calculating the relative JMP offset to a codecave patch works by subtracting your patch address with your current programm counter address:
Note: current_len is the number of bytes your JMP instruction takes. This depends on the fact if its a short jmp (EB) or a long jump (E9). In your example 2 bytes, but a regular JMP (E8 0x12345678) takes 5 bytes.
So here we see that your example wont work easily, because you would have to override the next bytes that belong to the following MOV and even the CALL instruction(s). This relies on the fact that your codecave has a greater distance to the current instruction offset because it is allocated in a different region in the address space.
So what you can do is to copy the overwritten 7 Bytes into your cave. That can only work if you dont mess with EDI register in your patch (because of the "MOV ECX, EDI"). And you would have to correct the CALLs address you are overwriting. So this is probably not the best location to place a codecave, but its doable.
i wrote my own hooking library that cares for generic register arguments, stack cleanup and overwritten asm paddings, but i suggest to use the above mentioned frameworks.
regards,
michael
从跳转后的指令地址减去跳转目标的地址即可得到跳转偏移量。
Subtracting the address of your jump target from the address of the instruction after the jump will give you the jump offset.
如果您没有得到这样的东西，请使用 MS Detours、N-CodeHook 等库或其他库。
If you don't get such things, use a library like MS Detours, N-CodeHook, or something else.