Großes Projekt: C++ oder C#?
Hallo,
in der Firma arbeiten wir mit C#. Ich selber arbeite auch viel mit C#, wobei mir aber C++ auch nicht Fremd ist. Ich überlege ein großes Projekt zu starten, dass wenn es gut wird, auch "verkauft" werden soll. Aber nun stellt sich mir die Frage:
Dekompilieren macht es gefährlich. Möchte man C++ Anwendungen dekompilieren, so erhält man nichts klar lesbares. Klar, wer sich auskennt, der kann damit umgehen, aber man kommt auf den Nativen C++ Code nicht 1 zu 1 zurück. In C# hingegen bekommt man, selbst mit Obfuscating , 100% den originalen Sourcecode zurück. Das bedeutet jeder könnte das Programm dekompilieren und selber verbreiten als sein eigenes, da er dann die source hat. Das solche Programme gecrackt werden, das ist normal und mir auch ziemlich egal. Mein Anliegen ist nur, dass man ja die originale source bekommt und somit das ganze klauen kann.
Wie seht ihr das? Eignet sich C# wirklich für große Software Projekte, die man möglicherweise auch verkaufen kann? Oder doch lieber C++ dafür benutzen, damit der Code einfach besser abgesichert ist und nicht so leicht geklaut werden kann?
Ich hoffe mein Gedankengang ist soweit verständlich, ansonsten nochmal nachfragen
4 Antworten
In C# hingegen bekommt man, selbst mit Obfuscating , 100% den originalen Sourcecode zurück.
Das stimmt nicht.
Man bekommt nie den Original-Code zurück, viele Variablen verlieren ihre Namen, viel Struktur wird umgeformt und viele Features basieren einzig auf dem Umbau, den der Compiler leistet.
Generierter Code kann meistens gar nicht genutzt werden, da er Zeichen enthält, die C# nicht unterstützt. Das ist Absicht, damit es keine Namenskonflikte gibt.
Es gibt auch Fälle (z.B. bei Lambda-Expressions), bei denen OP-Codes genutzt werden, die nicht nach C# zurück-übersetzt werden können.
Das alles kann man manuell korrigieren und jemand, der sich auskennt, wird auch keine großen Schwierigkeiten haben, aber der Original-Code ist's definitiv nicht mehr.
Und Obfuscation kann durchaus viel bringen, der Code ist danach zwar nutzbar, nur Verstehen wird schwer. Aber was stört dich daran, dass man den Code ausführbar machen kann? Das größere Problem ist, wenn z.B. für die Lizenz relevante Inhalte verändert werden können und dagegen kann man etwas tun.
Außerdem zeigt die Erfahrung, dass das die meisten nicht tun. Die, die es tun wollen, schaffen das auch so und die Vorkehrungen sind am Ende teurer als der potentielle Verlust.
Eignet sich C# wirklich für große Software Projekte, die man möglicherweise auch verkaufen kann?
Definitiv C#, hauptsächlich weil es einfacher und besser wartbar ist.
C++ wird dann interessant, wenn man die spezifischen Vorteile braucht.
Wenn man die C++-Vorteile nur in kleinem Umfang (z.B. ein Gerät steuern) braucht, kann man das auch in C++ entwickeln und die Hauptanwendung, die in C# entwickelt wurde, ruft nutzt die C++-DLL.
Wenn Du unbedingt auf Nummer Sicher gehen willst/musst, dann kannst Du dir bei C# auch die native Kompilierung anschauen, die bringt aber auch einige Einschränkungen mit sich.
PS:
Noch ein sehr elementarer Faktor: Erfahrung.
Ein erfahrener C#-Entwickler mit weniger C++-Erfahrung sollte möglichst mit C# arbeiten - und umgekehrt. Beide Sprachen sind extrem verschieden und auch wenn C# einfacher ist, sollte man es nicht unterschätzen.
Heißt jetzt ReadyToRun
Nutzen solltest Du es aber nicht.
Ich habe es nie genutzt, aber es kann sein, dass die native Variante sogar langsamer läuft, außerdem gibt es garantiert einige Einschränkungen und Fallstricke mehr.
Abgesehen davon ist das einfach nur unnötig, das zu nutzen, nur um den Code schwerer lesbar zu machen.
Aber wenn Du willst, probier's aus, aber informiere dich vorher ausführlich über die Nachteile.
Ich habe mal ein wenig dazu gelesen und es mal ausprobiert. Statt einer Exe kommt mit ReadyToRun eine exe und eine DLL raus. Die DLL beinhaltet nach dem decompilen mit einem einfach C# decompiler alles wie vorher. Ich habe ja gelesen, das nicht alles compiliert werden kann für Ready To Run, aber selbst der Standard krams ist immer noch der selbe 🤔Es kommt mir so vor, als wurde einfach nur alles von exe zu dll ausgelagert und das war's. Also ist das komplett Sinnlos und kein bisschen nativ?
Es gibt auch ohne ReadyToRun eine exe und eine dll. Die Windows-spezifische Exe ruft nur die dll auf, bei Linux wäre es dann Linux-spezifisch.
Und ReadyToRun ist ein AheadOfTime-Compiler, der erzeugt keinen reinen nativen Code, sondern macht das, was der JustInTIme-Compiler zur Laufzeit macht, schon vorher.
Außerdem ist es noch relativ neu, kann also sein, dass es noch nicht fertig ist.
Eine tatsächlich vollständige native Kompilierung wird aber sowieso nie funktionieren und war auch nie das Ziel.
PS:
Ahhhh, ok, danke. Dann habe ich das ein wenig falsch eingeordnet. Gut zu wissen
Sehr gute Antwort aber zum Thema Obfuscator noch eine Anmerkung:
Niemand wird ein ganzes obfusciertes Programm lesen wollen, sondern nur lesen wollen, wie DIE eine kurze Funktion arbeitet, die magische Dinge tut.
Und bei so kurzen Codeabschnitten sind Variablennamen und Lambdas egal. Da sitzt man dann eben mal einen Nachmittag an einer 20 Zeilenfunktion, um die Cashcow der Konkurrenz zu reversen.
Zweiter Use-Case: Kopierschutz bzw. Lizenzprüfung. Da ist mir die Obfuscation auch total egal, weil mich nur die eine einzige Instruktion NACH dem Aufruf besagter Funktion interessiert, vor der ich nur irgend ein Flag flippen muss.
Leute die Obfuscatoren nutzen, denken immer, dass jemand das ganze Programm lesen will. Das will aber niemand. Es geht nur darum, meist eine Hand voll Codezeilen verstehen bzw. manipulieren zu können. Mehr nicht. Und davor schützt auch kein Obfuscator! :)
Leute die Obfuscatoren nutzen, denken immer, dass jemand das ganze Programm lesen will.
Leute die Obfuscatoren nutzen, denken immer, dass man nur diesen einen Codeabschnitt lesen und bearbeiten muss ;)
Bevor Du irgendetwas tun kannst, muss Du diesen Codeabschnitt überhaupt erst finden und das ist der entscheidende Punkt, den man sehr schwer machen kann.
Z.B. kann man dafür sorgen, dass es nicht nur den einen Codeabschnitt gibt, sondern viele Codeabschnitte. Du könntest auch dafür sorgen, dass diese vielen Codeabschnitte nicht als Methode aufgerufen, sondern jedes mal als Ganzes kopiert werden. Oder man macht's ganz wild und verändert beim Start vor der Ausführung relevanter Code-Stellen eben diese Code-Stellen im RAM, sodass Du so viel dekompilieren kannst, wie Du willst, Du wirst nie den Code finden, der am Ende tatsächlich ausgeführt wird.
Es gibt viele Wege, das Finden von Code sehr schwer zu machen.
Und man kann .NET-DLLs auch vor Veränderungen schützen, indem man sie signiert. Das macht es zwar auch nicht unmöglich, sie zu ändern, aber zumindest noch aufwändiger, als ohne Signatur und genau das ist ja das Ziel.
Ich hab auch mal eine .NET-DLL komplett ohne Member-Namen (öffentliche Member ausgeschlossen) gesehen. Keine Ahnung, was da gemacht wurde, aber ILSpy und der .NET Reflector haben beide keine Namen ausgespuckt. Dürfte ziemlich schwer sein, da irgendetwas zu finden, besonders wenn noch massig random Code dazwischen hängt, der nur ablenken soll.
Also bei C++ Programmen und Bibliotheken gibt es grundsätzlich keine Symbole, die nicht für ein API exportiert wurden, und die Aufruf und Einsprungpunkte einer Funktion zu finden ist trivial.
Funktionen in Mehrfachausführung sind ebenfalls olle Kamellen und jedes Reversingtool hat Skripte dafür.
Ich nutze gerne radare2 und sich damit einen statischen Aufrufbaum genieren zu lassen geht, indem man vier mal hinter einander ein "a" eingibt: "aaaa"
Das ist alles. Und damit sind alle Punkte erschlagen, die du oben genannt hast. Eben weil es seit Jahrzehnten alle Entwickler in allen Sprachen überall auf der Welt genau so machen. Das ist so ziemlich das erste, was jeder Disassembler bzw. Debugger als erstes automatisiert skriptgesteuert tut.
Bei MSIL-Code ist das ganze sogar noch einfacher.
Im Schnitt brauche ich - bei sehr großen Spielen mit Kopierschutz - keine 5 Minuten um die Funktionen zu lokalisieren, die für die Lizenzprüfung zuständig sind. Das meiste davon pauschal automatisiert, der Rest trivial beim durchsteppen des Calltrees.
Es ist wirklich sehr sehr einfach, ohne anfängliche Anhaltspunkte, Ausführungsabschnitte in Maschinencode zu finden. Ob da vorher obfusciert wurde, oder nicht, bemerke ich oft gar nicht, weil es mich gar nicht interessiert und auch völlig irrelevant ist.
Im Gegenteil, wenn irgendwo eine Funktion "checkLicense" als Symbol exportiert wird, dann ist mein erster Gedanke: Honeypot. Denn so blöd ist kein Entwickler! :)
Wie gesagt, ich reverse fast nur nativen Code. Aber meine bisherigen Erfahrungen mit Werkzeugen für MSIL waren immer seeeehr komfortabel, verglichen mit dem, was ich von IDA & Co kenne, und die nehmen einem wirklich schon 99% der gesamten Arbeit ab! :)
Naja, so eng würde ich das nicht sehen. Und die Crackbarkeit sollte auch nicht die Hauptentscheidung für neue Projekte sein.
Bei C# legst du dich eben auf Windows fest, bei C++ kannst du verglichen damit trivial leicht deine Projekte auf andere Plattformen portieren.
Und zum Reversing: Ja, MSIL-Code liest sich flüssig und schnell, auch wenn man den gar nicht zu C# zurück wurschtelt.
C# Software zu knacken ist in der Tat trivial und Obfuscation ist ein schlechter Witz, der nicht mal Skriptkiddies aufhält.
Bei C++ werden hingegen teilweise mehere Seiten Quelltext in eine einzige Konstante oder eine einzige CPU-Instruktion eingedampft. Man muss sich also richtig intensiv mit der Software befassen, und zu erkennen, wie sie was wo wann tut.
Von Kopierschutzmechanismen würde ich immer abraten. Damit verärgert man nur ehrliche Kunden. Im Grunde sind alle trivial zu cracken.
Wir haben früher auf dem Gynmansium mal für eine TheMida-Lizenz zusammen gelegt, eigene Programme damit "kopiergeschützt" und dann gewettet wer wie lange zum Reversing braucht. :)
Ich weiß gar nicht, ob es TheMida, Armadillo, usw. noch gibt ... aber die haben auf ihren Websites immer einen totalen Stuss versprochen, genauso wie die ganzen Antivirenhersteller.
Und am Ende war es enttäuschend einfach zu knacken.
Von daher: Wer deine Software cracken und den Kopierschutz entfernen will, der schafft das auch. Und das gilt auch für interessierte 13jährige. Da kannst du leider nichts gegen machen.
Achte lieber auf eine hohe Testabdeckung, gute QS, und defensive Programmierung. Das ist alles viel viel wichtiger, als irgendwelche Cracker im Hinterkopf zu haben! :)
Bei C# legst du dich eben auf Windows fest
Also DIE Zeiten sind schon lange vorbei ;)
Selbs das offizielle .NET 5 SDK unterstützt alle gängigen Desktop Betriebssysteme. Dann gibt es noch offizielle Laufzeitumgebungen für Android, iOS, Tizen und WASM. Zusätzlich gibt es noch Projekte wie das nanoFramework, welches sogar verschiedenste eingebettete Systeme unterstützt.
Auch wenn C# seine Wurzeln bei Windows hat, ist es schon lange nicht mehr wahr dass daran gebunden gebunden ist.
Alles Marketing. In der Praxis làuft das Ganze so instabil und fehlerhaft, dass es nur für Proof-Of-Concepts reicht.
Mit der gleichen Logik könnte man behaupten, dass große Lazarus-Projekte keine Probleme machen, dass man mit Java oder C# Mikrocontroller programmieren kann, oder Spiele in Python möglich sind.
Ja, geht alles ... Auf Frickelniveau. Für wirklich ernsthafte, auf Dauer angelegte, Projekte taugt das alles nichts!
Alles Marketing. In der Praxis làuft das Ganze so instabil und fehlerhaft, dass es nur für Proof-Of-Concepts reicht.
Das ist sehr verallgemeinert! Bei C# für Mikrocontroller bin auch auch sehr skeptisch was Stabilität und langfristigen Support angeht. Bei z.B. ASP.NET für Linux sieht es allerdings ganz anders aus.
Die Bereitstellung von Linux-Containern für ASP.NET ist mittlerweile ein Kennerschaft von Microsoft. Solltest du dir mal die Github-Projekte dazu anschauen, wirst du merken wie viele Ressourcen seit Jahren in deren Planung, Entwicklung und Qualitätskontrolle gesteckt wird.
Bei Xamarin sieht es ähnlich aus. Es es ist schon seit Jahren eine etablierte Plattform für mobile Applikationen die ihren Alternativen in nichts nachsteht.
Klauen und Cracken kann man es egal welche Sprache du nutzt. Das ist absolut kein Entscheidungskriterium.
Schau die lieber an wer die Sprachen wie gut kann und ob ihr z.B. Cross-Platform bauen wollt. Vielleicht braucht ihr auch das letzte Fünkchen Performance und habt dafür auch Experten?
Dann merkst du schnell was die bessere Sprache ist.
Naja, das Projekt ist für mich angesetzt, also Privat. Da gibt es leider kein "wir". C# kann ich sehr gut. Aktuell mache ich eine Ausbildung, wo ich C# können muss. C++ habe ich hier und da nur Privat mal verwendet (auch mit UI). Nur wenn das Projekt wirklich gut wird und ich davon überzeugt bin, dann wäre das irgendwann zukünftig eine Möglichkeit Geld damit zu verdienen. Also an C++ Code zu kommen ist mir neu. Bei C# sind es 2 Klicks mit dem richtigen Programm. Bei C++ kommt eher Assembler Code heraus oder halt nach Konvertierung irgendein Möchtegern C++ code. Das ist, was ich dazu weiß
Na und? Das entkräftet nicht meinen Punkt. Klar bei C++ bekommst du keinen schönen Code raus, bei C# aber auch nicht.
Und das ist auch völlig an der Realität vorbei was du die ganze Zeit erzählst. Wenn du C# sehr gut kannst, C++ aber nur so mittelmäßig dann ist C# offensichtlich die 1000 Mal bessere Wahl.
.NET Framework 4.x ist tot, die Wahl sollte als keine Wahl sein.
und ob ihr z.B. Cross-Platform bauen wollt.
Ist schon lange kein Kriterium mehr.
Solange man eines der großen Betriebssysteme hat, läuft auch .NET
Hatte auch schon über ähnliches Gedanken gemacht.
Ein Projekt mit C# WPF.
Da war auch die Problematik das wenn man das dann ausliefert ob nicht einer das Dekompiliert und es dann anderweitig Verbreitet.
Das beste wäre es in dem Falle statt auf WPF zu Entwickeln es als ASP laufen zu lassen und es statt auf ein Windows PC laufen lassen es als Webseite anzubieten.
Da die eigentliche "Arbeit" irgendwo auf dem Server/Verteilte API´s läuft kann man auch kein Code klauen (Hacks natürlich ausgeschlossen).
Gibt es natives C# nicht nur bei UWP Anwendungen? Ich habe jedenfalls etwas in die Richtung gelesen