» »

win32 api vs "linux api"

win32 api vs "linux api"

PrimozBo ::

Kolikor raumem ima windows nek ogromem seznam raznih funkcij, ki skupaj nekako tvorijo win32 api. Zanima me pa kako je z tem pri linuxu ?
Kaj je osnoven API za linux, je to C standard library in potem naprej odvisno od desktopa ?

Hvala za razlago in lp

metalc ::

Pri Linuxu (kot tudi na splošno pri Unixih) se vstopnim točkam do funkcionalnosti kernela reče sistemski klici (system calls ali krajše syscalls), v C knjižnici pa imaš wrapperje do njih v obliki C-jevskih funkcij. Konkretno število teh sistemskih klicev je odvisno od različice jedra. Seznam dobiš z "man 2 syscalls", če te strani nimaš inštalirane, lahko poškiliš tudi sem.

PrimozBo ::

Čeprav razumem ima linux v osnovi par sto sistemskih klicev, ki so vsi wrappani v C standardno knjižico. Na windowsih pa imaš MS-jevo verzijo standardne C knjižice in poleg tega še nekaj tisoč dodatnih win32 API funkcij za uporabo katerih rabiš ustrezne header datoteke. Nekaj tega win32 api-ja pa je wrappanega v MFC knjižico ?

fiction ::

Tudi na Windowsih imaš sistemske klice. To je splošen koncept delovanja OS, kako lahko manj priviligirana koda (ki teče uporabniškem načinu) zahteva nekaj od bolj priviligirane kode v jedrnem načinu. Brez tega praktično ne moreš narediti ničesar, niti odpreti datoteke. Direkten klic neke funkcije, bi lahko bil problematičen, ker mora prav low-level v strojni opremi priti do spremembe informacije o tem kakšna koda se kdaj izvaja (ring 0-4 na x86), ker uporabniški program npr. ne more dostopati do celotnega pomnilniškega prostora itd. Zato pride do neke vrste prekinitve.

Na Linux OS je npr. glibc direktno wrapper za sistemske klice, tako da programer v C-ju kliče open(), ne pa da naloži nekam številko storitve, sproži prekinitev itd. V Windows ima vse skupaj malo več plasti. Imaš še win32 api in standardna C knjižnica v bistvu potem kliče to drugo knjižnico. Težava je v tem, da se številke sistemskih klicev stalno spreminjajo (med različnimi verzijami Windowsev) in bi bil direkten klic težko prenosljiv.

Edit: Sej več kot ene 100 sistemskih klicev pomoje ne potrebuješ. V win32 imaš zelo različne stvari, ki se potem preslikajo na isti sistemski klic. Pač hoteli so narediti bolj modularno vse skupaj pa so malo zakomplicirali :) Toliko da rabiš še najrazličnejše wrapperje nad tem wrapperjem, preden zadeva postane uporabna.

Zgodovina sprememb…

  • spremenil: fiction ()

napsy ::

Linux je precej POSIX kompitabilen sistem in zato ponuja vrsto sistemskih klicev. Vendar to ni dovolj za nadzor userspace okolja. Na primer že urejanje omrežja je lahko zapleteno. Večina modernih sistemov uporablja NetworkManager za uporavljanje omrežnih vmesnikov. NetworkManager tudi ponuja svoj API. Vendar še vedno bodo sistemi, ki ga ne uporablajo in je potrebno klicat drug API. Oz. na splošno ne obstaja nek garantiran API kot npr win32, kjer bi lahko trdil, da omogoča popolni nadzor nad sistemom.
"If you die, you die. But when you live you live. There is no time to waste."

denial ::

Najbrž še MSFT natančno ne ve koliko syscall-ov vsebuje njihov Core API >:D. Vsekakor jih je krepko preko 2000. Pač odvisno od različice Oken ter ali upoštevaš tudi nedokumentirane funkcije. Linux jih uporablja veliko manj. Kar sploh ni slabo.

Sicer pa je @fiction lepo pojasnil zadevo. Evo še oldie-but-goldie slikica iz kategorije "fun with undocumented API functions":

SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

fiction ::

Erm, da se popravim: ring 0-3 jasno (ker so 4-je). Typo. In ring 0 je najbolj priviligiran.

Ko se je ravno denial oglasil. V Linux shellkodi, ki jo uporablja kakšen exploit, ponavadi vidiš 0xcd 0x80 bajta - to je klic določenega prekinitvenega vektorja (INT 128), s katerimi so med drugim realizirani sistemski klici. Z njimi potem program ali pa zlonamerna koda sploh interagira z okoljem. Prej v registre nafilaš številko funkcije in ostale parametre. Brez sistemskih klicev je program bolj kot geek cel dan zaprt v svoji sobi... Sicer lahko marsikaj izračuna, samo kaj ko z nikomer ne komunicira. :)

V Windows shellkodi nikoli ne zaslediš česa takega, ker bi drugače zadeva delala samo na točno eni verziji. Zakaj bi te koda, ki jo izvedeš po uspešnem napadu omejevala, če te že vse ostalo.

Aja pa obstaja tudi Systrace za to, da določiš kaj program lahko pokliče. Zanimiv koncept.

denial ::

Prekinitvi, ki jih uporabljajo Okna za tranzicijo Ring3 => Ring0, sta int 2E (0xcd 0x2e) ter sysenter (0x0f 0x34). Teh prekinitev v Win32 shellcodi ne vidiš ker se številke sistemskih klicev v Oknih konstantno spreminjajo (kar nato povzroča masovno "Guru meditacijo" rootkit-anih sistemov). Iz tega razloga se v Oknih raje uporablja DLL kot nekakšen "trampolin". Čeprav je s prihodom ASLR tudi to unreliable in passé.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

fiction ::

denial je izjavil:

Prekinitvi, ki jih uporabljajo Okna za tranzicijo Ring3 => Ring0, sta int 2E (0xcd 0x2e) ter sysenter (0x0f 0x34).
Namenoma nisem kompliciral s sysenter. To je pač samo hitrejša alternativa za izvedbo sistemskih klicev in deluje tudi na Linuxu od 2.6 naprej. Če se dela s prekinitvami se pa vidi razlika v tem katera številka vektorja je bila izbrana za sistemske klice s strani OS. Druga izvedba je praktično povsod enaka, razlike so bolj v detajlih npr. kako se prenašajo parametri (na BSD-ju kolikor vem vse pushas na sklad).

Enostavna razlaga sistemskih klicev

denial je izjavil:

Iz tega razloga se v Oknih raje uporablja DLL kot nekakšen "trampolin". Čeprav je s prihodom ASLR tudi to unreliable in passé.
V bistvu hacker naredi isto kot bi naredil običajen programer. Ne pokliče direktno določene zadeve, kar bi zmanjšalo prenosljivost, ampak nek wrapper, ki potem poskrbi za vse skupaj. Povratek v knjižnico (return-into-libc) je na UNIX-u mišljen kot izhod, če je npr. sklad neizvršljiv in ne moreš pretihotapiti svoje shellkode, na Windows OS pa praktično ni nobene alternative kot da prej ali slej skočiš v kodo od neke knjižnice.

noraguta ::

ni mi jasno kje je kaka bistvena razlika me msvcrt in libc.
Pust' ot pobyedy k pobyedye vyedyot!

PrimozBo ::

A so v linuxu funcije iz glibc 1 na 1 mapirane z sistemskimi klici al to velja samo v določenih primerih ? Pokrijejo funkcije iz glibc vse sistemske klice al samo večino ?

Kako v C kodi direktno izvedeš klic, recimo za branje datoteke ?

napsy ::

Sistemski klic izvedeš z syscall(). Večina IO klicev glibc so tako wrapperji za sistemske klice. Vendar dvomim da so 1:1.
"If you die, you die. But when you live you live. There is no time to waste."

BlueRunner ::

