C# einzelne Funktion "fertig kompilieren" und nicht in IL-Code wandeln?

second.name

Lieutenant
🎅Rätsel-Elite ’24
Registriert
Sep. 2009
Beiträge
723
Hallo Forum,

besteht die Möglichkeit, beim kompilieren eines Projektes eine einzelne Funktion zu nativem Maschinencode zu kompilieren und die Generierung des IL-Codes somit einzeln/funktionsweise abzuschalten?
 
Hallo vbuser09,

prinzipiell: Nein.

Das was Du eigentlich wirklich suchst, findest Du aber unter 'Obfuscation'. :-)

Grüße
Thorsten
 
Hallo vbuser09,

prinzipiell: Ja.

Das was Du suchst, findest Du unter P/Invoke :-)

Grüße
F_GXdx
 
Danke Leute!

Aber ein Problem: Wo finde ich zu beide brauchbares Material?
 
Hallo,

P/Invoke / Marshalling ist dafür da, nativen Code zu nutzen, so zum Beispiel API-Funktionen zu importieren. Nicht aber um .Net-Code in ASM und nicht in IL zu übersetzen.

Grüße
Thorsten
Ergänzung ()

@vbuser09: Einfach mal .Net Obfuscation in die Suchmaschine Deiner Wahl tippen. Da wirst Du genug Beiträge und Informationsmaterial finden.
 
mach doch deine einzelnen Funkionen mit C++ und erstell dir ne dll die du dann in C# nutzt
 
@SheldonCooper:

Die Frage ist, warum sollte man das tun?

Ich finde nur eine Antwort - um seinen Code zu schützen. Auch C++-Kompilate kann man einen reverse engineering unterziehen. Natürlich ist das bei MSIL wesentlich leichter. Jedoch genau für diesen Zweck gibt es Obfuscation, die richtig eingesetzt taugt auch.

Man könnte sogar noch weiter gehen und die eigene Anwendung nur als Launcher sehen, die die Programmteile (Assemblies) aus einem Assemblybag holt, wo sie verschlüsselt abgelegt sind. Schon wäre die Hürde noch einmal höher um an den Programmcode zu kommen.

100%igen Schutz gibt es aber sicherlich nie.

Grüße
Thorsten
 
Ich verstehe dich einfach nicht, DrTopo. Meinen Ansatz hat ja SheldonCooper dankenswerter Weise schon weiter ausgeführt. So geht es nämlich auch.

edit: hier stand Käse
 
Zuletzt bearbeitet:
Nein, obfuscated wird nicht der ursprüngliche C#-Code, sondern der MSIL-Code. Einfach mal die Suchmaschine seiner Wahl nach .Net Obfuscation suchen lassen.

Einem Obfuscator wirfst Du eine Assembly vor, mit dem ursprünglichen Quellcode macht ein Obfuscator gar nichts. Übrigens arbeitet auch so der mit VS gelieferte Obfuscator. (Extras -> Dotfuscator Software Services)

Sicherlich nicht der beste, aber um zu sehen wie sowas arbeitet, sollte es ausreichen.
 
Hab es soeben mit Dotfuscator ausprobiert und es funktioniert wunderbar! Doch wie sicher ist das jetzt wirklich?
...Mal gesponnen: Ich würde ein Passwort in die EXE "hardcoden", wie schwer wäre es, dieses einzusehen?
 
vbuser09: Passwörter gehören nicht in Programmcode. Die gehören nicht einmal in einen normalen string zur Laufzeit - dafür gibt es System.Security.SecureString.

Wenn Du ein Passwort im Programmcode ablegen musst, so musst Du Dich mit zwei Dingen konfrontiert sehen:

1. Dein Design ist schlecht. Software ist so zu designen, dass man keine Passwörter in der Anwendung selbst abzulegen hat.
2. Falls dies doch - aus irgendwelchen Gründen - notwendig sein sollte, sind die Passwörter verschlüsselt abzulegen.

Zu Punkt 2 wirst Du auch ausreichende Informationen finden. Ein Hinweis wäre zum Beispiel das Passwort in die app.config zu setzen und die ganze app.config zu verschlüsseln, oder eben nur das jeweilige Setting. Auch dafür bietet das .Net-Framework erprobte Funktionalitäten.

