VS2005 C# DLL in Exe integrieren
- Ersteller Devastators
- Erstellt am
Devastators
Grand Admiral Special
Gibt es eine Möglichkeit eigene DLLs in die kompilierte Exe zu integrieren?
Grund:
.Net Assemblys lassen sich ja vollkommen Problemlos in jedem Projekt nutzen.
Wo man bei C einst noch die Lib benötigte sind seit .NET die Assemblies vollkommen autonom.
Ich will also verhindern, dass ein Kunde oder sonstwer einfach meine DLLs nimmt und bei sich integriert und weiter nutzen kann. (geht ja leider vollkommen Problemlos)
Da ich (und Kollegen) die DLLs in mehreren Projekten nutze, will ich den Quellcode auch nicht einfach als Projekt einbinden, oder macht das am meißten Sinn?
Kollegen wiederrum sollen nicht einfach das Projekt ändern können.
Ich möchte also konkret einem Kollegen die DLL geben. Das Projekt was er daraus erstellt darf diese DLL aber nicht mehr sichtbar enthalten.
Geht das irgendwie oder habe ich etwas total übersehen?
Ein weiteres Problem ist auch der Quellcodeschutz vor einer Dekompilierung.
Da scheint sich Microsoft ja scheinbar gar keine Gedanken drum gemacht zu haben
CIL-Code läßt sich ziemlich einfach nahezu 1:1 dekompilieren 
Der mitgelieferte Dotfuscator ist auch nicht das gelbe vom Ei...
Grund:
.Net Assemblys lassen sich ja vollkommen Problemlos in jedem Projekt nutzen.
Wo man bei C einst noch die Lib benötigte sind seit .NET die Assemblies vollkommen autonom.
Ich will also verhindern, dass ein Kunde oder sonstwer einfach meine DLLs nimmt und bei sich integriert und weiter nutzen kann. (geht ja leider vollkommen Problemlos)
Da ich (und Kollegen) die DLLs in mehreren Projekten nutze, will ich den Quellcode auch nicht einfach als Projekt einbinden, oder macht das am meißten Sinn?
Kollegen wiederrum sollen nicht einfach das Projekt ändern können.
Ich möchte also konkret einem Kollegen die DLL geben. Das Projekt was er daraus erstellt darf diese DLL aber nicht mehr sichtbar enthalten.
Geht das irgendwie oder habe ich etwas total übersehen?
Ein weiteres Problem ist auch der Quellcodeschutz vor einer Dekompilierung.
Da scheint sich Microsoft ja scheinbar gar keine Gedanken drum gemacht zu haben
CIL-Code läßt sich ziemlich einfach nahezu 1:1 dekompilieren Der mitgelieferte Dotfuscator ist auch nicht das gelbe vom Ei...
BoMbY
Grand Admiral Special
Also ich hab mal ein bisschen für Dich gegooglet und folgendes gefunden: http://msdn.microsoft.com/en-us/library/0tke9fxk(v=VS.80).aspx
Vielleicht hilft Dir das weiter?
Vielleicht hilft Dir das weiter?
Devastators
Grand Admiral Special
soweit ich das verstanden habe leider nicht wirklich.
Das gesamte (durch 'internal' "geschützte") Assembly muss dennoch dem Kunden mitgegeben werden.
Ich denke das läßt sich problemlos umgehen
und sowieso "decompilieren"
hier übrigens die "Stellungsnahme" von Microsoft..
http://msdn.microsoft.com/de-de/library/bb979397.aspx
Das gesamte (durch 'internal' "geschützte") Assembly muss dennoch dem Kunden mitgegeben werden.
Ich denke das läßt sich problemlos umgehen
und sowieso "decompilieren"hier übrigens die "Stellungsnahme" von Microsoft..
http://msdn.microsoft.com/de-de/library/bb979397.aspx
yourgreatestfear
Grand Admiral Special
.Net-DLL gegen freie Weiternutzung schützen geht heilwegs gut mit delayed signing, onlineAuthentifizierung(soweit zumutbar) und guten Anwälten.
.Net-DLL gegen Reengineering schützen ist in meinen Augen unmöglich. Dafür hat MS selbst viel zu mächtige Features eingeführt in die .Net-Technologie und auf die ist man sehr stolz in dem Verein. Selbst während der Codeausführung kann ich noch frei eingreifen und dabei interessier mich Tricks bei der Codegestaltung wenig. Konstrukte wie signed AppDomains, Assemblies, Typabgrenzungen etc. dienen der Laufzeitstabilität, Programmintegrität und Modularität. Dies dazu einzusetzen den Code zu schützen ist fast schon Zeitverschwendung. Dotfuscator hilft in dem Moment auch nicht mehr und es wurden schon ein halbe Dutzend netter Tools entwickelt um während der Laufzeit .Net-Anwendungen zu überwachen, ändern und umzuleiten.
Entweder Deine Anwendung ist billig genug um durch die empfohlenen Tricks ein Reengineering unrentabel zu machen oder man nimmt die guten alten Sprachen mit dem ein Reengineering eine fast unbezahlbare Qual ist (unmöglich ists bei keiner Sprache).
.Net-DLL gegen Reengineering schützen ist in meinen Augen unmöglich. Dafür hat MS selbst viel zu mächtige Features eingeführt in die .Net-Technologie und auf die ist man sehr stolz in dem Verein. Selbst während der Codeausführung kann ich noch frei eingreifen und dabei interessier mich Tricks bei der Codegestaltung wenig. Konstrukte wie signed AppDomains, Assemblies, Typabgrenzungen etc. dienen der Laufzeitstabilität, Programmintegrität und Modularität. Dies dazu einzusetzen den Code zu schützen ist fast schon Zeitverschwendung. Dotfuscator hilft in dem Moment auch nicht mehr und es wurden schon ein halbe Dutzend netter Tools entwickelt um während der Laufzeit .Net-Anwendungen zu überwachen, ändern und umzuleiten.
Entweder Deine Anwendung ist billig genug um durch die empfohlenen Tricks ein Reengineering unrentabel zu machen oder man nimmt die guten alten Sprachen mit dem ein Reengineering eine fast unbezahlbare Qual ist (unmöglich ists bei keiner Sprache).
Devastators
Grand Admiral Special
Das ist leider auch mein letzter Kenntnisstand
Billig kann man unsere Anwendungen nicht nennen (teils oberer 5 Stelliger Bereich) aber das Problem steckt mehr im KnowHow was wir dadurch verlieren könnten.
Kollegen beschäftigen sich mit Verschlüssellungstechniken (zur Laufzeit) diverser Anbieter, aber ich stehe solch einem dritten im Bunde i.A. sehr skeptisch gegenüber.
Mir würde es schon reichen, wenn meine DLLs(die sich leider auch sehr oft ändern) nicht ungefragt benutzt werden können.
Einfachste Möglichkeit wäre es doch den ganzen Quellcode einfach ins eigene Projekt zu kopieren und dort "erneut" zu kompilieren..., dies jedoch vollautomatisch und mit Schreibschutz der Quelle.
Echt erstaunlich wie gerade Microsoft aus jedem .Net Programm ein OpenSource Projekt erzwingt
yourgreatestfear
Grand Admiral Special
...
Einfachste Möglichkeit wäre es doch den ganzen Quellcode einfach ins eigene Projekt zu kopieren und dort "erneut" zu kompilieren..., dies jedoch vollautomatisch und mit Schreibschutz der Quelle.
Echt erstaunlich wie gerade Microsoft aus jedem .Net Programm ein OpenSource Projekt erzwingt
Dank den tollen Reflections, der CIL und allem was damit erreichbar ist macht es für mich keinen Unterschied ob ich nun die Exe der Hostanwendung oder einzelne DLL unter die Lupe nehme. .Net ist unter der Prämisse entstanden RAD zu ermöglichen und jeden billigen Softwareassistenten/praktikanten zum vollwertigen Entwickler zu machen. Die einzigen wirklich funktionierenden Schutzmechanismen sind verschlüsselte Onlineauthentifizierungen.
Als kleiner freier Entwickler in einem TEAMprojekt, oder kleine Firma für ein Großprojekt muss das Entgeld für dieses eine Projekt eventuell offenbartes KnowHow mit abgelten. Alles andere hält nur Doofe ab.
BoMbY
Grand Admiral Special
Genau dafür sind doch die Friend-Assemblies. Mit Signierung sollte da nicht mehr viel möglich sein. Du deklarierst einfach die wichtigen Klassen als Private, und nur die Applikation vom Kollegen kann darauf zugreifen.
yourgreatestfear
Grand Admiral Special
Merkt man, dass Dein Wissen nur von Googel stammt.
Assemblykeys, StrongNameIdentityPermission, delayed signing, AppDomain-Security -> Codetrust, unter anderem für Absicherung gegen Weiterverwendung
friend assembly -> reine Usabilityerweiterung und nur selten notwendig bei klaren Schnittstellen. Gut für RAD und Freizeitproggern, aber genaugenommen würd ich davon sogar abraten, weil es zu unsauberen Code führt und keine Notwendigkeit bei der Absicherung ist.
Assemblykeys, StrongNameIdentityPermission, delayed signing, AppDomain-Security -> Codetrust, unter anderem für Absicherung gegen Weiterverwendung
friend assembly -> reine Usabilityerweiterung und nur selten notwendig bei klaren Schnittstellen. Gut für RAD und Freizeitproggern, aber genaugenommen würd ich davon sogar abraten, weil es zu unsauberen Code führt und keine Notwendigkeit bei der Absicherung ist.
Ich kann mich dem hier nur anschließen...
Selsbt das universal-Tool "Dotnet reflector" kann den IL-Code dekompilieren udn bringt den sourcecode fast haargenau zurück... nutze ich des öfteren um das API "zu erkunden" bei neuen DLLs.
Wobei Opensource in der Hinscht ein Kalauer ist... Opensource bedeutet nämlich entgegen des Namens, nicht nur die freie zugänglichkeit des Quellcodes, sondern vielmehr die Lizenz (erlaubnis) diesen zu benutzen, zu modifizieren und weiterzuentwickeln. Und davor "schützen" größtenteils die EULAs.
Was .Net definitiv mitbringt sind offene, transparente Schnittstellen... wäre die Win-API derart übersichtlich wäre das WINE Projekt schon seit 5 Jahren mit der Arbeit fertig...
MS ist wohl auf dem Standpunkt "KnowHow schützt man durch Patente...", Quellcode durch EULAs und fertig...
Selsbt das universal-Tool "Dotnet reflector" kann den IL-Code dekompilieren udn bringt den sourcecode fast haargenau zurück... nutze ich des öfteren um das API "zu erkunden" bei neuen DLLs.
Wobei Opensource in der Hinscht ein Kalauer ist... Opensource bedeutet nämlich entgegen des Namens, nicht nur die freie zugänglichkeit des Quellcodes, sondern vielmehr die Lizenz (erlaubnis) diesen zu benutzen, zu modifizieren und weiterzuentwickeln. Und davor "schützen" größtenteils die EULAs.
Was .Net definitiv mitbringt sind offene, transparente Schnittstellen... wäre die Win-API derart übersichtlich wäre das WINE Projekt schon seit 5 Jahren mit der Arbeit fertig...
MS ist wohl auf dem Standpunkt "KnowHow schützt man durch Patente...", Quellcode durch EULAs und fertig...
Devastators
Grand Admiral Special
MS ist wohl auf dem Standpunkt "KnowHow schützt man durch Patente...", Quellcode durch EULAs und fertig...
Das funktioniert international leider nur sehr begrenzt, vor allem in den östlichen, eher kommunistisch geprägten Regionen
Dort geht es eher nach der Methode, alles kopieren was nicht niet- und nagelfest ist und da war eine anständige Steuerung (wir sind ein Maschinenbauunternehmen) eigentlich der letzte Schutz vor Produktpiraterie.
yourgreatestfear
Grand Admiral Special
Da Deinerein an dem miesen KnowHow-Schutz einer .Net-Anwendung nix ändern kann, schreib Deine DLL in C++.
Prinzipiell ist es kein Problem aus C# heraus C++-DLL zu nutzen. Allerdings hat auch diese Variante ein paar Stolpersteine parat und erfordert extra Aufwand sowohl bei der Hostanwendung als auch in der DLL. Gerade die Weiterverwendung der DLL ohne Reengineering ist wieder explizit zu verhindern durch eigene Konstrukte. Es ist nur eine Notlösung, wenn man nicht auf .Net verzichten kann. Technisch machbar solang die Entwickler wissen was sie tun allemal.
Wenn ich Maschinenbau und Steuerung höre frage ich mich aber, wieso überhaupt .Net? Für dokumentbasierte Anwendungen und Frontendlösungen sind die .Net-Sprachen ja ganz doll, aber in Deiner Branche recht ungewöhnlich davon zu hören. Oder hab ich was verschlafen?
Prinzipiell ist es kein Problem aus C# heraus C++-DLL zu nutzen. Allerdings hat auch diese Variante ein paar Stolpersteine parat und erfordert extra Aufwand sowohl bei der Hostanwendung als auch in der DLL. Gerade die Weiterverwendung der DLL ohne Reengineering ist wieder explizit zu verhindern durch eigene Konstrukte. Es ist nur eine Notlösung, wenn man nicht auf .Net verzichten kann. Technisch machbar solang die Entwickler wissen was sie tun allemal.
Wenn ich Maschinenbau und Steuerung höre frage ich mich aber, wieso überhaupt .Net? Für dokumentbasierte Anwendungen und Frontendlösungen sind die .Net-Sprachen ja ganz doll, aber in Deiner Branche recht ungewöhnlich davon zu hören. Oder hab ich was verschlafen?
Devastators
Grand Admiral Special
Da Deinerein an dem miesen KnowHow-Schutz einer .Net-Anwendung nix ändern kann, schreib Deine DLL in C++.
Prinzipiell ist es kein Problem aus C# heraus C++-DLL zu nutzen. Allerdings hat auch diese Variante ein paar Stolpersteine parat und erfordert extra Aufwand sowohl bei der Hostanwendung als auch in der DLL. Gerade die Weiterverwendung der DLL ohne Reengineering ist wieder explizit zu verhindern durch eigene Konstrukte. Es ist nur eine Notlösung, wenn man nicht auf .Net verzichten kann. Technisch machbar solang die Entwickler wissen was sie tun allemal.
Wenn ich Maschinenbau und Steuerung höre frage ich mich aber, wieso überhaupt .Net? Für dokumentbasierte Anwendungen und Frontendlösungen sind die .Net-Sprachen ja ganz doll, aber in Deiner Branche recht ungewöhnlich davon zu hören. Oder hab ich was verschlafen?
bis jetzt steckt das meißte KnowHow in alten C-Code, man plant nur etwas weiter in die Zukunft.
Die Bedienpannels werden zukünftig in C# programmiert und ein Teil des KnowHows steckt auch dort.
Auch liefern wir einiges an Arbeitsvorbereitungs- sowie Simulationsprogramme die ein Teil des KnowHows beinhalten können und auch müssen.
Das Wrappen "alten" C-Codes ist auch hier eine Option und bei einer Beschränkung auf den nur Schützenswerten Code u.A. auch mein Favoriet.
Ich bin halt auf der Suche nach einer allgemeinen und vor allem eleganten Lösung dieses Problems. Online-Authentifizierung z.B. irgendwelcher indischen Steuerungs-Rechner ist leider nahezu Utopisch
Wir versuchen eigentlich alles Mögliche um die Rechner von der Umwelt abzuschotten
yourgreatestfear
Grand Admiral Special
Klare Empfehlung zu C++ in Verbindung mit einem (GUI)-Framework eigener Wahl (Qt, wxWidgets, GTK+, etc).
Nicht nur das damit das Wrappen alter C-Libs weitaus problemloser ist, auch hat man dann weniger Ärger mit Reengineering. Ein Schutz von einfacher Weiterverwendung der Libs ist machbar. Nachteil dürfte der etwas größere Zeitaufwand sein bei der Entwicklung.
Jede Wette aber, dass dies mal wieder von der BWL entschieden wird und nicht von der technischen Seite
Nicht nur das damit das Wrappen alter C-Libs weitaus problemloser ist, auch hat man dann weniger Ärger mit Reengineering. Ein Schutz von einfacher Weiterverwendung der Libs ist machbar. Nachteil dürfte der etwas größere Zeitaufwand sein bei der Entwicklung.
Jede Wette aber, dass dies mal wieder von der BWL entschieden wird und nicht von der technischen Seite
Devastators
Grand Admiral Special
Jede Wette aber, dass dies mal wieder von der BWL entschieden wird und nicht von der technischen Seite
auf jeden Fall nicht von irgendwelchen ITlern/Softwareentwicklern
Vor gut 6-8 Wochen ist die Problematik hier erst klar geworden.
Da wurde dann Panik geschoben, viele Mails verteilt, Lösungsansätze (u.A. externe Verschlüsselungs-Software die ich strickt ablehne) ausprobiert und das ganze dann auf eine Sitzung vertagt.
Auf diese "klärende" Sitzung warte ich nun schon gute 4-5 Wochen und denke da passiert nichts weiter
Unsere Herrschaften und Verwalter/Organisator/Ausrichter aller Besprechungs-Termine widmen sich wohl wieder alltäglichen Problemen...
Dann war die Panik aber auch definitiv nicht groß genug...!?
Nenn mich dumm wenn du willst, aber wenn ich vor etwas richtig bammel habe dann klemm ich mich dahinter... wenn das so "wischiwaschi" läuft und im Sande verschwindet, wars ihnen nicht wirklich wichtig.
Eigentlich ne traurige Angelegenheit.. da gibt es nagelneue Werkzeuge, produktivitätsverbesserungen etc. und dann muss man letztenendes doch wieder auf das alte zeugs zurück damit nicht hinz und kunz das alles kopiert...
Wobei ich mich immer frage... wenn compiler nachvollziehbare strukturen erzeugen, dann ist doch prinzipiell auch jeglicher Code dekomplilierbar...!?
Natürlich mit Einschränkungen, aber die gibts bei .net auch nur deswegen nicht, weil mehr Metainformationen gespeichert werden. CIL ist halt doch noch ein bisschen höher angesiedelt als Assembler...
Lustig wirds wenn man sich manche "obfuscators" so anschaut... in javascript gibts da die eine oder andere lustige anwendung, wo der Ganze Code Base64 kodiert in einem string steht und per eval() zur Ausführung gebracht wird...
Aber theoretisch könnte man doch auch ein .Net-Programm schreiben, welches Sourcen aus irgend welchen .xyz - files nachlädt, entpackt (wenns seinmuss mit irgend nem exotischen oder selbstgebauten packer) und das ganze dann zur ausführung bringt...!?
Klar wäre das dann auch wieder alles dekompilierbar etc. aber der Aufwand um dahinter zu kommen was da abgeht wäre schonmal ne ganze Ecke größer...
Was ich mich frage, wie ist das bei Java z.B.?
Prinzipiell müssten die das selbe Problem haben, auch wenn die Metainformationen nicht ganz so ausführlich sind (die Typinformation bei generischen Datenstrukturen ist z.b. nach dem kompilieren weg)
Nenn mich dumm wenn du willst, aber wenn ich vor etwas richtig bammel habe dann klemm ich mich dahinter... wenn das so "wischiwaschi" läuft und im Sande verschwindet, wars ihnen nicht wirklich wichtig.
Eigentlich ne traurige Angelegenheit.. da gibt es nagelneue Werkzeuge, produktivitätsverbesserungen etc. und dann muss man letztenendes doch wieder auf das alte zeugs zurück damit nicht hinz und kunz das alles kopiert...
Wobei ich mich immer frage... wenn compiler nachvollziehbare strukturen erzeugen, dann ist doch prinzipiell auch jeglicher Code dekomplilierbar...!?
Natürlich mit Einschränkungen, aber die gibts bei .net auch nur deswegen nicht, weil mehr Metainformationen gespeichert werden. CIL ist halt doch noch ein bisschen höher angesiedelt als Assembler...
Lustig wirds wenn man sich manche "obfuscators" so anschaut... in javascript gibts da die eine oder andere lustige anwendung, wo der Ganze Code Base64 kodiert in einem string steht und per eval() zur Ausführung gebracht wird...
Aber theoretisch könnte man doch auch ein .Net-Programm schreiben, welches Sourcen aus irgend welchen .xyz - files nachlädt, entpackt (wenns seinmuss mit irgend nem exotischen oder selbstgebauten packer) und das ganze dann zur ausführung bringt...!?
Klar wäre das dann auch wieder alles dekompilierbar etc. aber der Aufwand um dahinter zu kommen was da abgeht wäre schonmal ne ganze Ecke größer...
Was ich mich frage, wie ist das bei Java z.B.?
Prinzipiell müssten die das selbe Problem haben, auch wenn die Metainformationen nicht ganz so ausführlich sind (die Typinformation bei generischen Datenstrukturen ist z.b. nach dem kompilieren weg)
Dalai
Grand Admiral Special
Hat es auch, meiner Vermutung nach sogar noch stärker/schlimmer als .NET. Ich hab selbst schon aus bestimmten Gründen ein Java-Projekt dekompiliert und der benutzte Decompiler hat wunderbar lesbaren Code erzeugt (ich schätze sogar, dass der mit dem Quellcode identisch war).
MfG Dalai
Devastators
Grand Admiral Special
dumm auf keinen Fall, allerhöchstens etwas naiv, denn Du hast vollkommen rechtDann war die Panik aber auch definitiv nicht groß genug...!?
Nenn mich dumm wenn du willst, aber wenn ich vor etwas richtig bammel habe dann klemm ich mich dahinter... wenn das so "wischiwaschi" läuft und im Sande verschwindet, wars ihnen nicht wirklich wichtig.
Wenn unsere Firma mal gegen die Wand gefahren ist, will es niemand gewesen sein, weil ja niemand etwas (falsches) gemacht hat... *hust*
Aber das ist ein ganz anderes Problem, wahrscheinlich nicht nur in unserer Firma.
"Eigentlich" kannst Du Streichen, solch Probleme hier sind ja noch Probleme höherem Niveau an denen hier einige Scheitern...
Sicher, aber das kannst du mit .Net ebenfalls, Stichwort "Dotnet Reflector"...
Der dekompiliert dir klassen, DLLs usw. inkl. sauber qualifizierter Generics usw. (und das kann er bei java mal definitiv nicht, da sieht eine generische liste im bytecode nämlich genau wie eine untypisierte aus...die runtime weiß nix von generischen Typen)
Ist wohl das ewig abwägen... entweder die tollen modernen RAD-features mit all den nachteilen oder der alte C-Code mit allen Schwächen in Sachen Plattformunabhängigkeit, Compiler-Eigenheiten, stolperfallen usw.
Ich bin nur gespannt ob wir in 20 jahren immernoch C benutzen müssen um das Knowhow zu schützen...dann wäre die Sprache über ein halbes jahrhundert alt...
yourgreatestfear
Grand Admiral Special
Bei Java liegt ihr daneben.
Hier habe ich die Wahl ob ich in plattformunabhängigen Bytecode für den JIT compiliere oder ob ich mit dem AOT-Compiler direkten Maschinencode erzeuge. Reengineering ist nach dem AOT-Compiler ähnlich schwer/sinnlos wie bei C/C++.
C++ und Java sind in meinen Augen mächtig und zukunftsicher genug für die nächsten Jahre. Dank der dutzend Frameworks dazu eignet sich der Spaß auch für RAD. Wenn auch nicht ganz so idiotensicher wie mit .Net.
Hier habe ich die Wahl ob ich in plattformunabhängigen Bytecode für den JIT compiliere oder ob ich mit dem AOT-Compiler direkten Maschinencode erzeuge. Reengineering ist nach dem AOT-Compiler ähnlich schwer/sinnlos wie bei C/C++.
C++ und Java sind in meinen Augen mächtig und zukunftsicher genug für die nächsten Jahre. Dank der dutzend Frameworks dazu eignet sich der Spaß auch für RAD. Wenn auch nicht ganz so idiotensicher wie mit .Net.