Wywołania systemowe w oknach i natywnym API?

Question

Niedawno używałem wielu języków Assemblera w systemach operacyjnych * NIX. Zastanawiam się nad domeną Windows.

---

Wywołanie konwencja w systemie Linux:

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

to wszystko. W ten sposób powinniśmy wykonać wywołanie systemowe w systemie Linux.

odniesienia wszystkich wywołań systemowych w systemie Linux:

odniesieniu do których $ SYS_Call_NUM & które parametry możemy użyć tego odnośnika: http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html

OFFICIAL referencyjny: http://kernel.org/doc/man-pages/online/dir_section_2.html

---

konwencja wywoływania w systemie Windows:

???

odniesienia wszystkich wywołań systemowych w systemie Windows:

???

Nieoficjalna: http://www.metasploit.com/users/opcode/syscalls.html, ale w jaki sposób korzystać z nich w zespole, chyba że znam konwencję wywołującą.

OFICJALNE: ???

• Jeśli powiecie, nie udokumentowali tego. W jaki sposób można napisać libc dla Windows bez znajomości wywołań systemowych? Jak zamierza się programować w systemie Windows Assembly? Przynajmniej w programowaniu sterowników trzeba to znać. dobrze?

---

Teraz Siema z tzw Native API? Czy Native API & System calls for windows oba są różne terminy odnoszące się do tego samego? W celu potwierdzenia, że ​​w porównaniu tych dwóch nieoficjalnych

wywołań systemowych: http://www.metasploit.com/users/opcode/syscalls.html

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

Moje obserwacje:

1. Wszystkie wywołań systemowych są rozpoczynające się od liter Nt gdzie jako Natywny interfejs API składa się z wielu funkcji, które nie zaczynają się od liter Nt.
2. System Call of windows są podzestawem Native API. Wywołania systemowe są tylko częścią Native API.

Czy ktoś może to potwierdzić i wyjaśnić.

EDIT:

Nie było innej odpowiedzi. To była druga odpowiedź. Naprawdę mi się to podobało, ale nie wiem, dlaczego odbierający je skasował. Poprosiłem go o ponowne przesłanie odpowiedzi.

Answer 1

Jeśli wykonujesz programowanie zespołów w systemie Windows, nie wykonuj ręcznych wywołań systemowych. Do tego celu używasz NTDLL i Native API.

Natywny interfejs API jest po prostu opakowaniem po stronie kernelmode. Wszystko, co robi, to wykonać syscall dla właściwego API.

NIGDY nie powinieneś ręcznie sprawdzać, czy twoje pytanie jest zbędne.

Kody syscall systemu Linux nie ulegają zmianie, system Windows, dlatego należy pracować nad dodatkową warstwą abstrakcji (inaczej NTDLL).

EDIT:

Ponadto, nawet jeśli pracujesz na poziomie zespołu, nadal masz pełny dostęp do API Win32, nie ma powodu, aby być pomocą NT API zacząć! Import, eksport itp. Wszystko działa dobrze w programach montażowych.

EDIT2:

jeśli naprawdę chcesz to zrobić ręcznie wywołań systemowych, będziesz potrzebować, aby odwrócić Ntdll dla każdej odpowiedniej wersji systemu Windows, dodać wykrywanie wersji (przez PEB) i przeprowadzić wyszukiwanie syscall dla każdego połączenie.

Jednak byłoby głupio. NTDLL jest tam z jakiegoś powodu.

Answer 2

Wywołania systemowe systemu Windows są wykonywane przez wywołanie do systemowych bibliotek DLL, takich jak kernel32.dll lub gdi32.dll, co odbywa się za pomocą zwykłych wywołań podprogramów. Mechanizmy przechwytywania do warstwy uprzywilejowanej systemu operacyjnego są nieudokumentowane, ale jest to w porządku, ponieważ biblioteki DLL, takie jak kernel32.dll, robią to za Ciebie.

I przez wywołania systemowe, mam na myśli udokumentowane punkty wejścia Windows API, takie jak CreateProcess() lub GetWindowText(). Sterowniki urządzeń będą generalnie używać innego interfejsu API niż Windows DDK.

Answer 3

OFFICIAL Wywołanie konwencję w systemie Windows: http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

(mam nadzieję, ten link przetrwa w przyszłości, jeśli tak nie jest, po prostu szukaj „Konwencje x64 oprogramowania” na MSDN).

Konwencja wywoływania funkcji różni się w Linuksie & Windows x86_64. W obu ABI parametry najlepiej przechodzą przez rejestry, ale stosowane rejestry różnią się. Więcej na Linux ABI można znaleźć na http://www.x86-64.org/documentation/abi.pdf

Answer 4

Drugą rzeczą, którą musisz wiedzieć o konwencji okna syscall jest to, że jak rozumiem stoły syscall są generowane jako część procesu kompilacji. Oznacza to, że mogą się po prostu zmienić - nikt ich nie śledzi. Jeśli ktoś doda nowy na początku listy, nie ma to znaczenia. NTDLL nadal działa, więc wszyscy, którzy nazywają NTDLL, nadal działają.

Nawet mechanizm użyty do wykonania syscalls (który int lub sysenter) nie jest poprawiony w kamieniu i zmienił się w przeszłości, i myślę, że kiedyś ta sama wersja systemu Windows używała różnych bibliotek DLL, które używały innego wpisu mechanizmy w zależności od procesora w maszynie.