Standardkonform programmieren wg. Virenschutz

knivil

Also wenn mir jemand mit haltlosen Anschuldigungen entgegentritt, dann wuerde ich ihn auch wegschicken/abwimmeln. Keine Ahnung, was ihr gegen die IT-Abeitlung habt.

Und wenn ich sowas lese:

Euer Produkt (das Executable) enthält offensichtlich eine Signatur, die vom Virenkiller erkannt wird ...

Ja alles sehr offensichtlich ...

na was weiß denn ich, die IT behauptet halt dass es das sein kann

Behauptet es koennte sein ... alles sehr offensichtlich.

Dabei ist es egal, was es wirklich ist. Auf Grundlage der gegebenen Information ist alles moeglich. Also was soll der Scheiss?

hustbaer

Und vor allem...

Ich würde in so einem Fall die IT bei meinem AL/Chef anschwärzen, und zwar gröber. Also nach dem Motto "unsere PCs funktionieren nicht richtig, die IT weigert sich etwas zu unternehmen und sabotiert damit unsere Arbeit".

Natürlich würde ich erstmal probieren es selbst mit denen zu regeln, aber wenn die auf stur schalten und mit so völlig behämmerten Aussagen daherkommen... tjoah.

Ihr macht das ja nicht zum Spass, also was soll der ganze Bockmist?

Wenn die IT behauptet dass da ne böse Signatur in euren Files ist, dann sollen sie euch sagen was für ne Signatur und wie ihr dafür sorgen könnt dass die nicht mehr erkannt wird.
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.

Und am Ende des Tages bleibt: ihr müsst Files kopieren und es funktioniert nicht. Die IT ist zuständig dass eure PCs funktionieren, und dazu gehört nunmal auch dass man Files kopieren kann. => Die IT soll nicht rumspinnen sondern zusehen dass ihr mit euren PCs arbeiten könnt.

dasdsfdggfhgjg schrieb:

Hallo!

Wir entwickeln Software für embedded systems, welche NICHT auf x86 aufbauen.

Nun stürzen unsere Entwicklungs PCs recht oft ab, wenn wir das Programm (in Form einer EXE Datei, welche auf Windows CE läuft) auf die Speicherkarte kopieren.
Unsere Entwickler-PCs sind 1000fach abgesichert durch Virenschutz, Firewall, usw..., worauf wir aber keinen Einfluss haben.

Folglich muss sich die IT Abteilung darum kümmern. Diese sagt nun, dass unser Programm wohl als Virus erkannt wird und es deswegen wohl dazu kommt, dass es beim Kopieren zu Problemen kommt und folglich der Entwickler PC abstürzt.

Meiner Meinung nach sollte also der Virenschutz lockerer eingestellt werden.
Die IT verneint: es gibt weltweite Standards wie Programme auszusehen haben, damit es keine Probleme mit dem Virenschutz gibt, folglich: wir müssen unsere SW anpassen.
Außerdem arbeiten wir mit veralteten Tools (Compilern), das kann auch zu Problemen führen. Auch hier sind uns die Hände gebunden, der Compiler für die Plattform ist unmal alt, aber deswegen NICHT schlecht!!!

Wir haben es hier mit einer EXE Datei zu tun, die unmöglich auf x86 ausgeführt werden kann. Außerdem steht bereits im EXE Header drinnen, dass es sich hierbei nicht um ein Programm für den Desktop handelt, und Windows somit die Ausführung sowieso nicht ermöglicht.

Das Programm ist in C++ geschrieben, ich habe keinen direkten Enfluss darauf, wie der binäre Output aussieht, geschweige denn habe ich eine Ahnung welches binäre Muster den Virenscanner dazu bringt, zu schreien.

Frage: Was soll ich davon halten?
Ich jedenfalls finde es ziemlich sinnlos, eine Software anzupassen, nur damit der Virenscanner nicht mehr anschlägt und der PC nicht abstürzt.
Was heißt außerdem "standardkonformes programmieren", damit der Virenscanner nicht anschlägt.

Warum gebt ihr eurem Binary die Programmendung *.exe?

Das sind doch genau die Programmendungen die Dateien kennzeichnen und deswegen von Antivireprogrammen durchsucht werden.
Mein Vorschlag, ändert die Dateiendung in *.bin oder *.dat um, dann durchwühlt auch keine Antivirensoftware diese Datei. Vorrausgesetzt natürlich, sie ist so eingestellt, dass nur bekannte Dateinamen durchgeprüft werden.

Ansonsten gilt. Antivirensoftware verwendet bestimmte Heuristicen und sucht nach Mustern in Binärdateien, die so aussehen, wie sie auch Virenschreiber schreiben würden.
Dazu zählen dann so Sachen wie selbstmodifizierender Code und so etwas muss man nun nicht wirklich selbst in seinem eigenen Binary umsetzen.

Es ist auch aus Kundensicht doof.

Jetzt stell dir mal vor, ihr entwickelt Firmware für PC Hardware und ein Kunde will seine Firmware updaten und läd eure Firmware erstmal auf jotti hoch, weil er euch nicht traut und dann schlagen 10 von 30 Antivirenscanner alarm, was meinst du, welches Licht das auf eure Firma wirft?
False positiv gibt's zwar immer, aber ein einziger führt schon zu einem faden Beigeschmack und im Zweifelsfall entscheidet man sich lieber gegen einen potentiellen Virus.

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

Ob nun ein Entwickler PC unbedingt die ganze Antivirensoftware braucht ist natürlich ein ganz anderes Thema. Wenn es nach mir ginge, dann wären die Entwickler PCs vom Firmen LAN getrennt und hätten zumindest ihr eigenes getrenntes LAN.
Internetzugriffe erfolgen über VPN auf einer anderen Maschine und dann braucht man auch keine aktiven Virenscanner auf dem Entwickler PC.

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.