Appels système dans windows & API Native?
Récemment, j'ai été en utilisant beaucoup de langage d'Assemblage sous *NIX systèmes d'exploitation. Je me demandais sur le domaine windows.
Convention d'appel dans linux:
mov $SYS_Call_NUM, %eax
mov $param1 , %ebx
mov $param2 , %ecx
int $0x80
C'est tout. C'est la façon dont nous devrions faire un appel système sous linux.
Renvoi de tous les appels système sous linux:
À l'égard de laquelle $SYS_Call_NUM & les paramètres, nous pouvons utiliser cette référence : http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html
Référence OFFICIELLE : http://kernel.org/doc/man-pages/online/dir_section_2.html
Convention d'appel dans Windows:
???
Renvoi de tous les appels système dans Windows:
???
Non officiel : http://www.metasploit.com/users/opcode/syscalls.html , mais comment puis-je les utiliser dans l'assemblée, si je sais que la convention d'appel.
OFFICIEL : ???
- Si vous le dites, ils n'ont pas documenté. Alors comment peut-on écrire de la libc pour windows sans le savoir, les appels système? Comment on va faire Windows Assemblage de programmation? Au moins dans la programmation d'un pilote a besoin de connaître ces. droit?
Maintenant, whats up avec le soi-disant API Native? Est Native API
& System calls for windows
les deux sont différents termes se référant à la même chose? Pour confirmer, j'ai comparé ces deux Sources OFFICIEUSES
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 sont commençant par les lettres
Nt
où, comme API Native est composé de beaucoup de fonctions qui ne sont pas au début avec des 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 cela et expliquer.
EDIT:
Il y avait une autre réponse. C'était une 2ème réponse. J'ai vraiment aimé, mais je ne sais pas pourquoi répondeur a été supprimée. - Je lui demander de le reposter sa réponse.
- Lire ceci: stackoverflow.com/questions/919051/...
- Votre metasploit liens sont brisés...
Vous devez vous connecter pour publier un commentaire.
Si vous faites de l'assemblée de la programmation sous Windows, vous n'avez pas le faire en manuel syscalls. Vous utilisez NTDLL et de l'API Native de le faire pour vous.
L'API Native est tout simplement un wrapper autour de la kernelmode côté des choses. Tout ce qu'il fait est de procéder à un syscall pour l'API correcte.
Vous ne devriez JAMAIS manuellement syscall pour que toute votre question est redondante.
Linux syscall les codes ne changent pas, Windows de le faire, c'est pourquoi vous avez besoin de travailler à travers une couche d'abstraction supplémentaire (aka NTDLL).
EDIT:
Aussi, même si vous travaillez au niveau de l'assemblage, vous avez toujours le plein accès à l'API Win32, il n'y a pas de raison d'être à l'aide de la NT API pour commencer! Les importations, les exportations, etc tous fonctionnent très bien dans le montage de programmes.
EDIT2:
Si vous voulez VRAIMENT le faire en manuel syscalls, vous allez avoir besoin pour inverser NTDLL pour chaque version de Windows, ajouter la détection de la version (via le PEB), et d'effectuer un syscall de recherche pour chaque appel.
Cependant, ce serait ridicule. NTDLL est là pour une raison.
Personnes ont déjà fait le reverse-engineering de la partie: voir https://j00ru.vexillium.org/syscalls/nt/64/ pour une table de système de numéros d'appel pour chaque noyau de Windows. (Notez que plus tard, les lignes ne changent même entre les versions de Windows 10.) Encore une fois, c'est une mauvaise idée à l'extérieur à des fins personnelles uniquement à des expériences sur votre propre ordinateur pour en savoir plus sur l'asm et/ou Windows internals. Ne pas système en ligne d'appels dans le code que vous distribuez à quelqu'un d'autre.
L'autre chose que vous devez savoir sur windows syscall convention est que, comme je comprends le syscall tables sont générées 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 encore, donc tout le monde qui appelle NTDLL fonctionne toujours.
Même le mécanisme utilisé pour effectuer des appels (qui int, ou sysenter) n'est pas fixé dans la pierre et qui a changé dans le passé, et je pense qu'une fois la même version de windows utilisée Dll différents qui utilisent différents mécanismes d'entrée en fonction du CPU de la machine.
Windows appels système sont effectuées par l'appel système Dll, telles que
kernel32.dll
ougdi32.dll
, ce qui est fait avec de simples appels de sous-programme. Les mécanismes de piégeage dans le système d'exploitation privilégié de la couche est sans-papiers, mais c'est bien parce que la Dll commekernel32.dll
le faire pour vous.Et par les appels système, je fais allusion à l'documenté Windows API points d'entrée comme
CreateProcess()
ouGetWindowText()
. Les pilotes de périphériques utilisent généralement une API différente à partir de le kit DDK de Windows.J'étais intéressé à faire un appel API de windows à l'assemblée avec aucun des importations (comme un exercice éducatif), j'ai donc écrit ce qui suit FASM assemblée à faire ce NtDll!NtCreateFile n'. C'est un rude démonstration 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 de la syscall est nulle si elle est couronnée de succès. Tout est mis en place par le Windows x64 convention d'appel, puis le système de numéro d'appel est chargé dans RAX, et puis c'est le syscall instructions de montage pour exécuter l'appel. Mon exemple crée le fichier c:\HelloWorldFile_FASM, de sorte qu'il doit être exécuté "en tant qu'administrateur".
J'ai utilisé la documentation de Ntdll!NtCreateFile, et j'ai aussi utilisé le débogueur de noyau à regarder et copier beaucoup de la params.
mov r10, rcx
est probablement pour la même raison que Linux:syscall
lui-même clobbersrcx
(etr11
) avant que le noyau de la voir, de sorte que le noyausyscall
convention d'appel utiliser10
au lieu dercx
. Quelle version(s) de Windows ne ce code de travail sur? Lesyscall
ABI n'est pas stable sur Windows, paramètres différents ou même un code autre queeax = 0x55
pourrait être la bonne façon de l'appeler sur les autres versions de Windows.syscall
et RCX, voir Pourquoi ne x86-64 Linux système d'appels modifier RCX, et quelle est la valeur moyenne? et Différence dans l'ABI entre Linux x86_64 les fonctions et les syscalls. Et Pourquoi Assemblée x86_64 syscall paramètres ne sont pas dans l'ordre alphabétique comme i386 pour un exemple d'une fonction wrapper comme Linux/glibcmmap
qui ne dispose que demov r10,rcx
)mov r10,rcx
est parce que le syscall interface passe le premier paramètre via r10 au lieu de RCX. Régulièrement 64-bit appel de fonction utilise RCX, RDX, R8 et R9. Syscall utilise R10, RDX, R8 et R9. La raison pour cela est que lasyscall
instruction instruction remplace RCX (il remplace également le R11).Microsoft a choisi d'utiliser R10 pour le premier paramètre de l'appel système au lieu donc pourquoi vous verrezmov r10, rcx
push 0x0DF0AD8B
) est de maintenir la pile de l'alignement pour des raisons de performances. Vous devez ajouter 8 octets (un quadword) de rembourrage SI il existe un équivalent d'un même nombre de pousse fait avant le syscall (sinon vous n'avez pas besoin de rembourrage). C'est parce que la pile n'est pas correctement alignée par 8 au pointstart
est exécuté parce que l'adresse de retour est sur la pile.syscall
. Vous avez poussé l'équivalent de 13 quadwords pour configurer le syscall vous avez besoin d'ajuster la pile après le syscall pour restaurer le pointeur de pile à son état précédent avant de faire leret
. 13*8=104 octets mis sur la pile avant syscall. Après le syscall vous pouvez simplement faireadd rsp, 104
pour nettoyer la pile.mov rcx, _Handle
avecmov r10, _Handle
et ensuite, vous pouvez supprimer lemov r10, rcx
tout à fait. Vous pouvez également modifierpush rcx
àpush r10
syscall
directement (sans passer par les paramètres passés pour commencer), l'adresse de retour de l'adresse n'a pas à avoir une quelconque valeur.syscall
de ne pas l'utiliser pour retourner à (syscall
sera de retour à l'instruction aprèssyscall
). Ainsi, au lieu depush endOfProgram
vous pouvez simplement appuyer sur n'importe quel registre (sa valeur n'a pas d'importance) commepush rbp
(oupush rax
registre n'a pas d'importance)OFFICIEL de la convention d'Appel dans Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx
(espérons que ce lien survit dans l'avenir; s'il ne le fait pas, il suffit de chercher "x64 Logiciel Conventions" sur MSDN).
La fonction de convention d'appel diffère dans Linux & Windows x86_64. Dans les deux ABIs, les paramètres sont de préférence transmis via les registres, les registres utilisés diffèrent. Plus sur l'ABI Linux peut être trouvé à http://www.x86-64.org/documentation/abi.pdf