Standardkonform programmieren wg. Virenschutz

hustbaer schrieb:

Wenn aber das einzige was sie liefern können irgend ein unspezifisches Gelaber von "internationale Standards" ist (von denen ich noch nie gehört hätte!), dann sollen sie verdammtnochmal die Fresse halten.

Das sind so Dinge, auf die Antivirensoftware anspringt:

http://en.wikipedia.org/wiki/Self-modifying_code
http://en.wikipedia.org/wiki/Oligomorphic_code
http://en.wikipedia.org/wiki/Polymorphic_code
http://en.wikipedia.org/wiki/Metamorphic_code

Solche Sachen sollte man also vermeiden.

hustbaer

Au Danke Herr Haswell, das weiss ich selbst. Und wo ist jetzt der internationale Standard nach den man sich richten kann?
Und dabei ignorierst du immerzu eines, genau wie die superschlaue IT des OP: es handelt sich hier nicht um x86 Code, sondern was anderes (vermutlich ARM Code).

Was interessiert es einen x86 Virenscanner dann was da drinnen steht oder nicht drinnen steht?

Klar gibt es DEN Standard nicht, das ist alles ungeschriebenes Gewohnheitsrecht.

Und das mit ARM habe ich nicht ignoriert, sondern darauf hingewiesen, die Dateiendung nicht *.EXE zu nennen.

Außerdem gibt's auch Crossantivirensoftware, Androidsysteme sind ja inzwischen auch stark verbreitet, und wer seine E-mails auf seinem PC weiterleiten will, der will sein Android ja auch nicht verseuchen. Da bieten sich dann solche Antivirenkiller an.

SeppJ

Haswell schrieb:

Und das mit ARM habe ich nicht ignoriert, sondern darauf hingewiesen, die Dateiendung nicht *.EXE zu nennen.

Wenn das funktioniert, dann hätte ich da ein geniales Konzept, wie man Viren ganz leicht zu 100% vor Scannern schützen kann...

Xin

SeppJ schrieb:

Haswell schrieb:

Und das mit ARM habe ich nicht ignoriert, sondern darauf hingewiesen, die Dateiendung nicht *.EXE zu nennen.

Wenn das funktioniert, dann hätte ich da ein geniales Konzept, wie man Viren ganz leicht zu 100% vor Scannern schützen kann...

.COM schon... verrat's uns.

tntnet

Stürzt der Explorer ab, ist der Explorer Buggy. Stürzt der Virenscanner ab ist er Buggy. Stürzt das Betriebssystem ab, ist es Buggy. All das ist unabhängig davon, was so auf dem Rechner rum liegt. Gerade ein Anwender, der keine Admin-Rechte auf dem System hat, darf ein System nicht zum Absturz bringen können.

Wenn Du Deine Arbeit erledigen musst und nicht kannst, da Dir die notwendige Technik verwehrt wird, dann spreche mit Deinem Vorgesetzten, um das Problem aus der Welt zu schaffen. Und zwar ganz Sachlich und Zielorientiert und ohne auf die "blöden Admins" zu schimpfen.

tntnet schrieb:

Stürzt der Explorer ab, ist der Explorer Buggy.

Jein. Kann auch irgendeine Shell-Extension sein (die laufen im Kontext des Explorers), das würde ich mal überprüfen. Ein großes Problem ist auch, dass dieser ganze Antiviren-Dreck dermaßen in anderen Teilen des Betriebssystems rumpfuscht[*], dass ich einem damit verunstaltetem System eh nicht über den Weg trauen würde.

Trotzdem würde ich andere Ursachen nicht komplett ausschließen. Tritt das Problem auch auf, wenn du die Datei per Kommandozeile kopierst?

* und das teilweise auch noch ziemlich dilettantisch, nach dem Motto "hauptsache, es läuft jetzt". Bis ein zukünftiges Sicherheitsupdate mal eine interne Struktur verändert.

hustbaer

tntnet schrieb:

Stürzt der Explorer ab, ist der Explorer Buggy.

Der von Vista ist das auch. Der kommt schon mit instabilen Netzwerkverbindungen nicht klar. Wenn da ein Virenscanner dazwischenfunkt will ich gar nicht wissen was passiert. + Das was badgerbadgerbadger geschrieben hat (Shell-Extension).

Stürzt das Betriebssystem ab, ist es Buggy.