Win32 API je tradicionalno Win32 funkcionalen ekvivalent POSIX API-jev. Upravljanje s pomnilnikom, I/O enotami, datotečnim sistemom, nitenje, kontrola dostopa, ... osnovne sistemske storitve pač. Bistvene razlike so morda le to, da Win32 API vsebuje GDI, funkcije za delo s konzolo in funkcije za delo z zvokom. POSIX teh stvari ne pozna, saj je bila grafika odseljena v X, terminali pa so pač terminali za zvok pa imamo nekaj različnih API-jev.

Ne mešati Win32 API z t.i. NTAPI, ki so ekvivalent sistemskih klicev Linux-a (jedra). NTAPI je dejanski API, ki se ga uporabi za implementacijo zgoraj navedenih funkcionalnosti. Win32 pa je samo podsistem (oziroma osebnost - personality), ki ga operacijski sistem ponuja aplikacijam. Včasih smo imeli še OS/2 podsistem, še danes pa se najde tudi POSIX podsistem. Kdor si hoče greniti življenje (ali pa razvija sistemske gonilnike), lahko uporabi (oziroma mora uporabiti) tudi neposredno NTAPI.

Ostale stvari, ki jih nekateri mečejo pod Win32 API, pa to niso, pa so API-ji za različne bolj ali manj standardne dodatne module v sistemu, ki so jih zapakirali v Win32 SDK oziroma sedaj, ko imamo tudi 64-biten API kar "Windows SDK". Ekvivalent temu so tudi različni API-ji, ki jih najdeš na GNU/Linux sistemih. NetworkManager, DBUS, ALSA, PulseAudio, ... so primeri takšnih.

Zgodovina sprememb…

noraguta ::

Ostale stvari, ki jih nekateri mečejo pod Win32 API, pa to niso, pa so API-ji za različne bolj ali manj standardne dodatne module v sistemu, ki so jih zapakirali v Win32 SDK oziroma sedaj, ko imamo tudi 64-biten API kar "Windows SDK". Ekvivalent temu so tudi različni API-ji, ki jih najdeš na GNU/Linux sistemih. NetworkManager, DBUS, ALSA, PulseAudio, ... so primeri takšnih.

jen mejčkn popravek včasih so "platform SDK", no dons pravjo pa "wsdk".
Pust' ot pobyedy k pobyedye vyedyot!

denial ::

Native API sestavljajo vse funkcije, ki jih exportata NTDLL.DLL (ring 3) in NTOSKRNL.EXE (ring 0) in katerih imena se začenjajo na Zw* ali Nt*. Če tem dodaš še funkcije, ki jih exportata USER32.DLL in GDI32.DLL dobiš Core API.

Pokrijejo funkcije iz glibc vse sistemske klice al samo večino ?

Glibc pokrije vse sistemske klice z izvorom v ring 3: KLIK

ni mi jasno kje je kaka bistvena razlika me msvcrt in libc.

Meni tudi ne :D. Najbrž je sploh ni oz. je irelevantna(?)

Kako v C kodi direktno izvedeš klic, recimo za branje datoteke ?

Če si vešč zbirnega jezika uporabiš inline assembly.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

BlueRunner ::

denial je izjavil:

Native API sestavljajo vse funkcije, ki jih exportata NTDLL.DLL (ring 3) in NTOSKRNL.EXE (ring 0) in katerih imena se začenjajo na Zw* ali Nt*. Če tem dodaš še funkcije, ki jih exportata USER32.DLL in GDI32.DLL dobiš Core API.

I beg to differ. USER32, GDI32 in še kaj so Win32 API. NTAPI ali pa Native API pa je to, kar si napisal. Ne spada pa NTAPI pod Win32 API in obratno. Ta distinkcija je jasna tudi pri Linux/glibc kombinaciji. Če si spregledal, ko sem napisal, ponovim, da MS implementira tudi POSIX API, ki je enakovreden Win32 API. Včasih pa je obstajal tudi OS/2 API, ki je ravno tako bil implementiran preko NTAPI sistemskih klicev.

denial je izjavil:

ni mi jasno kje je kaka bistvena razlika me msvcrt in libc.

