In der Shoutbox der EE habe ich mich ja schon darüber ausgelassen. Das Topic mache ich mal hier auf, weil ich denke, dass hier ein paar mehr Leute unterwegs sind, die damit evtl. etwas Erfahrung haben.

Ich habe für meinen mp3-Player mit InnoSetup einen Installer gebaut. Dieser wird seit gestern(?) vom Windows Defender als "Trojan:Win32/Ludicrouz.C" erkannt. "False Positives" sind ja nichts neues, und grade bei Delphi kommt das immer wieder mal vor (z.B. auch mit den Indy-Komponenten). Etwas blöd ist, dass es diesmal der Windows Defender ist, der sehr weit verbreitet sein dürfte. Außerdem ist blöd, dass das Microsoft-Formular zur Malware-Analyse den Upload verweigert ("Upload failed, please try again"), und mir somit eine Meldung dieses Fehlers (erstmal) nicht möglich ist (verschiedene Browser probiert, verschiedene OS probiert, verschiedene Varianten probiert, z.B. auch zip mit Passwort wie im Formular angegeben, ...).

Dann habe ich mir gedacht: Gut, veränderst du halt das Setup ein bisschen - vielleicht reicht das ja, um die Heuristik dann nicht mehr zu triggern. Interessanterweise hat das beim ersten Versuch geklappt. Ich habe im InnoSetup-Script die Zeile

markieren

Code:

#define MyAppPublisher "Daniel Gaußmann"

ausgetauscht durch

markieren

Code:

#define MyAppPublisher "Daniel Gausi Gaußmann"

Das hat tatsächlich gereicht, um den Windows Defender stumm zu schalten . Laut VirusTotal ist eine McAfee-Variante damit immer noch nicht zufrieden, aber das soll mir egal sein.

Jetzt kann ich nachvollziehen, dass eine Malware-Heuristik bei einer nicht signierten Exe Alarm schlägt, wenn als Publisher z.B. "Microsoft" eingetragen ist. Sowas ist "verdächtig", völlig klar. Aber wenn ich einen unbekannten Hobby-Entwickler durch einen anderen ersetze, sollte das doch keinen Unterschied machen, oder? Ich halte Antiviren-Software ja tendenziell eher für Schlangenöl, aber so blöd kann das ja nicht sein ...

Dann ist mir aufgefallen, dass die neue Version (mit dem längeren Publisher-String) ein paar Bytes kleiner ist als die alte. Beim Blick in die beiden Binaries (z.B. mit HxD) sieht man, dass dieser (und andere) Strings mit einer konstanten Länge (Unicode-String, aufgefüllt mit Leerzeichen) in der Datei zu finden sind - da ändert sich die Dateigröße also nicht.

Relativ am Ende (größenordnungsmäßig die letzten 10%) des Installers findet sich dann ein Teil mit größeren Binär-Unterschieden. Die Teile sind dabei echt verschieden, nicht einfach nur um ein paar Bytes verschoben, beginnend mit "Inno Setup Setup Data" (als AnsiString). Ich nehme mal an, dass in diesem Teil die Setup-Daten nochmal(?) in komprimierter(?) Form vorliegen, und dass der längere String in Kombination mit den anderen Strings insgesamt besser komprimiert werden kann. Weiter kann ich mir vorstellen, dass in diesem anderen "Bytehaufen" dann keine Muster mehr vorkommen, die auch in besagtem Trojaner vorkommen.

Jetzt ist es natürlich etwas komisch bzw. verdächtig, wenn ich schreibe "Ich hab da nur einen String ausgetauscht", und ein misstrauischer Anwender dann mal ein Diff macht und weitaus mehr Unterschiede findet.

Hat damit jemand schon Erfahrung gesammelt, bzw. weiß, warum sich dieser letzte Teil im Installer so deutlich unterscheidet, wenn man nur eine String-Konstante ändert?

