การโทรของระบบใน windows & Native API หรือไม่

เมื่อเร็วๆ นี้ ฉันใช้ภาษา Assembly มากมายในระบบปฏิบัติการ *NIX ฉันสงสัยเกี่ยวกับโดเมน windows


แบบแผนการเรียกใน linux:

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

แค่นั้นแหละ. นั่นคือวิธีที่เราควรทำการเรียกระบบใน linux

การอ้างอิงการเรียกระบบทั้งหมดใน linux:

เกี่ยวกับ $SYS_Call_NUM ใดและพารามิเตอร์ใดที่เราสามารถใช้การอ้างอิงนี้: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

ข้อมูลอ้างอิงอย่างเป็นทางการ: http://kernel.org/doc/man-pages/online/dir_section_2.html


แบบแผนการเรียกใน Windows:

???

การอ้างอิงการเรียกระบบทั้งหมดใน Windows:

???

ไม่เป็นทางการ : http://www.metasploit.com/users/opcode/syscalls.html แต่ฉันจะใช้สิ่งเหล่านี้ในการประกอบได้อย่างไร เว้นแต่ฉันจะรู้รูปแบบการโทร

เป็นทางการ : ???

  • ถ้าจะบอกว่าพวกเขาไม่ได้บันทึกไว้ ถ้าอย่างนั้นเราจะเขียน libc สำหรับ windows โดยไม่รู้การเรียกของระบบได้อย่างไร เราจะเขียนโปรแกรม Windows Assembly ได้อย่างไร? อย่างน้อยที่สุดในการเขียนโปรแกรมไดรเวอร์เราจำเป็นต้องรู้สิ่งเหล่านี้ ขวา?

ทีนี้เกิดอะไรขึ้นกับสิ่งที่เรียกว่า Native API? Native API & System calls for windows ทั้งสองคำต่างกันที่อ้างถึงสิ่งเดียวกันหรือไม่ เพื่อยืนยันว่าฉันได้เปรียบเทียบสิ่งเหล่านี้จากแหล่งข้อมูลที่ไม่เป็นทางการสองแห่ง

การโทรของระบบ: http://www.metasploit.com/users/opcode/syscalls.html< /ก>

API ดั้งเดิม: http://undocumented.ntinternals.net/aindex.html

ข้อสังเกตของฉัน:

  1. การเรียกของระบบทั้งหมดเริ่มต้นด้วยตัวอักษร Nt โดยที่ Native API ประกอบด้วยฟังก์ชันมากมายที่ไม่ได้ขึ้นต้นด้วยตัวอักษร Nt
  2. System Call of windows เป็นสับเซตของ Native API การเรียกของระบบเป็นเพียงส่วนหนึ่งของ Native API

ใครสามารถยืนยันสิ่งนี้และอธิบายได้

แก้ไข:

มีอีกคำตอบหนึ่ง เป็นคำตอบที่ 2. ฉันชอบมันมาก แต่ฉันไม่รู้ว่าทำไมผู้ตอบจึงลบมันออกไป ฉันขอให้เขาโพสต์คำตอบของเขาอีกครั้ง


person claws    schedule 22.03.2010    source แหล่งที่มา


คำตอบ (5)


หากคุณกำลังเขียนโปรแกรมแอสเซมบลีใน Windows คุณจะไม่ทำการเรียกระบบด้วยตนเอง คุณใช้ NTDLL และ Native API เพื่อทำสิ่งนั้นให้กับคุณ

Native API เป็นเพียงตัวห่อหุ้มด้านเคอร์เนลโหมดของสิ่งต่างๆ ทั้งหมดที่ทำได้คือดำเนินการ syscall สำหรับ API ที่ถูกต้อง

คุณไม่ควรจำเป็นต้อง syscall ด้วยตนเอง ดังนั้นคำถามทั้งหมดของคุณจึงซ้ำซ้อน

