System Service Descriptor Tabel: Nøglen til Windows-sikkerhed og ydeevne

Forståelse af de indre mekanismer OS Moderne er essentielt for enhver IT-professionel, især når det kommer til spørgsmål relateret til sikkerhed og udvikling drivere eller reverse engineering. Et af nøglebegreberne inden for dette felt er System Service Descriptor Tabel (SSDT), en grundlæggende struktur i kernen af Windows-systemer, som, selvom den ofte går ubemærket hen for den gennemsnitlige bruger, spiller en afgørende rolle i interaktionen mellem softwaren og hardware, i håndteringen af systemkald og desværre også i visse angrebs- og forsvarsteknikker i verden af malware og antivirusprogrammer.

Denne artikel tilbyder En komplet og detaljeret oversigt over, hvad SSDT er, hvordan det fungerer i forskellige versioner og arkitekturer af Windows, hvad dets rolle er i udførelse af systemkald (syscalls), hvordan det kan bruges af både rootkits og legitime sikkerhedsværktøjer, og hvilke teknikker gør det muligt at inspicere, manipulere eller beskytte dets integritet. Hvis du er involveret i driverudvikling, retsmedicinsk analyse, cybersikkerhed eller du blot brænder for hjertet i Windows-systemer, vil denne vejledning tjene som en uundværlig reference.

Hvad er System Service Descriptor-tabellen (SSDT)?

La Tabel over systemtjenestebeskrivelser, også nævnt som Tabel for systemtjenesteforsendelse og kendt under akronymet SSDT, er en særlig tabel, der vedligeholdes af Windows-kernen (Ntoskrnl.exe) der indeholder pointere til kernefunktioner, der er ansvarlige for at behandle systemkald foretaget fra brugerområdet. Med andre ord er det en slags "bro", der forbinder anmodninger foretaget af applikationer eller brugerbiblioteker (såsom Ntdll.dll) med de interne tjenester i operativsystemkernen.

En 32-bit systemer, er SSDT'en simpelthen et array af absolutte adresser til kernefunktionerne. 64-bit filerAf sikkerheds- og effektivitetsårsager gemmer tabellen relative forskydninger fra en kendt base i kernen. Denne detalje er vigtig, fordi den påvirker, hvordan stier til interne funktioner løses, og hvordan de kan analyseres eller manipuleres af debuggere eller analyseværktøjer.

Sådan fungerer SSDT i praksis

Flytningen af et systemkald fra brugerområdet til dets håndtering i kernen kan opsummeres som følger:

• Et brugerprogram eller en brugerproces anmoder f.eks. om åbning af en fil ved hjælp af en Windows API-funktion, f.eks. Opret fil.
• Dette kald ender med at kalde en funktion af Ntdll.dll som NtCreateFile, som er ansvarlig for at forberede det tilhørende systemkald (syscall).
• Funktionen af Ntdll.dll udfører en instruktion syscall (på x64) eller int 0x2e (på x86), hvor et indeks sendes som en parameter, der entydigt identificerer, hvilken systemtjeneste der kræves.
• Allerede i kernetilstand bruges dette indeks til at søge i SSDT offset eller adressen for den tilsvarende kernefunktion, og kontrollen overføres til den funktion (f.eks. nt!NtCreateFile).

På denne måde SSDT Den fungerer som en jump table, der gør det muligt at gøre hundredvis af kernefunktioner tilgængelige på en ordnet og effektiv måde, samt giver en klar adskillelse mellem brugerområdet og det beskyttede kerneområde.

SSDT'ens interne struktur og dens repræsentation i hukommelsen

I Windows-kernen er SSDT tilgængelig via en struktur kaldet KeServiceDescriptorTable, eksporteret af ham selv Ntoskrnl.exeDenne struktur indeholder vigtige oplysninger om tabellen, herunder tabellens base (KiServiceTable), antallet af tjenester og andre metadata.

Måden at tilgå SSDT'en og fortolke dens input på varierer mellem arkitekturer:

• En x86 (32-bit), KiServiceTable Det er et array, hvor hvert element peger direkte på den absolutte adresse for en kernefunktion.
• En x64 (64-bit), elementerne er relative forskydninger (offsets) i forhold til basen, så for at opnå den reelle adresse er det nødvendigt at anvende en formel, der tager basen og tilføjer den tilsvarende forskydning, normalt efter en bitjustering til højre (forskydning >> 4).

Lad os se på et virkeligt eksempel, hvor WinDBG-debuggeren bruges til at illustrere, hvordan tabellen dannes i hukommelsen:

0: kd> dps nt!KeServiceDescriptorTable L4
fffff801`9210b880 fffff801`9203b470 nt!KiServiceTable
fffff801`9210b888 00000000`00000000
fffff801`9210b890 00000000`000001ce
fffff801`9210b898 fffff801`9203bbac nt!KiArgumentTable

Det første element peger på KiServiceTable, det vil sige selve SSDT'en. Det tredje element angiver normalt antallet af tilgængelige tjenester. Ved inspektion KiServiceTable, vil vi se en række værdier, der hver især er forskydningerne eller adresserne i forhold til hver kernefunktion, der eksporteres af SSDT'en.

Variationer af bordene: SSDT og SSDT Shadow