Beide Varianten als Download, falls sich das jemand ansehen möchte:
"Mit" Trojaner
"Ohne" Trojaner

Erstell mal zwei Dateien auf der Kommandozeile:

markieren

Code:

echo x  x>xx

markieren

Code:

echo x   x>xxx

Der Unterschied in den Dateien ist genau ein Leerzeichen.

Zippe sie und vergleiche sie.
Bei mir finde ich in den Zips 36 Unterschiede.

Oder: Marginale Änderungen können in gepackter Form zu absolut unterschiedlichen Ergebnissen führen.

Statt 'ner Stringänderung in 'ner Datei füge doch einfach eine weitere, für das Programm nicht erforderliche Datei mit in das Setup ein. Da musst Du Dich dann niemandem gegenüber rechtfertigen. 'ne Datei, die nur die Versionsnummer des Programmes enthält oder die MD5-Checksumme der Exe, jeweils 'ne neue GUID oder sonstein Phantasiewert.

Wenn Du diese Datei dann immer im Setup hast, fällt ein Vergleich alte/neue Installation auf Dateiebene dem Anwender sicherlich erstmal nicht auf.
Eventuell reicht es ja sogar, in diese Datei immer aktuelles Datum und aktuelle Uhrzeit vom Zeitpunkt der Erstellung des Setups zu nehmen. Damit ist diese Datei garantiert bei jedem Erstellen des Setups anders und Du hast (mit etwas Glück) so den Fehler/Virusverdacht mit dem nächsten Neuerstellen des Setups behoben.

Oder ein zusätzliches, für das Setup entbehrliches,

markieren

Code:

#define GUID <jedesmal ein neuer Wert>

einfügen.

Einfach mal probieren, welche der Varianten zu einer deutlich anderen Setupdatei führt und diese Variante dann nutzen.

Frei nach dem Motto:

Erstellprozess des Setups starten.
Upps: Virusalarm
Erstellprozess des Setups starten.
Kein Virusverdacht.

Zitat von Gausi:

... dass das Microsoft-Formular zur Malware-Analyse den Upload verweigert ("Upload failed, please try again"),..

Vermutlich weil du eine Virenverseuchte Datei hochlädst...

Zitat von Gausi:

Das hat tatsächlich gereicht, um den Windows Defender stumm zu schalten .

das ist Heuristik. Da kann schon ein Byte (an der richtigen Stelle) genügen...

Zitat von Gausi:

Aber wenn ich einen unbekannten Hobby-Entwickler durch einen anderen ersetze, sollte das doch keinen Unterschied machen, oder?

Das ist heuristik. Da kann alles zuschlagen das deine Anwendung "gerade so" über die Warnschwelle bringt ...

Zitat von Gausi:

Ich halte Antiviren-Software ja tendenziell eher für Schlangenöl, aber so blöd kann das ja nicht sein ...

Doch, bei Heuristik schon. Hatten erst vor kurzen den Fall das eine 1/2 Jahre alte DLL immer wieder gelöscht wurde und von immer mehr (gleiche Engine) Scannern angemeckert wurde.
Damit muss man halt mittlerweile leben ...

Zitat von Delphi.Narium:

Frei nach dem Motto:

Erstellprozess des Setups starten.
Upps: Virusalarm
Erstellprozess des Setups starten.
Kein Virusverdacht.

Also genau das, was die Virenprogrammierer auch machen, die allerdings vermutlich automatisiert und mit vielen Virenscannern.

Dass beim packen kleine Änderungen massive Auswirkungen haben können, ist mir durchaus klar. Frage ist eher, warum der String einmal im Klartext in der Datei zu lesen ist, und sich dann aber auch anderer Teil weiter verändert. Da gibt es also anscheinend eine Doppelung - oder irgendwelche anderen Wechselwirkungen. Ob da wirklich was komprimiert wird, weiß ich ja nicht einmal. Desweiteren ist die Frage, warum die Malware-Heuristik auf den gepackten(?) Daten läuft (und nicht auf den entpackten), und dann String-Konstanten so einen Einfluss haben können.