รหัส syscall ของ Linux จะไม่เปลี่ยนแปลง เช่นเดียวกับ Windows นั่นคือสาเหตุว่าทำไมคุณต้องทำงานผ่านเลเยอร์นามธรรมเพิ่มเติม (หรือที่รู้จักในชื่อ NTDLL)

แก้ไข:

นอกจากนี้ แม้ว่าคุณจะทำงานในระดับแอสเซมบลี คุณยังคงสามารถเข้าถึง Win32 API ได้อย่างเต็มที่ แต่ก็ไม่มีเหตุผลที่ต้องใช้ NT API ในการเริ่มต้น! การนำเข้า การส่งออก ฯลฯ ล้วนทำงานได้ดีในโปรแกรมแอสเซมบลี

แก้ไข 2:

หากคุณต้องการดำเนินการ syscall ด้วยตนเอง คุณจะต้องย้อนกลับ NTDLL สำหรับ Windows แต่ละเวอร์ชันที่เกี่ยวข้อง เพิ่มการตรวจหาเวอร์ชัน (ผ่าน PEB) และดำเนินการค้นหา syscall สำหรับการโทรแต่ละครั้ง

อย่างไรก็ตามนั่นจะโง่ NTDLL อยู่ที่นั่นด้วยเหตุผล

ผู้คนได้ทำส่วนวิศวกรรมย้อนกลับไปแล้ว: ดู https://j00ru.vexillium.org/syscalls/nt/64/ สำหรับตารางหมายเลขการโทรของระบบสำหรับเคอร์เนล Windows แต่ละตัว (โปรดทราบว่าแถวหลังๆ จะเปลี่ยนแปลงแม้ระหว่างเวอร์ชันของ Windows 10) ขอย้ำอีกครั้ง นี่เป็นความคิดที่ไม่ดีนอกเหนือจากการทดลองใช้งานส่วนบุคคลเท่านั้นในเครื่องของคุณเองเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ asm และ/หรือภายในของ Windows อย่าอินไลน์ระบบเรียกรหัสที่คุณแจกจ่ายให้กับบุคคลอื่น

person RaptorFactor    schedule 22.03.2010
comment
+1 และขอบคุณ คุณช่วยแสดงโค้ดตัวอย่างที่สาธิตวิธีใช้ WIN32 API และ NT API จากภาษา Assembly ได้ไหม - person claws; 22.03.2010
comment
คุณใช้แอสเซมเบลอร์อะไร? ตัวอย่างเช่น หากคุณใช้ MASM วิธีที่ง่ายที่สุดคือใช้ 'INVOKE' ผลลัพธ์แรกของ Google ที่ฉันพบว่าสรุปไว้คือ: movsd.com/masm.htm - person RaptorFactor; 22.03.2010
comment
บทความสั้นและกระชับซึ่งเป็นส่วนเสริมที่ดีสำหรับคำตอบนี้: codeproject.com/KB/ ระบบ/Win32.aspx - person claws; 22.03.2010
comment
บทความนั้นไม่ใช่สิ่งที่คุณกำลังมองหา โดยจะแสดงวิธีการดำเนินการ syscall ด้วยตนเอง ซึ่งคุณไม่ควรทำเนื่องจากตัวเลขจะเปลี่ยนไปในเวอร์ชัน Windows และ Service Pack ดังที่ฉันได้กล่าวไปแล้ว คุณควรใช้ Windows API เพื่อดำเนินการจัดส่งให้กับคุณ NTDLL ถูกแมปเข้ากับกระบวนการทั้งหมดโดยอัตโนมัติ ดังนั้นแม้ว่าคุณจะไม่สามารถใช้การนำเข้าได้ด้วยเหตุผลบางอย่าง (ฉันไม่สามารถนึกถึงเวลาที่เหมาะสมในกรณีนี้ได้) คุณยังคงสามารถรับการจัดการกับ NTDLL และระบุ EAT ด้วยตนเองเพื่อรับตัวชี้ฟังก์ชันที่จำเป็น (แม้ว่า คุณไม่ควรจะต้อง) - person RaptorFactor; 23.03.2010
comment
ไม่แน่นอน ฉันแค่พยายามทำให้ชัดเจนว่าข้อมูลเฉพาะที่คุณอ้างถึงไม่เกี่ยวข้องกับคำถามของคุณ เพราะคุณไม่จำเป็นต้องรู้ว่ากระบวนการจัดส่งระบบทำงานอย่างไรเพื่อทำการเรียกระบบใน Windows นั่นเป็นสาเหตุที่ Win32 API ระดับสูง (หรือแม้แต่ NT API) อยู่ที่นั่นเพื่อสรุปรายละเอียดที่ไม่เกี่ยวข้องดังกล่าวออกไป - person RaptorFactor; 26.03.2010
comment
@claws บทความนี้น่าสนใจมาก ขอบคุณมาก - person Felix Dombek; 25.09.2012
comment
สิ่งนี้ไม่ได้มุ่งเป้าไปที่ผู้เขียนคำตอบนี้โดยเฉพาะ แต่ฉันไม่เข้าใจว่าทำไมคำตอบเหล่านี้จึงไม่แพร่หลายใน SO นี่ไม่ควรเป็นเว็บไซต์สำหรับโปรแกรมเมอร์มืออาชีพและผู้กระตือรือร้นใช่ไหม เหตุใดไซต์นี้จึงส่งเสริมความพยายามในการค้นคว้าอย่างมาก แต่เมื่อคุณพบคำถามที่อยากรู้อยากเห็นระดับต่ำเหล่านี้ ฉันก็พบว่า กระแสของคุณอย่างต่อเนื่องไม่จำเป็นต้องรู้!!!. ใครคือกลุ่มเป้าหมายที่แท้จริงของเว็บไซต์นี้อีกครั้ง? ผู้ที่ต้องการจับมือหรือผู้ที่เต็มใจที่จะขุดลึกจริงๆ? - person jrh; 15.03.2017

