¿Llamadas al sistema en Windows y API nativa?

Question

Recientemente he estado usando gran cantidad de lenguaje ensamblador en los sistemas operativos * NIX. Me preguntaba sobre el dominio de Windows.

---

convención de llamada en Linux:

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

Eso es todo. Así es como deberíamos hacer una llamada al sistema en Linux.

de referencia de todos los sistemas de llamadas en Linux:

En cuanto a los cuales $ SYS_Call_NUM & qué parámetros podemos utilizar esta referencia: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

referencia oficial: http://kernel.org/doc/man-pages/online/dir_section_2.html

---

convención de llamada en Windows:

???

de referencia de todos los sistemas de llamadas en Windows:

???

no oficial: http://www.metasploit.com/users/opcode/syscalls.html, pero ¿cómo lo uso en el montaje de éstos a menos que sepa la convención de llamada.

OFICIAL: ???

• Si usted dice, no lo documentaron. Entonces, ¿cómo se va a escribir libc para Windows sin conocer las llamadas al sistema? ¿Cómo va uno a hacer la programación de la Asamblea de Windows? Al menos en la programación del controlador uno necesita saber esto. ¿derecho?

---

Ahora, cuál está para arriba con la llamada API nativo? ¿Es Native API & System calls for windows ambos son términos diferentes que se refieren a lo mismo? Con el fin de confirmar que compararon estos a partir de dos fuentes no oficiales Llamadas

Sistema: http://www.metasploit.com/users/opcode/syscalls.html

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

Mis observaciones:

1. Todas las llamadas al sistema que comienzan con las letras Nt donde como La API nativa consiste en muchas funciones que no comienzan con las letras Nt.
2. System Call of windows son subconjunto de Native API. Las llamadas al sistema son solo parte de la API nativa.

Puede alguno confirmar esto y explicar.

EDIT:

No había otra respuesta. Fue una segunda respuesta. Realmente me gustó, pero no sé por qué el que responde lo ha eliminado. Le solicito que vuelva a publicar su respuesta.

Answer 1

Si está realizando la programación de ensamblaje en Windows, no realiza llamadas de sistema manuales. Utiliza NTDLL y la API nativa para hacer eso por usted.

La API nativa es simplemente una envoltura alrededor del lado del kernelmode. Todo lo que hace es realizar un syscall para la API correcta.

NUNCA necesita llamar el sys manualmente para que toda su pregunta sea redundante.

Los códigos de syscall de Linux no cambian, Windows sí, por eso es necesario trabajar a través de una capa de abstracción adicional (también conocida como NTDLL).

EDIT:

Además, incluso si está trabajando a nivel de montaje, todavía tiene acceso completo a la API de Win32, no hay razón para estar con la API de NT para empezar! Las importaciones, exportaciones, etc. funcionan bien en los programas de ensamblaje.

Edit2:

Si realmente quiere hacer llamadas al sistema manuales, vas a tener que invertir NTDLL relevante para cada versión de Windows, agregue la detección de versiones (a través del PEB), y llevar a cabo una búsqueda para cada llamada al sistema llamada.

Sin embargo, eso sería una tontería. NTDLL está ahí por una razón.

Answer 2

Las llamadas al sistema de Windows se realizan llamando a las DLL del sistema, como kernel32.dll o gdi32.dll, que se realiza con las llamadas de subrutina normales. Los mecanismos para atrapar en la capa con privilegios del sistema operativo no están documentados, pero eso está bien porque las DLL como kernel32.dll hacen esto por usted.

Y por llamadas al sistema, me refiero a los puntos de entrada de Windows API documentadas como CreateProcess() o GetWindowText(). Los controladores de dispositivos generalmente usarán una API diferente del DDK de Windows.

Answer 3

OFICIAL convención de llamada en Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(espero que este enlace sobrevive en el futuro; de no ser así, sólo la búsqueda de "Convenciones de software x64" en MSDN).

La convención de llamada a función difiere en Linux & Windows x86_64. En ambos ABI, los parámetros se pasan preferiblemente a través de registros, pero los registros utilizados difieren. Más sobre Linux ABI se puede encontrar en http://www.x86-64.org/documentation/abi.pdf

Answer 4

La otra cosa que necesita saber sobre la convención de syscall de Windows es que, según tengo entendido, las tablas de syscall se generan como parte del proceso de compilación. Esto significa que simplemente pueden cambiar, nadie los rastrea. Si alguien agrega uno nuevo en la parte superior de la lista, no importa. NTDLL todavía funciona, por lo que todos los que llaman NTDLL todavía funcionan.

Incluso el mecanismo utilizado para realizar syscalls (que int, o sysenter) no está arreglado en piedra y ha cambiado en el pasado, y creo que érase una vez la misma versión de Windows usaba diferentes DLL que usaban diferentes entradas mecanismos dependiendo de la CPU en la máquina.