Principen för operativsystemet Core Debugger. Felsökning av kärnläget för Windows operativsystem Vad är kärnans felsökning

Hur man startar Kernel Debugger?

Magister svar:

I processen med mjukvaruutveckling finns det en mycket viktig komponent - det här är debugging. I förhållande till applikationsprogram utförs det med hjälp av det som arbetar i användarläge och ofta inbäddat i IDE. För att kunna avvika, till exempel, föraren, måste Kernel Debugger lanseras.

Du måste köra CMD-kommandotprocessorn. Öppna Start-menyn på aktivitetsfältet. I fönstret som visas, klicka på "Run ...". Fönstret "Startprogram" visas. I textrutan anger du CMD och klickar sedan på "OK" -knappen.

Skapa nu en säkerhetskopia av boot.ini-filen. Först ta reda på installationsvägen för den aktuella kopian av Windows med kommandot: echo% Systemroot%

Därefter, gå till disken, med det installerade operativsystemet genom att ange enhetslistor, och efter dem, sätta kolon. Använd CD-kommandot, gå till rotkatalogen. Använd nu ATTRIB-kommandot, ta bort de "dolda" attributen, "skrivskyddade" och "systemet" från boot.ini-filen. Kopiera kommandot Skapa en säkerhetskopia och ställ sedan in attributen till platsen.

För att ta bort den aktuella nedladdningsalternativslistan, använd kommandot BootCFG / Query. Visa listan och definiera det objektet på grundval av vilka nya inställningar som ska skapas med möjligheten att felsöka i kärnläget. Boot Record-identifieraren bör komma ihåg.

Använd kommandot bootcfg / copy för att skapa en startpost. För att ange inspelningsidentifieraren som du kopierar, använd parametern / ID. Använda / D-parametern, ställ in inspelningsnamnet som visas. Nu måste du gå tillbaka till nedladdningsalternativslistan med kommandot BootCFG / Query, och titta på den extra inmatningsidentifieraren.

Nu måste du aktivera alternativ för att starta Kernel Debugger till den tidigare skapade startposten. Om du debug på målmaskinen behöver du bara lägga till / debug-alternativet.

Om du vill implementera en fjärrfelsökning med anslutning av måldatorn via COM-porten till värdmaskinen, använd sedan / Port och / Baud-alternativen för att ange portnummer och växelkurs.

Om du distanserar dig genom FireWire-kabeln (IEEE 1394-gränssnittet), sedan för att möjliggöra ett lämpligt läge, använd alternativet / DBG1394 och ange alternativet för kanalnummer / CH.

För att försäkra dig om att ändringarna är gjorda, kontrollera starten med kommandot bootcfg med / frågeparametern. Stäng kommando-processorns fönstret genom att placera Exit-kommandot.

Om det behövs, ändra operativsystemets startparametrar. Öppna kontrollpanelen via Start-menyn och öppna "System" -elementet redan i det. I "Systemegenskaper" -fönstret som öppnas, välj fliken Avancerat. På den här fliken väljer du ett avsnitt med namnet "nedladdning och återställning" och klickar på knappen "Parametrar". I fönstret "Ladda och återställning" som visas måste du aktivera alternativet "Display lista med operativsystem". Stäng båda dialogrutan med "OK" -knappen.

Utför en dator för att starta om. Välj Loading med Debugger. Logga in på systemet och börja fungera på målmaskinen eller starta fjärrfelsökning. Dra nytta av medlen som vindbg och kd.

Denna serie av artiklar uppstod av två skäl. Först, jag gillar att arbeta med projektet HacksysextremevulneredRiver. . För det andra fick jag massfrågor För att belysa detta ämne.

Hela koden som används av att skriva denna serie finns i mitt förråd.

I denna cykel av artiklar kommer vi att överväga att skriva exploaterna på kärnnivån i Windows. Det är viktigt att notera att vi kommer att hantera välkända sårbarheter, och i omvänd teknik är det inte nödvändigt (åtminstone för föraren).

Det antas att efter att ha bekant med alla artiklar kommer du att känna till alla vanligaste boomklasser och driftsmetoder, och också kunna hamn utnyttja X86-arkitekturen till X64-arkitekturen (om möjligt) och läs de senaste skyddsmetoderna i Windows 10.

Schema Debugging Kernel

