Hey oda.krell,


Wenn Fragen auftauchen, dann bitte diese auch als Fragen an mich stellen. Damit kann ich viel besser umgehen.
Dein Einwand ist jedoch berechtigt, deshalb antworte ich einfach mal, als ob du gefragt hättest: "WTF ist das Halteproblem? Und wieso ist das problematisch für einen AV-Guard?". Hoffentlich treffe ich damit den Sinn deines Beitrags.

Halteproblem
Das Halteproblem ist die Tatsache, dass es keine formulierbare Abfolge von Arbeitsschritten (Fachchinesisch: "Algorithmus") gibt, damit ein Programm entscheiden könnte, ob ein beobachtetes Programm in einer Endlosschleife steckt oder irgendwann in der (fernen) Zukunft von selbst anhält.

Also z.B. du hast ein Programm laufen, welches sich nach dem Start nicht auf der GUI zeigte und dennoch als Prozess im Taskmanager steht. Die Frage ist jetzt: Ist das vernünftig gestartet? Vermutlich nicht. Also wie lange muss ich warten, bis es sich von selbst beendet? Vielleicht eine Sekunde? Hmm, nein es läuft noch. Muss ich vielleicht fünf Minuten warten? Eine Stunde? Ein Jahr? Ab wann kann ich von außen erkennen, dass es gerade in einer Endlosschleife festhängt?

Für diese Problemsituation gibt es keine durch einen Algorithmus formulierbare Lösung. Es gibt also kein Programm, welches andere Programme überwachen und dann automatisch neustarten könnte, sobald diese in einer Endlosschleife hängen würden.

Anmerkung: Dieses Problem wird auf Kernelebene elegant umschifft, indem Programme (welche sich aufhängen könnten) sich mit speziellen Werten in bestimmten zeitlichen Intervallen zurückmelden. Hängt sich dann das überwachte Programm auf, dann verstummen die Rückmeldungen und der Kernel startet einfach aufs geradewohl neu (Fachchinesisch: "Watchdog"). Das geht meistens gut. Manchmal geht das schief. Die Ursachen dafür führen zuweit von dem hier besprochenen Thema weg.

Falls das Halteproblem bis hierhin noch nicht verstanden wurde, dann bitte ich um Nachfragen. Schließlich kann ich nicht in deinen Kopf schauen und feststellen, dass da noch Erklärungen benötigt werden.

AV-Guards haben es schwer
Virenscanner brüsten sich mit zwei grundlegenden Konzepten der Heuristikerkennung.
Erstens: "Wir lassen das in einer emulierten Umgebung (leider wird auch das landläufig als "Sandbox" bezeichnet!) laufen und schauen mal, was für Aufrufe das Programm versucht. Sind die kritisch, dann vermuten wir, dass es sich um eine Schadsoftware handeln könnte." (dynamische Analyse)
Zweitens: "Wir schauen in das Programm selbst und versuchen dessen Funktionen zu erraten." (statische Analyse)

Punkt zwei funktioniert nicht zuverlässig, weil das Durchsuchen von Code ebenfalls Speicherplatz und Prozessorzeit kostet. Für den Virenprogrammierer ist die Option dann einfach in den Op- oder Bytecode ein bisschen Füllwerk reinzuschreiben, welches nur (scheinbar) endlos Variablen von A nach B (oder nach C oder nach D...) schaufelt und den Schadcode erst dann aufrufen würde, wenn das passende Ergebnis rauskommt. Für den Parser bleibt der problematische Teil "inaktiv" und deshalb wird dieser nicht untersucht. Ganz zu schweigen davon, dass Codeobfuscating eine sehr effektive Disziplin der Codegestaltung ist und deshalb die statische Analyse wenig Chancen hat, "guten" Code von "bösen" Code zu unterscheiden.
Als weitere Option kann auch der eigentliche Aufruf in den Schadcode als (zur Laufzeit zu erzeugendes) Ergebnis einer Funktion festgelegt werden. Das sollte auch den fortschrittlichsten Parser abbrechen lassen.
D.h. wir haben hier das Halteproblem, weil nicht erkannt werden kann, dass es sich nur um eine Köderfunktion handelt, welche vom (inaktiven) Schadcode ablenken soll.
Eine Zyklenerkennung funktioniert auch nur unter der Voraussetzung dass genügend gescannte Codeteile sich nicht verändern (sog. "Invarianten", darauf fussen auch sogenannte "partielle Korrektheitsbeweise" (PCA)). Aber so eine sich selbst erhaltende dynamische "Endlos"-schleife frisst Ressourcen und Zeit (ohne dass etwas Schlimmes passiert), weshalb der Parser dann irgendwann abbrechen muss.
Sollte er das nicht tun, ist die Situation schlechter: Ein geschickt zusammengebautes Programm würde dann zu einer endlosen Wartezeit führen, in welcher der Parser nicht mehr genügend Ressourcen für andere Programme zur Untersuchung hat (die Warteliste wächst unaufhörlich) oder der Benutzer einfach genervt ist, weil nach zwei Stunden ein Programm immernoch nicht starten kann (es wurde "noch" nicht vom AV-Guard freigegeben, aber das wird bestimmt gleich erledigt sein...).

Der erste Punkt ist jetzt hoffentlich leichter zu verdauen. Der Virenhersteller muss nur eine Warteschleife vor dem Schadcode einbauen, welche den Schadcode erst nach sagen wir mal ca. 15 Minuten startet. Das kann auch durch ein Ereignis stattfinden, welches auf jeden Fall eintreten wird. Es kann sich dabei auch einfach nur um die "Aktivierung am Freitag, den 13." handeln (und nur dann!). Aber hierbei könnte man der statischen Analyse vielleicht auf den Leim gehen, wenn das nicht geschickt genug verschleiert wird.
Besser ist z.B. die Ackermann-Funktion vorneweg zu implementieren. Dafür gute Werte zu wählen und den Algorithmus durch Füllwerte und Tricksereien zu verschleiern. Auch hier laufen wir in das Halteproblem: Wieviel Zeit können wir das zu untersuchende Programm in der emulierten Umgebung testen, bis wir sicher sein können, dass es keine Schadsoftware ist? Wieviel Wartezeit können wir dem Anwender zumuten?

Manche AV-Guards öffnen darüberhinaus noch ein weiteres Tor: Beim Aufruf eines Programms wird nur dieses untersucht. Wird dasselbe Programm dann außerhalb des AV-Guards aufgerufen, so kann dieses Programm weitere Funktionen in einer Bibliothek nachladen, ohne dass diese Funktionen nochmal durch den AV-Guard wandern. Eine simple Abfrage "Sobald der Starter keine emulierte Umgebung erkennt, soll die Schadsoftware nachgeladen werden. Andernfalls spiele mit zwanzig Variablen Bäumchen-wechsle-Dich." ist heute nur eine Frage des zeitlichen Aufwands.

Keine guten Aussichten. Was wir mit der Heuristik im Allgemeinen erkennen können, ist nämlich nur die Schadsoftware, die in einem der nächsten Signaturupdates ohnehin aufgelistet worden wäre.

Gruss
Bill