DLLs von .NET Framework einzeln mitliefern?

[Bubble]

Es geht in diesem Fall nichtmal sosehr ums Know How vielmehr das derjenige

sehr viel Schweiß und Arbeit da reingesteckt hat (zumal das nur ein Modul des Ganzen ist).

Aufgrund der reingesteckten Arbeit ist so eine Reaktion zwar verständlich: Aber selbst wenn der Source offen liegen würde, bedeutet das noch nicht, dass jemand das Programm unerlaubt benutzen oder vervielfältigen darf.

Wenn sich jemand die Mühe machen will per Disassembler, Reflection oder in diesem Fall MSIL Decompiler mehr über das Programm zu erfahren, wäre mir das aber wohl auch eher egal bzw. ich würde es hinnehmen müssen. Zusätzlich gibt es noch Programme, die unter anderem Bezeichner umbenennen, wodurch das zurückübersetzte Ergebnis unübersichtlicher ist.

Du scheinst da was nicht verstanden zu haben. Um das Programm zu nutzen muss man nicht zwangsläufig den Code kennen.

Ich glaube Du hast etwas nicht verstanden: Damit ein Programm ausgeführt werden kann, muss eine Form des Codes bekannt sein - meistens ist diese Form CPU-spezifisch oder in dem Fall hier die Intermediate Language. Das wirst Du akzeptieren müssen oder das Programm, bzw. der relevante Teil von diesem, darf nur auf einem nur von Dir kontrollierten Computer ausgeführt werden.

Zumal werden wohl eher die wenigstens User eines Programmes das Programm nach dem Code (Zumal diese meist nicht die möglichkeiten dazu haben) bewerten sondern nach der Userbillity etc.

Ja, das ist meistens so. Allerdings kann das je nach Fall auch schon mal anders aussehen.

Mir geht es vielmehr darum, das die die es nicht kennen es auch nicht erfahren....

Lege die Daten in einem Verzeichnis ab, auf das nur der jeweilige Benutzer zugreifen kann. Das wäre schon mal ein erster Schritt. Ich hoffe doch mal nicht, dass das Programm für jeden Programmbenutzer im gleichen Betriebssystem-Benutzer-Kontext ausgeführt wird?

Höchstmögliche Sicherheit dürfte aber (für Dich) zu viel Aufwand bedeuten und könnte unter Umständen ein TPM im jeweiligen Rechner erfordern.

Das Passwort wird ja nach dem Entschlüsseln nicht in ein File abgelegt sonder existiert nur in einer Stringvariable eines Moduls zum vergleich der Eingabe des Users.

Sobald etwas im Speicher steht, kann es vom Prinzip her abgegriffen werden.

[Guybrush Threepwood]

Beispielsweise müssen die Anmeldedaten für den POP3 oder IMAP sowie die vom SMTP Server hinterlegt werden. Logischerweise kann ich diese nicht Hashen sonst wird es bei der Anmeldung mehrere Probleme geben.

Dann musst du diese den Benutzer immer eingeben lassen wenn du nicht willst das die Daten irgendwo stehen wo sie jemand anderes auslesen kann. Sobald du sie irgendwo in irgendeiner beliebigen Form abspeicherst so das dein Programm wieder den Klartext ermitteln kann kann das auch jeder andere machen. Zu glauben das man das irgendwie im Bytecode der Exe verstecken kann ist nur Selbsttäuschung.

[Gateway_man]

Zu glauben das man das irgendwie im Bytecode der Exe verstecken kann ist nur Selbsttäuschung.

Ja ich hatte es selbstverständlich wie schon gesagt nicht in der compilierten Exe stehen. Da stand wie gesagt nur der verwendete Algorithmus.

Das selbige Gespräch hatte ich auch schon mit einem Arbeitkollegen.

Er meinte ich solle doch sicherheitsrelevante Routinen einfach in einer anderen Sprache schreiben und als eigenes Modul ausgliedern.

Er hatte mir PowerBasic empfohlen mit der Begründung es wäre nicht decompilierbar und die verfassten Module wären enorm schnell, solange man den richtigen Compiler hernimmt (welcher den Quellcode direkt als Maschinensprache generiert). Scheint da wohl diverse unterschiede zu geben....