En moderne versioner af Windows Udover hovedbordet er der et "skyggebord" kaldet KeServiceDescriptorTableShadowDenne anden tabel bruges normalt til mere specifikke tjenester, såsom dem, der er relateret til systemets grafiske brugerflade (f.eks. kald til win32kSystemet bestemmer i realtid, via parametre fra kaldeprocessen, hvilken af de to tabeller der skal bruges til at løse et givet syscall.

Eksempel: Løsning af kernekald og -funktioner ved hjælp af SSDT

Antag, at en udvikler eller analytiker ønsker at vide, hvilken kernefunktion et bestemt syscall-nummer svarer til, for eksempel den, der er knyttet til NtCreateFileProcessen ville være som følger:

• Vi identificerer indekset for syscall'en ved at se på koden i Ntdll.dllFor eksempel kunne det være 0x55.
• Hver indgang af KiServiceTable (SSDT'en) optager 4 bytes, så for syscall 0x55 tilgår vi positionen KiServiceTable + 4*0x55.
• Vi udtrækker forskydningen, og ved at anvende den passende formel løser vi funktionens absolutte retning.
• Vi kan disassemblere funktionen i debuggeren for at kontrollere, at dette offset faktisk peger på den pågældende kode. nt!NtCreateFile.

Dette system sikrer, at alle systemopkald foretaget fra brugeren effektivt og sikkert dirigeres til den relevante interne funktion, hvilket opretholder systemets integritet og optimerer ydeevnen.

SSDT-analyse og manipulationsteknikker

Adgang til og analyse af SSDT Det er afgørende for både udviklingen af legitime drivere og detektion af rootkits og malware. For eksempel i WinDbg Alle absolutte adresser for funktionerne i tabellen kan udtrækkes af scripts, der gennemløber SSDT og løser navnene på de API'er, der er knyttet til hver adresse. Eksempel på et kodestykke script:

.foreach /ps 1 /pS 1 ( offset {dd /c 1 nt!KiServiceTable L poi(nt!KeServiceDescriptorTable+10)}){ r $t0 = ( offset >>> 4) + nt!KiServiceTable; .printf "%p - %y\n", $t0, $t0 }

Denne teknik giver dig mulighed for at liste og analysere mulige ændringer, identificere om funktioner er blevet hooket, og opdage mulige infektioner.

SSDT Hooking: Legal brug og misbrug af malware

Modificer SSDT, en teknik kendt som SSDT-tilslutning, består i at erstatte tabelposter for at omdirigere bestemte systemkald til egne funktioner, normalt fra tredjepartsdrivere. Dette gør det muligt at opfange, ændre eller blokere bestemte operationer, noget der er blevet brugt af antivirus y firewalls for at beskytte systemet i realtid.

Den samme teknik er imidlertid blevet udnyttet i vid udstrækning af rootkits og avanceret malware til at camouflere deres tilstedeværelse, skjule processer, filer eller forbindelser eller endda lette udførelsen af vilkårlig kode i kernen. SSDT-hooking kan være særligt farligt, fordi det giver fuld kontrol over kritiske systemhændelser, og når det først er ændret, er det vanskeligt at opdage ændringer uden de passende værktøjer eller en ren systemreference.

Et tydeligt eksempel kan ses, når man sammenligner SSDT'ens tilstand før og efter installationen af et rootkit:

Rootkittet har erstattet den legitime adresse med sin egen. Brug af kommandoen ln I WinDbg er det muligt at identificere, hvilken legitim funktion der er blevet forfalsket (f.eks. NtQueryDirectoryFile), og hvad malwaren forsøger at skjule (f.eks. ondsindede filer eller mapper).

Af begge grunde er SSDT-hooking et tveægget sværd: det muliggør implementering af avancerede sikkerhedsløsninger, men det giver også yderst effektive mekanismer til undvigelse og hemmelig kontrol af systemer.

Begrænsninger, beskyttelse og udvikling af SSDT

I årenes løb, microsoft har styrket tabellens sikkerhed for at forhindre tredjepartsdrivere eller malware i frit at ændre dens poster. For eksempel med ankomsten af PatchGuard (Kernel Patch Protection) på x64-systemer er automatisk overvågning af SSDT-integriteten implementeret, og ethvert forsøg på at ændre den uden for de tilladte mekanismer ender uundgåeligt i en nedbrud af systemet (blå skærm).

Derudover opfordrer de nyeste versioner af Windows udviklere til at bruge dokumenterede API'er og teknikker i stedet for direkte at tilgå eller ændre SSDT'en, hvorved angrebsfladen reduceres og fremtidige inkompatibiliteter undgås. Der er dog stadig scenarier (retsmedicinsk analyse, malwareundersøgelse, driverkompatibilitet), hvor det er nødvendigt at forstå, hvordan det fungerer, og hvordan man sikrer eller inspicerer det.

Forskelle mellem SSDT og andre systemtabeller

Selvom SSDT ofte forveksles med andre service- eller afbrydelsesbeskrivelsesstrukturer, er det vigtigt at skelne den fra f.eks. Afbrydelsesbeskrivelsestabel (IDT)Mens SSDT håndterer systemkald (kernetjenester) fra brugerområdet, IDT Den er ansvarlig for at løse hardware- og softwareafbrydelser, der når CPU'en, og dirigere dem til de passende afbrydelsesservicerutiner (ISR'er). Hver har sin egen struktur, funktion og beskyttelsesmekanismer, men begge er afgørende for operativsystemets stabilitet og sikkerhed.

relateret artikel:

Sådan sikkerhedskopieres registreringsdatabasen i Windows 11

Isaac

Passioneret forfatter om bytes-verdenen og teknologien generelt. Jeg elsker at dele min viden gennem skrivning, og det er det, jeg vil gøre i denne blog, vise dig alle de mest interessante ting om gadgets, software, hardware, teknologiske trends og mere. Mit mål er at hjælpe dig med at navigere i den digitale verden på en enkel og underholdende måde.