Ja, oder irgendwas was sich in mittels Hilfstreiber Ring 0 reingefressen hat. Wie vermutlich so ziemlich jeder Virenkiller.

Grundsätzlich sind wir uns aber einig: man sollte von einem Computer der "für einen" gewartet/konfiguriert/... wird auch erwarten können dass er funktioniert.

Bitte ein Bit

@dasdsfdggfhgjg:
Ich kenne da ein paar Probleme mit EMET. Wenn das Programm eine Bedingung XYT feststellt, terminiert EMET das Programm. Abstürze sind nicht selten.

Wenn der Explorer abstürzt, mache mal ein Crash Dump mittels ProcessExplorer und lade ihn in WinDbg.

Stürzt der Explorer ab, ist der Explorer Buggy. Stürzt der Virenscanner ab ist er Buggy. Stürzt das Betriebssystem ab, ist es Buggy.

Nö stimmt nicht.

Es hängt immer noch von den DLL's ab.

Application Verifier beispielsweise ist ein Programm zur Fehlersuche von anderen Programmen und überprüft bzw. simuliert gewisse Dinge. So ist es möglich für Programm XYZ eine Low Resource Simulation zu starten. Das Programm wird dann nur noch wenige Resourcen bekommen und so mancher new Aufruf dürfte schiefgehen, s.d. das entsprechende Programm abstürzt. Selbst Notepad++ stürzt regelmäßig ab, wenn man diese Notepad++ auf diese Weise debuggt.

Ist übrigens ein prima erster April Streich, da Application Verifier resistent arbeitet.

hustbaer

Was meinst du mit resistent?
Resistent gegen was?

tntnet

Bitte ein Bit schrieb:

@dasdsfdggfhgjg:
Ich kenne da ein paar Probleme mit EMET. Wenn das Programm eine Bedingung XYT feststellt, terminiert EMET das Programm. Abstürze sind nicht selten.

Wenn der Explorer abstürzt, mache mal ein Crash Dump mittels ProcessExplorer und lade ihn in WinDbg.

Stürzt der Explorer ab, ist der Explorer Buggy. Stürzt der Virenscanner ab ist er Buggy. Stürzt das Betriebssystem ab, ist es Buggy.

Nö stimmt nicht.

Es hängt immer noch von den DLL's ab.

Application Verifier beispielsweise ist ein Programm zur Fehlersuche von anderen Programmen und überprüft bzw. simuliert gewisse Dinge. So ist es möglich für Programm XYZ eine Low Resource Simulation zu starten. Das Programm wird dann nur noch wenige Resourcen bekommen und so mancher new Aufruf dürfte schiefgehen, s.d. das entsprechende Programm abstürzt. Selbst Notepad++ stürzt regelmäßig ab, wenn man diese Notepad++ auf diese Weise debuggt.

Stürzt ein Programm ab, da er keinen Speicher mehr hat, dann ist das Programm Buggy. Ein Programm, bei dem eine Speicheranforderung fehl schlägt, sollte dennoch nicht abstürzen, sondern höchstens sich sauber beenden.

DLL's sind Teil des Programms. Daher kann man nicht sagen, dass ein Programm zwar fehlerfrei ist, aber seine DLL's nicht.

Ein Plugin-Interface, wie der Explorer es anbietet ist natürlich so ein Sonderfall. Da ist es tatsächlich so, dass ein Plugin in der Regel im Speicherbereich des Programms läuft, aber die Entwickler des Programms keinen Einfluss darauf haben, was es eigentlich macht.

Wobei weiterhin die Behauptung steht, dass ein normaler Anwender keine Möglichkeit haben darf ein Betriebssystem zum Absturz zu bringen. Er darf ja normalerweise keine Kernelmodule oder so was laden. Dazu darf er keine Berechtigung haben. Daher kann der Admin es nicht auf den Entwickler abwälzen, wenn das Betriebssystem abstürzt.

Der Admin ist im vorliegenden Fall ja sowohl für die Lauffähigkeit des Betriebssystems als auch für den Virenscanner verantwortlich.

hustbaer

tntnet schrieb:

Stürzt ein Programm ab, da er keinen Speicher mehr hat, dann ist das Programm Buggy. Ein Programm, bei dem eine Speicheranforderung fehl schlägt, sollte dennoch nicht abstürzen, sondern höchstens sich sauber beenden.

