GrumpyCat schrieb:
Pff, und was macht Java und C# und JavaScript und Lua und so ziemlich der ganze Rest der Welt auch
.NET (weil damit kenn ich mich aus) setzt W^X flags, siehe u.A. hier
https://github.com/dotnet/runtime/issues/50391, d.h. sie setzen sauber die Bereiche die Code beinhalten und sauber Speicherbereiche die Daten beinhalten und verbieten die Mischung
MS signiert seinen eigenen Bibliotheken, JRE macht das gleiche (und whitelisted die natürlich
)
Je nach Konfiguration erzeugt Auto Py To Exe nur eine Datei, d.h. der Loader entpackt zur Laufzeit die entsprechenden DLLs im Speicher und führt die aus, da knallt dann W^X drüber bzw. DEP (je nach Plattform).
Das ist immernoch ein größerer Unterschied zu einer PE Datei mit entsprechenden Flags, die z.b. den IL von .NET enthält.
Die Annahme das .NET etc. nicht als potentielle Schadsoftwar erkannt wird ist nur potentiell richtig, wenn du ähnliche tricks machst (insb. mit alten Versionen) wie z.b. selber Assemblies im Speicher zu laden, triffst du auf ähnliche Probleme (bevor MS W^X sauber unterstütz hat).
Das lässt sich teilweise, wie oben schon geschrieben, mit EV Code Signature Zertifikaten umgehen, dann whitelisted dich MS zwar nicht automatisch, aber Defender schreibt dann nur noch hin, "dieses Programm wird selten ausgeführt" oder ähnliches.
Wenn du googlest, siehst du das gerade ältere JRE Versionen auch gerne von DEP erkannt werden.
Nur weil die Technik vor 20 Jahren aktuell war, (das ist etwa so der Bereich) und mittlerweile entsprechende Sicherheitsmechanismen existieren um sowas zu erkennen, ist das nicht gleich nur Einnahmequelle für AV Hersteller. Kein Programm sollte den Daten und den Executable Bereich im Speicher mischen, in Windows gibts da mittlerweile diverse saubere Konzepte, ua CreateEnclave.
Es ist und bleibt heutzutage ein anti-pattern.
