Laden...

Prozess schützen (Nur dokumentierte Apis, keine Hooks)

Erstellt von Floste vor 12 Jahren Letzter Beitrag vor 12 Jahren 4.696 Views
Floste Themenstarter:in
1.130 Beiträge seit 2007
vor 12 Jahren
Prozess schützen (Nur dokumentierte Apis, keine Hooks)

Beschreibung:

Schade, dass ich diese Methode erst heute entdeckt habe:
Der Windows-Kernel hat einen Objektmanager, welcher diverse Objekte und deren Handles verwaltet. Prozesse sind solche Objekte.
Ein Prozess hat standardmäßig ein Handle auf sich selbst, welches das Recht WRITE_DAC hat. Dieses kann man nutzen, um die Zugriffsrechte auf das Prozess-Objekt zu ändern. Man kann z.B. hinzufügen, dass für alle Nutzer bestimmte Rechte gesperrt werden. Wenn jetzt ein NEUES Handle mit diesen Rechten angefordert wird, dann wird der Zugriff gesperrt. (Vorher erstellte Handles sind aber afaik weiterhin gültig).

Jedenfalls lassen sich so die Funktionen TerminateProcess (welches der Taskmanager verwendet) und CreateRemoteThread (aka dll injection) und WriteProcessMemory und einiger anderer Kram blockieren.

Es funktioniert nur, wenn der Benutzer nicht zuviele (Admin-)Rechte hat.
Die Idee hat ansonsten noch 3 Schwächen:
1.) Es können Handles erstellt werden, bevor der Code ausgeführt wird. Dies lässt sich eventuell umgehen, indem man einen weiteren Prozess startet und diesen sofort schützt, noch bevor er die Ausführung beginnt.
2.) Mit dem Debug Privilege (welches Existiert, um als Admin Systemservice zu debuggen) lassen sich trotzdem Handles erstellen.
3.) Ich bin mir nicht ganz sicher, aber ich glaube, mit SetWindowsHookEx lässt es sich ebenfalls umgehen.

Die Idee ist nicht von mir, aber ich bin wohl der erste, der das in C# umsetzt.

Man könnte es noch erweitern, dass man auch die Threadobjekte schützt, das wird aber etwas komplizierter.

Projekte:Jade, HttpSaver
Zum Rechtschreiben gibts doch schon die Politiker. Aber die bauen auch nur mist!

U
400 Beiträge seit 2008
vor 12 Jahren

Finde ich aber gerade für unser Game-SDK recht vorteilhaft, da man für die Spiele z.b. Hacks und Cheats zumindest erschweren kann.

C
1.214 Beiträge seit 2006
vor 12 Jahren

Wenn du grad von Spielen spricht, find ich sowas ehrlich gesagt nicht schön. Bei Online Spielen ist Schutz vor Cheatern auf jeden Fall nötig. Den sollte man aber auch möglichst Server-seitig implementieren. Aber bei lokalen Spielen will ich selber entscheiden können, ob ich cheate oder nicht. Und wenn ich in einem verbuggten oder an einer Stelle langweiligen Spiel keine Cheats oder Trainer finde, dann leg ich das Spiel halt ganz weg. Und verbuggte Spiele sind ja jetzt nun mal nicht selten. Finds schon lästig, wenn man von vornherein keine Cheats oder Debugconsolen einbaut, und man deswegen einen Trainer braucht. Aber wenn selbst das nicht geht, dann hätt der Steller bei mir für immer verloren.

Hinweis von winSharp93 vor 12 Jahren

Bitte keine Grundsatzdiskussion über den Sinn und Unsinn von Cheatschutz in Spielen in .NET-Komponenten und C#-Snippets - falls noch Diskussionsbedarf besteht, bitte eine PM ans Team; dann können wir die Diskussion nach Smalltalk verschieben.