Hatte bisher aber noch die Zeit mir das mal genauer anzusehn.

Wiederrum ein andere Kollege meinte ich solle mich damit abfinden und nichts wäre zu 100% Sicher.

Bearbeitet 21. August 2010 von Gateway_man

[Guybrush Threepwood]

Das spielt keine Rolle ob Passwort oder Algorithmus. Du kannst nicht davon ausgehen das es geheim bleibt weil es nunmal nicht geheim ist.

Aber das hab ich ja schon vor 17 Beiträgen geschrieben

[Tony-Montana]

Obfuscator!

Das Prinzip ist ganz gut und es gibt auch kostenlose tools dafür.

In Visual Studio ist so ein Programm drin.

greets

Tony

[ToolsDevler]

Also das mit dem Obfuscator hab ich mir mal angeschaut.... Naja...

Bei microsoft gibts hier was dazu zu lesen (Decompiler und Obfuscator). Aber besonders der folgende Ausschnitt finde ich Entscheidend:

Können Obfuskatoren Software schützen?

String Encryption wird allgemein überschätzt. Es wird nur ein geringer Schutz erreicht und dies zu Lasten einer schlechteren Performance. Daher sollten Obfuskatoren höchstens nach dem Motto „besser ein geringer Schutz als gar keiner“ eingesetzt werden. Der Salamander .NET Decompiler ist sogar in der Lage, String Encryption in einer Assembly zu erkennen, die injizierte Decrypt()-Methode zu finden, aufzurufen und an deren Stelle den entschlüsselten String in den Sourcecode einzufügen.Darüber hinaus nehmen Obfuskatoren Umbenennungen aller Symbolnamen vor. Allerdings können Verwirrungen bei der Benennung von Klassen, Methoden und Variablen mit ein wenig Zeit und Geduld durch Debugging des rekonstruierten Sourcecodes aufgelöst werden. Das Problem der derzeit am Markt angebotenen Obfuskatoren besteht darin, dass der Verschlüsselungsalgorithmus einschließlich des verwendeten Schlüssels in der „geschützten“ Assembly ausgeliefert wird und damit jedem Hacking ausgeliefert ist. Ein verschlüsselter Inhalt kann nach dem heutigem Sicherheitsverständnis jedoch nur dann wirkungsvoll vor unberechtigten Dritten bewahrt werden, wenn der Schlüssel geheim bleibt, nur dem Empfänger des Inhalts bekannt ist und losgelöst von der eigentlichen Nachricht verwaltet wird.

Es scheint wirklich keine Möglichkeit zu geben, den Quellcode zu schützen.

Da dies sich aber auf den IL-Code bezieht, würde mich noch interessieren, wie sicher dagegen eine native .exe ist.

ToolsDevler

[Tony-Montana]

ich hab mal google gefragt und als sprache cpp hergenommen. Und die resultate in vielen alternativen Foren etc. sind fast immer gleich:

link.

While decompilation is theoretically possible (in an impractical sense of "theoretically"), the answer is no.

"Even if you know everything about the compiler, manufacturer, version number, compile-time options, third party libraries, and debugging information, the cost of writing a decompiler that works with even one particular compiler and has even a modest success rate at generating code would be significant — on the par with writing the compiler itself from scratch."

"Most executables have had their debugging information stripped out, so the resulting decompiled code will be totally unreadable."

http://www.parashift.com/c++-faq-lite/c ... l#faq-37.4

[ToolsDevler]

Also ist es, denke ich, am besten wenn man sich zu .NET noch eine alternative Sprache (z.B. C++) anschaut. Somit wäre das Problem mit dem Dekompilieren soweit eingeschränkt oder gar komplett behoben.

Ich denke, dass dieses Thema soweit beantwortet wurde.

ToolsDevler

[Guybrush Threepwood]

Ich glaube da liegt noch ein Missverständnis vor. Für viele der hier angesprochenen "Probleme" muss man die Anwendung nichtmal dekompilieren sondern einfach nur debuggen und schauen was im Speicher steht. Dann hat man das Passwort oder die Datenstruktur auch schnell raus.

