Les appels système dans Windows et API native?

https://stackoverflow.com/questions/2489889

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 lettres Nt.
System Call of windows sont sous-ensemble de Native 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

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow