Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC (https://www.delphipraxis.net/151485-heuristik-fund-bei-shellexecute-createprocess-winexec.html)

implementation 20. Mai 2010 17:46

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Ich denke mal die testen das Ding dann inner Sandbox und schaun, was es anrichtet.

Namenloser 20. Mai 2010 17:56

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Zitat:

Zitat von internetnavigator
Könnte da jeder seine Viren hin schicken und die verifizieren die? :lol:

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 20. Mai 2010 18:00

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
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 20. Mai 2010 19:02

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
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:
Delphi-Quellcode:
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 20. Mai 2010 20:32

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Versuch doch mal CreateProcess und ruf einfach die cmd.exe (Win2K oder neuer) bzw. command.exe (Win98-) mit deiner Batch als Parameter auf.

ErazerZ 20. Mai 2010 20:34

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Zitat:

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:
Delphi-Quellcode:
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 20. Mai 2010 21:04

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Wo du recht hast, da hast du recht.
Achja, heißt doch "ShellExecute" (Hab mir die Importtabelle nicht angeschaut)

MfG

internetnavigator 20. Mai 2010 23:24

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
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 :angel2:

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

mfg !N

H4ndy 21. Mai 2010 03:43

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
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 21. Mai 2010 05:00

Re: Heuristik-Fund bei ShellExecute/CreateProcess/WinExeC
 
Zitat:

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 :angel2:

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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:38 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz