Till skillnad från vad många tror, ​​finns det faktiskt flera sätt att göra detta. Vissa av dem är vanliga, andra ses sällan. Några av dem är svaga, andra starka. Allt beror på hur du gör det.

Låt oss gå igenom en samling av dem:

1. Pre-NT RegisterServiceProcess trick
Windows 9x och andra pre-NT-operativsystem hade ett odokumenterat API i kernel32.dll som heter RegisterServiceProcess (som namnet antyder) registrerar processen som en systemtjänst. När en process hade kallat den här funktionen ansåg operativsystemet att den var kritisk och tillät inte uppgiftshanteraren att döda den. Den här funktionen togs bort när NT kom, så den fungerar inte på XP eller högre.

2. Processnamnstrick
Tillbaka i WinXP innehöll Aktivitetshanteraren en hårdkodad lista med processnamn som den skulle vägra att döda i stället att visa ett meddelande som det du nämnde. Dessa täckte i princip kritiska systemtjänster som smss.exe och rpcss.exe . Problemet var att sökvägen inte är kontrollerad, så alla andra körbara filer med samma namn skulle resultera i en process som inte kan dödas. Det här tricket förhindrar inte att processen dödas i sig utan hindrar snarare Windows XP Aktivitetshanteraren från att kunna döda processen. Det är fortfarande möjligt att använda ett annat verktyg för att döda processen.

3. Håll livsprocesser
Dessa är överlägset de vanligaste. Två processer skapas och kontrolleras upprepade gånger för den andras existens. Om en dödas, återupplivar den andra den. Detta hindrar dig inte från att verkligen döda processen, men det gör det irriterande att stoppa processen från att komma tillbaka.

Aktivitetshanteraren innehåller ett alternativ för att döda processträdet, vilket gör att du kan döda en process och alla underordnade processer, vilket kan hjälpa till att lösa problemet. När en process skapas i Windows håller OS reda på det process-ID som skapade det. Döda processträdet går igenom alla processer och letar efter dem som har ett förälders-ID som är lika med det process-ID som du dödar. Eftersom livsprocesser vanligtvis fungerar med en upprepad avfrågning kan du döda båda processerna innan de märker att något gick fel.

Ett försvar mot detta är att skapa en dummyprocess som skapar livsprocessen, sedan har den där dummeprocessen avslutad. Huvudprocessen skickar sitt ID till dummyprocessen och dummyprocessen skickar sitt ID till keep-alive-processen, men kedjan bryts när dummyprocessen avslutas. Detta gör att både de primära processerna och processerna som håller vid liv går, men gör det omöjligt att använda Aktivitetshanterarens dödprocessträdfunktion. Istället måste du skriva ett skript för att döda dem, eller använda ett verktyg som låter dig döda flera processer samtidigt.

4. Användarläge krokar via laddade DLL-filer
Det är möjligt att injicera en DLL i en pågående process. I själva verket erbjuder Windows en funktion för att ladda alla DLL-filer i alla processer som importerar user32.dll, i syfte att utöka. Denna metod kallas AppInit-DLL-filer. När en DLL har injicerats kan den manipulera processens minne. Det är då möjligt att skriva över värdena för vissa funktionspekare så att samtalet omdirigeras till en stubrutin, som sedan anropar målfunktionen. Denna stubrutin kan användas för att filtrera eller manipulera parametrarna och returvärdena för ett funktionsanrop. Denna teknik kallas hooking , och den kan vara mycket kraftfull. I det här fallet skulle det vara möjligt att injicera en DLL i körningsprocesser som kopplar OpenProcess och TermineraProcess för att säkerställa att ingen applikation kan ta hand om din process eller avsluta den . Detta resulterar något i ett vapenlopp, eftersom alternativa användarläge-API: er kan användas för att avsluta processer, och det är svårt att koppla ihop och blockera dem alla, särskilt när vi betraktar odokumenterade API: er.

5 . Användarläge krokar via injicerade trådar
Detta trick fungerar på samma sätt som med DLL-filer, förutom att ingen DLL-fil behövs. Ett handtag till målprocessen skapas, en del minne tilldelas inom den via VirtualAllocEx , kod och data kopieras till minnesblocket via WriteProcessMemory och en tråd skapas i processen via CreateRemoteThread . Detta resulterar i att någon utländsk kod körs inom en målprocess, som sedan kan starta olika krokar för att förhindra att en process dödas.

6. Kärnlägessamtalskrokar
I kärnan finns en speciell struktur som kallas System Service Dispatch Table (SSDT), som kartlägger funktions-ID: n från användarlägessamtal till funktionspekare till kärn-API: er. Den här tabellen används för att växla mellan användarläge och kärnläge. Om en skadlig drivrutin kan laddas kan den ändra SSDT så att dess egen funktion körs istället för rätt API. Detta är en krokläge-krok som utgör en rootkit. I huvudsak är det möjligt att dra ullen över operativsystemets ögon genom att returnera falska data från samtal. I själva verket är det möjligt att göra processen inte bara odödbar utan också osynlig. En fråga med detta på x64-byggnader är att SSDT är skyddad av Kernel Patch Protection (KPP). Det är möjligt att inaktivera KPP, men detta har långtgående konsekvenser som kan göra det svårt att utveckla ett rootkit.

7. Direkt manipulering av kärnobjekt (DKOM)
Detta trick innebär också att en skadlig drivrutin laddas i operativsystemet, men det krävs ingen ändring av SSDT. Processer i systemet lagras som EPROCESS strukturer i kärnan. Tänk på att den här strukturen är helt versionberoende och endast delvis dokumenterad av Microsoft, så omvänd teknik krävs över flera målversioner för att se till att koden inte försöker läsa fel pekare eller data. Men om du lyckas hitta och räkna upp genom EPROCESS -strukturer i kärnan är det möjligt att manipulera dem.

Varje post i processlistan har en FLink och BLink -pekare som pekar på nästa och föregående processer i listan. Om du identifierar din målprocess och gör dess FLink och BLink pekare tillbaka till sig själva, och FLink och BLink av sina syskon pekar på varandra, OS hoppar helt enkelt över din process när du gör några hushållsoperationer, t.ex. dödande processer. Detta trick kallas avlänkning. Inte bara gör detta processen osynlig för användaren, men det förhindrar också att alla användarläge-API: er kan rikta in sig på processen såvida inte ett handtag till processen genererades innan den avlänkades. Detta är en mycket kraftfull rootkit-teknik, särskilt för att det är svårt att återhämta sig från.

8. Debugger tricks
Detta är ett ganska coolt trick som jag ännu inte har sett i naturen, men det fungerar ganska bra. Windows-felsöknings-API: n tillåter alla processer att felsöka en annan, så länge den har behörighet att göra det. Om du använder felsöknings-API: et är det möjligt att placera en process i ett "felsökt" tillstånd. Om den här processen innehåller en tråd som för närvarande stoppas av en felsökare kan processen inte dödas av Windows, eftersom korrekt trådkontroll inte kan garanteras under avslutning när tråden blockeras. Naturligtvis, om du dödar felsökaren slutar processen att felsökas och antingen stängs eller kraschar. Det är emellertid ibland möjligt att producera en situation där det finns en processkedja som felsöker varandra i en slinga. Om varje process stoppar en dummytråd i nästa, kan ingen dödas. Observera att det är möjligt för en kraftanvändare att manuellt döda andra trådar i processen, vilket gör den oanvändbar, men den kommer fortfarande inte att dödas.

9. Windows 8 DRM
Det här är en ny som jag bara hört talas om nyligen, men jag vet inte mycket om det. Det gick lite rykt på Twitter om det, och jag har sett utdrag här och där på olika tekniska webbplatser, men jag har ännu inte sett någon konkret forskning. Jag tror att det fortfarande är tidiga dagar. I grund och botten är historien att Windows 8 har en mekanism som gör det möjligt för "betrodda leverantörer" att registrera processer som DRM-kritiska, vilket förhindrar att de dödas eller manipuleras av användaren. Vissa människor har spekulerat i att mekanismen för kontroll av betrodda leverantörer är svag och kan vara öppen för attacker. < - Ser ut som att den här var falsk. Så mycket för ryktfabriken!

Uppdatering: Harry Johnston påpekade i kommentarerna att Windows 8.1 introducerar skyddade tjänster, som är utformade för att användas av AV och DRM för att skydda mot att manipuleras eller attackeras av lägre privilegierad kod i systemet.

10. Verktygshantering
Den här har förmodligen använts mycket i naturen, men jag har aldrig sett det gjort ordentligt. I huvudsak handlar detta trick om att rikta in sig på specifika verktyg, t.ex. Aktivitetshanteraren, genom att redigera körbarheten på disken på ett sätt som ändrar funktionaliteten. Det här liknar mycket de användarläge-krok-trick som jag nämnde tidigare, men i det här fallet kvarstår de på hårddisken och har större konsekvenser än enkel API-anslutning. Naturligtvis är en fråga att Windows File Protection (WFP) förhindrar ändring av vissa kritiska systemfiler, inklusive aktivitetshanteraren. Underhållande är det dock möjligt att ändra standardaktivitetshanterarens sökväg via registret. Så istället för att röra med den exekverbara filfilen för uppgiftshanteraren, dumpa bara din egen version någonstans och få operativsystemet att använda den.