อีกสิ่งหนึ่งที่คุณต้องรู้เกี่ยวกับแบบแผน syscall ของ windows คือเมื่อฉันเข้าใจแล้ว ตาราง syscall จะถูกสร้างขึ้นโดยเป็นส่วนหนึ่งของกระบวนการสร้าง ซึ่งหมายความว่าพวกเขาสามารถเปลี่ยนแปลงได้ - ไม่มีใครติดตามพวกเขา หากมีคนเพิ่มรายการใหม่ที่ด้านบนของรายการ ก็ไม่สำคัญ NTDLL ยังคงใช้งานได้ ดังนั้นทุกคนที่เรียก NTDLL ก็ยังใช้งานได้

แม้แต่กลไกที่ใช้ในการดำเนินการ syscalls (ซึ่ง int หรือ sysenter) ก็ไม่ได้รับการแก้ไขและมีการเปลี่ยนแปลงในอดีต และฉันคิดว่ากาลครั้งหนึ่ง Windows รุ่นเดียวกันนั้นใช้ DLL ที่แตกต่างกันซึ่งใช้กลไกการป้อนข้อมูลที่แตกต่างกันขึ้นอยู่กับ ซีพียูในเครื่อง

person Stewart    schedule 30.04.2010
comment
+1 เพราะฉันพบว่าสิ่งนี้น่าสนใจมาก คุณมีแหล่งข้อมูล (อินเทอร์เน็ตหรือหนังสือ) ที่สามารถเรียนรู้เพิ่มเติมเกี่ยวกับ Win32 API / syscall ภายในประเภทนั้นได้หรือไม่ - person stakx - no longer contributing; 30.04.2010
comment
มันค่อนข้างล้าสมัย แต่ฉันคิดว่า Inside Windows 2000 ครอบคลุมเรื่องนี้ nynaeve.net/?p=48 มีการสนทนาที่ดีและยังแสดงให้เห็นว่ามี แบบแผน syscall สามแบบล่าสุดที่ใช้งานบน windows บน x86 และ x64 IA64 อาจจะทำสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิงอีกครั้ง และแน่นอนว่ายังมี Alpha, PowerPC, MIPS และอาจมีอย่างอื่นด้วย แน่นอนว่ามีข้อแม้ตามปกติ - ทั้งหมดไม่มีเอกสารและมีแนวโน้มที่จะเปลี่ยนแปลง - person Stewart; 01.05.2010

