Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC

[implementation]

Ich denke mal die testen das Ding dann inner Sandbox und schaun, was es anrichtet.

[Namenloser]

Zitat von internetnavigator:

Könnte da jeder seine Viren hin schicken und die verifizieren die?

Habe ich mich auch schon gefragtm müsste man eigentlich mal ausprobieren. Würde mich nicht wundern, wenn da gelegentlich aus Faulheit nicht mehr genauer nachgeprüft wird.

[Luckie]

Wie sollten die ihre Virendantenbank aufbauen, wenn sie den Quellcode bräuchten? Oder meint ihr die Virenautoren schicken denen die Quellcodes von ihren Viren? Die werden die Exe disassemblieren und gucken, was sie macht. Die brauchen den Quellcode nicht. Und wenn, dann bräuchten sie ja für jede Programmiersprache extra Compiler und IDs. Wie soll das funktionieren?

[Aphton]

Sobald bestimmte Calls in der Importtabelle der Exe drin stehen, tendieren die meisten AV-Software auf eine verdächtige Datei.

Eine (praktische) Lösung wäre zB.: du lädts die DLLs und ermittelst die Adressen der
Funktionen - zur Laufzeit. Somit sind sie auch nicht nach der Kompilierung in der Importtabelle deiner Exe...

Wichtig dabei ist auch, dass du zB nicht soetwas wie das hier machst:
MyShellExec := GetProcAddress( hDLL, 'ShellExecuteA' ); denn, dann beinhaltet die Exe wieder den String "ShellExecuteA".

Delphi-Quellcode:

MyShellExec := GetProcAddress( hDLL, pChar( SimpleDecrypt('XsGgfdASasdsa') ) );
{Anmerkung: "XsGgfdASasdsa" ist jetzt nur ein Beispiel - entschlüsselt sollte dieser Buchstabenhaufen "ShellExecuteA" ergeben}

MfG

[H4ndy]

Versuch doch mal CreateProcess und ruf einfach die cmd.exe (Win2K oder neuer) bzw. command.exe (Win9 mit deiner Batch als Parameter auf.

[ErazerZ]

Zitat von Aphton:

Sobald bestimmte Calls in der Importtabelle der Exe drin stehen, tendieren die meisten AV-Software auf eine verdächtige Datei.

Eine (praktische) Lösung wäre zB.: du lädts die DLLs und ermittelst die Adressen der
Funktionen - zur Laufzeit. Somit sind sie auch nicht nach der Kompilierung in der Importtabelle deiner Exe...

Wichtig dabei ist auch, dass du zB nicht soetwas wie das hier machst:
MyShellExec := GetProcAddress( hDLL, 'ShellExecuteA' ); denn, dann beinhaltet die Exe wieder den String "ShellExecuteA".

Delphi-Quellcode:

MyShellExec := GetProcAddress( hDLL, pChar( SimpleDecrypt('XsGgfdASasdsa') ) );
{Anmerkung: "XsGgfdASasdsa" ist jetzt nur ein Beispiel - entschlüsselt sollte dieser Buchstabenhaufen "ShellExecuteA" ergeben}

MfG

Wenn er schon damit anfängt dann kann das ja was werden, sowas ist keine Lösung. Wenn schon dann maximal GetProcAddress ( hDLL, "ShellExecute" ), aber mehr auch nicht. Er kann ja nichts dafür, dass ein AntiViren Hersteller schlechte Signaturen benutzt ( false positives kommen oft vor ).
Am besten du schreibst ihnen eine Mail, und verweist eventuell auf den Thread hier. Sie sollten dann im besten Fall die Signatur rausnehmen.
Weil dass du jetzt extra deinen Code umprogrammieren musst nur weil ein AntiViren Hersteller meint dein Programm sei böse, das ist keine Lösung.

[Aphton]

Wo du recht hast, da hast du recht.
Achja, heißt doch "ShellExecute" (Hab mir die Importtabelle nicht angeschaut)

MfG

[internetnavigator]

Wie gesagt, habs' jetzt im OnActivate der Form... Geht erst einmal, nicht sauber, da habt ihr Recht. Ich hab nur heute Nachmittag released und wenn ich jetz wieder den Installer patche gibts noch ein größeres Durcheinander.

Im nächsten Update werd ich dann das ganze wieder "ordentlich" in das OnCreate schreiben und dann gData kontaktieren.

Vielen Dank erstmal für eure Hilfe...

Achja, das mit dem GetProcAddress ist natürich eine Möglichkeit, aber wenn ShellExecute keine Fehler mehr macht, dann kommt vielleicht irgend etwas anderes und macht Probleme. Ich kann mir ja nicht alle Grundfunktionen so zusammenpuzzlen

Was ich nur vollkommen außer Acht gelassen habe: Wenn gData rummeckert, dann tuen es vielleicht auch andere Scanner :/

mfg !N

[H4ndy]

GData hat keine eigene Engine. Es benutzt zwei Engines anderer Hersteller. Vor zwei Jahren war es BitDefender und Kaspersky. Ob das heute andere sind, weiss ich leider nicht. Ist jedenfalls der Grund, warum GData langsamer ist, dafuer aber zuverlaessiger arbeitet (aber damit auch mit doppelt sovielen False Positives).

[cookie22]

Zitat von internetnavigator:

Wie gesagt, habs' jetzt im OnActivate der Form... Geht erst einmal, nicht sauber, da habt ihr Recht. Ich hab nur heute Nachmittag released und wenn ich jetz wieder den Installer patche gibts noch ein größeres Durcheinander.

Im nächsten Update werd ich dann das ganze wieder "ordentlich" in das OnCreate schreiben und dann gData kontaktieren.

Vielen Dank erstmal für eure Hilfe...

Achja, das mit dem GetProcAddress ist natürich eine Möglichkeit, aber wenn ShellExecute keine Fehler mehr macht, dann kommt vielleicht irgend etwas anderes und macht Probleme. Ich kann mir ja nicht alle Grundfunktionen so zusammenpuzzlen

Was ich nur vollkommen außer Acht gelassen habe: Wenn gData rummeckert, dann tuen es vielleicht auch andere Scanner :/

mfg !N

was du hier beschreibst ist ganz normal. durch zufall entstehen bei der entwicklung öfter mal muster die denen in den signaturen der av programme gleich oder ähnlich sind und dann gibts halt n false positve. meistens lässt sich das ganz einfach beheben, indem man an der betroffenen stelle den code etwas ändert.

Zitat:

Was ich nur vollkommen außer Acht gelassen habe: Wenn gData rummeckert, dann tuen es vielleicht auch andere Scanner :/

soweit ich weiss hat gdata die bitdefender und avast engine.

um zu testen welche scanner dein programm nicht mögen, jag es einfach durch einen online scanner wie z.b.:
http://www.virustotal.com/de/

dort wird dein program von den wichtigsten av scannern getestet.