Windows Malware Development

[H4x0r007]

Hi,

da ich mich schon vor einigen Jahren aus der Malware-Entwicklung verabschiedet hatte, habe ich natürlich einiges an Entwicklung verpasst.
Damals™ verwendete ich meist C++ mit WinAPI. Gibt es heute noch irgendeinen Grund, native Programme mit WinAPI zu bauen und nicht auf .net zu gehen? Ich bin kein großer Freund von .net, aber alles ist besser als die hässliche WinAPI.

Welche Vor- und Nachteile gibt es bei der Malware-Entwicklung mit z.B. C#? Ich weiß noch, dass damals einige Crypter-Entwickler .net verwendeten, da auf jedem System ein .net Compiler vorhanden war und man damit seine Programe polymorph gestalten (oder zumindest die Detection Rate niedrig halten) konnte.

Lassen sich .net Executables ähnlich gut crypten bzw. obfuscaten wie native Binaries?

Ich habe irgendwann der Windows-Entwicklung den Rücken gekehrt und quasi nur noch Linux genutzt und daher die ganze Entwicklung verschlafen. Das Thema wird jetzt aber wieder aktueller, da wir hier auf dem Forum ja ein paar neue Tools brauchen, um wieder neue Member werben zu können. Damals gab es Software wie Sand am Meer Evtl. könnte man ja später einmal gemeinsam ein paar Tools entwickeln, die dann auf dem F-H Git-Server mit Source veröffentlicht werden.

[hoschi111]

Sehr nicer Scheiß, der gerade in der Mache/frisch bei .Net ist:

.NET Standard: https://blogs.msdn.microsoft.com/dot...-net-standard/
.NET Native: https://entwickler.de/online/windows...er-171183.html

[Sawyer]

Sehr nicer Scheiß, der gerade in der Mache/frisch bei .Net ist:

.NET Standard: https://blogs.msdn.microsoft.com/dot...-net-standard/
.NET Native: https://entwickler.de/online/windows...er-171183.html

Das ganze ist aber soweit mir bekannt nur für die neuen Windows Apps verfügbar. Leider kein WinForms oder dergleichen. Somit für die Maleware entwicklung eher unbrauchbar. Ich weiß nicht inwiefern das in der Zukunft weiter ausgebaut wird, kann mir aber nicht vorstellen das sie es auf das ganze Framework anpassen.

Ich meine der ursprüngliche Grund der Einführung war eher gedacht für die Mobilen Geräte, oder eben die sogenannten "Universellen Anwendungen" wo sie auf allen Endgeräten gleichermaßen schnell lauffähig sein sollten.

Welche Vor- und Nachteile gibt es bei der Malware-Entwicklung mit z.B. C#? Ich weiß noch, dass damals einige Crypter-Entwickler .net verwendeten, da auf jedem System ein .net Compiler vorhanden war und man damit seine Programe polymorph gestalten (oder zumindest die Detection Rate niedrig halten) konnte.

Nachteile sehe ich zumindest was die Unterstützung angeht (wenn man auf die Basis .NET 2.0 setzt) keine. Ein Großteil wird heute in .NET entwickelt, da gibt es unzählige beispiele. Ich bin allerdings auch nicht gerade besonders gut auf dem laufenden, weshalb auch meine Einschätzung nicht zu ernst genommen werden sollte.

MfG

[H4x0r007]

Auf .net 2.0 aufzusetzen ist sicher keine schlechte Idee. Auf der anderen Seite ist es auch völlig ausreichend, wenn die Software ab Windows 7 läuft. Alles andere hat sowieso einen vernachlässigbar kleinen Marktanteil.
Ich hatte so eine Antwort schon erwartet. Es ist einfach zu schmerzhaft, heute noch die WinAPI zu verwenden.

[wacked]

Naja was soll deine Malware denn können? Falls du irgendwas in einem anderen Prozess machen willst brauchst du nativen Code. Falls du hooken willst brauchst du nativen Code. Falls du exploits ausnutzen musst brauchst du wahrscheinlich nativen code (also nicht nur für den shellcode sondern auch für die pointer aritmetik vorher)

Lassen sich .net Executables ähnlich gut crypten bzw. obfuscaten wie native Binaries?

Da muss man irgendwas extra machen, aber was weiß ich nicht.

[ChEeTaH182]

Da muss man irgendwas extra machen, aber was weiß ich nicht.

Damit man .NET dlls in einem Nativen Host (Prozess) ausführen kann (=Crypter payload)muss man zuerst den CLRHost laden, welcher für die Interpretierung des MSIL codes zuständig ist (Wie bei Java die JVM). Ist aber kein großes Ding und funktioniert einwandfrei: https://github.com/sunsided/native-d...code-injection

Was hier im Prinzip gemacht wird:
1. eine native (Bootstrap) DLL wird injected, welche die .NET Runtime im Hostprozess lädt
2. die managed DLL wird injected und die Main() Methode aufgerufen (.NET dlls haben keine call Events wie native dlls, deswegen muss die ausführung händisch angestoßen werden)
3. Bootstrap DLL wird wieder entfernt

[H4x0r007]

Sorry, ich hatte den Thread hier ganz vergessen.

Naja was soll deine Malware denn können? Falls du irgendwas in einem anderen Prozess machen willst brauchst du nativen Code. Falls du hooken willst brauchst du nativen Code. Falls du exploits ausnutzen musst brauchst du wahrscheinlich nativen code (also nicht nur für den shellcode sondern auch für die pointer aritmetik vorher)

Ich hatte bisher noch keine konkreten Vorstellungen. Es ging erst mal nur darum, ob es sich noch lohnt, rein auf die WinAPI zu setzen.
Pointerarithmetik und andere Dinge in reinem C sind kein Problem - ich finde nur die Winapi so schmerzhaft. Da .net in irgendeiner Form auf jedem modernen Windows vertreten sein dürfte, werde ich mir mal C# anschauen, bzw. mich überhaupt mal mit der .net-Welt befassen.

Danke soweit für die Antworten.