Meni tudi ne :D. Najbrž je sploh ni oz. je irelevantna(?)

Razlika je bistvena. MSVCRT je "MicroSoft Visual C Run Time". Knjižnica funkcij, ki so standardno na voljo v C in C++ programih, ki jih prevajaš z MS-jevim C/C++ prevajalnikom. Malo zmede morda zato, ker je glibc implementira POSIX API, ki vključuje tudi C standard (oz. to čemur se reče "standardna" knjižnica za C). Recimo C++ standardno knjižnoco dobiš pri gcc prevajalniku ločeno v libstdc++.

denial ::

Govoriva o isti stvari vendar nama težave povzroča semantika :D

Enotna sva si kaj je Native API (NTAPI). Tudi Win32 API "ni problematičen" (komponente so navedene tukaj: KLIK). Težave torej povzroča le Core API, kar je tudi razumljivo, saj gre za neuradno poimenovanje, ki ga v Microsoftovi dokumentaciji najbrž ne boš našel. Kakorkoli, Core API sestavljajo knjižnice preko katerih je možen direkten dostop do jedra. Sem pa spadata tudi USER32.DLL in GDI32.DLL: KLIK (slide 13). Seveda pa ni nič narobe če funkcije iz obeh knjižnic prištevaš med Win32 API ;-)
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

BlueRunner ::

Ja, imaš prav. "Core API" je meni sicer neznano poimenovanje, ki ga ne uporabljam. Zato sem si ga v glavi izenačil z NTAPI. Hvala na popravku.

