仅使用系统调用而不是Windows dll制作程序 [英] Make a program using only system-calls not windows dll's

查看:116
本文介绍了仅使用系统调用而不是Windows dll制作程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使程序可以通过dll(kernel32.dllntdll.dll)进行系统调用.
例如,我知道Windows 10 64位中的0x2C(44)系统调用是NtTerminateProcess buy 网页.另外,当我反汇编ntdll.dll时,我发现该代码:

I am trying to make a program work with system-calls not dll's (kernel32.dll,ntdll.dll).
I know for example that the 0x2C (44) system call in windows 10 64-bit is the NtTerminateProcess buy that web page. Also when I disassemble the ntdll.dll i found that code:

NtTerminateProcess:
        mov r10, rcx
        mov eax, 44
        test byte [abs 7FFE0308h], 01h  ;also what is in that memory address?
        jnz label
        syscall
        ret    
label:  
        int 46 ;and why the 46 (the 2Eh windows NT interrupt) is here
        ret

我的问题是例如如何以这种方式终止程序?

My question is how can for example terminate the program with that way?

推荐答案

直接执行系统调用不是一个好主意,因为这不是稳定的ABI.从理论上讲,这些数字可以在Service Pack之间进行更改,甚至可以进行简单的更新.

Doing syscalls directly is not a good idea because this is not a stable ABI. The numbers can in theory change between service packs and even a plain update.

在32位Windows上使用的指令在所有系统上也不相同!

The instruction used on 32-bit Windows is not the same on all systems either!

Windows NT和2000始终使用int 2e. Windows XP在较新的" Intel/AMD CPU上运行时,开始使用 SysEnter /SysCall奔腾II,AMD K7和更高版本).由于Windows XP还支持较早的CPU,因此它使用了一些辅助功能(SystemCallStub)进入内核模式.此函数(之后,此函数的地址)存储在可访问的内存页中通过位于0x7ffe0000的所有名为_KUSER_SHARED_DATA的进程进行.

Windows NT and 2000 always uses int 2e. Windows XP started using SysEnter/SysCall when running on "newer" Intel/AMD CPUs (Pentium II, AMD K7, and later). Because Windows XP also supported older CPUs, it used a little helper function (SystemCallStub) to enter kernel mode. This function (and later, the address of this function) is stored in a memory page accessible by all processes called _KUSER_SHARED_DATA located at 0x7ffe0000.

仍然支持原始的int 2e方法,但是我不确定为什么64位Windows会费心检查使用哪种方法,因为它运行的每个CPU都支持SysCall.我的Windows 8计算机无法检查:

The original int 2e method is still supported, but I'm not sure why 64-bit Windows bothers checking which method to use, since every CPU it runs on supports SysCall. My Windows 8 machine does not check:

0:000> uf ntdll!NtTerminateProcess
ntdll!ZwTerminateProcess:
000007ff`1ad52ea0 4c8bd1          mov     r10,rcx
000007ff`1ad52ea3 b82a000000      mov     eax,2Ah
000007ff`1ad52ea8 0f05            syscall
000007ff`1ad52eaa c3              ret

无论如何,这些只是实现细节,它们可以随时更改.参见 https://j00ru.vexillium.org/syscalls/nt/64/用于按Windows内核版本细分的x64 NT系统调用号的反向工程表. (请勿在可移植代码中使用,仅用于满足您对Windows和/或asm的工作原理的好奇心的实验.)

These are just implementation details anyway, and they can change at any time. See https://j00ru.vexillium.org/syscalls/nt/64/ for a reverse-engineered table of x64 NT system-call numbers broken down by Windows kernel version. (Do not use in portable code, only for experiments to satisfy your curiosity about how Windows and/or asm works.)

int 2e可能要慢一些,所以如果要保持便携性",只需在64位代码中使用SysCall在32位代码中使用int 2e.

int 2e is probably a little bit slower, so just use SysCall in 64-bit code and int 2e in 32-bit code if you want to stay "portable".

这篇关于仅使用系统调用而不是Windows dll制作程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