Wie gesagt - 100%ig sicher ist nichts. Der Dotfuscator zählt auch zu den schlechteren Vertretern seiner Gattung...

Grüße
Thorsten
 
DrTopo schrieb:
Die Frage ist, warum sollte man das tun?

Für mich war aus der Fragestellung nicht ersichtlich, dass es um das Absichern des Codes vor RE ging. Ich hab einfach nur darauf geantwortet ob die Möglichkeit besteht "beim kompilieren eines Projektes eine einzelne Funktion zu nativem Maschinencode zu kompilieren und die Generierung des IL-Codes somit einzeln/funktionsweise abzuschalten". In VS kann man in einem Projekt verschieden Sprachen kombinieren und C++ wird "fertig kompiliert", somit war meine Antwort auf die Frage (so wie ich sie verstanden hab) korrekt. Wenn es um zeitkritische Funktionen geht kann es unter Umständen sogar sinnvoll sein so vorzugehen.
 
Hallo!

Es ist 'normal', dass Fragesteller, die sich nur oberflächlich mit einer Thematik auskennen, Fragen stellen, die genau genommen an dem eigentlichen Problem vorbeigehen. Gerade bei Fragen die Entwicklung von Software betreffend.

Es lohnt immer nachzufragen und zu überlegen, ob die Beantwortung der so gestellten Frage überhaupt Sinn macht. Auch Kunden wollen oft was ganz anderes als sie eigentlich anfragen. Dies ist auch dort erst einmal zu klären und zu erarbeiten.

Ein Gefühl dafür kommt mit der entsprechenden Erfahrung.

Wenn es um zeitkritische Funktionen geht, macht die Auslagerung in eine C++-DLL auch keinen Sinn. Die Optimierungen, die der JIT-Compiler vornehmen kann, übertreffen meist die Optimierungen, die der C++-Compiler vornehmen kann. Hier gibt es genügend Performancevergleiche - mal 'gewinnt' das C++-Kompilat, mal die MSIL-Assembly.

Wenn man weiß worum man besser einen Bogen macht, kann man es mit .Net-Code performancetechnisch absolut mit C++-Code aufnehmen. Ist zeitkritisch so gedacht, dass binnen einer gewissen Zeit eine Antwort garantiert werden muss, so scheidet Windows als Betriebssystem ohnehin aus. Die Voraussetzungen hier für eine solche Verarbeitung mit garantierten Laufzeiten sind nicht gegeben.

Grüße
Thorsten
 
Ich habe Kunden schon oft gegeben, was sie wollten, obwohl ich wusste, dass sie eigentlich was anderes bräuchten. Ich find das lustig :D Das liegt vor allem an 2 Sachen, weil nämlich

1) Die meisten sehr selbstsicher auftreten, wenn sie detailiert das Falsche bestellen
2) Es sichert zukünftige Aufträge, wenn man nicht sofort das Richtige liefert :D
 
Ich halte dieses von Dir geschilderte Geschäftsgebahren, F_GXdx, für sehr kurzsichtig.

Meine Kunden berate ich vernünftig, sie bekommen das was sie brauchen und manchmal stellen sie sogar fest, dass sie schon alles haben, was sie sich wünschen. Dafür kommen sie immer wieder auf mich zurück und empfehlen mich auch weiter.

Dementsprechend ist auch das Vertrauen in mich für größere Aufträge, die normalerweise nur sehr viel größere Firmen erteilt bekommen, gegeben.

Leben und leben lassen, dann kommen alle miteinander klar. Sobald ich mich geschäftlich so verhalte, dass mein Erfolg zum Nachteil meiner Kunden ist, grabe ich mir selbst früher oder später das Wasser ab. Das ist leider etwas, was noch nicht alle verstanden haben.
 
War auch etwas übertrieben, aber die Kernaussage ist eben: Es gibt Leute, die müssen unbedingt ihren Kopf durchsetzen, warum soll ich sie davon abhalten? Wenn er 100 Mal gegen die Wand gelaufen ist, wird sogar dieser Typ Mensch "MANCHMAL" nachdenklich über sein Verhalten.

Bin mir mittlerweile sicher, dass das Dunning-Kruger Syndrom eine Management Schlüsselkompetenz ist.
 
Zurück
Oben