Les appels système dans Windows et API native?
-
21-09-2019 - |
Question
Récemment, je me sers beaucoup de la langue Assemblée * NIX les systèmes d'exploitation. Je me demandais sur le domaine Windows.
La convention d'appel dans linux:
mov $SYS_Call_NUM, %eax
mov $param1 , %ebx
mov $param2 , %ecx
int $0x80
Thats it. Voilà comment nous devrions faire un appel système linux.
Référence de système appelle linux:
En ce qui concerne ce qui SYS_Call_NUM $ et quels sont les paramètres que nous pouvons utiliser cette référence: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html
OFFICIEL Référence: http://kernel.org/doc/man-pages /online/dir_section_2.html
La convention d'appel dans Windows:
???
Référence de système appelle dans Windows:
???
non officiel: http://www.metasploit.com/users/opcode/syscalls. html , mais comment puis-je utiliser dans l'ensemble à moins que je connais la convention d'appel.
OFFICIEL: ???
- Si vous dites, ils ne documentées il. Alors, comment est-on va écrire libc pour Windows sans connaître les appels système? Comment est-on va faire la programmation de l'Assemblée de Windows? Atleast dans la programmation du pilote, il faut connaître ces derniers. droit?
Maintenant, ce qui est avec le soi-disant API native? Est-Native API
& System calls for windows
sont deux termes différents référence à même chose? Afin de confirmer que je comparais ces de deux sources non officielles
Appels système: http://www.metasploit.com/users/opcode/syscalls .html
API native: http://undocumented.ntinternals.net/aindex.html
Mes observations:
- Tous les appels système commencent avec des lettres
Nt
alors que l'API native est composée de beaucoup de fonctions qui ne sont pas en commençant par les lettresNt
. -
System Call of windows
sont sous-ensemble deNative API
. Les appels système ne sont qu'une partie de l'API native.
Quelqu'un peut-il confirmer et expliquer.
EDIT:
Il y avait une autre réponse. Ce fut une 2ème réponse. J'ai vraiment aimé, mais je ne sais pas pourquoi answerer a supprimé. Je lui demande de rediffuser sa réponse.
La solution
Si vous faites la programmation en assembleur sous Windows vous ne faites pas syscalls manuel. Vous utilisez NTDLL et l'API native de le faire pour vous.
L'API native est simplement une enveloppe autour du côté KernelMode des choses. Tout ce qu'il fait est effectuer une syscall pour l'API correcte.
Vous ne devriez jamais besoin de syscall manuellement est donc redondante votre question entière.
Linux codes syscall ne changent pas, ne de Windows c'est la raison pour laquelle vous avez besoin de travailler à travers une couche d'abstraction supplémentaire (alias NTDLL).
EDIT:
En outre, même si vous travaillez au niveau de l'assemblage, vous avez toujours accès à l'API Win32, il n'y a aucune raison d'être en utilisant l'API NT pour commencer! Les importations, les exportations, etc tous fonctionnent très bien dans les programmes de montage.
EDIT2:
Si vous voulez vraiment faire syscalls manuel, vous allez avoir besoin d'inverser NTDLL pour chaque version de Windows nécessaire, ajoutez la détection de version (via le PASE) et effectuer une recherche de syscall pour chaque appel.
Cependant, ce serait stupide. NTDLL est là pour une raison.
Les gens ont déjà fait la partie ingénierie inverse: voir https: //j00ru.vexillium .org / syscalls / nt / 64 / pour une table de numéros appel système pour chaque noyau Windows. (Notez que les lignes plus tard ne changent même entre les versions de Windows 10.) Encore une fois, cela est une mauvaise idée en dehors de-usage personnel exclusivement des expériences sur votre propre machine pour en savoir plus sur asm et / ou fonctionnement interne de Windows. Ne pas les appels système en ligne dans le code que vous diffusez à quelqu'un d'autre.
Autres conseils
L'autre chose que vous devez savoir sur les fenêtres convention syscall est que si je comprends bien les tables syscall sont générés dans le cadre du processus de construction. Cela signifie qu'ils peuvent simplement changer - personne ne les suit. Si quelqu'un ajoute un nouveau en haut de la liste, il n'a pas d'importance. NTDLL fonctionne toujours, donc tout le monde qui appelle NTDLL fonctionne toujours.
Même le mécanisme utilisé pour effectuer des appels système (qui int, ou sysenter) n'est pas fixée dans la pierre et qui a changé dans le passé, et je pense que une fois la même version de Windows utilisé différentes DLL qui ont utilisé différents mécanismes d'entrée en fonction de la CPU dans la machine.
appels système Windows sont effectuées en appelant DLL système tels que kernel32.dll
ou gdi32.dll
, qui se fait avec des appels de sous-programme ordinaire. Les mécanismes de piégeage dans la couche privilégiée OS est en situation irrégulière, mais qui est bien parce que DLLs comme kernel32.dll
font pour vous.
Et par les appels système, je fais référence à des points d'entrée de l'API de Windows documentés comme CreateProcess()
ou GetWindowText()
. Les pilotes de périphériques utilisent généralement une autre API de Windows DDK.
Je me suis intéressé à faire un appel API Windows dans l'assemblage sans les importations (comme un exercice pédagogique), donc je l'ai écrit l'assemblée FASM suivante pour faire ce que fait NTDLL! NtCreateFile. Il est une démonstration grossière sur ma version 64 bits de Windows (Win10 1803 Version 10.0.17134), et il se bloque après l'appel, mais la valeur de retour du syscall est nul si elle est réussie. Tout est mis en place par la convention d'appel x64 de Windows, puis le numéro d'appel du système est chargé dans RAX, et il est l'instruction de montage syscall pour exécuter l'appel. Mon exemple crée le fichier c:. \ HelloWorldFile_FASM, il doit être exécuté « en tant qu'administrateur »
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
J'ai utilisé la documentation Ntdll! NtCreateFile, et j'ai aussi utilisé le débogueur du noyau pour regarder et copier beaucoup de params.
__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
);
OFFICIEL Convention d'appel dans Windows: http://msdn.microsoft.com /en-us/library/7kcdt6fy.aspx
(espérons que ce lien survit à l'avenir, si elle ne constitue pas, juste pour la recherche « Conventions de logiciels x64 » sur MSDN).
La convention d'appel de fonction est différente dans Linux & Windows x86_64. Dans les deux Abis, les paramètres sont de préférence transmises par l'intermédiaire de registres, mais les registres utilisés diffèrent. Plus de détails sur l'ABI Linux peut être trouvé à http://www.x86-64.org /documentation/abi.pdf