12 Antworten in diesem Thema

[Crap]

Deleted

[Take1T]

War "Betatester" vom Crypter und hatte 3 Tage Zeit, ihn zu testen. Vorab, der Crypter hat viele Funktionen, jedoch ist er nicht allzu kompliziert aufgebaut. Wenn dennoch Fragen entstehen, kann man sich immer an die beiden wenden. Habe sehr schnelle Antworten von n1nja (in meinem Fall) bekommen. Der Kontakt war ebenfalls freundlich! Ich habe den Crypter erfolgreich mit NanoCore und Beta 1.8 getestet.

Scantime FUD:

Please Login HERE or Register HERE to see this link!

 

Runtime kann ich derzeit nicht testen, sorry.

[rat123]

-"Process Injection" funktioniert auch für .NET assemblys? x86/x64 ? 

-ring3 Rootkit ? 

 

.NET ist wirklich keine passende Sprache für Buisness Produkte.

[Crap]

Process Injection funktioniert für jede beliebige File.

 

 

.NET ist wirklich keine passende Sprache für Buisness Produkte.

 

Könntest du das bitte genauer, mit etwas mehr Belegen, erklären?

 

LG

[n1nja]

Ja Injection geht mit .Net Assemblys.

Rootkit hat es nicht, wird es auch in Zukunft nicht geben.

 

C# ist einer der meist verbreiteten Sprachen die es gibt.

Solang die Software funktioniert, interessiert es niemanden in was es gecodet wurde.

[pr0legend]

-"Process Injection" funktioniert auch für .NET assemblys? x86/x64 ? 

-ring3 Rootkit ? 

 

.NET ist wirklich keine passende Sprache für Buisness Produkte.

 

Award für den dümmsten Satz der Woche!

 

// Crypter sieht gut aus! 

Bearbeitet von pr0legend, 16 January 2016 - 05:40 Uhr.

[rat123]

Ja Injection geht mit .Net Assemblys.

Rootkit hat es nicht, wird es auch in Zukunft nicht geben.

 

C# ist einer der meist verbreiteten Sprachen die es gibt.

Solang die Software funktioniert, interessiert es niemanden in was es gecodet wurde.

 

-ez reversable

-ez detection

-managed applikationen sind in der regel größer als native

-.NET v2.0 dependency

-schwache performance

-richtiges hiding ist managed ohne weiteres nicht möglich

-usermode instanzen = ez killable

 

C# ist wirklich keine schlechte Sprache, hat sogar seine Vorteile gegenüber anderen Sprachen. Nur wenn es richtung serious malware dev und co. geht sollte man runter vom managed Stoff

[Crap]

Reversable: Ich denke nicht das du ProteC#tion einfacher cracken kannst, als eine beliebe Native Datei.

Detection: Falsch. Obs .NET oder Native ist tut eig nichts zur Sache.

Managed: Unsere Output files sind teilweise nur 20kb größer, als die jeweiligen Input files(siehe main Post).

NET: Mit unserem Crypter ist es möglich den .NET Output zu bestimmen. .NET 4 ist von Win7 - Win 10 vorinstalliert.

Performance: Wenn man vernünftig coden kann ist eine .NET Application nicht langsamer als ein Native Application.

Usermode instanzen: Möchtest du damit auf Persistence anspielen?

 

LG

Bearbeitet von Crap, 16 January 2016 - 20:49 Uhr.

[rat123]

Reversable: Ich denke nicht das du ProteC#tion einfacher cracken kannst, als eine beliebe Native Datei.

Detection: Falsch. Obs .NET oder Native ist tut eig nichts zur Sache.

Managed: Unsere Output files sind teilweise nur 20kb größer, als die jeweiligen Input files(siehe main Post).

NET: Mit unserem Crypter ist es möglich den .NET Output zu bestimmen. .NET 4 ist von Win7 - Win 10 vorinstalliert.

Performance: Wenn man vernünftig coden kann ist eine .NET Application nicht langsamer als ein Native Application.

Usermode instanzen: Möchtest du damit auf Persistence anspielen?

 

LG

 

Reversable: .NET Apps verfügen über mehr metadaten, welche beim decompilen helfen können. C# benutzt außerdem CIL beim compilen, welches ebenfalls den code einfacher lesen lässt. 

Reflection ist jetzt nicht richtiges reversen, nur ein Beispiel.

