Systemaufrufe in Windows & Native API?

Question

Kürzlich habe ich viele Assembly-Sprache in * NIX-Betriebssystemen verwendet. Ich habe mich über die Windows Domain gewundert.

---

Aufrufkonvention in Linux:

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

Thats it. So sollten wir in Linux einen Systemaufruf machen.

Referenz aller Systemaufrufe unter Linux:

In Bezug auf die & $ SYS_Call_NUM, die wir diese Referenz-Parameter verwenden: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

OFFIZIELLE Referenz: http://kernel.org/doc/man-pages/online/dir_section_2.html

---

Aufrufkonvention

in Windows:

???

Referenz aller Systemaufrufe unter Windows:

???

Inoffiziell: http://www.metasploit.com/users/opcode/syscalls.html, aber wie verwende ich diese in Assembler, es sei denn, ich kenne die Aufrufkonvention.

OFFIZIELLE: ???

• Wenn Sie sagen, sie haben es nicht dokumentiert. Wie wird man dann libc für Windows schreiben, ohne Systemaufrufe zu kennen? Wie wird man Windows Assembly programmieren? Bei der Treiberprogrammierung muss man diese kennen. Recht?

---

Nun, was ist mit dem so genannten Mutter API up? Ist Native API & System calls for windows beide unterschiedliche Begriffe, die sich auf dasselbe beziehen? Um verglich ich diese aus zwei inoffiziellen Quellen

Systems zu bestätigen Anrufe: http://www.metasploit.com/users/opcode/syscalls.html

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

Meine Beobachtungen:

1. Alle Systemaufrufe beginnen mit den Buchstaben Nt wo als Native API besteht aus vielen Funktionen, die nicht mit Buchstaben Nt beginnen.
2. System Call of windows sind Teilmenge von Native API. Systemaufrufe sind nur ein Teil der nativen API.

Kann jeder dies bestätigen und erklären.

EDIT:

Es gibt eine andere Antwort war. Es war eine zweite Antwort. Ich mochte es wirklich, aber ich weiß nicht, warum der Beantworter es gelöscht hat. Ich bitte ihn, seine Antwort zu wiederholen.

Answer 1

Wenn Sie Assembly-Programmierung unter Windows durchführen, führen Sie keine manuellen Systemaufrufe aus. Sie verwenden NTDLL und die native API, um dies für Sie zu tun.

Die native API ist einfach ein Wrapper rund um den Kernelmodus. Es führt lediglich einen Syscall für die richtige API aus.

Sie sollten NIEMALS manuell syscall, so dass Ihre gesamte Frage redundant ist.

Linux Syscall-Codes ändern sich nicht, Windows tun, deshalb müssen Sie eine zusätzliche Abstraktionsschicht (alias NTDLL) arbeiten.

EDIT:

Auch wenn Sie auf Baugruppenebene arbeiten, können Sie immer noch vollen Zugriff auf den Win32-API haben, gibt es keinen Grund, die NT-API zu verwenden zu beginnen! Importe, Exporte usw. funktionieren alle gut in Assemblierungsprogrammen.

EDIT2:

Wenn Sie wirklich wollen manuelle syscalls zu tun, Sie gehen NTDLL für jede relevante Windows-Version, fügen Sie Versionserkennung (über die PEB), und führen Sie einen syscall-Lookup für jede müssen umkehren Anruf.

Allerdings wäre das albern. NTDLL ist aus einem bestimmten Grund da.

Answer 2

Windows-Systemaufrufe werden durch Aufrufen von System-DLLs wie kernel32.dll oder gdi32.dll ausgeführt, was mit gewöhnlichen Subroutinenaufrufen erfolgt. Die Mechanismen zum Einfangen in die privilegierte Schicht des Betriebssystems sind undokumentiert, aber das ist in Ordnung, weil DLLs wie kernel32.dll dies für Sie tun.

Und durch Systemaufrufe, ich verweise auf dokumentierte Windows-API-Einstiegspunkte wie CreateProcess() oder GetWindowText(). Gerätetreiber verwenden in der Regel eine andere API als das Windows DDK.

Answer 3

OFFIZIELLE Aufrufkonvention in Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(hoffen, dass diese Verbindung in Zukunft überlebt, wenn es nicht, nur die Suche für "x64 Software Konventionen" auf MSDN).

Die Funktion Aufrufkonvention unterscheidet sich in Linux & Windows x86_64. In beiden ABIs werden Parameter vorzugsweise über Register weitergegeben, aber die verwendeten Register unterscheiden sich. Mehr über Linux ABI finden Sie unter http://www.x86-64.org/documentation/abi.pdf

Answer 4

Die andere Sache, die Sie über die Windows-Syscall-Konvention wissen müssen, ist, dass, wie ich es verstehe, die Syscall-Tabellen als Teil des Build-Prozesses generiert werden. Das bedeutet, dass sie sich einfach ändern können - niemand verfolgt sie. Wenn jemand einen neuen an der Spitze der Liste hinzufügt, ist das egal. NTDLL funktioniert immer noch, also funktioniert jeder andere, der NTDLL aufruft, immer noch.

Sogar der Mechanismus zur Ausführung von syscalls (welcher int oder sysenter) ist nicht in Stein fixiert und hat sich in der Vergangenheit geändert, und ich denke, dass einmal die gleiche Version von Windows verschiedene DLLs verwendet, die anderen Eintrag verwendet Mechanismen abhängig von der CPU in der Maschine.