ฉันสนใจที่จะทำการเรียก windows API ในชุดประกอบที่ไม่มีการนำเข้า (เป็นแบบฝึกหัดด้านการศึกษา) ดังนั้นฉันจึงเขียนชุดประกอบ FASM ต่อไปนี้เพื่อทำสิ่งที่ NtDll!NtCreateFile ทำ เป็นการสาธิตคร่าวๆ บน Windows เวอร์ชัน 64 บิตของฉัน (Win10 1803 เวอร์ชัน 10.0.17134) และเกิดปัญหาหลังการโทร แต่ค่าที่ส่งคืนของ syscall นั้นเป็นศูนย์ ดังนั้นจึงดำเนินการได้สำเร็จ ทุกอย่างได้รับการตั้งค่าตามหลักการเรียก Windows x64 จากนั้นหมายเลขการโทรของระบบจะถูกโหลดลงใน RAX จากนั้นจะเป็นคำสั่งแอสเซมบลี syscall เพื่อเรียกใช้การโทร ตัวอย่างของฉันสร้างไฟล์ c:\HelloWorldFile_FASM ดังนั้นจึงต้องเรียกใช้ "ในฐานะผู้ดูแลระบบ"

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

ฉันใช้เอกสารประกอบสำหรับ Ntdll!NtCreateFile และฉันยังใช้เคอร์เนลดีบักเกอร์เพื่อดูและคัดลอกพารามิเตอร์จำนวนมากด้วย