//EDIT - Obfuscation oder PE header ereasing macht es nicht unmöglich zu reversen, es erschwert einem nur die Arbeit

 

Detection: Methoden/Klassen sind einfacher zu erkennen. Höhere chance auf heuristik.

 

Dependencies: ansichtssache XP SP3 hat NET Framework 2.0 vorinstalliert, den einen stört es, den anderen nicht

 

Usermode: Peristence, Rootkitties

 

alles was im usermode lauert kann auch vom usermode aus gekillt werden. In .NET kann man nicht eben einen kernel driver schreiben, dse patchen bzw mbr modifizieren und den treiber installieren. 

 

"richtige" ring3 Rootkits tuhen zwar zur sache, haben aber nur begrenzte reichweite. 

 

"Critical Process" flaggt einfach nur deine instanz, ist trotzdem killable

Bearbeitet von rat123, 16 January 2016 - 21:29 Uhr.

[Crap]

• Um vernünftige Rootkis zu coden, sollte man sowieso eher ASM verwenden. Critical Process sorgt beim Beenden für ein Bluescreen.
• Bei einem guten USG sind HEUR Dts nahezu unmöglich.
• Aber die Systeme die momentan hauptsächlich verwendet werden sind Win7-10. Wenn die entsprechende File auf .NET 4 compiled(bei unserem ProteC#tor einstellbar) ist, kann man sie auch ohne ein extra installiertes Framwork öffnen.
• Jede Sprache kann reversed werden, nur .NET einfacher. Wenn man aber Private Obfuscator und online Vars verwendet, welche nur geladen werden, wenn der User eingeloggt ist etc. ist es für die Meisten beinahe unmöglich, dass ensprechene Tool zu cracken.

LG

[n1nja]

Die Hälte vo dem was hier rat123 geschrieben ist Schwachsinn.

 

Man kann sowohl mit .Net Sprachen einen Treiber, Rootkits coden.

Man muss nur wissen wie?!

 

Jede exen verwenden IL zum ausführen. Der große unterschied ist dabei das Framework wo dahinter steckt.

Man kann in C# sowohl auch Code schreiben, der genauso kein Framework braucht.

 

Der Crypter hat hier auch 2 unterschiedliche Arten von Execution.

Das einzige was hier letztendlich wirklich in C# gecodet wurde ist der Builder, und wem interessiert das?

 

Klar kann ich die GUI etc. alles in C++ coden, aber wozu, wenn MS das Framework zur Verfügung stellt.

 

Das einzige wo ich dir Recht gebe, ist das cracken.

Die Performance ist auch etwas, was sich drüber streiten lässt.

 

Auf Rechnern von 30 Jahren merkt man vllt einen Unterschied in welcher Sprache ein Programm gecodet wurde.

Und wenn man nicht richtig programmieren kann, ist auch ein natives Programm wesentlich langsamer als eines, wo Frameworks gebraucht werden.

 

 

 

Das hier ist außerdem ein Verkaufsthread. und es hat hier nix zu verlieren!!!

Wenn jemand Crypter schlecht machen will, dann gibt es genug andere Foren, wo man den ganzen Tag posten darf.

Bearbeitet von n1nja, 17 January 2016 - 03:48 Uhr.

[rat123]

 

• Um vernünftige Rootkis zu coden, sollte man sowieso eher ASM verwenden. Critical Process sorgt beim Beenden für ein Bluescreen.
• Bei einem guten USG sind HEUR Dts nahezu unmöglich.
• Aber die Systeme die momentan hauptsächlich verwendet werden sind Win7-10. Wenn die entsprechende File auf .NET 4 compiled(bei unserem ProteC#tor einstellbar) ist, kann man sie auch ohne ein extra installiertes Framwork öffnen.
• Jede Sprache kann reversed werden, nur .NET einfacher. Wenn man aber Private Obfuscator und online Vars verwendet, welche nur geladen werden, wenn der User eingeloggt ist etc. ist es für die Meisten beinahe unmöglich, dass ensprechene Tool zu cracken.

LG

 

 

Critical Process - Du weisst glaube ich selber nicht was du genau machst. Du adjustest die privilege deiner Instanz, dafür muss dein caller SeDebugPrivilege eingeschaltet haben. Für SeDebugPrivilege brauchst du Administrationsrechte.

Mit NtSetInformationProcess setzt du deine Instanz in einen "kritischen Zustand". BSOD beim kill, richtig.

Trotzdem kannst du via NtSetInformationProcess die Instanz vom kritischen Zustand entfernen, ohne irgendwas killen zu müssen = kein bsod. 

 

Heuristik wird spätestens in der Laufzeit anfällig. RunPEs von 1990 zu benutzen hilft dir wirklich nicht weiter, moderne AntiViren Scanner protkollieren deine kompletten NT Calls...

 

"private obfuscator, online vars ... welche nur geladen werden wenn der user eingeloggt ist ... beinahre unmöglich"

Von .net reflection ist hier nicht die rede, man kann deine software trotzdem reversen und man kommt dahinter. Du willst es nur nicht wahr haben und schwörst auf deine online vars und private obfuscation. 

 

 

Die Hälte vo dem was hier rat123 geschrieben ist Schwachsinn.

 

Man kann sowohl mit .Net Sprachen einen Treiber, Rootkits coden.

Man muss nur wissen wie?!

 

Jede exen verwenden IL zum ausführen. Der große unterschied ist dabei das Framework wo dahinter steckt.

Man kann in C# sowohl auch Code schreiben, der genauso kein Framework braucht.

 

Der Crypter hat hier auch 2 unterschiedliche Arten von Execution.

Das einzige was hier letztendlich wirklich in C# gecodet wurde ist der Builder, und wem interessiert das?

 

Klar kann ich die GUI etc. alles in C++ coden, aber wozu, wenn MS das Framework zur Verfügung stellt.

 

Das einzige wo ich dir Recht gebe, ist das cracken.

Die Performance ist auch etwas, was sich drüber streiten lässt.

 

Auf Rechnern von 30 Jahren merkt man vllt einen Unterschied in welcher Sprache ein Programm gecodet wurde.

Und wenn man nicht richtig programmieren kann, ist auch ein natives Programm wesentlich langsamer als eines, wo Frameworks gebraucht werden.

 

 

 

Das hier ist außerdem ein Verkaufsthread. und es hat hier nix zu verlieren!!!

Wenn jemand Crypter schlecht machen will, dann gibt es genug andere Foren, wo man den ganzen Tag posten darf.

 

oh ja, treiber in C#

du kannst in der tat treiber ( windows services ) in .NET entwickeln, soweit ich weiss gibt es da sogar ne extra library für.

trotzdem ist der treiber unsigniert und für dse unbekannt. 

-Sie werden sich ohne weiteres nicht vollständig installieren lassen

-Detected

-Spätestens wird DSE den Treiber blockieren

Wie man DSE umgeht will ich jetzt nicht sagen, mit .NET wirst du es aufjedenfall nicht so einfach hinbekommen.

 

Ja, native dllimports, trotzdem brauchst du .NET Framework um die application zumindest in den entrypoint zu bringen

 

Builder in C#, was ist mit dem stub? 

 

 

 

 

Gut trotzdem, will den sale nicht stören

 

glws

[n1nja]

- BSOD braucht Admin, das is soweit richtig. Da ich aber einen richitgen funktionierenden UAC Bypass code, übrigens auch in C#, wird das in Zukunft auch mit Userrechten funktionieren.

Und klar das alles was auf eine Ebene passiert, auch von der Ebene wieder zurückgesetzt werden kann.

 

- Und ja man Treiber, Software in C# entwickeln, die kein .Net Framework benötigen.

Das Framework besteht auch nur aus Files, die es ermöglichen native Funktionen zu callen.

Wenn man weiß, wie man sowas umgehen kann, dann ist das auch möglich:)

 

- Dedections: Es ist meine Meinung egal, ob ein "File.Copy" in C# oder C++ dedected ist.

Ist jetzt nur ein Beispiel.

Aber meine C# Stub hat weniger dt Probleme als die C++.

Deswegen kann ich das auch nicht so behaupten.

 

- Insgesamt habe ich 2 Stubs gecodet. Und am wenigstens Probleme hab ich mit der .Net Stub.

Da ich schwer davon ausgehen kann, das du auch Ahnung hast. Muss ich nicht sagen, das man das beste Resultat erzielt, wenn man mehrere Sprachen kombiniert.

 

 

Wenn jemand mehr Infos möchte, kann er mich gerne kontaktieren.

Bearbeitet von n1nja, 17 January 2016 - 10:13 Uhr.