Wenn das ganze dann noch verschickt wird gehts sogar noch einfacher indem man einfach den Netzwerkverkehr überwacht.

Man kann es drehen und wenden wie man will, Sicherheit durch (scheinbare) Verschleierung gibt es nicht.

[Gateway_man]

Es gibt prinzipiell immer Möglichkeiten, nur ob der Zeitaufwand es wert ist ....

Ich hatte mal vor ca einem halben Jahr ne Firewall, auf deren Prozesse man nicht zugreifen konnte. Selbst in deren Speicherbreich konnte man nicht einsehn. Wäre wirklich mal interessant zu wissen, wie die das bewerkstelligt haben.

Hier hab ich noch einen interessanten Artikel über Secure Programming(Cpp).

link to *.doc

Früher unter Windows 2000 hatte man noch die cacls.

Fand ich super.

Da konnte man die Programmpfade einzel sperren beziehungsweise, man kreierte einen Passwort geschützten User, welcher als einziger Zugriff auf den Pfad hatte und hat dann beim starten immer mit dem User auf die Exe Zugegriffen.

[Klotzkopp]

Ich hatte mal vor ca einem halben Jahr ne Firewall, auf deren Prozesse man nicht zugreifen konnte. Selbst in deren Speicherbreich konnte man nicht einsehn. Wäre wirklich mal interessant zu wissen, wie die das bewerkstelligt haben.

Es gibt da jede Menge mehr oder wenige dreckige Möglichkeiten. Schau dir mal an, was aktuelle Anti-Cheat-Programme für Spiele so alles tun. Die verhindern sogar, dass du einen Debugger überhaupt startest.

[ToolsDevler]

Ich glaube da liegt noch ein Missverständnis vor. Für viele der hier angesprochenen "Probleme" muss man die Anwendung nichtmal dekompilieren sondern einfach nur debuggen und schauen was im Speicher steht. Dann hat man das Passwort

Wenn man auf dem lokalen PC ein Passwort aus dem Speicher lesen will, muss man zuvor doch erst eins eingeben? Von dem her braucht man sich diesbezüglich keine Gedanken machen (natürlich sollte man so oder so (egal in welcher Form) lokal keine Passwörter im klartext zwischenspeichern). Oder seh ich das falsch?

...oder die Datenstruktur auch schnell raus.

Dann müsste es ja eig auch Decompiler oder ähnliches (zumindest für die Datenstruktur) für normale native .exe geben...oder?

Edit: Boah... 2 Beiträge während ich meinen geschrieben hab^^

[Guybrush Threepwood]

Ich hatte mal vor ca einem halben Jahr ne Firewall, auf deren Prozesse man nicht zugreifen konnte. Selbst in deren Speicherbreich konnte man nicht einsehn. Wäre wirklich mal interessant zu wissen, wie die das bewerkstelligt haben.

Auch das wirst du mit genügend Aufwand wieder umgehen können.

Wenn man auf dem lokalen PC ein Passwort aus dem Speicher lesen will, muss man zuvor doch erst eins eingeben? Von dem her braucht man sich diesbezüglich keine Gedanken machen (natürlich sollte man so oder so (egal in welcher Form) lokal keine Passwörter im klartext zwischenspeichern). Oder seh ich das falsch?

Stimmt das war darauf bezogen das man das verschlüsselt wegspeichert und den Schlüssel im Programmcode stehen hat.

Dann müsste es ja eig auch Decompiler oder ähnliches (zumindest für die Datenstruktur) für normale native .exe geben...oder?

Was dir ein decompiler in so einem Fall bei zum Beispiel bei einem C++ Programm ausspuckt kann ich dir nicht sagen da ja glaube ich die Klasseninformationen verloren gehen weil es im Machinencode keine Klassen gibt. Aber auch in dem Fall wäre es wahrscheinlich viel einfacher das im Debugger oder imNetzwerksniffer anzuschauen.

[Bubble]

Es scheint wirklich keine Möglichkeit zu geben, den Quellcode zu schützen.

