Gospodarji prstana 0
Korenski kompleti ali "rootkiti" so širši javnosti postali znani šele po znanem škandalu s Sonyjevo zaščito proti kopiranju glasbenih CDjev. Pa vendar so v strokovni javnosti znani že veliko dlje, lastnosti, ki so značilne zanje, pa s pridom uporabljajo virusi in trojanski konji.
Zgoraj zapisano izjavo je izrekel eden izmed vodilnih mož korporacije Sony/BMG kmalu zatem, ko je strokovnjak za računalniško varnost Mark Russinovich odkril, da Sonyjeva zaščita XCP (Extended Copy Crotection) proti kopiranju glasbenih CDjev uporablja metode, značilne za delovanje korenskih kompletov. XCP DRM (Digital Rights Management) namreč v sistem namesti gonilnik (konkretno aries.sys), ki ob pomoči programerske tehnike, imenovane "prestrezanje klicev API" (API hooking), prikrije delovanje in izpisovanje procesov, registrskih ključev, imenikov in vseh objektov z začetnico $sys$. Skratka, na vsak način se poskusi prikriti in se skorajda ne pusti odnamestiti. Kot vsak spodoben virus ali trojanski konj. Škandal je dvignil veliko medijskega prahu in Sony je bil primoran dvomljive glasbene CDje umakniti s trga. Nedavno pa je eno izmed ameriških sodišč odločilo, da mora gigant izplačati tudi odškodninske tožbe. Poglejmo torej natačneje, kaj sploh je "rootkit" oziroma korenski komplet?
Znani že od nekdaj
Korenski kompleti so v taki obliki, kot jih poznamo danes, prvič nastali sredi devetdesetih let prejšnjega stoletja, in sicer v sistemih Unix. Po nekaterih (nepreverjenih) virih je bil prvi tak komplet odkrit v Sunovem operacijskem sistemu, nekatere elementarne zametke v obliki čistilcev dnevniških zapisov (log cleaner) pa so skrbniki v svojih sistemih odkrivali že konec osemdesetih let. Glavni in osnovni namen korenskega kompleta je prikrivanje dejavnosti napadalca v sistemu. Seveda mora vsiljivec predhodno kompromitirati sistem na skrbniški ravni. Vsekakor je zmotno enačenje teh kompletov s stranskimi vrati (backdoor) ali izkoriščevalskimi orodji (exploit), čeprav so na voljo tudi paketi, imenovani "auto-rooters", ki so naphani z zlobno kodo različnih oblik in namenskosti, tudi s korenskimi kompleti, vohljači, stranskimi vrati in čistilci dnevniških zapisov, da vohunskih in reklamnih programov niti ne omenjamo. Namen teh paketov je popolno kompromitiranje sistema s kar najmanj truda in kar najhitreje. Taka sovražna koda spada med priljubljene "igračke" skriptnih otročajev ...
Uporabniški ali jedrni
Na splošno korenske komplete delimo v dve kategoriji: uporabniške ali "user-land", ki so sicer izvedeni v kontekstu privilegiranega uporabnika, vendar operativni v varnostnem obroču ring 3, ter jedrne ali "kernel-land" (operativne v privilegiranem varnostnem obroču ring 0).
Glede na uporabljeno metodo implementacije pa se kompleti delijo na štiri podkategorije: programske (binarne) komplete, jedrne komplete, virtualne komplete ter knjižnične komplete (library rootkit). Slednji dve obliki sta sicer navzoči le v zelo omejenem, najpogosteje eksperimentalnem obsegu. Najpreprostejši uporabniški kompleti so nedvomno programski, ki enostavno izvedejo zamenjavo originalnih datotek s trojanskimi oz. prirejenimi. Zelo znani predstavniki te kategorije so T0rnkit, Tuxkit in LRK, ki delujejo v Linuxu (jedro 2.2-2.4). Programski kompleti preprosto zamenjajo nekatere sistemske programe, kot npr. login, netstat, ps, find, ls, ifconfig, du, syslogd, w, lsof ..., z modificiranimi različicami, katerih koda je prirejena tako, da filtrira prikazovanje določenih parametrov, ki jih napadalec predhodno definira v konfiguracijski datoteki kompleta. Tako prepreči npr. izpisovanje naslovov IP, programskih vrat, datotek, procesov, uporabnikov ...
Podobno metodo uporabljajo tudi kompleti na ravni knjižnic, le da namesto programov zamenjujejo sistemske knjižnice. Med najbolj znane take komplete nedvomno spada t0rnkit8 (jedro 2.4), ki zamenja standardno sistemsko knjižnico libproc s trojansko različico. Napadalcu tako ni treba zamenjati sistemskih programov, saj bodo ti že prejeli "prečiščene" informacije. S krpanjem (patch), kavlji (hook) ali zamenjavo sistemskih klicev, izvedenih prek kompromitiranih knjižnic, lahko vsiljivec "preusmeri" izvajanje, tako da se namesto izvirnega programa dejansko izvede trojanska različica. Metoda je sicer znana pod nazivom "execution redirection" in je eden izmed osnovnih prijemov, ki jih uporabljajo kompleti na ravni jedra. Velja omeniti, da so statično povezani in prevedeni programi (ti ne uporabljajo zunanjih knjižnic) imuni za tako obliko korenskih kompletov.
V okenskem okolju je programski pristop skoraj neuporaben, saj imajo Okna od Windows 2000 naprej vgrajeno storitev WFP (Windows File Protection), ki nenehno preverja integriteto sistemskih datotek in ob morebitni nepravilnosti nemudoma zamenja kompromitirano datoteko z rezervno varnostno kopijo. Skrbnikom je pri preverjanju integritete v pomoč tudi sistemski program System File Checker (sfc.exe) ali Microsoftovo namensko orodje FCIV. Tudi v Linuxu je programske in knjižnične komplete razmeroma preprosto odkriti. Zadostuje namreč uporaba programov za preverjanje celovitosti datotek (Samhain, Tripwire, AIDE), namenska orodja, kot sta Rootkit Hunter in chkrootkit, jih dokaj uspešno odkrivata, odlično pa se odrežejo tudi programi strace, ltrace in syscalltrack, ki se uporabljajo za sledenje sistemskim klicem.
Danes se programska in knjižnična oblika kompletov vse bolj umikata in prepuščata oder jedrnim kompletom. Kot zanimivost omenimo, da so imeli pri kodiranju nekaterih programskih kompletov Linux prste vmes tudi slovenski hekerji. Eden izmed (zdaj že nekdanjih) akterjev je razkril, da so nekateri kompleti skupine "etC!" imeli stranska vrata, za katera je tedaj le malokdo vedel.
rkhunter je odlično orodje za odkrivanje uporabniških korenskih kompletov v Linuxu.
Pripnimo se na API
V Oknih so hekerji ubrali nekoliko drugačno metodo. Tako uporabniški kakor jedrni kompleti v Oknih prikrivajo svoje delovanje s prestrezanjem funkcij API, s katerimi preusmerijo izvajanje na drug pomnilniški naslov, kjer je alternativna funkcija, operacija ali namenska koda. Ta izvede specifične manipulacije ali modifikacije (najpogosteje filtriranje določenih parametrov) in vrne nadzor funkciji, ki je izvedla klic. V programerskih vodah je metoda bolj znana kakor "kavlji" API (API hooking). Programski vmesnik (API, Application Programming Interface) je nabor funkcij, prek katerih lahko uporabniški programi komunicirajo z operacijskim sistemom ali jedrom.
Klici API so ustreznik sistemskih klicev v okolju Unix. Kot zanimivost, Linux (jedro 2.6) vsebuje približno 300 sistemskih klicev (definirani so v datotekah syscall.h ali unistd.h), medtem ko osrednji Win32 API vsebuje več kot 2000 klicev (število je tudi sicer relativno, saj je pogojeno z različico Oken in ne upošteva nativnih klicev API). Osrednji Win32 API se deli na Kernel API (implementiran v kernel32.dll in advapi32.dll), User API (implementiran v user32.dll) in GDI API (implementiran v gdi32.dll). Omenjeni moduli vsebujejo, v programerskem žargonu "eksportirajo", vse dokumentirane osrednje funkcije API. Poleg omenjenih so še drugi vmesniki, npr. Shell API, Winsock API, DirectX ..., pa tudi vmesnik, ki ga Microsoft zelo nerad omenja. Celo dokumentirati ga ne želi. To je t. i. nativni API, znan tudi kot "nedokumentirani API", ki predstavlja dejansko komunikacijo z jedrom. Po Microsoftovem prepričanju naj bi uporabniški programi ne imeli prek kernel32.dll neposrednega dostopa do jedra.
Povezava uporabniških modulov in jedrnih komponent v Oknih
Nativni API je nameščen v knjižnici ntdll.dll (za klice iz obroča ring 3) in ntoskrnl.exe (za klice iz obroča ring 0). Za dokumentiranje vmesnika so poskrbeli kar sami hekerji: metasploit.com/users/opcode/syscalls.html. Odlično orodje za sledenje klicev API je StraceNT, nativne funkcije API pa najlaže odkrijemo po začetnicah "Nt" ali "Zw". Nemalokrat bomo presenečeni, koliko sistemskih klicev sproži še tako preprosta operacija. Podatkovni tok je zares impresiven, brez uporabe filtrirnih parametrov pa tudi praktično nepregleden.
StraceNT je odlično orodje za sledenje klicev API.
Prestrezanje funkcij API se pri uporabniških kompletih najpogosteje izvaja z modifikacijo kazalcev v tabeli IAT/EAT ali z "vzporednim prestrezanjem" (inline hooking). Vsak program, proces in dinamična knjižnica razpolaga s svojo "uvozno tabelo" (IAT, Import Address Table) in "izvozno tabelo" (EAT, Export Address Table), v katerih so pomnilniški naslovi funkcij API. IAT tako vsebuje naslove funkcij, ki jih objekt trenutno uporablja, EAT pa vsebuje naslove funkcij, ki so na razpolago drugim objektom. S spreminjanjem kazalcev funkcij API v tabelah IAT/EAT napadalec preusmeri klice na alternativno lokacijo.
Grafični prikaz prestrezanja klicev API
Pri vzporednem prestrezanju gre za nižjenivojsko manipulacijo kode v pomnilniku, kjer na začetek funkcije vrinemo ukaz za brezpogojni skok (JMP). Opisana metoda je nastala v Microsoftovih laboratorijih in je znana tudi kot "hot patching". Pogosto se uporablja pri nameščanju varnostnih popravkov v sisteme, ki ne dopuščajo vnovičnega zagona. Vprašanje za milijon evrov se seveda glasi: Kako sploh lahko izvedemo vzporedno prestrezanje ali manipulacijo kazalcev IAT/EAT, če vemo, da vsi procesi delujejo v navideznem pomnilniku in je torej pomnilniški prostor procesa "A" izoliran pred manipulacijo s strani procesa "B"? Znane so zvijače, s katerimi lahko napadalec v pomnilniški prostor procesa A "vbrizga" modificirane dinamične knjižnice (DLL injection) ali povzroči preusmerjanje dinamične knjižnice (DLL redirection) ter tako namesto originalne knjižnice uporabi prirejeno. Če omenimo le dve metodi: uporaba programa LordPE, s katerim priredimo tabelo IAT izbrane izvršilne datoteke (npr. cmd.exe), ali pa preprosto uporabimo registrski ključ
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
Ob zagonu se naložijo vse knjižnice DLL, ki so navedene v tem ključu. Ko je namenska knjižnica enkrat naložena v pomnilniški prostor procesa, lahko napadalec prek nje neovirano izvaja prestrezanje klicev API.
Najznamenitejši okenski uporabniški korenski kompleti so Hacker Defender, Vanquish in AFX. Odkrivanje teh zlonamernih programov skrbnikom ne povzroča večjih težav, saj je zelo veliko namenskih programov, ki odlično opravijo svojo nalogo. Če jih naštejemo le nekaj: Rootkit Revealer, BlackLight, Gmer, Ice Sword, Rootkit Detective, Rootkit Uncover, Anti-Rootkit ... Odkrivajo pa jih tudi standardni protivirusni programi. Čeprav morda zveni nekoliko zmedeno, so API "kavlji" (hooks) popolnoma legitimna programerska tehnika. Microsoft je razvil celo posebno knjižnico, s katero je programerjem nekoliko olajšal delo. Več informacij: research.microsoft.com/sn/detours.
Kavlji SSDT obroča 0, kot jih prikaže IceSword.
Jedrni kompleti
Kompleti na ravni jedra uporabljajo veliko bolj prefinjeno metodo, priredijo namreč srce operacijskega sistema, torej kernel. Arhitektura IA-32, ne glede na dejansko količino fizičnega pomnilnika, alocira 2^32 oziroma 4 GB (4.294.967.296 bajtov) navideznih (virtualnih) pomnilniških lokacij, ki so privzeto tako na platformi Linux kakor Windows razdeljene na zgornji uporabniški prostor (user-land) ter spodnji jedrni prostor (kernel-land). Za informacijo, arhitektura x86-64 lahko upravlja 2^64 ali okrog 16 eksabajti pomnilniških naslovov. Jedro skrbi za upravljanje sistemskih rezerv ter za povezovanje strojnih in programskih komponent operacijskega sistema. Vsi moderni procesorji x86 omogočajo delovanje v zaščitenem načinu (protected mode), ki temelji na načelu zaščitnih obročev ali prstanov (rings). Koncept je preprost, privilegiji izvršene kode so definirani glede na obroč, v katerem je izvedena.
Operacijski sistem ob zagonu preklopi delovanje procesorja iz nezaščitenega, realnega načina (real mode) v zaščiteni način. V realnem načinu vsa koda, izvedena v procesorju, velja za privilegirano, torej bi lahko vsak uporabniški proces dostopal do pomnilniškega prostora drugega procesa, v končni fazi pa bi lahko, v primeru sesutja, povlekel s seboj ves sistem. Slednje smo v praksi pogosto izkusili ob uporabi slabo napisanih ali nepodprtih gonilnikov. Le-ti namreč delujejo v obroču ring 0, njihovo "sesutje" pa neizbežno vodi do osovraženega modrega zaslona (BSOD). Starejši operacijski sistemi, kot npr. MS-DOS, so delovali zgolj v realnem načinu. Privzeto se, predvsem zaradi združljivosti, celo najnovejši procesorji še vedno zaganjajo v realnem načinu. Med samim izvajanjem OS preklaplja delovanje procesorja med obroči glede na privilegije kode. Procesorji Intel/AMD uporabljajo štiri obroče, čeprav se dejansko uporabljata le dva: neprivilegirani (uporabniški) ring 3 ter privilegirani (jedrni) ring 0. Vsa jedrna koda (HAL - Hardware Abstraction Layer, vhodno/izhodni sistem, servisi za upravljanje pomnilnika in procesi, funkcije za upravljanje prekinitev in izjem, varnostni mehanizmi, GDI ...) in gonilniki se izvajajo v obroču ring 0, nasprotno pa se vsa uporabniška koda in procesi (med uporabnike prištevamo tudi račune root, Administrator in SYSTEM) izvajajo v obroču ring 3.
Gonilniki in neposredno prepisovanje pomnilnika
Jedro je tako izolirano in zaščiteno pred neposredno manipulacijo s strani uporabniških procesov. Seveda uporabniški programi pri izvajanju svojih nalog potrebujejo podatke iz določenih struktur jedra. Vsaka akcija v uporabniškem obroču ima namreč svojo reakcijo v jedrnem obroču. Še tako preprosta operacija, kot je npr. odpiranje praznega dokumenta, zahteva posredovanje jedra. Tu vstopijo že omenjeni sistemski klici, ki omogočajo komunikacijo med obroči oziroma med uporabnikom in jedrom. V okolju Linux (podobno velja tudi za Okna) se uporabljata dva načina izvajanja jedrnih kompletov: naložljivi moduli (LKM, Loadable Kernel Modules), v Windows imenovani preprosto gonilniki, in neposredno prepisovanje /dev/kmem (lahko tudi /dev/mem ali /dev/mmem). Te komponente predstavljajo psevdonaprave, ki preslikujejo različne segmente fizičnega pomnilnika. V tem primeru gre torej za nizkonivojsko manipulacijo jedra v delovnem pomnilniku (RAM). Tak pristop (tudi zaradi težavnosti) ne uporablja ravno veliko korenskih kompletov, najbolj znan je nedvomno SucKIT ali novejša izvedba SucKIT-ng, ki deluje tudi z jedrom 2.6. Nekatere distribucije Unix/Linux predvsem iz varnostnih razlogov ne uporabljajo omenjenih naprav, oziroma onemogočajo zapisovanje vanje. Tudi Okna vsebujejo podobno datoteko: \Device\PhysicalMemory. Ta se po svoji funkcionalnosti prav v ničimer ne razlikuje od različice Unix/Linux. Microsoft je iz varnostnih razlogov v Windows 2003 Server onemogočil dostop do omenjene datoteke iz obroča ring 3. Če želimo raziskovati krajevni delovni pomnilnik na domačih mlinčkih, zadostuje uporaba orodja PhysMem (Windows Sysinternals):
download.sysinternals.com/Files/PhysMem.zip
Dve zanimivi lokaciji, kjer se lahko s programom poigramo, sta 0xF0000 - 0xFFFFF (preslikava ROM BIOSa v delovnem pomnilniku) ter 0x10000 (NTLDR). Seveda program omogoča zgolj pregledovanje in ne tudi urejanja.
Prvi javno objavljeni korenski komplet, ki je uporabljal pristop LKM (pa tudi prvi jedrni komplet na splošno), je heroin.c (1997). Med najznamenitejše komplete, ki uporabljajo metodo LKM, pa prištevamo še Knark, Adore, Adore-ng in SIDE (slednja delujeta tudi z jedrom 2.6).
Linux, kakor tudi vsi moderni operacijski sistemi, omogoča dinamično nalaganje modulov ali gonilnikov. Ti pa delujejo, kakor smo že omenili, v obroču ring 0, prostoru absolutnih pravic ... Poskusimo ponazoriti: če drži, da je root/Administrator kralj v sistemu, potem je uporabnik, ki manipulira s kodo ki se izvaja v privilegiranem obroču, bog. Tako v Linuxu kakor Oknih pa je "bog" lahko vsakdo, ki v jedro naloži modul/gonilnik, prek katerega nato prireja vrednosti sistemskih klicev ali prekinitvenih opravilnikov (interrupt handlers). Za boljše razumevanje si oglejmo, kako deluje mehanizem sistemskih klicev v Linuxu. Za inicializacijo sistemskih klicev se uporablja instrukcija INT s programsko prekinitvijo 0x80. Ko se sproži sistemski klic, se v register EAX vnese zaporedna številka funkcije, aktivira pa se tudi prekinitveni opravilnik (interrupt handler), ki je odgovoren za upravljanje specifične prekinitve. V naslednjem koraku nadzor prevzame opravilnik sistemskih klicev (system_call handler), ki na podlagi podatkov v tabeli sistemskih klicev in zaporedne številke funkcije locira naslov sistemskega klica. Med celotnim procesom ima vsiljivec veliko možnosti za manipulacijo sistemskih klicev, najpogosteje pa se napadalci poslužujejo prirejanja IDT (Interrupt Descriptor Table), kjer so definirane prekinitve in izjeme ali tabele sistemskih klicev. Odkrivanje takih kompletov je veliko težavnejše. Nekatere znane komplete sicer uspešno odkrivata tudi Rootkit Hunter in chkrootkit, dejansko pa lahko komplet LKM odkrijemo le z analizo pomnilniškega prostora jedra. Eden izmed načinov odkrivanja je primerjava naslovov sistemskih klicev. Čeprav se primerjava lahko izvede tudi ročno, so skrbnikom v veliko pomoč orodja Samhain, kstat in kern_check.
VICE razkrije tako "kavlje" v obroču ring 3 kakor tudi v obroču ring 0.
Slabost korenskega kompleta v okolju Windows, ki izvaja prestrezanje funkcij API v obroču ring 3, je vsekakor zahteva po aktivnem in konstantnem opazovanju vseh procesov, ki se izvajajo v sistemu. Komplet mora namreč pravočasno "zakrpati" vse klice. Prestrezanje klicev API v samem jedru je veliko elegantnejše in, kar je še pomembneje, velja na globalni ravni. Seveda tudi v Oknih velja osnovno pravilo: uporabniška koda lahko do jedra dostopa le prek klicev API (sistemskih). Pri inicializaciji klicev v Windows 2000 ter starejših se uporablja instrukcija INT in programska prekinitev 0x2E. Ob sprožitvi klica API se v register EAX vnese zaporedna številka funkcije, register EDX pa vsebuje naslov, na katerem so locirani parametri funkcije v uporabniškem obroču ring 3. Procesor na podlagi vrednosti v IDT (Interrupt Descriptor Table) za prekinitev 0x2E prikliče ntoskrnl.exe funkcijo KiSystemService(), ki ima vlogo razdeljevalca sistemskih klicev (kernel service dispatcher). Le-ta nato primerja vnose v tabeli SSDT (System Service Dispatch Table) in registru EAX ter prikliče zahtevano funkcijo. V Windows XP in novejših je celoten proces nekoliko drugačen. Bistvena razlika je opustitev programske prekinitve 0x2E in uporaba ukaza SYSENTER.
Preden sistemski klic zapusti obroč ring 3 in vstopi v obroč ring 0, mora skozi posebna vrata, imenovana Interrupt Gate. Njihov namen je, da preverjajo, kateri klici lahko vstopijo v jedrni obroč. V bistvu so "vrata" funkcionalnost procesorja, ki na podlagi privilegijev, definiranih v tabeli Interrupt Gate Descriptor (IGD), preveri, ali je uporabniški program pooblaščen za izvajanje sistemskih klicev. V novejših izvedenkah Oken je sistem "vrat" implementiran v posebnih registrih (MSR, Model Specific Registers). Z manipulacijo tabel SSDT/IGD/IDT ali registrov MSR lahko heker preusmeri izvajanje klicev na svoj mlin. Jedrni kompleti za Windows so najpogosteje v obliki sistemskih gonilnikov (.sys). Najznamenitejši primerki so nedvomno NTroot (prvi jedrni komplet za Okna), Fu ter novejša izpeljanka Futo.
Na srečo je veliko odličnih programov, ki odkrivajo take modifikacije v jedru: SSV, VICE, System Hook Analizer, Hook Explorer ... Odkrivajo jih seveda tudi vsi boljši protivirusni programi. Morda je paradoksalno le to, da slednji kot dodatno raven zaščite intenzivno prakticirajo ravno prestrezanje globalnih klicev API.
Hook analyzer prikaže globalne "kavlje" AV programa Kaspersky
Pokvarimo raje obstoječi gonilnik
V zadnjem času se vse bolj uveljavlja metoda, imenovana direktna manipulacija jedrnih struktur (DKOM, Direct Kernel Object Manipulation). Korenski komplet v tem primeru ne naloži namenskega modula/gonilnika, temveč modificira enega izmed že obstoječih in prednaloženih v jedru.
Preprosta(?) rešitev korenskih kompletov na ravni jedra bi bila uporaba podpisanih modulov in gonilnikov. To je Microsoft že uvedel s "kernel patch protection" v x86_64 Windows 2003 Server in Vista. Druga možna rešitev bi bila uvedba obroča ring 1, ki bi omogočil razdvajanje jedrne kode in gonilnikov. Med uporabne (vendar ne najbolj priljubljene) ukrepe seveda lahko prištejemo tudi uporabo monolitnega jedra, torej jedra, ki ne dopušča nalaganja modulov, kar nekateri Unix/Linux skrbniki prakticirajo že dalj časa. Slednje seveda ni rešitev pred metodama DKOM ali /dev/kmem.
Kompleti za kartice PCI
Za konec še beseda ali dve o virtualnih in PCI korenskih kompletih. Nedavno so raziskovalci varnosti v družbi NGS Software odkrili način, kako lahko ob pomoči strojnega jezika AML (ACPI Machine Language) priredijo strojno programsko opremo na nekaterih karticah PCI, da bo ta izvedla namensko kodo. Koncept sicer ni nov, saj so pred leti raziskovalci pri USENIX predstavili tudi nasprotno: strojni detektor jedrnih kompletov na vodilu PCI. Več informacij:
www.komoku.com/pubs/USENIX-copilot.pdf
www.ngssoftware.com/research/papers/Implementing_And_Detecting_A_PCI_Rootkit.pdf
Čeprav je koncept PCI korenskih kompletov še globoko v razvojni fazi, odkritje nedvomno odpira nova vprašanja. Lahko se namreč vprašamo, ali so potencialno nevarne vse strojne naprave in enote, ki omogočajo zapisovanje v pomnilnik strojne programske opreme oz. pomnilnik flash?
Navidezni kompleti delujejo na podlagi spremembe zagonskega zaporedja v sistemu in poženejo najprej sovražno kodo namesto samega operacijskega sistema. Ko je komplet naložen v pomnilniku, se sproži nalaganje operacijskega sistema, vendar ima ta vlogo gostujočega sistema (guest OS). Ker virtualni komplet deluje kot gostitelj (host OS), torej deluje na najnižji ravni, lahko brez težav prestreza sistemske klice. Tak pristop bo najverjetneje naslednji (velik) korak v razvoju korenskih kompletov, saj je virtualizacija v velikem razmahu. V spletu najdemo kar nekaj takih kompletov, npr. bootkit, sysrq2, bootroot in SubVirt.
V taki ali drugačni preobleki so korenski kompleti še vedno klasična oblika sovražne programske kode. Zagotovo pa niso "the root of all (digital) evil ..."
Uporabne povezave:
www.cs.tut.fi/~rammer/aide.html
la-samhna.de/library/kern_check.c
www.antirootkit.com/software.htm
www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
ftp2.de.freebsd.org/pub/misc/www.rootshell.com/hacking/heroin.c