"Buggy" ist relativ. Klar ist das strenggenommen ein Bug. Bzw. sind es Bugs, weil es meistens zig oder sogar hunderte Stellen sind wo Programme nicht mit fehlschlagenden Speicheranforderungen klarkommen.

Nur gibt starke Kräfte die dahingehend drücken dass man den Fall "out of memory" in den meisten Anwendungen und auch vielen Libraries/Frameworks einfach ignoriert (bzw. zumindest nicht vollständig korrekt behandelt):

Dank virtuellem Speicher kommt der Fall "out of memory" quasi nicht vor. Zumindest auf 64 Bit Systemen. Klar, es gibt bestimmte Anwendungstypen die extrem Speicherhungrig sind, aber sogar dort hat man dann eher das Problem dass alles extremst langsam wird, weil das OS zu pagen anfängt, als dass einem ein bad_alloc um die Ohren fliegt.
Bestimmte Dinge sind verflixt schwer komplett wasserdicht zu bekommen wenn man auch den Fall "out of memory" korrekt abdecken will. Bzw. genauer: die Fälle, weil es in jeder Anwendung zig bis hunderte oder sogar tausende Stellen gibt wo man da aufpassen müsste.
Dank virtuellem Speicher gibt es zumindest einen Fall den man anwendungsseitig sowieso nicht erschlagen kann, und das ist wenn das Commit einer neuen Stack-Seite fehlschlägt. Da die wenigsten Threads auch nur annähernd so viel Stack verwenden wie standardmässig reserviert wird, wird beim Anlegen des Stacks nämlich nur der Adressraum reserviert, aber noch kein "Commit" gemacht. D.h. das OS stellt nicht sicher dass das Programm den Speicher auch bekommen kann. Wenn nun der physikalische Speicher voll ist, das Pagefile voll ist und auch die Disk auf der das Pagefile liegt voll ist, dann kann das OS keinen neuen Speicher mehr besorgen.
Angenommen in deinem Programm das brav alle "out of memory" Fälle zu behandeln versucht schlägt nun eine Speicheranforderung fehl. Angenommen das Programm reagiert darauf mit dem Aufruf einer Logging-Funktion. Und angenommen diese ist so implementiert dass sie keinen Speicher anfordern muss. Alle nötigen nicht-Speicher Resourcen wie Files etc. sind schon offen, und der für Puffer/Variablen nötige Speicher wird vom Stack genommen. Und dabei wird eine Stack-Seite verwendet die bis jetzt nur "reserved" war, aber noch nie committed wurde. Dann hat das OS ein Problem das es nicht lösen kann: es hat dem Programm versprochen den Stack-Speicher im Falle des Falles zu besorgen, aber es kann nicht. Was macht das OS? Es bricht den Prozess einfach ab. Boom, you're dead.

tl;dr: Grundsätzlich hast du Recht. Die Realität sieht aber so aus, dass die wenigsten Programme mit "out of memory" umgehen können. Bei 32 Bit kann das lästig werden, weil man da auch mit realen Anwendungen relativ schnell an dem Punkt ist wo es wirklich passiert. Bei 64 Bit ist das Problem aber grösstenteils akademisch.

Bitte ein Bit

Was meinst du mit resistent?
Resistent gegen was?

Sorry. Ich meinte dass das Programm dauerhaft aktiv ist.

Wenn ich Einstellung vornehme, kann ich die GUI des Application Verifier schließen und er behält die Optionen. Vermutlich überleben die Einstellungen auch einen Neustart.

"Internationale Standards"... so ein Bullshit von Leuten die offenbar keinen Plan vom Programmieren haben. Es gibt tausend Gründe warum ein Virenscanner an einer Datei rummeckern kann.

Haswell schrieb:

Ich würde also, wenn möglich diese Codetricks vermeiden, auf die die Heuristicscanner der Antivirensoftware anspringen.
Insofern hat eure IT Abteilung da recht.

Was heisst "Codetricks"? Es sind teilweise banale Dinge auf die ein Virenscanner anspringt. Bei uns hat sich ein Virenscanner mal wegen dem String "hosts" in der EXE gemeldet. Und da soll mir mal irgendwer einen "Standard" oder auch "ungeschriebene Regel" zeigen, die empfiehlt sowas nicht zu tun. Letztendlich kann man solche Dinge teilweise nur per Zufall finden und beheben.

Bzgl der IT:
Ich würd in so einem Fall runter gehen (bei uns sitzen die im Keller) und die so richtig rund machen. Jawoll.