I motsats till felsökning på användarnivå, när utförandet av en separat process är suspenderad, aktiveras hela systemet på kärnnivån, och vi kommer inte att kunna använda den här metoden. Följaktligen behöver du en separat felsökningsmaskin som kan kommunicera med det system där kärnan debugged, se minnet och strukturen på kärnan, såväl som att fånga systemets färger.

Ytterligare material för studier:

Drift av kärnans sårbarheter

Denna process är mycket roligare än operationen på användarnivå J.

Det huvudsakliga målet är att uppnå privilegierat utförande inom ramen för kärnan. Och då beror allt på vår fantasi, allt från en husdjur med inhemsk öl och slutar med införandet av ondskanlighet som sponsras av staten.
I allmänhet är vår uppgift att få ett skal med systembehörigheter.

Trådar av artiklar i denna cykel

Del 1: Ställa in arbetsmiljön

Konfigurera tre virtuella maskiner och system som kommer att fungera som en debugger.
Konfigurera Windbg Debugger.

Del 2: Användbara belastningar

Studie av de vanligaste fördelaktiga belastningarna. I efterföljande delar kommer specifika sårbarheter att övervägas och, om nödvändigt, se den här artikeln.

Andra delar.

Övervägande av sårbarheter.

Livscykeln för utvecklingen av nivån på nivån av kärnan

Hitta sårbarhet. Detta ämne kommer inte att övervägas i denna cykel, som vi redan vet exakt var barerna är belägna.
Avlyssning av flödet av utförande. Vissa sårbarheter ger förekomsten av kod, för vissa finns ytterligare krav.
Utbyggnad av privilegier. Huvudmålet är att få ett skal med systembehörigheter.
Återställa flödet av utförande. Odeccounted undantag på kärnnivån leder till systemets kollaps. Om du inte ska skriva utnyttjande för DOS-attack, bör detta faktum beaktas.

Typer av målsystem

Vi kommer att arbeta med sårbarheter i följande system (specifik version är inte grundläggande):

Win7 x86 VM.
Win7 x64 VM.
Win10 x64 vm.

Låt oss börja med X86-arkitekturen, och då kommer vi att hämta exploatera för Win7 X64-systemet. Vissa exploater körs inte på maskiner med Win10 på grund av närvaron av nytt skydd. I det här fallet ändrar vi antingen logiken för exploateringsarbetet, eller vi kommer att använda ett helt annat sätt.

Programvara som används:

Hypervisor (massalternativ).
Windows 7 x86 VM
Windows 7 x64 VM
Windows 10 x64 VM

Ställa in system för felsökning

Felsökningssystem som vi kommer att interagera är avsedda att ladda ner en sårbar förare. På dessa maskiner kommer kollaps ofta att uppstå, eftersom de flesta undantag i kärnan bidrar till fenomenen av detta slag. Det är nödvändigt att markera tillräckligt RAM för dessa system.

På varje maskin som kommer att felsökas måste du göra följande:

Inne i Virtualkd-katalogen, kör målen \\ vminstall.exe-filen. En ny boot-post kommer att läggas till och felsökningsfunktionerna kommer att finnas tillgängliga och den automatiska anslutningen till VirtualkD-servern installerad i systemet som fungerar som en debugger.

När det gäller Windows 10 VM måste du aktivera test signeringsläge, vilket gör att du kan ladda ner unsigned drivrutiner till kärnan.

Efter att ha kört den bcdeditit / set testning på och omstart på skrivbordet visas "testläge".

KORT BESKRIVNING HEVD-modul

Driverentry-proceduren är starten för varje förare:

