Systemprozess von nicht Systemprozess unterscheiden

[gandime]

Hallo,
ich schreibe gerade ein anti Botnetsoftware, welche einen Speziellen Bot killen soll und die exe löschen soll.
Das ganze funktioniert auch alles schon blos das doofe ist, das der Prozess smss.exe heisst. Wie unterscheide ich nun den System-Prozess und den anderen Prozess?
Gibt es eine Möglichkeit den Startpfad des Prozesses zu lokalisieren?

mfg
gandime

[Delphi-Laie]

Zitat:

Zitat von gandime

Gibt es eine Möglichkeit den Startpfad des Prozesses zu lokalisieren?

Ja! Mithilfe einer Modulenumeration (Schnapschuß bzw. Snapshot mit Übergabe der Prozeß-ID) lassen sich alle Module dieses Prozesse inkl. Pfad zur Datei über die Variable „szExePath“ aufspüren. Nach meiner Beobachtung ist immer die erste über den Modulschnappschuß erhaltene Datei (bzw. der erste erhaltene Eintrag) die Exe-Datei selbst, deshalb vermute ich, daß Windows so programmiert wurde, daß es immer so ist.

Die Funktionsweise kannst Du Dir auch über mein Programm „Prozesse“ (geeignetes Suchwort im Forum: „Prozeßbetrachter“) veranschaulichen; just heute lud ich eine neue Version hoch, die auch den exklusiven Zugriff auf die Kernelmodus- bzw. Ring-0-Prozesse ermöglicht.

Edit: Eine „saubere“ Unterscheidung zwischen System- und Nichtsystemprozeß sieht vermutlich allerdings anders aus. Einfache und Systemprozesse müßten sich in einer ganzen Reihe von Eigenschaften eindeutig voneinander unterscheiden.

[rollstuhlfahrer]

also mit dem First32Process o.ä. geht das mit dem Parameter szexepath leider nicht so einfach. Dieser gibt nur den absoluten Dateinamen an, ohne den Pfad zu der Exe.
An diesen kommt man über die Kommandozeile inkl. Parameter. Bsp.
Wodurch sich Systemprozesse noch von anderen Prozessen unterscheiden ist, dass der Firmenname auf "Microsoft Coporation" steht. Ich glaube auch, dass die Systemprozesse alle digital signiert sind und die meisten der frei rumlaufenden Viren/Trojaner/Bots nun eben mal nicht.

Also: Ein wirklich gutes Alleinstellungsmerkmal ist das Prüfen auf ein digitales Zertifikat und die Prüfung dieses Zertifikats. Wie man das allerdings anstellt, weiß ich nicht.

Bernhard

[Delphi-Laie]

Zitat:

Zitat von rollstuhlfahrer

also mit dem First32Process o.ä. geht das mit dem Parameter szexepath leider nicht so einfach. Dieser gibt nur den absoluten Dateinamen an, ohne den Pfad zu der Exe.

Warum gab ich wohl den Modulschnappschuß an? :gruebel:

Zitat:

Zitat von rollstuhlfahrer

An diesen kommt man über die Kommandozeile inkl. Parameter

Es geht doch hier um ein Programm und nicht um die (manuelle!) Bedienung einer Textkonsole!

Zitat:

Zitat von rollstuhlfahrer

Wodurch sich Systemprozesse noch von anderen Prozessen unterscheiden ist, dass der Firmenname auf "Microsoft Coporation" steht. Ich glaube auch, dass die Systemprozesse alle digital signiert sind und die meisten der frei rumlaufenden Viren/Trojaner/Bots nun eben mal nicht.

Also: Ein wirklich gutes Alleinstellungsmerkmal ist das Prüfen auf ein digitales Zertifikat und die Prüfung dieses Zertifikats. Wie man das allerdings anstellt, weiß ich nicht.

Ein wirklich gutes? Was ist mit den Diensten? Die müssen keinesfalls alle von Mikroweich stammen (kann man schließlich auch selbst programmieren), doch nach meinem Wissen laufen die regelmäßig im Kernelmodus! Müssenn die wirklich digital signiert sein?

Ein nach meiner Beobachtung eindeutiges Unterscheidungsmermal ist z.B., daß die Kernelmodusprozesse - im Gegensatz zu den Usermodusprozessen - den Modulschnappschuß nicht a priori erlauben, sondern erst nach explizter Privileganforderung. Allerdings weiß ich nicht, wie man Modulanzahl 0 (eigentlich gar nicht möglich, die Exe muß als 1 Modul eigentlich immer zurückgeliefert werden) von einem abgewiesenen Modulschnappschuß unterscheiden kann.

[himitsu]

Die andere Frage ist nur, warum wollen in letzter Zeit ständig alle selber ihr Viren/Würmer/Trojaner/Bots entfernen, anstatt auf die allgemein üblichen Entfernungstools der großen Firmen zurückzugreifen oder statt den einzig wirklich sicheren Weg zu nehmen?

[JamesTKirk]

Hi!

Zitat:

Zitat von Delphi-Laie

Zitat:

Zitat von rollstuhlfahrer

An diesen kommt man über die Kommandozeile inkl. Parameter

Es geht doch hier um ein Programm und nicht um die (manuelle!) Bedienung einer Textkonsole!

Er meint damit die Kommandozeile, die verwendet wurde, um das Programm zu starten. Diese wird für jeden Prozess von Windows mitgespeichert und kann z.B. auch im Taskmanager angezeigt werden (passende Spalte hinzufügen).

Zitat:

Zitat von Delphi-Laie

