Chiamate di sistema in Windows e API Native?

Recentemente ho usato molto linguaggio Assembly in sistemi operativi * NIX. Mi stavo chiedendo il dominio di Windows.


Convenzione di chiamata in linux:

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

Questo è tutto. È così che dovremmo fare una chiamata di sistema in linux.

Riferimento di tutte le chiamate di sistema in linux:

Per quanto riguarda $ SYS_Call_NUM e quali parametri possiamo usare questo riferimento: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

Riferimento UFFICIALE: http://kernel.org/doc/man-pages/online/dir_section_2.html


Convenzione di chiamata in Windows:

???

Riferimento di tutte le chiamate di sistema in Windows:

???

Non ufficiale: http://www.metasploit.com/users/opcode/syscalls.html , ma come faccio a utilizzarli in assembly a meno che non conosca la convenzione di chiamata.

UFFICIALE: ???

  • Se dici, non l’hanno documentato. Allora come si può scrivere libc per windows senza conoscere le chiamate di sistema? Come si fa a programmare Windows Assembly? In ogni caso, nella programmazione dei driver, è necessario conoscerli. destra?

Ora, come va con la cosiddetta API Nativa? Native API e le System calls for windows sono termini diversi che si riferiscono alla stessa cosa? Per confermare ho confrontato questi da due fonti non ufficiali

Chiamate di sistema: http://www.metasploit.com/users/opcode/syscalls.html

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

Le mie osservazioni:

  1. Tutte le chiamate di sistema iniziano con le lettere Nt dove Native API è costituita da molte funzioni che non iniziano con le lettere Nt .
  2. System Call of windows sono sottoinsiemi di Native API . Le chiamate di sistema sono solo parte dell’API nativa.

Qualcuno può confermarlo e spiegare.

MODIFICARE:

C’era un’altra risposta. Era una seconda risposta. Mi è piaciuto molto ma non so perché il rispondente lo abbia cancellato. Gli chiedo di ripubblicare la sua risposta.

Se si sta eseguendo la programmazione di assiemi in Windows, non si effettuano le syscasc manuali. Si utilizza NTDLL e l’API nativa per farlo per te.

L’API Nativa è semplicemente un involucro attorno al lato kernelmode delle cose. Tutto ciò che fa è eseguire un syscall per l’API corretta.

Non dovresti MAI richiedere manualmente syscall in modo che la tua intera domanda sia ridondante.

I codici syscall di Linux non cambiano, quello di Windows, ecco perché è necessario lavorare su un layer di astrazione aggiuntivo (noto anche come NTDLL).

MODIFICARE:

Inoltre, anche se lavori a livello di assembly, hai ancora pieno accesso all’API Win32, non c’è motivo di utilizzare l’API NT per cominciare! Le importazioni, le esportazioni, ecc. Funzionano tutte bene nei programmi di assemblaggio.

EDIT2:

Se si desidera REALMENTE fare syscalls manuali, sarà necessario invertire NTDLL per ogni versione di Windows pertinente, aggiungere il rilevamento della versione (tramite PEB) ed eseguire una ricerca syscall per ogni chiamata.

Tuttavia, sarebbe sciocco. NTDLL è lì per un motivo.

L’altra cosa che devi sapere sulla convenzione di windows syscall è che, come ho capito, le tabelle syscall sono generate come parte del processo di compilazione. Ciò significa che possono semplicemente cambiare – nessuno li tiene traccia. Se qualcuno ne aggiunge uno nuovo all’inizio dell’elenco, non importa. NTDLL funziona ancora, quindi tutti gli altri che chiamano NTDLL funzionano ancora.

Anche il meccanismo utilizzato per eseguire i syscalls (che int, o sysenter) non è fisso nella pietra ed è cambiato nel passato, e penso che una volta la stessa versione di Windows usasse DLL differenti che usavano diversi meccanismi di entrata a seconda del CPU nella macchina.

Le chiamate di sistema di Windows vengono eseguite chiamando in DLL di sistema come kernel32.dll o gdi32.dll , operazione eseguita con normali chiamate di subroutine. I meccanismi per il trapping nel livello privilegiato del sistema operativo non sono documentati, ma va bene perché DLL come kernel32.dll fanno questo per te.

E per le chiamate di sistema, mi riferisco ai punti di accesso all’API di Windows documentati come CreateProcess() o GetWindowText() . I driver di dispositivo generalmente utilizzano un’API diversa da Windows DDK.

Ero interessato a fare una chiamata all’API di Windows in assembly senza importazioni (come esercizio educativo), quindi ho scritto il seguente assembly FASM per fare ciò che fa NtDll! NtCreateFile. È una dimostrazione approssimativa sulla mia versione a 64 bit di Windows (Win10 1803 versione 10.0.17134), e si interrompe dopo la chiamata, ma il valore di ritorno di syscall è zero, quindi ha successo. Tutto è impostato per convenzione di chiamata x64 di Windows, quindi il numero di chiamata di sistema viene caricato in RAX, quindi è l’istruzione di assemblaggio syscall a eseguire la chiamata. Il mio esempio crea il file c: \ HelloWorldFile_FASM, quindi deve essere eseguito “come amministratore”.

 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 

Ho usato la documentazione per Ntdll! NtCreateFile, e ho anche usato il debugger del kernel per esaminare e copiare molti parametri.

 __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 ); 

Convenzione di chiamata UFFICIALE in Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(Spero che questo link sopravviva in futuro, altrimenti, cerca “Convenzioni software x64” su MSDN).

La convenzione di chiamata alla funzione differisce in Linux e Windows x86_64. In entrambe le ABI, i parametri vengono preferibilmente passati attraverso i registri, ma i registri utilizzati differiscono. Maggiori informazioni sull’ABI di Linux sono disponibili su http://www.x86-64.org/documentation/abi.pdf