__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
);
person Elliot    schedule 23.07.2018
comment
mov r10, rcx อาจเป็นเพราะเหตุผลเดียวกันกับ Linux: syscall ตัวมันเองปิดกั้น rcx (และ r11) ก่อนที่เคอร์เนลจะมองเห็นได้ ดังนั้นหลักการเรียกเคอร์เนล syscall จึงใช้ r10 แทน rcx รหัสนี้ใช้ได้กับ Windows เวอร์ชันใด syscall ABI ไม่เสถียรบน Windows ดังนั้นพารามิเตอร์ที่แตกต่างกันหรือแม้แต่รหัสอื่นที่ไม่ใช่ eax = 0x55 อาจเป็นวิธีที่ถูกต้องในการเรียกใช้บน Windows เวอร์ชันอื่น - person Peter Cordes; 23.07.2018
comment
ขอบคุณสำหรับข้อมูลเกี่ยวกับ mov r10, rcx line; ฉันยังไม่ได้ดูเรื่องนั้นเลย windows เวอร์ชันของฉันคือ 10.0.17134 Build 17134 - person Elliot; 23.07.2018
comment
สำหรับรายละเอียดเกี่ยวกับ syscall และ RCX โปรดดูที่ เหตุใดการเรียกของระบบ x86-64 Linux จึงปรับเปลี่ยน RCX และค่านี้หมายถึงอะไร และ ความแตกต่างใน ABI ระหว่างฟังก์ชัน x86_64 Linux และ syscalls และ เหตุใดพารามิเตอร์ syscall ของ Assembly x86_64 จึงไม่เรียงตามตัวอักษรเช่น i386 สำหรับตัวอย่างฟังก์ชัน wrapper เช่น Linux/glibc mmap ที่มีเฉพาะ ถึง mov r10,rcx) - person Peter Cordes; 23.07.2018
comment
ขอบคุณ. ฉันได้ดูเอกสาร syscall แล้วและเห็นว่าบันทึกที่อยู่ถัดไปลงใน RCX ฉันอาจปรับปรุงการสาธิตของฉันข้างต้นเพราะฉันสังเกตเห็นว่าหลังจากสร้างไฟล์แล้ว ไฟล์ขัดข้องโดยมีข้อยกเว้นการละเมิดการเข้าถึง ฉันไม่ต้องการโทรอีกครั้งเพื่อยุติกระบวนการอย่างถูกต้อง - person Elliot; 23.07.2018
comment
@PeterCordes ฉันไม่ได้บอกว่าฉันแนะนำให้ใช้หมายเลข syscall โดยตรง (เนื่องจากมีการเปลี่ยนแปลง) แต่หมายเลข syscall คือ เอกสารอย่างไม่เป็นทางการ Windows เวอร์ชัน 10.0.17134 คือ Windows(1803) และ syscall สำหรับ NtCreateFile คือ 0x55 Win 10 ทั้ง 5 รุ่นที่วางจำหน่ายใช้ 0x55 จนถึงตอนนี้ (Pre Win10 ใช้หมายเลขโทรศัพท์ของระบบอื่นที่ไม่ใช่ 0x55) - person Michael Petch; 24.07.2018
comment
mov r10,rcx เป็นเพราะอินเทอร์เฟซ syscall ส่งผ่านพารามิเตอร์แรกผ่าน r10 แทนที่จะเป็น RCX การเรียกใช้ฟังก์ชัน 64 บิตปกติใช้ RCX, RDX, R8 และ R9 Syscall ใช้ R10, RDX, R8 และ R9 เหตุผลก็คือคำสั่ง syscall เขียนทับ RCX (และเขียนทับ R11 ด้วย) Microsoft เลือกใช้ R10 สำหรับพารามิเตอร์แรกของการเรียกระบบแทน ดังนั้นเหตุใดคุณจึงเห็น mov r10, rcx - person Michael Petch; 24.07.2018
comment
เหตุผลในการเติมช่องว่างเพิ่มเติม (เช่น push 0x0DF0AD8B) คือเพื่อรักษาการจัดตำแหน่งสแต็กด้วยเหตุผลด้านประสิทธิภาพ คุณควรเพิ่มช่องว่างภายใน 8 ไบต์ (ควอดเวิร์ด) หากมีการพุชจำนวนเท่ากันก่อน syscall (ไม่เช่นนั้นคุณไม่จำเป็นต้องมีช่องว่างภายใน) เนื่องจากสแต็กไม่ตรงแนวด้วย 8 ที่จุด start ถูกดำเนินการเนื่องจากที่อยู่ผู้ส่งอยู่บนสแต็ก - person Michael Petch; 24.07.2018
comment
สาเหตุที่โค้ดของคุณล้มเหลว เป็นเพราะคุณไม่ได้ล้างสแต็กหลังจาก syscall คุณผลักดัน 13 quadwords ที่เทียบเท่าเพื่อตั้งค่า syscall คุณต้องปรับสแต็กหลัง syscall เพื่อคืนค่าตัวชี้สแต็กเป็นสถานะก่อนหน้าก่อนที่คุณจะทำ ret 13*8=104 ไบต์วางบนสแต็กก่อน syscall หลังจาก syscall คุณสามารถทำ add rsp, 104 เพื่อล้างสแต็ก - person Michael Petch; 24.07.2018
comment
เนื่องจากพารามิเตอร์แรกของ syscall อยู่ใน R10 แทนที่จะเป็น RCX คุณสามารถแทนที่ mov rcx, _Handle ด้วย mov r10, _Handle จากนั้นคุณสามารถลบ mov r10, rcx ทั้งหมดได้ คุณต้องการเปลี่ยน push rcx เป็น push r10 - person Michael Petch; 24.07.2018
comment
รหัสเวอร์ชันแก้ไขของคุณที่ยังคงใช้งานได้และคำนึงถึงทั้งหมดนี้อยู่ที่นี่: capp-sysware.com/misc/stackoverflow/2489889/winsyscall.asm - person Michael Petch; 24.07.2018
comment
เนื่องจากคุณกำลังสร้าง syscall โดยตรง (โดยไม่ต้องส่งพารามิเตอร์เพื่อเริ่มต้น) ที่อยู่ของที่อยู่ผู้ส่งจึงไม่จำเป็นต้องเป็นค่าเฉพาะใดๆ syscall จะไม่ใช้เพื่อกลับไปที่ (syscall จะกลับสู่คำสั่งหลังจาก syscall) ดังนั้นแทนที่จะเป็น push endOfProgram คุณสามารถพุชการลงทะเบียนใดก็ได้ (ค่าของมันไม่สำคัญ) เช่น push rbp (หรือ push rax การลงทะเบียนไม่สำคัญ) - person Michael Petch; 25.07.2018

