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 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.

Zitat von dummzeuch:

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.

Damit liegst du (leider) nicht so weit daneben. Bei VT hochladen war auch eine Weile Usus. Aber mittlerweile haben die Malwareautoren ihre eigenen Dienstleister. Man darf ja nicht vergessen, daß das nicht mehr die VXer aus den 1990ern und frühen 2000ern sind, die zeigen wollen was sie technisch so auf Lager haben, sondern daß es sich um eine im wahrsten Wortsinne organisierte Schattenwirtschaft handelt. Und unsere Geheimdienste mischen da mit, wie man spätestens nach Snowdens Enthüllungen auch ganz sicher weiß.

Übrigens: auch Zeitstempel (auch die von Signaturen, oder von den Datensätzen die zu den Debugsymbolen gehören oder der Zeitstempel im PE-Header - der allerdings nicht bei Delphi) sind Indikatoren bei den Heuristiken

Frisch erstelltes Programm bei dem andere Indikatoren knapp unter der Schwelle für die Erkennung bleiben? Oh?! Frisch erstellt! Bingo ... Hauptgewinn für den Entwickler!

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.

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.

Wobei bei Setupprogrammen meist ein Stub mit angehängten Daten (Overlay) zum Einsatz kommt. Will heißen die Unterschiede dürften sich meist aus der Kompression und Metadaten ergeben, sofern der Rest gleich ist.

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.

Ich hoffe die Lektüre meiner obigen Ausführungen hat dabei geholfen den rosa Feenstaub von deiner Brille zu putzen

Also erstens ist es meistens nicht gerade wenig Aufwand es einem Hersteller zu melden, sofern man das entsprechende Formular findet (und dieses auch funktioniert und man dutzendfach CAPTCHAs gelöst hat oder daran gescheitert ist). Aber während dieser Zeit tickt bereits die Uhr. Erstens wird der AV-Hersteller dem du den Fehlalarm meldest nicht einfach die Erkennung rausnehmen, sondern das wird einem anderen Prozeß zugeführt und nur in Ausnahmefällen guckt da mal ein Mensch drauf. Und bis dahin kann auch schonmal ne Woche oder zwei vergehen. Ach ja, macht dein AV-Hersteller auf der Formularseite ein Versprechen, man würde sich bei erfolgter Nachanalyse zurückmelden? Nicht? Tscha ... shit happens.

Und in dem jeweiligen Prozeß wird wahrscheinlich dein Programm nicht nur den Analysewerkzeugen rund um VT zugeführt, aber auch. Und wenn derweil andere AV-Hersteller schon bei deinem Hersteller die Erkennung - pardon, den Fehlalarm - "abgeguckt" haben, haste schwuppdiwupp nen Teufelskreis. Hersteller A guckt bei B ab und C wiederum bei A und B. Und jetzt kommst du "Würstchen" und willst denen erzählen deine Software sei harmlos?! Und jetzt kommst du "Würstchen" und willst denen erzählen deine Software sei harmlos?! Das spielst du jetzt mit fünf, sechs dutzend AV-Herstellern durch ...

Ich hab das selber mit WinDirStat durch. Und zwar in zwei Richtungen. Einmal wollte ich eine trojanisierte Variante in Erkennung aufnehmen lassen. Das ging recht flott, auch da ich durch unser Virenlabor halt Zugang zu anderen Kanälen hatte als der Endanwender oder betroffene Softwareentwickler. Ein anderes Mal wurde leider fälschlich ein harmloses Kompilat erkannt.

Ach ja, es gibt natürlich Premiumdienste wie diesen hier oder diesen hier, mit denen du mittelbar jene bezahlst, die für die Fehlalarme verantwortlich sind, aber nicht zur Verantwortung gezogen werden.

Zitat von Delphi.Narium:

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

Nee, das bedeutet wir such(t)en nach Indikatoren und ab einer bestimmten Schwelle schlagen wir Alarm, falls zu viele Indikatoren bedenkliche Werte zeigen.

