windowslinuxassemblykernelnt-native-api

System Calls in Windows & Native API?


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


Calling convention in 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.

Reference of all system calls in 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

OFFICIAL Reference : 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.

OFFICIAL : ???


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

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

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

My observations:

  1. 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.
  2. System Call of windows are subset of Native API. System calls are just part of Native 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.


Solution

  • 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.

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

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

    Linux syscall codes do not change, Windows's do, that's why you need to work through an extra abstraction layer (aka 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.

    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.

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

    People have already done the reverse-engineering part: see https://j00ru.vexillium.org/syscalls/nt/64/ for a table of system-call numbers for each Windows kernel. (Note that the later rows do change even between versions of Windows 10.) Again, this is a bad idea outside of personal-use-only experiments on your own machine to learn more about asm and/or Windows internals. Don't inline system calls into code that you distribute to anyone else.