Zitat von Delphi.Narium:

Da musst Du Dich dann niemandem gegenüber rechtfertigen. 'ne Datei, die nur die Versionsnummer des Programmes enthält oder die MD5-Checksumme der Exe, jeweils 'ne neue GUID oder sonstein Phantasiewert.

In gewisser Weise muss ich mich da auf jeden Fall rechtfertigen . Denn der Alarm trat ja erst mit dem jüngsten Signatur-Update des Defenders auf. Letzte Woche hatte ich beim Erstellen des Setups keine Probleme, jetzt meckert er bei mir und den Usern, die das Update durchführen wollen.

Eine nicht verwendete GUID in das Setup-Script zu schreiben bringt übrigens nichts. Wenn die Konstante weiter nicht verwendet wird, wird sie von InnoSetup nicht mit einkompiliert - beide Versionen sind dann binärgleich.

Eine Dummy-Datei zum Brechen der Heuristik mit auszuliefern hat allerdings auch im ersten Versuch geklappt. Vielleicht mach ich das, wenn das wieder einmal auftritt . Da schreib ich dann irgendeinen Blödsinn rein, und verkauf das als "Easteregg" .

Zitat von Delphi.Narium:

Frei nach dem Motto:

Erstellprozess des Setups starten.
Upps: Virusalarm
Erstellprozess des Setups starten.
Kein Virusverdacht.

Das funktioniert ggf. bei der Auslieferung. Aber wenn die Virenscanner ein blödes Update bekommen, habe ich das Problem wieder. Ich erwarte dabei nicht, dass das regelmäßig auftritt. Mir geht es mehr um das Verständnis der Ursachen in diesem Fall.

Zitat von Bernhard Geyer:

Vermutlich weil du eine Virenverseuchte Datei hochlädst...

Öhm, wenn ein Upload-Formular für die Analyse von Malware mit der Option "Fälschlicherweise als Malware erkannt, bitte prüfen" keine Dateien zulässt, die fälschlicherweise als Malware erkannt werden, dann ist das Konzept etwas kaputt.

Zitat von Bernhard Geyer:

das ist Heuristik. Da kann schon ein Byte (an der richtigen Stelle) genügen...
[...]
Damit muss man halt mittlerweile leben ...

Gut, dann hatte ich bisher eine etwas andere Vorstellung von der "Intelligenz" solcher Heuristiken. Muss ich dann nochmal etwas nach unten korrigieren.

Heuristik heißt bei Virenscanner: Wir suchen nach 'ner Ähnlichkeit.

Diese Ähnlichkeit muss Grenzen haben, denn ansonsten wäre alles ähnlich.

Wie genau diese "Ähnlichkeitesgrenze" definiert ist, weiß wohl nur der jeweilige "Ähnlichkeitenfindenentwickler". Sprich: Das ist von außen nicht durchschaubar.

Aber auf Byteebene kann diese Grenze nur bei einem Byte Unterschied liegen. Entweder etwas passt noch in die Heuristik oder eben nicht.

Bei alledem darf man nicht vergessen:

Wenn heute eine Datei problemlos durch alle Virenscanner als ok durchgeht, kann morgen schon die gleiche Datei in absolut unveränderter Form nicht mehr durchgehen, einfach, weil in der Heuristik was verändert wurde und nun irgendwas als Treffer interpretiert wird, was gestern noch kein Treffer war.

Man muss eigentlich immer damit rechnen, dass ein Virenscanner von heute auf morgen bei einer bestimmten Datei zuschlägt oder eben auch nicht mehr zuschlägt.

Das ist ein bisserl wie beim Münzwurf: Kopf oder Zahl.

Hatte mal so ein Problem bei einem Konsolenprogramm, dass einfach nur im Batchbetrieb Dateien mit OEM-Zeichensatz in ANSI-Zeichensatz konvertieren sollte.