Zitat von Delphi.Narium:

Sprich: Das ist von außen nicht durchschaubar.

Es ist bedingt durchschaubar, klar. Aber es ist jetzt auch nicht wirklich Zauberwerk ... vieles kann man sich auch allein denken. Beispiele:

• Welcher Compiler wurde benutzte (effektiv das was PEiD macht, AV-Hersteller benutzen bspw. Yara)
• Gibt es eine Signatur?
• Ist die Signatur gültig?
• Vertrauen WIR (als der AV-Hersteller) der Signatur?
• Welche Importe hat die Datei und aus welchen DLLs? (bspw. UNC-Pfade? ... böse!)
• Keine oder wenige Importe? (Laufzeitpacker/Protector oder der Versuch sich einer Analyse/Erkennung zu entziehen)
• Wie ist die Entropie der Datei (Laufzeitentpacker oder nicht ...)?
• Gibt es verdächtige Strings? (ja, das ist exakt das Beispiel von gausi!)
• Wird auf Debugsymbole verwiesen? Deren Pfade können verräterisch sein, siehe vorheriger Punkt ...
• Wie verhält sich die Datei beim emulieren innerhalb der Engine? (Jupp, bei uns steckte da ein echter Emulator drin, denn nur so konnte man bei Laufzeitentpackern und "Schutz"-Programmen ala Themida reingucken)

Zitat von Delphi.Narium:

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.

Sehr richtig!

Zitat von Delphi.Narium:

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.

Letzteres ist aber deutlich unwahrscheinlicher.

Erinnert sich noch jemand? Das war clever, aber jeder in der Industrie wußte, wie's läuft. Manuell war schon vor Jahren Pumpe. Manuelle Analysen von interessanter Malware hat man sich allenfalls noch als PR gegönnt und weil man so der Konkurrenz ne Nase drehen konnte.

Heute läuft vieles über Sandkästen. Gibt's sogar als FLOSS. Einige haben eigene Technologie zu dem Thema, meine ehemalige Firma hat das verschlafen. Bzw. ich weiß mittlerweile daß ein Konkurrent schneller war (der auch bei mir anfragte ob ich nicht Interesse an einem Job hätte). Schon auf der VB2013 war ein richtungsweisendes Paper vorgestellt worden. Diese Erkenntnisse hätte man nutzen und ausbauen können. Stattdessen wurde in dieser Richtung nichts getan und nun lizensiert man es halt von Dritten. Dumm gelaufen.

Eigentlich hatten wir auch sowas wie einen Sandkasten, nämlich die interne Version unseres Befehlszeilenscanners. Der hat jede Menge Extrainfos ausgespuckt, welche dann wiederum weiterverarbeitet werden konnten.

Einerlei, was passiert wenn du eine Datei bei VT hochlädst, ist daß die durch die ganzen AV-Engines durchgejagt wird und auch nochmal in mindestens einer Sandbox läuft. Was anderes machen auch die AV-Hersteller nicht. Nur stark parallelisiert und automatisiert. Da wird dann geclustert und versucht neue Methoden zu finden wie man zu Clustern kommen kann und das in Heuristiken abbilden kann. Da gibt es die wildesten Methoden.

Die haben überall ihre Honigtöpfe aufgestellt oder sehen bspw. anhand der URLs in Email-Kampagnen (Antispam und Antimalware ist nämlich in dieser Hinsicht supi kombinierbar) was gerade abgeht. So werden auch Malwarekampagnen zeitnah aufgedeckt. Aber gegen Spearphishing hilft das natürlich auch nix.

Zitat von Delphi.Narium:

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".

Wobei man dazusagen sollte, daß es in der Tat schon Malware hab, welche die vorkompilierten Objektdateien auf Rechnern mit Delphi (usw.) befiehl und somit die Programme frisch ab Werk verseucht waren. Aber deine Geschichte klingt schon nach Fehlalarm.