Ntstatus Driverentry (i PDRIVER_OBJECT DriverObject, i Punicode_String Registypath) (
Uint32 i \u003d 0;
Pdevice_Object DeviceObject \u003d null;
Ntstatus status \u003d status_unsuccessful;
Unicode_String DeviceName, dosdevicename \u003d (0);

Oreferaced_parameter (Registypath);
Paged_code ();

Rtlinitinicodestring (& DeviceName, L "\\\\ Device \\\\ HacksysextremevulneredRiver");
RTLINITUNICODESTRING (& DOSDEVICENAME, L "\\\\ DOSDEVICES \\\\ HACKSYSEXTREMEVULNERABLEDRIVER");

// Skapa enheten
Status \u003d ICreatedevice (DriverObject,
0,
& Enhetsnamn
File_device_unknown,
File_device_secure_open,
Falsk
& DeviceObject);

Denna procedur innefattar att man uppmanar iCreatedevice-funktionen som innehåller namnet på den förare som vi kommer att använda under kommunikationen.
DriverObject-objektet kommer att lägga till de önskade strukturerna och pekarna på funktionerna.
För oss är funktionspekaren associerad med drivrutinet -\u003e Majorfunktionsförfarandet viktigt för IOCTL-bearbetningen (I / O-kontroll; Ingång / utgångskontroll);
I HEVD kallas den här funktionen en Irpdeviceioctlhandler, vilket är ett utmärkt villkorligt uttryck med en mängd grenar för varje ioctl. Varje sårbarhet har en unik ioctl.

Exempel: hacksys_evd_ioctl_stack_overflow är en ioctl som används för att aktivera staplarna i samband med överflödet på stapeln.

Detta är den första delen slutar. I nästa artikel kommer vi att prata om nyttolast. För närvarande är endast den fördelaktiga belastningen tillgänglig för stöld av tokens, som kommer att användas i den tredje delen.

P.S. Jag förstår att det finns många subtiliteter och de problem som du kan stöta på. Eftersom denna cykel fokuserar på utvecklingen av utnyttjanden måste du lösa alla associerade problem själv. Men alla frågor du kan fråga i kommentarerna.

Författare:
Barinov S.S., Shevchenko O.G.
År:
En källa:
Informatik och datateknik / material av VI Internationella vetenskapliga och tekniska konferensen för studenter, doktorander och unga forskare - 23-25 \u200b\u200bnovember 2010, Donetsk, Donntu. - 2010. - 448 s.

anteckning

En jämförande analys av felsökning av användarläge och kärnläge appliceras på Microsoft Windows-operativsystemet, skiljer och problemen med att organisera den senare felsökningen. Baserat på de erhållna resultaten, de viktigaste kraven för uppbyggnad av Kernelregimens felsökare vid nödsituationer och interaktiva debugging. En analys av befintliga lösningar genomfördes för att kraven överensstämde. I synnerhet är särskild uppmärksamhet betalt till Microsoft Windows Debugger Debugger.

Huvudsak

Debugging är processen att bestämma och eliminera orsakerna till fel i programvara. I vissa projekt tar debugging upp till 50% av den totala utvecklingstiden. Felsökning kan förenklas avsevärt vid användning av specialverktyg som ständigt förbättras. Det viktigaste verktyget är debugger, som låter dig styra implementeringen av programvara, titta på dess rörelse och störa det. Kärnfelsökningsverktygen används huvudsakligen av förareutvecklare.

Application Software Development Toolkit erbjuder ett brett utbud av funktioner. Varje integrerad utvecklingsmiljö omfattar möjligheten att felsöka utan att behöva använda verktyg från tredje part. Om vi \u200b\u200bpratar om systemisk programvara och utvecklar förare i synnerhet, är utvecklingsprocessen extremt svår och har lite automatiserad. Alla faser av utveckling, inklusive debugging, är separata. För att utföra var och en av dem krävs särskilda villkor: skrivandet av programkoden utförs på ett fullfjädrat datorsystem, felsökning - på felsökningssystemet, testning - beroende på omständigheterna etc. Samma kärnregim debugger är mer komplex i utveckling och, följaktligen mindre vänlig.

I allmänhet kan vi prata om bristen på kärnfelsökning. Även om detta är tillgängligt är det ofta inte nödvändigt att prata om alternativ. Till exempel har Microsoft Windows Debugger Debugger en för högtröskel. Många programmerare pratar om den första negativa erfarenheten när han möter honom, och de flesta av dess möjligheter är avsedda.

Baserat på strukturen i det virtuella adressutrymmet, om ett fel görs i ansökan, som ett resultat, kommer programmet att spela in data till ett godtyckligt minnesplats, kommer programmet att skada bara sitt eget minne och inte påverka operationen av andra applikationer och operativsystemet. Medan kärnlägeskoden kan skada operativsystemets viktiga datastrukturer, vilket oundvikligen kommer att leda till ett vanligt misslyckande. Ineffektivt skriftlig drivrutin kan också orsaka allvarlig nedbrytning av hela operativsystemet.

debugging på källkodsnivån;
exekveringshantering;
visa och ändra minne;
visa och ändra innehållet i processorregistren;
visa stapel samtal.

För att underlätta arbetet med demonteringskod används de så kallade. Debugging tecken. Under Linkerens arbete kan också en datafil också skapas innehållande information som inte är nödvändig när du utför programmet, men det är extremt användbart när det felsöker det: Namnen på funktioner, Global variabler, beskrivning av strukturerna. Felsökningskaraktärer är tillgängliga för alla körbara Windows-operativsystemfiler.

Under exekveringskontrollen innebär möjligheten att avbryta och förnya genomförandet av programkoden för att uppnå ett visst kommando i programkoden. Om programkoden exekveras i steg-för-steg-läge - inträffar avbrottet för varje programmeringsspråk Lexeme eller när du lämnar subrutinen. Med fri verkställighet sker avbrottet i utförandet i avancerade sektioner av koden - platser där stopppunkterna är installerade.

När du avbryter kärnläge-koden inträffar följande dilemma. Debuggeren att interagera med programmeraren använder användargränssnittet. De där. Minst utförs den synliga delen av debuggeren i användarläget och det använder naturligtvis applikationsprogrammeringsgränssnittet (Windows API), som i sin tur vilar på kärnlägesmodulerna. Sålunda kan suspensionen av kärnlägeskoden leda till ömsesidig blockering: systemet kommer att sluta svara på användarförfrågningar.

För att komma åt kärnans minne måste debugägarens komponenter också utföras i kärnläget. Detta leder till uppkomsten av två problem samtidigt, vilket är en uppenbar konsekvens av minneorganisationen i det skyddade processorns läge.

Det första problemet handlar om sändningen av virtuella minnesadresser. Förare interagerar ständigt med användarregimens applikationer genom att lägga till åtkomst till deras minne. Windows operativsystem sänder virtuella adresser till det fysiska, som styrs av begreppet strömkontext. Strömskontexten är en struktur som återspeglar strömtillståndet och innefattar i synnerhet en uppsättning register och någon annan information. När kontrollen överförs till en annan ström uppstår en kontextbrytare, i vilken information om en ström sparas och information om den andra återställs. När du byter strömkontexten till en ström av en annan process, byts även sidkatalogen för att sända virtuella adresser till fysiska.

Den särdrag är att när du skickar systemsamtal, växlar Windows-operativsystemet inte sammanhanget. På grund av detta kan kärnlägeskoden använda den virtuella adressen till användarläget.

Annars är situationen när avsändningar avbryter eller utför systemtrådar. Avbrott kan inträffa när som helst, därför är det omöjligt att förutsäga vilket sammanhang av strömmen som kommer att användas. Systemiska strömmar hör inte till någon process och kan inte sända virtuell adress för användarläget. Härifrån följer det att det i dessa situationer är omöjligt att hänvisa till användarregimens minne.

Det andra problemet är att vädja till det rörliga minnet. Det mesta av informationen i minnet är den flyttade och kan när som helst flyttas från fysiskt minne till en hårddisk i sidfilen. Om du hänvisar till den sida som är frånvarande i fysiskt minne, kommer processorn i en normal situation att generera ett avbrott i minneshanterarens minne, och som ett resultat kommer sidan att läsas från sidfilen och laddas in i fysiskt minne.

Det beskrivna beteendet bryts om att debuggerens programkod är tvungen att använda en hög avbrottsfråga (avbrytningsförfrågningsnivåer, IRQL). Med IRQL, som sammanfaller med eller överstiger IRQL-minneschefen, kommer damen inte att kunna ladda den saknade sidan, eftersom Operativsystemet kommer att blockera avbrytningssidans fel. Detta kommer att leda till operativsystemets kollaps.

Felsökning accepteras för interaktiv och nödsituation. Med interaktiv lokal debugging utförs debugger i samma system som debugobjektet. Med interaktiv fjärrfelsökning utförs debugger och felsökningsobjekt i olika system. Vid felsökning av kärnkoden måste systemet övervakas, från de första stegen i dess nedladdning, när nätverket ännu inte fungerar, därför används enkla seriella gränssnitt, som COM, FireWire, USB, för att kommunicera system. Nyligen, på grund av trenderna i utvecklingen av virtualisering av programvara på olika nivåer av abstraktioner, blir virtuella maskiner alltmer. GuestSide OS fungerar som en debugged, OS Placed innehåller debuggerens användargränssnitt.

Således behöver du inte installera ett felsökningsverktyg på testdatorn. Windows-operativsystemets distribution omfattar mekanismer för implementering av nödfelsökning. Innan starten kan operativsystemet spara information om sitt tillstånd som utvecklaren kan analysera och ta reda på orsaken. Denna information som är lagrad i en fil kallas en minnesdump.

Grundläggande kärnläge Felsökningsorgan tillhandahålls av tillverkaren av Windows-operativsystemet inom ramen för de fria felsökningsverktygen för Windows-paketet. Verktyg inkluderar grafiska och konsolanordningar av vindbg respektive kd (i det följande Windows-debugger). Arbetet med dessa debuggers är baserat på de mekanismer som tillhandahålls av operativsystemets utvecklare och läggs i kärnan.

Huvudläget för Windows Debugger är kommandotolkläget. På grund av den modulära strukturen, tillsammans med de medföljande utvecklarna, stöder Windows Debugger-kommandon från tredje parts moduler som heter Extensions. Faktum är att de flesta inbäddade kommandon är också inredda i form av tillägg.

Windows Debugger är inriktad på fjärrinteraktiv och akutfelsökning, när alla dess kapacitet används. Samtidigt stöds inte fullfjädrad lokal interaktiv debugging: Debugger kan du se några kärnstrukturer.

Det finns en förlängningsmodul för Windows Debugger som heter Logkd, skapad av Mark Russinianovich, som i någon mening implementerar lokal interaktiv debugging. LiveKd på språng skapar en dumpning av arbetssystemminnet och använder det för debugging.

Verktygen "Felsökningsverktyg för Windows" uppdateras regelbundet och stöder alla moderna Windows-operativsystem.

Softice Kernel Debugger, som produceras av Compuware i Driverstudio-mjukvarupaketet, utförde traditionellt ett alternativ till paketet "Felsökningsverktyg för Windows". Ett distinkt inslag i Softice var genomförandet av lokal interaktiv debugging på den stödda hårdvaran. Debugger kan nästan helt kontrollera operativsystemets funktion.

Från den 3 april 2006 avbröts försäljningen av Driverstudio-familjeprodukterna på grund av de "många tekniska och affärsproblemen, liksom den allmänna statusen för marknaden." Den sista versionen av operativsystemet, vars stöd implementerades är Windows XP Service Pack 2. Som regel ändrar serviceuppdateringar inte operativsystemets applikationsgränssnitt, men antalet systemsamtalsnummer och annan ookumenterad information kan genomgå a förändra. Softice debugger åberopade styvt föreskrivna adresser till interna datastrukturer. Som en konsekvens - med upprätthållandet av Service Pack var 3 kompatibilitet bruten. Självklart stöds inte mer senare versioner av Windows-operativsystemet.

Syser Kernel Debugger skapad av ett litet kinesiskt företag Sysersoft som ersättning av en Softice debugger. Den första slutliga versionen släpptes 2007. Liksom SOFTICE kan Syser Kernel Debugger utföra interaktiv debugging på operativsystemet. Stöds är bara 32-bitars utgåvor av moderna versioner av Windows.

För närvarande är Windows Debugger det viktigaste verktyget bland utvecklarna av kärnmodulerna. Det använder också Windows Operating System Core Development Team.

Debugger - den andra efter kompilatorn är det nödvändigt att skapa program. Men många av dem som skriver datorprogram och använder debugger, vet inte vad principerna och mekanismerna i sitt arbete.

Det är svårt att vara debugger ...

Mot bakgrund av det faktum att programmerare använder debugger middag och nosno, särskilt när de går in i det djupa debug-läget, är det värt att säga att om en debugger inte är ett program, men en bit av järn, skulle han säkert överhettas och bröt . Eftersom så mycket arbete, hur mycket det går bort av debugger, har inte ens kompilatorn.

Naturligtvis, sedan nu många av alla olika programmeringsspråk, då debuggarna för var och en av dem sina egna. Och naturligtvis, för olika kategorier av dessa språk, det finns skillnader i felsökarens arbete: till exempel kommer debugger av program på den tolkbara rubinen att fungera annorlunda än för Java-språket som sammanställts i byte-koden och debugger För Java kommer i sin tur att ha skillnader från debugger Visual C ++.

Jag kommer att prata om debugging för Windows-plattformen. Att realisera principerna för felsökarens arbete för henne, det kommer att vara möjligt att hantera debuggers under POSIX-systemet, och med debuggers som arbetar inte på operativsystemets nivå, men på den virtuella maskinens nivå eller någon tolk .

Debuggers för Windows: Två typer

Det finns två fundamentalt olika typer av debuggers under Windows. Jag tror att allt mötte allt när det är programmerat på Delphi (inte programmerat på det? Det är svårt att tro. Vad är du programmerad i skolan och i junior kurser?). Dessa är debuggers anpassade applikationer. De är en hel del, och de finns individuellt och (särskilt förresten, ofta) som en del av de integrerade applikationsutvecklingsmiljön. Bland defödarna fördelade som separata mjukvaruprodukter tilldelar traditionellt Ollydbg, och jag skrev en gång om det i "Computer Westi".

Den andra typen av debugggers är kärnansvariga för operativsystemet. De möts och används mindre ofta och av sin enhet skiljer sig avsevärt från debugger användarapplikationer. Den mest kända, och samtidigt är den bästa kärnfelsökaren SOFTICE. Kanske hörde du inte bara om honom, men även använd.

Eftersom arbetet med var och en av de två typerna av debuggers har sina egna detaljer, kommer jag att berätta om var och en av dem.

Debugger användarapplikationer

Debugger av anpassade applikationer är enklare eftersom det svarta och smutsiga arbetet tar på operativsystemet. Windows har speciella programgränssnitt som är utformade för att felsöka användarnivåprogrammen - de kallas Windows Debugging API. Det är debugging API som används av alla defuggers som är inbäddade i populära integrerade utvecklingsmiljöer för Windows.

För att felsökning startar måste debuggeren starta den debugged processen speciellt - så att systemet vet att denna process kommer att felsökas. Därefter börjar felsökningscykeln: Programmet utförs före uppkomsten av en viss händelse, som kallas - en debug-händelse eller debug-händelse. I det här fallet startas felsökningscykeln i en separat ström för att förhindra debuggerhängande.

Men det här är bara början. Eftersom den mest intressanta saken i felsökarens arbete börjar när felsökningsevenemanget hände. När allt är, vad är det felsökarens jobb? För att hjälpa programmeraren att lokalisera ett fel med en noggrannhet till en specifik funktion, en specifik operation, en specifik variabel. I det här hårda fallet kan debugger också hjälpa operativsystemet.

Så, felsökningsevenemanget hände, och då är det nödvändigt att på något sätt ta reda på hur det är relaterat till programmets text. Detta är endast möjligt om speciell felsökningsinformation är aktiverad i själva programmet - fliken för debugging-tecken. Den innehåller information om överensstämmelsen mellan adresser och funktioner i funktioner, datatyper, antal kodrader. Det är tack vare dem som är att debugging från vilken varje Windows-programmerare är bekant. Symbolbord har olika format, och därför är det inte alltid möjligt att felsöka ett program som sammanställts av en kompilator av en enda utvecklare med hjälp av en debugger från en annan tillverkare. Men det vanligaste formatet kan fortfarande anges - det här är PDB (programdatabas), och det är utformat, naturligtvis Microsoft Corporation.

Så, om felsökningsbordet med tecken har ett PDB-format, kan du använda ett specialverktyg från Microsoft Corporation - en symbolisk debuggingprocessor. En gång gick han in i kärnan i systemet och kallades imagehlp.dll, men länge sedan var markerad i ett separat bibliotek. Symbolprocessorn gör att du kan hitta på en viss adress till närmaste öppna funktion eller en global variabel, liksom numret på strängen och namnet på källtextfilen, där den här raden är belägen. Omvända operationer stöds, till exempel söker adressadressen med namnet.

Detta är naturligtvis inte allt arbete som debuggeren är engagerad i anpassade applikationer. När exempelvis felsökning av flera gängade applikationer visas många mycket subtila stunder som är förknippade med interaktionen av flöden. Även när de felsöker sådana relativt enkla saker, som tjänster, finns nyanser.

Men på nyanserna kommer vi inte att sluta i slutet - i slutet av artikeln, jag kommer att berätta var du ska läsa om dem. Låt oss nu titta på Kernel Debuggers.

Kärnbuggare

Core defuggers - Program är mycket mer komplicerade än debuggarna av användarapplikationer, och jag antar att det är helt klart varför: de har ingen hjälpare i form av ett operativsystem. I det här fallet är det deras klient, för det är henne, i slutändan, bör felsöka.

De flesta kärnbuggare kräver två datorer kopplade till sitt arbete, anslutet med nollmodemkabel. Nollmodem är ett sätt att ansluta två datorer direkt kabel genom sina COM- eller LTP-portar. Den andra datorn behövs, eftersom en del av debugger som sitter på den första (den där skuldsystemet är installerat), har begränsad tillgång till hårdvara, och därför är hela datautmatningen null till den andra datorn.

I moderna processorer i Intel X86-arkitekturen finns det speciella felsökningsregister (och i den gamla 368: e, och i nyare modeller av processorer av dem bara åtta, kallas de till DR0-DR7). Dessa register tillåter debuggeren att ställa in kontrollpunkterna för läsning och inspelning av minnet, såväl som på I / O-portarna. I allmänhet ser allt ut så här, och jag tror inte att det är värt att skriva i detalj, för vilket var och en av debuggregisterna är ansvariga, vilka avbrott genombryts av brytpunkten och ge annan liknande information. Det är bättre att berätta om de specifika befintliga bokbugarna på kärnan för Windows.

Nåväl, det här är en debugger som är inbyggd i operativsystemets kärna. Det är i allt OS NT Ruler, som börjar med Windows 2000. Det här är en del av filen ntoskrnl.exe, och du kan aktivera det genom att ställa in alternativet "/ deug" för operativsystemet i boot.ini. Denna debugger behöver en nollmodemanslutning och den andra datorn med samma operativsystem.

Det finns en annan kärna debugger från Microsoft - Windbg. Strängt taget är detta inte en kärna debugger, men en hybrid debugger som också kan användas för att felsöka applikationer av användarnivå. Han, till skillnad från debuggeren som är inbäddad i kärnan, har ett grafiskt skal, och därför är det lättare att använda den. Denna debugger stöder också speciella förlängningar som kan vara användbara vid lösning av vissa felsökningsuppgifter. Men det kräver också att två datorer kommer att felsöka kärnan.

Det finns dock en kärnfelsökare som kan felsökas på en enda dator. Detta är ett mjukmedel. Samtidigt kan SOFTICE felsöka och applikationsprogram. Att använda denna debugger för användarprogram är motiverad, till exempel, när det gäller debugging realtidssystem som är knutna till en systemtimer. Om du fixar debugging med en vanlig debugger kan resultatet vara felaktigt även om programmet är korrekt drift, och Softice stoppar programmet och timer. Detta är användbart vid felsökning av flera gängade applikationer. Till hela tiden har Softice mycket, mycket välutvecklade medel för att mata ut information om alla flöden i systemet, om synkroniseringen av strömmar för multi-gängade applikationer, information om handtag "ah ... den enda minus av denna debugger är dess komplexitet för applikationsprogrammeraren. Men från kärnfelsökarna är det här det enklaste och mest effektiva.

För de mest nyfiken

Nu är en konversation om debugger för Windows-applikationer inte lika relevant som tio år sedan. Hela världen blev intresserad av Internet, och de viktigaste användarna av Softice blev dal, outtröttliga arbetare på nivapiratkopiering. Ändå är det inte så dåligt. Kommunikation med Softice "om, utan tvekan, utvecklar en person när det gäller kunskap om datorn, men självklart, om du bara kommunicerar med debugger och inte kommunicerar med levande människor, är vissa biverkningar möjliga. Tja, om det, tror jag Alla gissar.

Debuggers är en av de mest märkliga typerna av programvara, men när det gäller utveckling är även användarnivå debugggers ganska komplexa. Men, ändå, om du har en önskan och tid för att utveckla din egen debugger, kommer din kunskap inom operativsystem och programmering att öka avsevärt, och därför kommer chanserna att högt betalt arbete öka.

Så, om du vill skapa din egen debugger, bör du först vara bekant med materialet på detta ämne. Enligt min mening kommer den bästa ersättningen för början att vara boken av John Robbins "debugging Windows-program". Hon är redan den gamla, 2001-upplagan, men den information som anges i den är relevant och nu, eftersom den har gemensamt, även på vissa sätt en grundläggande natur. I den här boken finns det exempel på att skriva debugger för Windows, dessutom är det användbart för dig om du programmerar på C ++ och vill bättre räkna ut behandlingen av undantag. Egentligen var det från den här boken som jag lärde mig om debugger som anges i artikeln. Om du hittar den här boken fungerar inte (trots allt är det redan ganska gammalt), det finns flera adresser som du kan komma till nytta. Det första är detta: www.xakep.ru/post/19158/default.asp. Denna artikel från tidningen "Hacker" berättar mer information om kärnans felsökare än jag gjorde, och dessutom innehåller den den enklaste debuggerens kod. Och på Kalashnikoff.ru/assembler/issues/016.htm kan du lära dig hur du skriver en DOS-debugger. Men det är förstås bäst att läsa MSDN och samtidigt hitta en del debugger med öppna källtexter för att hantera det. Nåväl, om du kom att skriva en debugger, då framgång till dig i den här tiden!

För att bestämma kärnan måste du ansluta till datorn med en nollmodemkabel eller modemanslutning. En felsökningsdator kommer att kallas "värd", och namnet "mål" kommer att få ett problem.

Båda datorerna ska fungera som kör samma version av Windows, och teckenfilerna för måldatorn måste installeras på värddatorn. Symboliska filer finns på Windows-installations-CD-skivan i support \\ Deug-katalogen.

För att aktivera debugging måste du göra ändringar i filen boot.ini på måldatorn.

1. Ändra boot.ini-filattributen:

attrib C: \\ boot.ini - r - s

2. Redigera den här filen och i Windows-startsträngen, lägg till / debug-parametern (för att kunna ladda ner det operativa minnet om Kernel Debugger när du startar Windows). Ytterligare parametrar är / debugport, som rapporterar systemet, som COM-porten måste användas (standard COM2) och / Baudrate - för att ange dataöverföringshastigheten (standardhastigheten 19200 Baud, men det är bättre att använda 9600). Till exempel:

MULTI (0) disk (0) rdisk (0) partition (0) \\ windows \u003d "Windows nt" / debug / deugport \u003d com2 / baudrate \u003d 9600

3. Spara filen.

4. Installera de föregående boot.ini-filattributen:

attrib C: \\ boot.ini + r + s

I det här exemplet möjliggjorde måldatorn anslutningen genom COM2-porten med en hastighet av 9600 bitar / s.

Värddatorn måste konfigureras med de parametrar som krävs för debugging. Dessutom måste symboliska filer installeras. För att installera dem, gå till katalogen \\ Support \\ Debug på installations-cd-skivan och ange följande kommando:

expndssym. : <целевой диск и каталог>

Till exempel:

expndSym F: D: \\ symboler

Installationen kan ta lite tid. Kom ihåg att om uppdateringspaket installerades på måldatorn, bör dessa paket teckenfiler också installeras på värddatorn. Symboliska filer för paket med uppdateringar kan laddas ner från Microsofts webbplats.

Nästa steg är att konfigurera de miljövariabler som krävs för felsökning, till exempel variabler som anger platsen för symboliska filer etc. Följande är en beskrivning av dessa variabler.

Beskrivning av systemiska variabler

Definitionen av dessa variabler kan placeras i kommandofilen för att undvika att ange motsvarande kommandon med varje nedladdning:

echo av
Ange _nt_debug_port \u003d com2
Ange _nt_debug_baud_rate \u003d 9600
Ange _nt_symbol_path \u003d D: \\ symboler \\ i386
SET _NT_LOG_FILE_OPEN \u003d D: \\ Debug \\ Logs \\ Debug.log

Nu måste du kopiera Core Debug-programvaran som ligger i support \\ Deug-katalogen \\<процессор> På installations-cd-skivan (support \\ debug \\ i386). Det enklaste sättet att kopiera hela katalogen är helt, eftersom den har en liten storlek (ca 2,5 MB). För I386-plattformen används debugger, som levereras som en fil i386kd.exe. Felsökaren börjar använda kommandot i386kd. För att komma in i kommandot, klicka på knappen Tangent Och vänta tills KD\u003e Command Line-inbjudan visas.