windows和本机API中的系统调用?

Recently I've been using lot of Assembly language in *NIX operating systems. I was wondering about the windows domain.

最近我在*NIX操作系统中使用了大量的汇编语言。我想知道windows域。

Calling convention in linux:

在linux中调用协定:

mov $SYS_Call_NUM, %eax
mov $param1 , %ebx
mov $param2 , %ecx
int $0x80

Thats it. That is how we should make a system call in linux.

这是它。这就是我们在linux中进行系统调用的方式。

Reference of all system calls in linux:

linux中所有系统调用的参考:

Regarding which $SYS_Call_NUM & which parameters we can use this reference : http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

关于哪个$SYS_Call_NUM和哪些参数我们可以使用这个引用:http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

OFFICIAL Reference : http://kernel.org/doc/man-pages/online/dir_section_2.html

官方参考:http://kernel.org/doc/man-pages/online/dir_section_2.html

Calling convention in Windows:

在窗口调用协定:

???

? ? ?

Reference of all system calls in Windows:

视窗内所有系统呼叫的参考资料:

???

? ? ?

Unofficial : http://www.metasploit.com/users/opcode/syscalls.html , but how do I use these in assembly unless I know the calling convention.

非官方的:http://www.metasploit.com/users/opcode/syscalls.html，但是除非我知道调用约定，否则我如何在程序集中使用它们。

OFFICIAL : ???

官员:? ? ?

If you say, they didn't documented it. Then how is one going to write libc for windows without knowing system calls? How is one gonna do Windows Assembly programming? Atleast in the driver programming one needs to know these. right?
如果你说，他们没有记录下来。那么，如何在不知道系统调用的情况下为windows编写libc呢?如何进行Windows汇编编程?至少在驱动程序编程中，我们需要知道这些。对吧?

Now, whats up with the so called Native API? Is Native API & System calls for windows both are different terms referring to same thing? In order to confirm I compared these from two UNOFFICIAL Sources

那么，什么是所谓的原生API呢?windows的本机API和系统调用都是指同一事物的不同术语吗?为了确认我比较了两个非官方的来源。

System Calls: http://www.metasploit.com/users/opcode/syscalls.html

系统调用:http://www.metasploit.com/users/opcode/syscalls.html

Native API: http://undocumented.ntinternals.net/aindex.html

本机API:http://undocumented.ntinternals.net/aindex.html

My observations:

我的观察:

All system calls are beginning with letters Nt where as Native API is consisting of lot of functions which are not beginning with letters Nt.
所有的系统调用都是以Nt开头的，而作为本机API的许多函数都不是以Nt开头的。
System Call of windows are subset of Native API. System calls are just part of Native API.
windows的系统调用是本机API的子集。系统调用只是本机API的一部分。

Can any one confirm this and explain.

谁能证实这一点并解释一下吗?

EDIT:

编辑:

There was another answer. It was a 2nd answer. I really liked it but I don't know why answerer has deleted it. I request him to repost his answer.

另一个答案。这是第二个答案。我真的很喜欢它，但是我不知道为什么answerer把它删掉了。我请求他把他的回答重新张贴出来。

4 个解决方案

#1

If you're doing assembly programming under Windows you don't do manual syscalls. You use NTDLL and the Native API to do that for you.

如果你在Windows下进行汇编编程，你就不会做手动的系统操作。您可以使用NTDLL和本机API为您实现这一点。

The Native API is simply a wrapper around the kernelmode side of things. All it does is perform a syscall for the correct API.

本机API只是内核模式方面的包装。它所做的就是为正确的API执行一个syscall。

You should NEVER need to manually syscall so your entire question is redundant.

您永远都不需要手动syscall，因此您的整个问题都是多余的。

Linux syscall codes do not change, Windows's do, that's why you need to work through an extra abstraction layer (aka NTDLL).

Linux syscall代码不会改变，Windows也会，这就是为什么需要通过一个额外的抽象层(即NTDLL)来工作。

EDIT:

编辑:

Also, even if you're working at the assembly level, you still have full access to the Win32 API, there's no reason to be using the NT API to begin with! Imports, exports, etc all work just fine in assembly programs.

而且，即使您在程序集级别上工作，您仍然可以完全访问Win32 API，也没有理由一开始就使用NT API !进口、出口等在组装程序中都很好用。

EDIT2:

If you REALLY want to do manual syscalls, you're going to need to reverse NTDLL for each relevant Windows version, add version detection (via the PEB), and perform a syscall lookup for each call.

如果您真的想要手动执行syscalls，您将需要为每个相关的Windows版本反向NTDLL，添加版本检测(通过PEB)，并为每个调用执行syscall查找。

However, that would be silly. NTDLL is there for a reason.

然而，这是愚蠢的。NTDLL的存在是有原因的。

#2

The other thing you need to know about the windows syscall convention is that as I understand it the syscall tables are generated as part of the build process. This means that they can simply change - no one tracks them. If someone adds a new one at the top of the list, it doesn't matter. NTDLL still works, so everyone else who calls NTDLL still works.

关于windows syscall约定，您需要了解的另一件事是，正如我所理解的，syscall表是作为构建过程的一部分生成的。这意味着他们可以简单地改变——没有人跟踪他们。如果有人在列表的顶部添加了一个新的，那也没关系。NTDLL仍然有效，所以调用NTDLL的其他人仍然可以工作。

Even the mechanism used to perform syscalls (which int, or sysenter) is not fixed in stone and has changed in the past, and I think that once upon a time the same version of windows used different DLLs which used different entry mechanisms depending on the CPU in the machine.

甚至用于执行syscalls的机制(int，或sysenter)也没有固定在stone中，而且在过去已经发生了变化，我认为同一版本的windows曾经使用不同的dll，它们使用不同的入口机制，这取决于机器中的CPU。

#3

Windows system calls are performed by calling into system DLLs such as kernel32.dll or gdi32.dll, which is done with ordinary subroutine calls. The mechanisms for trapping into the OS privileged layer is undocumented, but that is okay because DLLs like kernel32.dll do this for you.

Windows系统调用是通过调用诸如kernel32之类的系统dll来执行的。dll或gdi32。dll，用普通的子例程调用完成。捕获到OS特权层的机制没有文档说明，但这没关系，因为像kernel32这样的dll。dll为你做这个。

And by system calls, I'm referring to documented Windows API entry points like CreateProcess() or GetWindowText(). Device drivers will generally use a different API from the Windows DDK.

通过系统调用，我指的是文档化的Windows API入口点，如CreateProcess()或GetWindowText()。设备驱动程序通常使用与Windows DDK不同的API。

#4

OFFICIAL Calling convention in Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

Windows的正式调用约定:http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx。

(hope this link survives in the future; if it doesn't, just search for "x64 Software Conventions" on MSDN).

(希望这种联系能在未来继续存在;如果没有，就搜索MSDN上的“x64软件约定”。

The function calling convention differs in Linux & Windows x86_64. In both ABIs, parameters are preferably passed via registers, but the registers used differ. More on the Linux ABI can be found at http://www.x86-64.org/documentation/abi.pdf

在Linux和Windows x86_64中，函数调用约定是不同的。在这两个ABIs中，参数最好通过寄存器传递，但是使用的寄存器不同。更多关于Linux ABI的信息可以在http://www.x86-64.org/documentation/abi.pdf中找到。

#1