Las llamadas al sistema de ventanas y API nativo?
https://stackoverflow.com/questions/2489889
-
21-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Recientemente he estado usando gran cantidad de lenguaje ensamblador en sistemas operativos * NIX. Me preguntaba sobre el dominio de las ventanas.
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 debemos hacer una llamada al sistema de Linux.
Referencia de todos los sistemas de llamadas en Linux:
Con respecto a los cuales $ SYS_Call_NUM y qué parámetros podemos utilizar esta referencia: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html
Oficial: http://kernel.org/doc/man-pages /online/dir_section_2.html
convención de llamada en Windows:
???
Referencia de todos los sistemas de llamadas en Windows:
???
No Oficial: http://www.metasploit.com/users/opcode/syscalls. html , pero ¿cómo se utiliza esto en el montaje a menos que sepa la convención de llamada.
OFICIAL: ???
- Si usted dice, no se documentaron. Entonces ¿cómo se va a escribir libc para las ventanas sin conocer las llamadas al sistema? ¿Cómo se va a hacer una programación Asamblea de Windows? Al menos en la programación del controlador es necesario conocer estos. ¿verdad?
Ahora, cuál está para arriba con la llamada API nativo? Se Native API y System calls for windows ambos son diferentes términos que se refieren a la misma cosa? Con el fin de confirmar Comparé estas dos fuentes no oficiales de
Llamadas al sistema: http://www.metasploit.com/users/opcode/syscalls .html
API nativo: http://undocumented.ntinternals.net/aindex.html
Mis observaciones:
- Todas las llamadas al sistema están comenzando con las letras
Ntdonde como API nativo está formado por gran cantidad de funciones que no empiezan con las letrasNt. -
System Call of windowsson subconjunto deNative API. Las llamadas al sistema son sólo parte de la API nativa.
Puede alguien confirmar esto y explicar.
EDIT:
No había otra respuesta. Fue una segunda respuesta. Me gustó mucho, pero no sé qué responde la haya eliminado. Le solicito volver a publicar su respuesta.
Solución
Si estás haciendo de programación en ensamblador bajo Windows que no hace llamadas al sistema manual. Se utiliza NTDLL y la API nativa de hacer eso para usted.
La API nativa es simplemente una envoltura alrededor de la parte KernelMode de las cosas. Todo lo que hace es realizar una llamada al sistema para la API correcta.
nunca debería ser necesario a syscall manualmente por lo que toda su pregunta es redundante.
códigos de llamadas al sistema Linux no cambian, tareas de Windows es por eso que necesita para trabajar a través de una capa de abstracción extra (también conocido 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., todos funcionan bien en los programas de montaje.
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 de llamada al sistema para cada llamada.
Sin embargo, eso sería tonto. NTDLL está ahí por una razón.
La gente ya ha hecho la parte de ingeniería inversa: véase el https: //j00ru.vexillium .org / llamadas al sistema / NT / 64 / de una tabla de números de llamadas al sistema para cada núcleo de Windows. (Tenga en cuenta que las filas posteriores cambian incluso entre las versiones de Windows 10.) De nuevo, esto es una mala idea fuera de uso personal sólo para experimentos en su propia máquina para aprender más acerca de Windows internas asm y / o. No hacerlo sistema en línea pone en código que distribuya a cualquier otra persona.
Otros consejos
La otra cosa que hay que saber sobre la convención de llamada al sistema de ventanas es que según entiendo las tablas syscall se generan como parte del proceso de construcción. Esto significa que simplemente se puede cambiar - nadie les sigue la pista. Si alguien añade una nueva en la parte superior de la lista, no importa. NTDLL todavía funciona, por lo que todos los demás que llama NTDLL todavía funciona.
Aunque el mecanismo utilizado para realizar llamadas al sistema (que int o SYSENTER) no está fijado en piedra y que ha cambiado en el pasado, y creo que en otro tiempo la misma versión de Windows utiliza diferentes archivos DLL, que utilizan diferentes mecanismos de entrada dependiendo de la CPU en la máquina.
llamadas de sistema de Windows se llevan a cabo al poner en DLL del sistema, tales como kernel32.dll o gdi32.dll, que se hace con las llamadas a subrutinas ordinarias. Los mecanismos para atrapar en la capa privilegiada OS es indocumentado, pero eso está bien porque DLL como kernel32.dll hacer esto para usted.
Y por llamadas al sistema, me refiero a documentados puntos de entrada de la API de Windows como CreateProcess() o GetWindowText(). Los controladores de dispositivos generalmente utilizar un API diferente de la DDK de Windows.
Yo estaba interesado en hacer una llamada a la API de Windows en el montaje sin importaciones (como un ejercicio educativo), así que escribí la siguiente asamblea FASM para hacer lo NTDLL! Hace NtCreateFile. Es una demostración áspera en mi versión de 64 bits de Windows (Win10 1803 Versión 10.0.17134), y se bloquea a cabo después de la llamada, pero el valor de retorno de la llamada al sistema es cero por lo que es un éxito. Todo está configurado por la convención de llamada Windows x64, entonces el número de llamadas al sistema se carga en RAX, y entonces es las instrucciones de montaje de llamada al sistema para ejecutar la llamada. Mi ejemplo se crea el archivo c: \. HelloWorldFile_FASM, por lo que se tiene que ejecutar "como administrador"
format PE64 GUI 4.0
entry start
section '.text' code readable executable
start:
;puting the first four parameters into the right registers
mov rcx, _Handle
mov rdx, [_access_mask]
mov r8, objectAttributes
mov r9, ioStatusBlock
;I think we need 1 stack word of padding:
push 0x0DF0AD8B
;pushing the other params in reverse order:
push [_eaLength]
push [_eaBuffer]
push [_createOptions]
push [_createDisposition]
push [_shareAcceses]
push [_fileAttributes]
push [_pLargeInterger]
;adding the shadow space (4x8)
; push 0x0
; push 0x0
; push 0x0
; push 0x0
;pushing the 4 register params into the shadow space for ease of debugging
push r9
push r8
push rdx
push rcx
;now pushing the return address to the stack:
push endOfProgram
mov r10, rcx ;copied from ntdll!NtCreateFile, not sure of the reason for this
mov eax, 0x55
syscall
endOfProgram:
retn
section '.data' data readable writeable
;parameters------------------------------------------------------------------------------------------------
_Handle dq 0x0
_access_mask dq 0x00000000c0100080
_pObjectAttributes dq objectAttributes ; at 00402058
_pIoStatusBlock dq ioStatusBlock
_pLargeInterger dq 0x0
_fileAttributes dq 0x0000000000000080
_shareAcceses dq 0x0000000000000002
_createDisposition dq 0x0000000000000005
_createOptions dq 0x0000000000000060
_eaBuffer dq 0x0000000000000000 ; "optional" param
_eaLength dq 0x0000000000000000
;----------------------------------------------------------------------------------------------------------
align 16
objectAttributes:
_oalength dq 0x30
_rootDirectory dq 0x0
_objectName dq unicodeString
_attributes dq 0x40
_pSecurityDescriptor dq 0x0
_pSecurityQualityOfService dq securityQualityOfService
unicodeString:
_unicodeStringLength dw 0x34
_unicodeStringMaxumiumLength dw 0x34, 0x0, 0x0
_pUnicodeStringBuffer dq _unicodeStringBuffer
_unicodeStringBuffer du '\??\c:\HelloWorldFile_FASM' ; may need to "run as adinistrator" for the file create to work.
ioStatusBlock:
_status_pointer dq 0x0
_information dq 0x0
securityQualityOfService:
_sqlength dd 0xC
_impersonationLevel dd 0x2
_contextTrackingMode db 0x1
_effectiveOnly db 0x1, 0x0, 0x0
He utilizado la documentación para Ntdll! NtCreateFile, y también he utilizado el depurador de núcleo para mirar y copiar muchos de los parametros.
__kernel_entry NTSTATUS NtCreateFile(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PLARGE_INTEGER AllocationSize OPTIONAL,
IN ULONG FileAttributes,
IN ULONG ShareAccess,
IN ULONG CreateDisposition,
IN ULONG CreateOptions,
IN PVOID EaBuffer OPTIONAL,
IN ULONG EaLength
);
OFICIAL convención de llamada en Windows: http://msdn.microsoft.com /en-us/library/7kcdt6fy.aspx
(espero que este enlace sobrevive en el futuro; si no lo hace, sólo la búsqueda de "convenios de software x64" en MSDN).
La convención función de llamada difiere en Linux y Windows x86_64. En ambos ABIs, los parámetros se pasan preferentemente a través de los registros, pero los registros utilizados difieren. Más en el ABI Linux se puede encontrar en http://www.x86-64.org /documentation/abi.pdf