การเรียกของระบบ Windows ทำได้โดยการเรียกเข้าไปใน DLL ของระบบ เช่น kernel32.dll หรือ gdi32.dll ซึ่งทำได้โดยใช้การเรียกรูทีนย่อยทั่วไป กลไกในการดักจับในเลเยอร์สิทธิพิเศษของ OS นั้นไม่มีเอกสารระบุไว้ แต่ก็ไม่เป็นไร เพราะ DLL เช่น kernel32.dll ทำสิ่งนี้เพื่อคุณ

และโดยการเรียกของระบบ ฉันหมายถึงจุดเข้าใช้งาน Windows API ที่บันทึกไว้ เช่น CreateProcess() หรือ GetWindowText() โดยทั่วไปไดรเวอร์อุปกรณ์จะใช้ API ที่แตกต่างจาก Windows DDK

person Will    schedule 22.03.2010
comment
1. ฉันจะใช้สิ่งเหล่านี้ในการเขียนโปรแกรมภาษา Assembly ได้อย่างไร 2. Windows API และการเรียกของระบบไม่เหมือนกัน WINDOWS API ใช้ การเรียกของระบบ การเปรียบเทียบที่คล้ายกันบนโดเมน linux จะเป็น POSIX API (WINDOWS API) ใช้การเรียกของระบบที่จัดทำโดยเคอร์เนล linux (เคอร์เนล windows) ดังนั้น ความกังวลของฉันเกี่ยวกับการโทรของระบบ จริง - person claws; 22.03.2010
comment
ฉันเข้าใจว่ามีความแตกต่างระหว่างการเรียก API และกับดักในเลเยอร์สิทธิพิเศษของระบบปฏิบัติการ (สิ่งที่คุณเรียกว่าการเรียกของระบบจริง) การเรียกระบบที่แท้จริงเหล่านี้เป็นรายละเอียดการใช้งาน DLLs ระบบ Windows คุณอาจทราบวิธีการทำงานได้โดยการแยกส่วน DLLs และดูที่ชุดประกอบ หรือคุณสามารถเขียนโค้ดแอสเซมบลีของคุณเพื่อเรียกเข้าสู่ DLLs ตามความเหมาะสม... ก็เป็นไปได้ - person Will; 22.03.2010

แบบแผนการเรียกอย่างเป็นทางการใน Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(หวังว่าลิงก์นี้จะคงอยู่ต่อไปในอนาคต หากไม่เป็นเช่นนั้น ให้ค้นหา "x64 Software Conventions" บน MSDN)

รูปแบบการเรียกใช้ฟังก์ชันแตกต่างกันใน Linux และ Windows x86_64 ใน ABI ทั้งสอง พารามิเตอร์จะถูกส่งผ่านรีจิสเตอร์ แต่รีจิสเตอร์ที่ใช้แตกต่างกัน สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับ Linux ABI ได้ที่ http://www.x86-64.org/documentation/abi.pdf

person claws    schedule 23.03.2010
comment
สิ่งนี้ไม่ได้ตอบคำถามซึ่งเกี่ยวกับแบบแผนการเรียกเข้าสู่โหมดเคอร์เนล นี่เป็นหลักการเรียกฟังก์ชันโหมดผู้ใช้ซึ่งค่อนข้างแตกต่าง และมีเอกสารครบถ้วน - person Stewart; 11.05.2013