Source Code

03/22/2014 13:19 .Saimo#1
Ich habe jetzt an einem Visual Basic Programm gearbeitet und habe dieses zum Test meinen Freund gesendet.
Er meinte er könne den Source Code ganz einfach ohne Probleme auslesen.

Jetzt die Frage:

Wie kann ich das verhindern?
03/22/2014 14:15 ​Tension#2
Obfuscator und oder Packer verwenden.
03/22/2014 15:35 マルコ#3
Den Source kann man ganz einfach aus _jedem_ Programm auslesen. Die Frage ist nur, zu welchem Grad. Bei interpreted (z.B. PHP, JS, Dart,...) und JIT compiled (z.B. VB, C#, Java,...) languages ist dies zu einem Grad möglich, an dem du sogar ganz einfach wieder eine High-Level Sprache raus bekommst. Bei compilierten Programmen (z.B. geschrieben in C, C++, Delphi,...) bekommt man meistens nur ASM zurück.
Selbst ein Obfuscator oder Packer kann daran nichts ändern, denn der Computer muss das Programm ja trotzdem lesen können. Was der Computer lesen kann, kann auch ein Mensch lesen.

Was bringt also ein Obfuscator?
Er baut den Quelltext so um, dass es sehr viel schwerer wird, den Sinn des Programmes zu verstehen (ohne die grundlegende Funktionsweise des Programmes zu ändern).
Ein Nebeneffekt ist meistens Performanceverlust.
Aber wie gesagt, mit herumprobieren lässt sich der Quellltext immer wieder herausfinden. Du kannst nur versuchen, es so schwer als möglich zu machen (so dass es einfacher ist, das Programm neu zu programmieren, als deinen Quelltext heraus zu finden).
Zudem gibt es zu den meisten Obfuscatoren in deiner Liga bereits De-Obfuscatoren, die den Obfuscation Prozess rückgängig machen können.
Gute Obfuscatoren kossten sehr viel Geld und es dauert meist nicht lange, bis ein Gegenprodukt entwickelt wurde (also musst du immer auf dem neusten Stand bleiben - wie bei allem im Computer Bereich)


Da du diese Frage hier stellst nehme ich aber sowieso an, dass dein Quelltext nicht genug Wert ist, um ihn zu obfuscaten, da er wahrscheinlich schneller neu geschrieben ist, als den .NETReflector o.ä. zu benutzen.
An deiner Stelle würde ich mir daher keine großen Gedanken darum machen.
Zudem verdient man heutzutage nicht mit Programmen Gelkd, sondern mit dem Support für die Programme (gerade weil es so einfach ist, sie zu cracken)
03/22/2014 17:27 YatoDev#4
[Only registered and activated users can see links. Click Here To Register...]
Reicht für deine projekte aus denke ich mal
03/22/2014 19:07 .Saimo#5
Quote:
Originally Posted by マルコ View Post
Den Source kann man ganz einfach aus _jedem_ Programm auslesen. Die Frage ist nur, zu welchem Grad. Bei interpreted (z.B. PHP, JS, Dart,...) und JIT compiled (z.B. VB, C#, Java,...) languages ist dies zu einem Grad möglich, an dem du sogar ganz einfach wieder eine High-Level Sprache raus bekommst. Bei compilierten Programmen (z.B. geschrieben in C, C++, Delphi,...) bekommt man meistens nur ASM zurück.
Selbst ein Obfuscator oder Packer kann daran nichts ändern, denn der Computer muss das Programm ja trotzdem lesen können. Was der Computer lesen kann, kann auch ein Mensch lesen.

Was bringt also ein Obfuscator?
Er baut den Quelltext so um, dass es sehr viel schwerer wird, den Sinn des Programmes zu verstehen (ohne die grundlegende Funktionsweise des Programmes zu ändern).
Ein Nebeneffekt ist meistens Performanceverlust.
Aber wie gesagt, mit herumprobieren lässt sich der Quellltext immer wieder herausfinden. Du kannst nur versuchen, es so schwer als möglich zu machen (so dass es einfacher ist, das Programm neu zu programmieren, als deinen Quelltext heraus zu finden).
Zudem gibt es zu den meisten Obfuscatoren in deiner Liga bereits De-Obfuscatoren, die den Obfuscation Prozess rückgängig machen können.
Gute Obfuscatoren kossten sehr viel Geld und es dauert meist nicht lange, bis ein Gegenprodukt entwickelt wurde (also musst du immer auf dem neusten Stand bleiben - wie bei allem im Computer Bereich)


Da du diese Frage hier stellst nehme ich aber sowieso an, dass dein Quelltext nicht genug Wert ist, um ihn zu obfuscaten, da er wahrscheinlich schneller neu geschrieben ist, als den .NETReflector o.ä. zu benutzen.
An deiner Stelle würde ich mir daher keine großen Gedanken darum machen.
Zudem verdient man heutzutage nicht mit Programmen Gelkd, sondern mit dem Support für die Programme (gerade weil es so einfach ist, sie zu cracken)
Danke für diese ausführliche Erklärung.
Wie will der Computer aber wissen welche "Sprache" er benutzen muss damit er erkennt was dort steht :?

(Könnt sein das die Frage falsch ausgedrückt ist sorry (._.) )
03/22/2014 19:22 YatoDev#6
Quote:
Originally Posted by .Saimo View Post
Danke für diese ausführliche Erklärung.
Wie will der Computer aber wissen welche "Sprache" er benutzen muss damit er erkennt was dort steht :?

(Könnt sein das die Frage falsch ausgedrückt ist sorry (._.) )
Dein VB.Net code wird in zwischen-code übersetzt den die .Net umgebung auf dem ziel computer ausführen kann. (deswegen muss der ziel pc auch .Net runtime installiert haben nicht so wie z.b. bei masm)
Der code ist aber leicht zurückübersetzbar.
C# und andere .Net sprachen müssen sich an gewisse regeln halten damit diese auch für die übersetzung kompatibel sind deswegen kannst bis auf paar aufnahmen c# .dll in vb oder anderen .Net programmen nutzen.

C# und VB.Net sind dann ganz grob gesehen das gleiche da nur der zwischencode so sein muss das die vm ihn ausführen kann

Bei wikipedia kann man das sehr ausführlich nachlesen
03/22/2014 21:47 Mostey#7
Quote:
Originally Posted by .Saimo View Post
Danke für diese ausführliche Erklärung.
Wie will der Computer aber wissen welche "Sprache" er benutzen muss damit er erkennt was dort steht :?

(Könnt sein das die Frage falsch ausgedrückt ist sorry (._.) )
Weil er am Ende nur Maschinensprache vorgesetzt bekommt. Ein Computer versteht kein "print("test");" sondern nur Folgen von den Ziffern 1 und 0. Assembler ist die Interpretation der Maschinensprache die wir Menschen lesen können.

Heißt also, wenn du in einer Hochsprache schreibst und dann kompilierst, wird dein Code in Maschinensprache übersetzt, sodass der Computer damit klar kommt. Dazu muss er nicht wissen, in welcher Sprache das geschrieben wurde.