Doch, da gibt es sogar mehrere, z.B. das Programm nur auf eigenen Computern ausführen (der beste Schutz) oder das Problem nicht per Software sondern per Hardware lösen, die so verpack ist, dass sie beim Versuch sie zu öffnen recht schnell kaputt geht (erhöht den Aufwand und die Kosten enorm, insbesondere wenn die Hardware pro Stück teuer verkauft wird).

Also ist es, denke ich, am besten wenn man sich zu .NET noch eine alternative Sprache (z.B. C++) anschaut. Somit wäre das Problem mit dem Dekompilieren soweit eingeschränkt oder gar komplett behoben.

Das Verlagert das Problem auf native code, welcher insbesondere mangels aussagekräftiger Bezeichner oft schwieriger zu überblicken ist, löst es aber nicht an sich.

Es gibt prinzipiell immer Möglichkeiten, nur ob der Zeitaufwand es wert ist ....

Richtig. Bei den hier bisher genannten Programmen bezweifle ich, ob jemand die Zeit aufwenden wollen würde.

Schau dir mal an, was aktuelle Anti-Cheat-Programme für Spiele so alles tun. Die verhindern sogar, dass du einen Debugger überhaupt startest.

Das Problem daran ist nur: Der Aufwand ist hoch und stellt trotzdem keinen völligen Schutz dar. Es kann für den Zweck reichen, aber man darf keine falschen Vorstellungen haben.

Um aber mal einen neuen Vorschlag zu machen: Es gibt Anbieter von Lösungen für den Softwareschutz, auch mit Spezialhardware. Da sollte man sich mal erkundigen.

[Gateway_man]

Ich finde dieses Thema nichts desto trotz enorm wichtig.

Zudem finde ich das nutzten mehrer Programmiersprachen in der Tat äußerst Interessant und zudem auch in diesem Zusammenhang sehr nützlich.

In der momentan Firma in der ich gerade Arbeite, muss es wohl schon mehrmals vorgekommen sein, das versucht wurde (von Konkurrenzfirmen) das Netzwerk zu "infiltrieren", um an den Quellcode bestimmter Module ranzukommen.

In dieser Firma wir neuerdings mit .NET gearbeitet, jedoch sind noch viele ältere Module in C/Cpp.

[ToolsDevler]

Es gibt da jede Menge mehr oder wenige dreckige Möglichkeiten. Schau dir mal an, was aktuelle Anti-Cheat-Programme für Spiele so alles tun. Die verhindern sogar, dass du einen Debugger überhaupt startest.

Diese Aussage hat mich schon die ganze Zeit verfolgt^^... Kennt sich jemand damit aus? Weiß jemand wie man sowas erreichen kann?

Immerhin is des schonma besser als garnix.

Grüße

ToolsDevler

EDIT: Auch das, was Gateway_man in Beitrag #35 geschrieben hat.

Bearbeitet 25. August 2010 von ToolsDevler

[Bubble]

Diese Aussage hat mich schon die ganze Zeit verfolgt^^... Kennt sich jemand damit aus? Weiß jemand wie man sowas erreichen kann?

Das möchtest Du genau erreichen?

Es sollte aber auch klar sein, dass bei einigen Vorgehensweisen möglicherweise das Risiko eines Support-Alptraums besteht, wenn die Vorgehensweise z.B. von Viren-Scannern irgendwann in der Zukunft als "verdächtig" eingestuft wird.

Immerhin is des schonma besser als garnix.

Den Aufbau von ein paar Kommunikationsprotokollen (darum ging es Dir doch?) muss man meiner Meinung nach nicht wirklich verstecken.

[ToolsDevler]

Das möchtest Du genau erreichen?

Dass alleine schon der Versuch, irwie in Programmabläufe reinzuspickeln, verhindert wird... aber ich glaube, des kann man nich wirklich durchsetzen.

Es sollte aber auch klar sein, dass bei einigen Vorgehensweisen möglicherweise das Risiko eines Support-Alptraums besteht, wenn die Vorgehensweise z.B. von Viren-Scannern irgendwann in der Zukunft als "verdächtig" eingestuft wird.

Hmm...Was Gateway_man in Beitrag #35 geschrieben hat, handelt von einer Firewall.

