Zitat von cosinus

Also ich versuch jetzt mal zu raten was gemeint ist: on-access / on-demand
Und falls ja: ja es ist ein Unterschied, ob der Wächter im Hintergrund anschlägt oder der manuelle (on-demand-) Scan. War zumindest vor ein paar Jahren noch ein riesiger Unterschied.

Ich weiß auch nicht wie oft das schon erwähnt wurde: kein Virenscanner arbeitet 100%ig zuverlässig. Woher kommt also immer diese Erwartungshaltung, dass ein AV perfekt sei und wenn es eben doch zu solchen komischen Ergebnissen kommt, man an alles mögliche denkt nur nicht, dass das AV eben komische Ergebnisse liefert?

Ja, das war gemeint. Ich dachte, dass On-Access und On-Demand die gleiche Kontrolle durchführen und das deswegen beide das gleiche Ergebnis haben sollten.

Ich weiss, dass ein Scanner auch falsche Ergebnisse liefern kann. Die Google Recherche zu dem Fund bei diesem Spiel sieht so aus als ist das ein false positive.

Zitat von Gleitlager

Ja, das war gemeint. Ich dachte, dass On-Access und On-Demand die gleiche Kontrolle durchführen und das deswegen beide das gleiche Ergebnis haben sollten.

Kommt ganz drauf an, aber gerade beim OAS ist Performance viel wichtiger. Microsoft macht im Rahmen von MVI auch seit einigen Jahren Vorgaben diesbezüglich. Je nachdem welche "Stufe" man erreicht, darf sich eine Firma dann an den von Microsoft gesammelten Telemetriedaten in unterschiedlichem Maße laben.

Beispielsweise gibt es überhaupt keine Gründe warum ein OAS jemals in Archiven buddeln sollte. Aber es ist sicher schon aufgefallen, dass sie es dennoch tun. Der Grund dafür ist, dass sich bei AV-Test eingebürgert hat Exemplare wie EICAR oder die AMTSO Security Features Check Tools auch in ZIP-Dateien usw. zu verpacken. Sinnvoll ist dies nicht. Malware kann nicht direkt aus einer ZIP-Datei ausgeführt werden, sondern landet immer zuvor auf der Platte, wo der OAS sie sieht. Selbst wenn man sich nun vorstellen würde, es würden Dateisystemtreiber für ZIP-Dateien entwickeln um den Inhalt als Volume ("Laufwerk") einzuhängen, sähe der OAS dann ein neues Laufwerk an welches er sich hängen kann (siehe Instanzen in fltmc).

Weiterhin laufen die meisten OAS als Dateisystemfiltertreiber im Kernelmode (KM). Manchmal ist die eigentliche Engine dann noch ein separater Treiber von dem Dateisystemfiltertreiber. Im KM gibt es eine Menge Einschränkungen. Um ein Beispiel zu geben: öffnest du in Excel ein Spreadsheet, läuft jede I/O-Anforderung (IRP) durch den Treiberstack. Sofern sie bei einem AV-Filter ankommt, kann dieser dann entscheiden den IRP weiterzuleiten oder ein Urteil (bspw. STATUS_ACCESS_DENIED) zu fällen und zurückzugeben. Dabei läuft der Code jedes Filtertreibers im Treiberstack in einem Thread von deinem Excel-Prozess. Will oder muss der Treiber nun beim Scan Fließkommaoperationen durchführen (bspw. beim Scan von PDFs und ähnlich komplexen Formaten), muss er auch explizit den Fließkommazustand bei Ankunft der Anfrage sichern und vor der Rückkehr wiederherstellen. Denn ansonsten "versaut" der Treiber dem Usermode-Teil des Prozesses den Fließkommazustand. Bei Excel kann man sich gut vorstellen wozu das führt. Des weiteren gibt es Beschränkungen bzgl. der Menge verfügbaren Speichers. Nicht alle Aktionen kann man überhaupt auf jedem IRQL durchführen usw. usf.

Kurzum: es gibt mehr Gründe warum es sich unterscheiden sollte, als es Gründe gibt OAS und ODS mit exakt gleichen Parametern laufenzulassen 😉

Ohhh, ich verstehe zwar nicht alles davon. Das mit AV-Test ist interessant, aber gut ein besseres Ergebnis dabei st ja auch ein Verkaufargument.

Ich hätte halt gedacht, dass die Scans anders ausgelöst werden, aber das gleiche passiert sobald die Scans ausgelöst sind.