Čisto vzporedno pa izkoriščam to priliko in zagodrnjam nad politično odločitvijo, da se je v NT 5.0 (Windows 2000) dele GDI-ja prestavilo v Win32k.sys, s čemer se je zaobšlo bistvene varnostne mehanizme in vsako napako GDI-ja (in teh je včasih res mrgolelo) spremenilo v potencialen ring0 exploit. Vse v imenu tega, da se bi lahko na tem sistemu igralo igrice. ;((

noraguta ::

Ja, imaš prav. "Core API" je meni sicer neznano poimenovanje, ki ga ne uporabljam.
corfe api je pomoje nekje prehod nem asm-jem. ker nekje štrinaje jedara nad hw niwojem definira prav orodje.
Pust' ot pobyedy k pobyedye vyedyot!

BlueRunner ::

oraNguta?

PrimozBo ::

A ni Native API (NTAPI) namenjen samo za interno MS uporabo in zato uradno nedokumentiran ?

Čisto vzporedno pa izkoriščam to priliko in zagodrnjam nad politično odločitvijo, da se je v NT 5.0 (Windows 2000) dele GDI-ja prestavilo v Win32k.sys, s čemer se je zaobšlo bistvene varnostne mehanizme in vsako napako GDI-ja (in teh je včasih res mrgolelo) spremenilo v potencialen


A se ni GDI-ja prestavilov jedro že v NT 4.0 ?

Drugače pa hvala za vse odogovre, vse skupaj je zlo zanimivo.

BlueRunner ::

A ni Native API (NTAPI) namenjen samo za interno MS uporabo in zato uradno nedokumentiran?

Da, NTAPI obsega cel kup funkcij, ki niso dokumentirane in MS-ju omogočajo stvari, ki jih morajo drugi početi drugače - predvsem manj optimalno. Nek minimalen del pa ga je dokumentiranega, saj brez tega ne bi bilo možno napisati ring0 gonilnika. Ni pa to API, ki bi bil namenjen neposredni uporabi v programih. Tako, kot ni mišljeno, da bodo programi za Linux neposredno klicali jedro. Nekaj čisto osnovnih informacij pa je tukaj.

A se ni GDI-ja prestavilov jedro že v NT 4.0?

Da in ne. V NT 4.0 je bil vmesnik za gonilnike za GDI res že prenešen v win32k.sys, kar je že povzročilo cel kup težav z nekvalitetno napisanimi gonilniki. To in nadaljevanje te zgodbe je bil tudi eden izmed razlogov za uvedbo WHQL potrdil v kasnejših verzijah oken. Preveč bugov in ring0 ranljivosti (s posledičnimi BSOD-i), za katere MS objektivno res ni bil kriv. Šele eden izmed service packov (ne spomnem se več kateri... to je le bilo skoraj desetletje nazaj) pa je stvar dokončal in jo po obsegu privedel na nivo NT5 jedra. Deli funkcionalnosti za DirectX z vsemi svojimi podsistemi so dobili domovinsko pravico v ring0.

Sam bi rekel, da je to nekako tako, kot DRI modul v Linux-u. Zadenjska vrata skozi katera privilegiran userland pride na hitro do neposrednega dostopa do HW-ja (dostop do HW ima samo in izključno ring0). Vendar pa to za seboj potegne tudi več možnosti za sesutje celotnega sistema.

PrimozBo ::

Je ta prestavitev GDI-ja v ring0 vzrok za toliko exploitov in malware na win sistemih ?

denial ::

Seveda ne. Je pa GDI/win32k.sys vzrok mnogih ring0 exploitov (BSOD/EoP). Nekaj najbolj svežih primerov: MS10-048 ter unpatched.
SELECT finger FROM hand WHERE id=3;

BlueRunner ::

Je ta prestavitev GDI-ja v ring0 vzrok za toliko exploitov in malware na win sistemih ?

Ne. Bistven vzrok za število zlonamerne kode na Windows sistemih je politika polnega dostopa do sistema, ki je bila v Windows XP, kot prvem consumer grade NT OS-u vsiljena zaradi lažjega prehodia iz Win16 in Win9x sistemov, ki varnosti niso poznali.

To izvorno zlo (lahko se mu reče napaka, lahko se mu reče nuja) se vleče še danes, vse kar se je spremenilo pa je t.i. UAC, ki naj bi uporabnika z administratorskimi pravicami omejil pri izkoriščanju teh pravic. Pravim "naj bi", ker se je do sedaj že nekajkrat izkazalo, da je sistem pomankljiv in v svojem bistvu zgrešen.

Je pa to danes razlog za množice BSOD-ov, kot je denial napisal. En slab gonilnik ali pa ena napaka v ring0, pa je konec zabave.

PrimozBo ::

denial je izjavil:

Seveda ne. Je pa GDI/win32k.sys vzrok mnogih ring0 exploitov (BSOD/EoP). Nekaj najbolj svežih primerov: MS10-048 ter unpatched.


Ok. Samo če imaš mnogo explitov ki ti omogočajo dvig pravic, potem to omogoča tudi mnogo malware. Tu ti ne pomaga nobeno poganjanje sitema kot navaden user, če je veliko lukenj, ki ti omogočajo dvig pravic.

BlueRunner ::

Dokler obstajajo lažji načini, da se ti ta zalega zaredi na računalniku, toliko časa to ni primaren razlog. Ko se bodo pa ti lažji načini zaprli, se bo pa morda tudi to spremenilo.

Zgodovina sprememb…

denial ::

Za uporabo EoP kode moraš imeti local ali remote dostop do mašine. Možna scenarija sta: a) mašina je že kompromitirana in b) zlobni insider.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Apple se poslavlja od 32 bitov (strani: 1 2 3 )

Oddelek: Novice / Apple iPhone/iPad/iPod
10812448 (7432) AndrejO
»

Vzroki v kernelu Linuxa da na njem ne delajo Win aplikacije (strani: 1 2 )

Oddelek: Programiranje
764568 (2935) BlueRunner
»

Linux jedro z resno varnostno luknjo

Oddelek: Novice / Varnost
485154 (1980) 'FireSTORM'
»

[VB6] Program Odštevalnik - verjetno preprosta rešitev ampak jest je ne najdem (strani: 1 2 )

Oddelek: Programiranje
513507 (2981) Nerdor
»

Odpiranje dat.exe v VB

Oddelek: Programiranje
122018 (1811) webblod

Več podobnih tem