Irgendwann war die Exe plötzlich virenverseucht (auch wenn man sie mit Delphi neu kompilierte). Ein paar Tage später war sie es dann nicht mehr, dazwischen lagen nur ein paar Updates der Signaturdateien des Virenscanners. Andere Virenscanner befanden die Exe die ganze Zeit über als "völlig unauffällig".

Wenn sich die Länge eines Strings in der EXE verändert, dann verschieben dich auch andere nachfolgende Dinge und Referenzen darauf müssen dann ebenfalls angepasst werden usw.


Am "Einfachsten" ist es ja immernoch dem betreffenen Antivierenhersteller seinen False-Positive zu melden und die Viren-Signatur bzw. die Heuristik dementsprechend verbessern zu lassen, anstatt selbst so lange zumzufummeln, bis "aktuell" bei einem selbst das Problem "weg" ist.


Auf Entwicklungsrechnern macht es sich auch nicht schlecht, wenn man die Virensoftware nicht alles gleich löschen lässt, sondern nur "sperren und melden" aktiviert, um weniger Arbeit zu haben, mit andauernd verschwindenen Dateien, ohne dass man vom Virenprogramm das "direkt" gesagt bekommt. (sondern es erst später zufällig im Log entdeckt)

Zitat von himitsu:

Wenn sich die Länge eines Strings in der EXE verändert, dann verschieben dich auch andere nachfolgende Dinge und Referenzen darauf müssen dann ebenfalls angepasst werden usw.

Das ist bei den Inno-Setups und den definierbaren Strings für AppPublisher etc. anscheinend anders. Die Strings haben da eine fixe Länge und werden ggf. mit Leerzeichen aufgefüllt. Das war ja auch der Grund, weswegen ich mir die beiden Dateien näher angeschaut habe. Die mit dem längeren String ist nämlich 7 Bytes kleiner, wo man naiv 6 Bytes mehr erwarten würde.

Zitat von himitsu:

Am "Einfachsten" ist es ja immernoch dem betreffenen Antivierenhersteller seinen False-Positive zu melden und die Viren-Signatur bzw. die Heuristik dementsprechend verbessern zu lassen, anstatt selbst so lange zumzufummeln, bis "aktuell" bei einem selbst das Problem "weg" ist.

Das habe ich ja probiert - geht nicht. Ich weiß auch, dass das keine sinnvolle Fehlerbeschreibung ist. Aber mehr liefert das Upload-Formular mir halt auch nicht. Deswegen habe ich ja überhaupt nur den anderen Weg probiert.

Aber gut, ich werde das dann wohl abhaken mit "kann man nix machen". Hätte ja sein können, dass sich jemand schon mal im Detail mit InnoSetup in diesem Sinne auseinandergesetzt hat, oder den Aufbau von solchen Installer-Binaries näher kennt - also z.B. was da im letzten Teil der exe zu finden ist.

In der Setupdatei findest Du eine mehr oder weniger große Anzahl von

markieren

Code:

PADDINGXXPADDING

Dahinter folgt die Zeichenfolge zlb + hex 1A. Ab dort ist der gepackte Inhalt Deines Programmes und aller seiner Bestandteile zu finden.

Änderungen an Deinem Programm oder zugehöriger Dateien führen zwangsläufig zu einer Änderung dieses Bereiches.

Quelltexte: https://github.com/jrsoftware/issrc

Zitat von Gausi:

Zitat von Delphi.Narium:

Da musst Du Dich dann niemandem gegenüber rechtfertigen. 'ne Datei, die nur die Versionsnummer des Programmes enthält oder die MD5-Checksumme der Exe, jeweils 'ne neue GUID oder sonstein Phantasiewert.

In gewisser Weise muss ich mich da auf jeden Fall rechtfertigen .

Ich finde das nicht .
Als irgendwann mal in meinem Forum mal wieder eine Anschuldigung kam, bin ich sehr pampig geworden. Und an ... gedacht.