Zitat:

Zitat von rollstuhlfahrer

Wodurch sich Systemprozesse noch von anderen Prozessen unterscheiden ist, dass der Firmenname auf "Microsoft Coporation" steht. Ich glaube auch, dass die Systemprozesse alle digital signiert sind und die meisten der frei rumlaufenden Viren/Trojaner/Bots nun eben mal nicht.

Also: Ein wirklich gutes Alleinstellungsmerkmal ist das Prüfen auf ein digitales Zertifikat und die Prüfung dieses Zertifikats. Wie man das allerdings anstellt, weiß ich nicht.

Ein wirklich gutes? Was ist mit den Diensten? Die müssen keinesfalls alle von Mikroweich stammen (kann man schließlich auch selbst programmieren), doch nach meinem Wissen laufen die regelmäßig im Kernelmodus! Müssenn die wirklich digital signiert sein?

Ein weiteres mögliches Merkmal ist die SID des Prozessbesitzers. Systemprozesse laufen meist im Kontext des Benutzers "SYSTEM" (SID: "S-1-5-18" siehe hier). Dies mag zwar nicht auf alle Prozesse zutreffen, aber auf den hier erfragten smss.exe trifft dies zu.

Zitat:

Ein nach meiner Beobachtung eindeutiges Unterscheidungsmermal ist z.B., daß die Kernelmodusprozesse - im Gegensatz zu den Usermodusprozessen - den Modulschnappschuß nicht a priori erlauben, sondern erst nach explizter Privileganforderung. Allerdings weiß ich nicht, wie man Modulanzahl 0 (eigentlich gar nicht möglich, die Exe muß als 1 Modul eigentlich immer zurückgeliefert werden) von einem abgewiesenen Modulschnappschuß unterscheiden kann.

Moment. Es gibt nur einen Prozess, der im Kernelmodus läuft und das ist der, der durch den Code von ntoskrnl.exe und den Treibern gespeist wird (und das ist nichteinmal ein richtiger Prozess...). Die anderen Prozesse laufen ALLE im Usermodus. Die Systemprozesse laufen "nur" unter einem authorisierten Benutzerkonto (z.B. oben genanntes "SYSTEM"-Konto).

Gruß,
Sven

[Delphi-Laie]

Ich bitte um Nachsicht, daß ich diese etwas angestaubte Diskussion noch einmal aufgreife!

Zitat:

Zitat von JamesTKirk (Beitrag 1020201)

Ein weiteres mögliches Merkmal ist die SID des Prozessbesitzers. Systemprozesse laufen meist im Kontext des Benutzers "SYSTEM" (SID: "S-1-5-18" siehe hier). Dies mag zwar nicht auf alle Prozesse zutreffen, aber auf den hier erfragten smss.exe trifft dies zu.

Bei der Beschäftigung mit dieser Materie bin ich auf ein weiteres Unterscheidungsmerkmal "Systemprozesse<->Nichtsystemprozesse" gestoßen, und zwar aus der API-Funktion GetSecurityInfo, bei der man nach der SID auch - als nächsten Parameter - die Gruppe gewinnen kann. Unter meinem Windows 2000 (wird später auf anderen, späteren NTx-Betriebsprogrammen noch genauer untersucht werden) liefert der Parameter "ppsidGroup" (wie gesagt, nach dem vorigen Parameter "ppsidOwner) bei den "Systemprozessen" den - noch zu transformierenden - String "SYSTEM" zurück, bei allen anderen auf meinem Windows 2000 "kein".

Also, wenn das (k)ein Zufall ist! ;-)

[Assarbad]

Zitat:

Zitat von gandime (Beitrag 1020175)

Das ganze funktioniert auch alles schon blos das doofe ist, das der Prozess smss.exe heisst.

:shock:

SMSS == Session Manager Subsystem

Das ist eines der Kernsubsysteme von Windows und wird aus dem Kernel heraus gestartet. Wird dieser Prozess beendet, gibt es einen Bluescreen. Würdest du csrss.exe (Client Server Subsystem) beenden, würde im besten Fall ein Bluescreen kommen und im schlimmsten Fall würden Win32-Prozesse sich merkwürdig verhalten, weil csrss.exe das Win32-Subsystem implementiert. Ja, Win32 ist eigentlich auf der NT-Plattform nur ein Subsystem, wenn auch mehr oder weniger das zentrale ...

Selbstverständlich kann sich auch ein bösartiger Prozess mit diesen Namen tarnen, aber dann könnte man wiederum Signaturen überprüfen (siehe Bernhards Vorschlag). Dennoch, bei diesem Mangel an Grundkenntnissen mag dein Ziel durchaus ehrenwert sein, aber bitte lasse es lieber sein. Du kannst damit Leute und deren Daten in die Bredouille bringen.

Zitat:

Zitat von Delphi-Laie (Beitrag 1020190)

Ein wirklich gutes? Was ist mit den Diensten? Die müssen keinesfalls alle von Mikroweich stammen (kann man schließlich auch selbst programmieren), doch nach meinem Wissen laufen die regelmäßig im Kernelmodus!

:shock:

Wie Sven schon schrieb, im KM laufen nur der Kernel und Treiber, wobei die Threads in den "normalen" Prozessen natürlich ab und an einen Ausflug in den KM machen um bspw. Dateien zu lesen, Ereignisse zu erstellen uns so weiter und so weiter. Treiber sind im Übrigen eher mit DLLs vergleichbar als mit Programmen, wenn man denn schon einen Vergleich benötigt um es sich zu verbildlichen ...