Was die Anti-Cheat Programme betreffen... OK.. da kanns durchaus sein, ich weiß aber nicht, ob man irwelche "verdächtigen" Funktionen benutzen muss, um zu prüfen, ob des Programm debuggt wird.

Aber dazu fehlt mir ein wenig des Hintergrundwissen.

Den Aufbau von ein paar Kommunikationsprotokollen (darum ging es Dir doch?) muss man meiner Meinung nach nicht wirklich verstecken.

Ja ok, dass mit den Kommunikationsprotokollen is zwar nich schön, aber im gegensatz zum Programm selber eher nebensächlich.

Es ging aber auch darum (was den Debugger betrifft), dass Maschinen- oder MSIL-code nur sehr schwer eingesehen werden kann.

Aber irwie endet des immer wieder in irgend nem Teufelskreis oder ner Sackgasse.

Grüße

ToolsDevler

[Bubble]

Dass alleine schon der Versuch, irwie in Programmabläufe reinzuspickeln, verhindert wird... aber ich glaube, des kann man nich wirklich durchsetzen.

Richtig.

Was die Anti-Cheat Programme betreffen... OK.. da kanns durchaus sein, ich weiß aber nicht, ob man irwelche "verdächtigen" Funktionen benutzen muss, um zu prüfen, ob des Programm debuggt wird.

Ein Programm, dass Debugger abfangen möchte ist doch immer irgendwie verdächtig, oder findest Du das nicht?

Viele der "Tricks" etwas zu verschleiern sind eher alt und wurden schon früher im Zusammenhang von Kopierschutzvorkehrungen genutzt. Beispielsweise wurde ausführbarer code gepackt (EXE-Packer), es wurde mit selbstmodifizierendem Code gearbeitet, um eine Analyse des Programms zu erschwerern, usw.

Wenn man tatsächlich einen wirklich sicheren Schutz aufbauen will, dann braucht man im Grunde ein sicheres DRM für den Programmcode. Das könnte Hardware- und Betriebssystemunterstützung erfordern. Es müsste z.B. auch verhindert werden, dass der Code in einer VM ausgeführt werden kann - nur Debugger aussperren reicht dann auch nicht. Für noch mehr Schutz müsstest Du auch noch sicherstellen, dass auch die Hardware nicht modifiziert ist, usw.

Es ging aber auch darum (was den Debugger betrifft), dass Maschinen- oder MSIL-code nur sehr schwer eingesehen werden kann.

Was befürchtest Du denn könnte passieren, falls jemand fremdes das Programm tatsächlich einsieht? Es gibt immerhin haufenweise Programme, die ohne derartige Schutzvorkehrungen auskommen.

[Guybrush Threepwood]

Dass alleine schon der Versuch, irwie in Programmabläufe reinzuspickeln, verhindert wird... aber ich glaube, des kann man nich wirklich durchsetzen.

Doch aber wenn du an dem Punkt angelangt bist kann der Computer es aber auch nicht mehr ausführen

Solange ein Computer das Programm ausführen kann kann jemand anderes auch wieder rückverwandeln und analysieren. Du kannst es nur schwieriger machen. Aber was bringt dir das wenn du 10 mal soviel Aufwand in die Verschleierung des Programms steckst wie in die eigentliche Entwicklung des Programms selber?

[Gateway_man]

Solange ein Computer das Programm ausführen kann kann jemand anderes auch wieder rückverwandeln und analysieren.

Er kann die Abläufe vielleicht unter umständen nachvollziehen (als leihe bestimmt nicht).

Aber den 1zu1 Quellcode wird er nie durch Auslieferung der assembly's bekommen (solange native compiliert).

Dafür weiß er viel zu wenig.

Er müsste wissen, welche Programmiersprache, welcher Compiler, welche ressourcen, etc. eingesetzt wurden.

Und wenn die debugging Informationen vom compiler entfernt wurden, wirds da auch recht schwierig.

Ich verweise mal diesbezüglich auf den Post #32.

Wie schon gesagt wurde, "Theoretisch" ist alles möglich.

[Guybrush Threepwood]

Aber den 1zu1 Quellcode wird er nie durch Auslieferung der assembly's bekommen

Hab ich nirgendwo behauptet, aber wozu brauch er den?