Sammantaget finns det många sätt att uppnå detta med varierande grad av robusthet. Ovanstående representerar en majoritet av dem, men är inte uttömmande. Faktum är att många av de knep som jag beskrev kan uppnås på olika sätt med olika mekanismer eller API för att uppnå samma mål.

Jag tror inte att det du försöker göra är möjligt. Du måste undergräva operativsystemet för att förhindra att en process kan dödas. Alla processer körs inom operativsystemet, därför kan operativsystemet döda vilken process som helst. Du kan till och med döda processer som "explorer.exe", vilket är det som kör startmenyn och skrivbordet.

De flesta program som verkar vara "okillbara" är faktiskt dödbara, men ett annat program övervakar deras körning och när den ser processen stängas, den startas automatiskt omedelbart. När du dödar processA startar processB och när du dödar processB startar processA. Eftersom du inte enkelt kan döda båda processerna exakt tillsammans blir det väldigt svårt att bli av med dem medan systemet är igång.

Samma teknik används av flera antivirusleverantörer såväl som de populära anti-fuskprogram PunkBuster.

Det är också möjligt på äldre system att processen kan köras som en tjänst. I Windows XP och Windows 2000 kan Aktivitetshanteraren inte döda processer som startades av servicechefen eftersom servicechefen körs under en annan användarkontext. På dessa äldre system skulle skapande av en Windows-tjänst vara motståndskraftig mot direkt dödande med Aktivitetshanteraren, men nyare versioner av Windows tillåter att den dödas.

Det kan vara användbart att se vilket sammanhang processen körs under om tillstånd nekas. Du kan använda ett verktyg som Process Explorer från SysInternal's svit för att se vilken användarkontext processen körs under. Om användarkontexten som Aktivitetshanteraren körs under inte har tillgång till dödprocesser som körs under det användarkontext som processen körs under kommer misslyckandet att misslyckas.

Relaterad information finns tillgänglig för superanvändare under denna fråga https://superuser.com/questions/109010/kill-a-process-which-gives-access-denied. Det verkar som om det finns en säkerhetsinställning per process som kan användas för att ta bort rätten att döda. Detta kan göras programmatiskt och skulle komplicera att döda det, men en administratör kan fortfarande ta äganderätten till processen och sedan justera behörigheterna för att tillåta att den dödas. De särskilda Windows-API: erna är CreateProcessWithTokenW och SetSecurityInfo.

Som nämnts av AJ är operativsystemet i slutändan ansvarigt. Den bestämmer om en process kan dödas, när den blir dödad, hur osv. Vissa processer kan "skyddas" av operativsystemet, vilket förhindrar att de avslutas, eller som också är fallet kan processen vara tekniskt dödbar, men dödar processen utlöser en avstängning av hela maskinen.

Om du skrev skadlig programvara och ville göra det omöjligt att döda en process, är det bästa alternativet att ändra operativsystemet för att förhindra det . Det är inte uteslutet och det är faktiskt något som författare redan har tänkt på. Att göra OS-modifieringar för att skydda resurser är faktiskt en så vanlig tråd att de har ett namn för det: " rootkit".

Så hur ändrar du det körande operativsystemet? Lyckligtvis är moderna operativsystem alla skrivna så att du kan göra sådana ändringar; skriv bara en kärnmodul (aka "driver"). Det finns till och med ett utvecklingspaket för att komma igång.

När du är där, kopplar du bara in kodvägen som hanterar processkontroll och lägger in din lilla uteslutningsregel. Läs mer om rootkits.

Att skapa en verkligt omöjlig process är ingen bra idé. Det är dock helt möjligt att skydda en process från att avslutas av någon annan användare än en administratör. Administratörer har och borde ha full tillgång till processen och de kan döda processen.

Sättet att göra är att ändra processen ACL för att OS ska vägra alla försök att döda processen av icke-administratörer.

I din startkod för processen bör du hämta processen DACL, lägga till en begränsning till den så att "Alla" får en "Åtkomst nekad" när du försöker döda processen och sedan skriva tillbaka processen DACL.

Jag kan ge dig .NET-källkod om hur du gör det, om du är intresserad.

En sak som har förbisetts här är begreppet (ab) att använda virtualisering för att implementera en hypervisor ovanför windows som innehåller din kod.

Eftersom din kod sedan körs utanför och ovanför windows är det inte lätt att upptäcka , och kan inte avslutas med windows.

" Blue Pill" var ett bevis på konceptet för ett sådant koncept, men efter en viss initial krångel nämns en sådan implementering mycket sällan och personligen Jag har ännu inte sett något sådant i naturen.