Saya tertarik untuk melakukan panggilan API windows di rakitan tanpa impor (sebagai latihan pendidikan), jadi saya menulis rakitan FASM berikut untuk melakukan apa yang dilakukan NtDll!NtCreateFile. Ini adalah demonstrasi kasar pada Windows versi 64-bit saya (Win10 1803 Versi 10.0.17134), dan macet setelah panggilan, tetapi nilai pengembalian syscall adalah nol sehingga berhasil. Semuanya diatur per konvensi pemanggilan Windows x64, kemudian nomor panggilan sistem dimuat ke RAX, dan kemudian instruksi rakitan syscall untuk menjalankan panggilan. Contoh saya membuat file c:\HelloWorldFile_FASM, sehingga harus dijalankan "sebagai administrator".
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
Saya menggunakan dokumentasi untuk Ntdll!NtCreateFile, dan saya juga menggunakan debugger kernel untuk melihat dan menyalin banyak parameter.
__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
);
Jika Anda melakukan pemrograman perakitan di bawah Windows, Anda tidak melakukan syscall manual. Anda menggunakan NTDLL dan Native API untuk melakukannya untuk Anda.
Native API hanyalah pembungkus di sekitar sisi kernelmode. Yang dilakukannya hanyalah melakukan syscall untuk API yang benar.
Anda TIDAK PERNAH perlu syscall secara manual sehingga seluruh pertanyaan Anda berlebihan.
Kode syscall Linux tidak berubah, Windows berubah, itu sebabnya Anda perlu bekerja melalui lapisan abstraksi ekstra (alias NTDLL).
EDIT:
Juga, bahkan jika Anda bekerja di tingkat perakitan, Anda masih memiliki akses penuh ke API Win32, tidak ada alasan untuk menggunakan API NT sejak awal! Impor, ekspor, dll semuanya bekerja dengan baik dalam program perakitan.
EDIT2:
Jika Anda BENAR-BENAR ingin melakukan syscall manual, Anda harus membalikkan NTDLL untuk setiap versi Windows yang relevan, menambahkan deteksi versi (melalui PEB), dan melakukan pencarian syscall untuk setiap panggilan.
Namun, itu konyol. NTDLL ada karena suatu alasan.
Orang-orang telah melakukan bagian rekayasa balik:lihat https://j00ru.vexillium.org/syscalls/nt/64/ untuk tabel nomor panggilan sistem untuk setiap kernel Windows. (Perhatikan bahwa baris selanjutnya memang berubah bahkan di antara versi Windows 10.) Sekali lagi, ini adalah ide yang buruk di luar eksperimen khusus penggunaan pribadi di mesin Anda sendiri untuk mempelajari lebih lanjut tentang asm dan/atau internal Windows. Jangan sebariskan panggilan sistem ke dalam kode yang Anda distribusikan ke orang lain.
Hal lain yang perlu Anda ketahui tentang konvensi syscall windows adalah seperti yang saya pahami, tabel syscall dibuat sebagai bagian dari proses pembuatan. Artinya, mereka dapat berubah begitu saja - tidak ada yang melacaknya. Jika seseorang menambahkan yang baru di bagian atas daftar, tidak masalah. NTDLL masih berfungsi, jadi semua orang yang menelepon NTDLL masih berfungsi.
Bahkan mekanisme yang digunakan untuk melakukan syscalls (yang int, atau sysenter) tidak tetap dan telah berubah di masa lalu, dan saya pikir dulu versi windows yang sama menggunakan DLL berbeda yang menggunakan mekanisme entri berbeda tergantung pada CPU di mesin.
Panggilan sistem Windows dilakukan dengan memanggil sistem DLL seperti kernel32.dll atau gdi32.dll , yang dilakukan dengan panggilan subrutin biasa. Mekanisme untuk menjebak ke dalam lapisan istimewa OS tidak didokumentasikan, tetapi tidak apa-apa karena DLL seperti kernel32.dll lakukan ini untukmu.
Dan dengan panggilan sistem, saya mengacu pada titik masuk Windows API yang terdokumentasi seperti CreateProcess() atau GetWindowText() . Driver perangkat umumnya akan menggunakan API yang berbeda dari DDK Windows.