Werden Klassen-, Methoden- und Variablennamen nach dem Kompilieren eines Windows-App-Projekts in eine EXE-Datei in das MSIL einbezogen?
z.B. Also, wenn Methoden ÜBER ihren Namen aufgerufen WERDEN:
Ja, sie sind im IL - starte Reflector und du wirst sie sehen. Wenn sie nicht im IL gelandet wären, könntest du nicht gegen sie als Bibliotheken kompilieren. (Und ja, du kannst .exe-Dateien referenzieren, als wären sie Klassenzugriffe.)
Allerdings wird dies alles einmal in JIT aufgelöst.
Halte Namen lesbar, damit du den Code in Zukunft weiterhin pflegen kannst. Das Leistungsproblem wird wahrscheinlich keinen messbaren Unterschied machen, und wenn du deinen Code verschleiern möchtest, mache es nicht auf der Ebene des Quellcodes (wo du derjenige bist, der den Code liest) - verwende einen speziell entwickelten Obfuskator.
EDIT: Was inbegriffen ist - warum startest du nicht einfach Reflector oder ildasm und findest es heraus? Soweit ich mich erinnere, verlierst du die Namen von lokalen Variablen (die in der pdb-Datei vorhanden sind, wenn du sie erstellst), aber das ist auch schon alles. Private Methodennamen und private Variablennamen sind immer noch vorhanden.
JIT-Kompilierung?! Wird JavaScript nicht auf diese Weise ausgeführt? Ist das nicht der schlimmste Fall, weil alle Mitgliedsnamen dem Reverse Engineer zur Verfügung stehen?
Wenn Sie wirklich so überrascht sind, dass .NET JIT-Kompilierung verwendet, schlage ich vor, dass Sie mehr über .NET lesen, bevor Sie C# verwenden. Und ja, Sie können Code rückentwickeln - das können Sie in jeder Sprache (theoretisch) tun. Sie können auch Code verschleiern, sodass nicht jeder .NET-Code praktisch Open Source ist.
Die virtuelle Methodentabelle wird zunächst nur mit einem Zeiger auf den JIT-Compiler selbst gefüllt, bis die Laufzeit zum ersten Mal die Methode aufruft, dann findet der JIT-Compiler heraus, wo sich der Methodencode befindet, und ersetzt den Aufruf an JIT durch den Offset zum tatsächlichen Code. Dies könnte für jede Maschine unterschiedlich sein.
Mitgliedsnamen werden in die IL aufgenommen, unabhängig davon, ob sie privat oder öffentlich sind. Tatsächlich wird auch Ihr gesamter Code aufgenommen, und wenn Sie Reflector verwenden würden, könnten Sie praktisch den gesamten Quellcode der Anwendung lesen. Übrig bleibt das Debuggen der App, und ich denke, es könnte Tools dafür geben.
Sie müssen ABSOLUT(ob ich es noch mehr betonen kann) Ihren Code obfuskieren, wenn Sie Anwendungen erstellen, die eine Vielzahl von Kunden und Wettbewerbern haben. Glücklicherweise stehen eine Reihe von Obfuskatoren zur Verfügung.
Dies ist ein großes Ärgernis, das ich mit .Net habe. Da MS so hart daran arbeitet, warum nicht einen professionellen Obfuskator entwickeln (oder erwerben) und diesen zu einem Bestandteil von VS machen. Dotfuscator reicht einfach nicht aus, nicht die Version, die sie für die Community haben.
Identifizieren Sie zuerst Ihr Bedrohungsmodell: Was erwarten Sie, dass Menschen mit nicht verborgenem Code tun, den Sie nicht möchten? Es ist zwar schön zu glauben, dass Sie einen super tollen Code haben, den jeder umdrehen möchte, aber praktisch macht das fast niemand. Wenn Sie das tun, sollten Sie es nicht an Ihre Kunden senden.
- Namen kurz halten, bessere Leistung für benannte Abfragen.
Wie könnte das einen Unterschied machen? Ich bin mir nicht sicher, wie Bezeichner vom VM abgerufen werden, aber ich bin ziemlich sicher, dass es keine einfache Zeichenfolgenvergleichsabfrage ist. Dies wäre der schlimmste Weg, dies zu tun.
- Namen kryptisch halten, schwerer zu dekompilieren.
Um ehrlich zu sein, glaube ich nicht, dass Code-Verschleierung so sehr hilft. Die meisten kompetenten Entwickler haben bereits einen "sechsten Sinn" entwickelt, um Dinge schnell herauszufinden, auch wenn Bezeichner wie Methodennamen völlig unzureichend sind, da sehr oft der Quellcode, den sie pflegen oder verbessern müssen, bereits diese Probleme hat (ich spreche von Methodennamen wie "DoAllStuff()").
Wie auch immer, Sicherheit durch Obskurität ist in der Regel keine gute Idee.
Mit .NET Reflector könnte jedes erste Jahr Informatikstudent Ihren Code herausfinden. Nicht zu verwirren ist äquivalent dazu, Ihre App als Open Source zu veröffentlichen. Open Source ist für viele kommerzielle Apps nicht praktisch. Entweder verwirren Sie den Code oder gehen den zusätzlichen halben Schritt und machen Ihre App Open Source.
Mhenry1384: Egal, wie Sie Ihr ausführbares Programm verschlüsseln, ein kompetenter Programmierer könnte es leicht herausfinden. Sie können Ihren Code zur Laufzeit generieren, was die Hürde ein wenig erhöhen würde, aber nicht viel. Genauso wie die meisten kopiergeschützten Spiele bereits wenige Tage nach Veröffentlichung geknackt werden.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
