Quelltext verschlüsseln

U

Uwe Friedrich

Angesehenes Mitglied
Hallo,

hat jemand von Euch Erfahrung mit der Verschlüsselung von Quelltext, evtl. mit diesem Tool hier: http://www.gocodelock.de/ ?
Oder welche anderen Tools bzw. Verfahren kennt Ihr die einen ähnlichen Leistungsumfang haben wie o.g. Software.

Viele Grüße
U. Friedrich
 
hallo uwe

kenne kein anderes tool, wollte mich aber für den link bedanken. ich finde es sieht gut aus. hab verschlüsselten code gerade gestern bei einer script-demo-version das erste mal gesehen.

dank und gruss

urs
 
Verschlüsseln kannst du den PHP Code, wenn Geld vorhanden ist, mit einem Zend Produkt. Wenn das den Budgetrahmen sprengt würde ich mal einfach nach „obfuscate php“ suchen da findest du schon was.

Wenn du den HTML-Code etwas unleserlicher gestalten willst, entferne einfach die unnötigen Leerzeichen, Tabs und Zeilenvorschübe.
 
Hi,

@hatschi1810

Bei dem Zend-Produkt handelt es sich bestimmt um ein Tool mit dem ich nur PHP verschlüsseln kann. Ich brauche es aber für alles, insbesondere den JS-Code.

Einfach nur Leerzeilen, Tabspaces etc. rausnehmen genügt mir nicht. Es sollte schon auf dem Niveau sein wie es das oben zitierte Tool kann, also mit individuellem Schlüssel.

@all

Grundsätzlich finde ich das von mir angeführte Tool schon ziemlich umfangreich, ich wollte aber einfach noch mal sehn ob es Alternativen zum Vergleich gibt, die ein ähnliches Leistungsspektrum haben.

Viele Grüße
U. Friedrich
 
hm das programm sieht interessant aus. aber ist dieser verschlüsselte code dann noch auf gängigen servern tauglich?? kann ich mir nicht recht vorstellen...
weshalb möchtest du denn genau javascript code verschlüsseln? was genau tust du mit javascript? könnte das nicht besser mit php gelöst werden?
 
Hallo,

@josh
Ich denke schon, das der Code auf den gängigen Servern tauglich ist. So steht es jedenfalls in "Alle Vorteile von Codelock auf einen Blick" Punkt 3,4,6 ff.

Warum will ich das tun? - Ich arbeite z.Zt. an einem Börsenchart-Tool, das auf der Basis von HTML,PHP und JS läuft. Dabei wird beim ersten Aufruf via http eine komplette GUI geladen, deren Steuerung [Explorer, Menüs, Kontextmenü] kpl über JS/DOM läuft. Ausserdem gibt es in dem Tool eine Zeit-Zoomfunktion via JS und eine Zeichenfunktion via JS, mit der man in den Wertpapierchart Trendlinien zeichnen, diese verschieben, automatisch in Richtung der Zeitachse verlängern und wieder löschen kann sowie ein über diverse Parameter einstellbares Handelssystem für Wertpapiere. Die Charts und die einzelnen Indikatoren werden als Grafik in PHP erzeugt, so dass die GUI selbst nach dem erstmaligen Laden immer bestehen bleibt und dann nur noch die Grafiken neu erzeugt und ausgetauscht werden. Dazu sind noch andere Features geplant. Und da das Alles sehr viel Arbeit macht wollte ich einfach verhindern das jederman nach Belieben klaut und kopiert. Zumal ich das dann als Alternative zu gleichartigen Desktopprogrammen via Internet als Abo anbieten will, mit individuellen Einstellfunktionen für den Abonnenten.

Viele Grüße
U. Friedrich
 
Nur mal so als Zwischenfrage: Das gibt doch eine relativ komplexe Applikation, auch was Grafik und Funktionen betrifft. Warum das nicht grad als Java- oder Dotnet-Applet implementieren? Mich würds einfach grausen, wenn ich an die vielen Browserunterschiede, grad was JS und CSS betrifft, denke. Und bei nem Applet wäre der Code sowieso kompiliert, da brauchts keine Verschlüsselung mehr.

Griessli
Irene
 
Ich finde das Teil sehr interessant: Es bietet Sicherheit ohne Modifikation am php und am Server. Und sogar JS wird verschlüsselt.
Genau das stört mich ein wenig: ein "unmodifizierter" Server kann nur "normales" php ausführen. Also muss doch das "verschlüsselte" Resultat reines php sein ? Mach ich einen Überlegungsfehler ?

Gruss
Roger
 
Hallo Irene,

über Applets habe ich auch nachgedacht, aber dies wäre auch problematisch.

1. Es muss sicher sein das beim Client Java aktiviert ist und er die gleiche Version verwendet.
2. die Zeichen/Zoomfunktion generiert neue Parameter für den Darstellungszeitraum, die dann an den Server geschickt werden um eine neu Chartgrafik zu erzeugen. Ist eine Interaktion zwischen Applet und Server möglich, ohne das Applet jedesmal mit den geänderten Parametern neu laden zu müssen?
3. Wechsle ich zu einem anderen Wertpapier muss ich das Applet neu laden, da die Daten, tw. über mehrere Jahre, wieder kpl. anders sind
4. in der php-Version laufen alle rechenintensiven Vorgänge [Indikatoren, Handelssystem mit Profitkalkulation und Moneymanagement] am Server, wie ist das beim Applet?
5. die Applikation wird für IE und Firefox zugeschnitten sein, das sollte reichen. Es müssen halt gewisse Mindestvoraussetzungen vom Client her gegeben sein. Alles allen zu ermöglichen mit jeder denkbaren Konstellation wäre zuviel Aufwand.


Zudem bietet das Verschlüsselungsmodell mit o.g. Tool noch weitere Vorteile, wie zeitl. Begrenzung, IP/Domains sperren etc.

In einer 2. Stufe ist die Portierung auf einen Windowsserver gedacht und das was z.Zt. als PHP läuft als Dienst [dll] direkt im Webserver laufen zu lassen. Und als Ergebniss dessen erhalte ich wieder HTML/JS-Code. Den muss ich dann auch wieder verschlüsseln.

Insofern habe ich mich hinsichtlich Verschlüsselung vs. Applet schon entschieden. Es ging mir nur um Erfahrungen in Bezug auf Verschlüsselung.

Viele Grüße
U. Friedrich
 
QUOTE (Roger Bobst @ Do 21.10.2004, 12:53)Und sogar JS wird verschlüsselt.
Genau das stört mich ein wenig: ein "unmodifizierter" Server kann nur "normales" php ausführen. Also muss doch das "verschlüsselte" Resultat reines php sein ?
Ich versteh das so, dass die PHP-Files auf der Serverdisk verschlüsselt gespeichert werden. Das Teil hängt sich quasi zwischen Disk und Webserver, und liefert dem Webserver den entschlüsselten Code im Memory. Nach dem Ausführen wird das Resultat dann wieder verschlüsselt und an den Client geschickt.
Allerdings versteh ich nicht ganz, wie denn HTML und JS verschlüsselt werden sollen. Ein Browser kann keinen verschlüsselten Source interpretieren - es sei denn, der Webserver liefert mit dem verschlüsselten Source ein (offenliegendes) JS mit dem Key zum Entschlüsseln. Und damit wärs für die Katz, weil dieses offenliegende JS kann ein User ja aus dem Source rausholen und den verschlüsselten Code damit entschlüsseln. Ich würd mir gern mal eine Seite ansehen, die tatsächlich so verschlüsselt geliefert wird ;-)

Griessli
Irene
 
QUOTE (Uwe Friedrich @ Do 21.10.2004, 13:25)1. Es muss sicher sein das beim Client Java aktiviert ist und er die gleiche Version verwendet.
2. die Zeichen/Zoomfunktion generiert neue Parameter für den Darstellungszeitraum, die dann an den Server geschickt werden um eine neu Chartgrafik zu erzeugen. Ist eine Interaktion zwischen Applet und Server möglich, ohne das Applet jedesmal mit den geänderten Parametern neu laden zu müssen?
3. Wechsle ich zu einem anderen Wertpapier muss ich das Applet neu laden, da die Daten, tw. über mehrere Jahre, wieder kpl. anders sind
4. in der php-Version laufen alle rechenintensiven Vorgänge [Indikatoren, Handelssystem mit Profitkalkulation und Moneymanagement] am Server, wie ist das beim Applet?
Ist mir klar, dass Deine Entscheidung betr. Technologie schon gefallen ist. Hier nur noch mein "Senf" zu ein paar Punkten; vielleicht nützt es Dir (oder anderen) bei einem späteren Projekt mal.

1. Wird üblicherweise durch Verwendung des Java-Plugins gelöst (d.h. Java muss schon aktiviert sein, aber das muss JS bei der HTML-Variante ja auch).
2. Eine Interaktion zwischen Applet und Server ist in Java mittels RMI, in Dotnet und Java über SOAP möglich.
3. Gleich wie 2., d.h. das Applet muss nicht neu geladen werden, sondern nur die anderen Daten vom Server holen (und natürlich neu darstellen).
4. Die rechenintensiven Vorgänge können im Applet oder im Server implementiert werden, je nachdem wieviele Daten zum Rechnen benötigt (sprich übermittelt) werden müssten. Wenn die halbe Datenbank zur Berechnung benötigt wird, macht es nicht viel Sinn, zuerst Megas zu übermitteln, nur damit der Client es rechnen kann. Wenn aber die Berechnungsgrundlagen sowieso beim Client sind (z.B. von Benutzereingaben) dann solls der Client rechnen und der Server muss nicht soviel schaffen ;-) Etwa so:


CODE ------
| DB |
------
| -------------- --------------------
| | | <-- Login ---> | |
|----| Webserver | | Client |
| | | -- Applet ---> | |
| -------------- | Soap / RMI |
| | |
| -------------- | Berechnungen |
| | Webservice | --- Daten ---> | Funktionen |
-----| oder | | Darstellung |
| RMI-Server | <- Eingaben -- | |
-------------- --------------------

Griessli
Irene
 
mein tipp: verwende java und programmier ein anständiges auf awt kontrollen basiertes applet. dabei brauchst du nur die mindestvoraussetzung, dass man eine java virtual machine installiert hat. danach brauchst du dich nie mehr um kompatibilität kümmern, weil das von den distributoren der vm übernommen wird. bei browsern wirst du ewig den kampf selber führen müssen.
 
QUOTE Ich versteh das so, dass die PHP-Files auf der Serverdisk verschlüsselt gespeichert werden. Das Teil hängt sich quasi zwischen Disk und Webserver, und liefert dem Webserver den entschlüsselten Code im Memory. Nach dem Ausführen wird das Resultat dann wieder verschlüsselt und an den Client geschickt.
Ja, so ungefähr ists, nur kann man dem nicht verschlüsseln sagen.....ups, ich muss hören, es ist absolut verboten, es zu reversen....
ph34r.gif


Fazit: Ich hätte echt nicht den Mut, sowas zu verkaufen.

Gruss
Roger
 
QUOTE Fazit: Ich hätte echt nicht den Mut, sowas zu verkaufen.

Das denk ich mir eben auch schon die ganze Zeit.
smile.gif


Java ist sicher ein gangbarer Weg. Aber weshalb überhaupt "Open Source" nehmen, wenn man das nachher als "Closed Source" verkaufen will?

Vielleicht bin ich naiv - ich nenn es ehrlich. Unter anderem programmiere ich auch Komponenten auf Basis ASP.NET (in C#.NET oder VB.NET geschrieben). Diese sind kompiliert und einigermassen vor fremden Augen geschützt. Ja - auch .NET-Kompilate kann man Reverse-Engineeren - Jedoch nur mit Aufwand.

Weshalb in aller Welt würde ich versuchen, ein Pferd (Open Source) an den Hufen (PHP) durch ein Nadelöhr (Kompilat) zu zwingen?

Das wird mich heute die ganze Nacht im Traum verfolgen...
blink.gif
 
Hi Schnuerbel,

Du bist ja ein richtiger Prediger, dazu noch philosophisch! Weshalb ziehst Du Dich denn in allen Deinen Beiträgen daran hoch das manch einer nicht Sack und Seele via Internet verscherbeln will. Für Dich mag das Internet der Selbstbedienungsladen von vor 5 - 6 Jahren sein und Du kannst doch Deine Dinge aller Welt zu Füßen legen. Es gibt aber andere Leute mit der Intention, das das Internet eben auch ein Kanal ist, über den man einige seiner Ideen oder Projekte vertreiben kann. Und dabei seine Arbeit schützen zu wollen, was ist daran schlecht?
Ein Auto fährt auch auf öffentlichen Strassen, aber der Hersteller liefert doch auch nicht all seine Patente in der Betriebsanleitung mit oder sagt 'Kupfert ab wass ihr braucht!'

Und genauso ist das im Internet. Die 69'er sind erledigt, der Kommunismus ist gescheitert und das das Internet nur für Leute Deines Anspruchs da ist oder geschaffen wurde ist ebenfalls jenseits der Realität.

Viele Grüße
U. Friedrich
 
QUOTE Weshalb ziehst Du Dich denn in allen Deinen Beiträgen daran hoch das manch einer nicht Sack und Seele via Internet verscherbeln will.

Schön gesagt
smile.gif
Ich werd's mir übers Bett hängen. Aber die Tapete brauchte mal wieder einen philosophischen Anstrich.

Du verstehst mich teilweise falsch. Ich verfolge einen pragmatischen Ansatz.

Hier war nie ein Selbstbedienungsladen. Es geht doch darum, dass man seine Inhalte mit der Welt teilt, resp. die Welt daran teilhaben lässt. Die Blogger und auch P2P kommen diesem Grundgedanken übrigens derzeit am nähesten - und lustigerweise entwickelt sich das Web automatisch in diese Richtung.

Natürlich kann man auch mit Anwälten alles regulieren. Aber dann warten wir noch ein paar Volksabstimmungen bis das Internet mal kommt.

Es ist Dein absolut gutes Recht, für Deine Arbeit entschädigt zu werden. Das stelle ich nicht in Abrede. Im Gegenteil: Ich lebe ja davon. Und auch als Benützerin kaufe ich letztendlich einiges bei Amazon, registriere Shareware, usw.

Aber weshalb um Himmels Willen wird mit Brachialgewalt versucht, PHP zu verschlüsseln, resp. vor fremden Augen zu schützen?

Du kannst das "philosophisch Predigen" nennen. Ich nenns Pragmatismus: Java und ASP.NET generieren Kompilate. Die lassen sich ohne Töölelis verkaufen...
 
Jetzt bitte nochmals für einen dummen Bürogummi wie mich: Wie soll das funktionieren? Wie interpretiert der Server verschlüsseltes PHP ohne dass er modifiziert wird? Wie interpretiert der Browser verschlüsseltes HMTL oder JS ohne zusätzliche Software beim User? Ich kapier's nicht...
 
QUOTE (grooviak @ Fr 22.10.2004, 13:54)Wie interpretiert der Server verschlüsseltes PHP ohne dass er modifiziert wird? Wie interpretiert der Browser verschlüsseltes HMTL oder JS ohne zusätzliche Software beim User?
Der Server interpretiert *kein* verschlüsseltes PHP. Das Tool verschlüsselt die auf der Festplatte liegenden PHP-Files (an die ja sowieso niemand rankommen sollte). Das Tool hat dann ein eigenes PHP-File, das die Entschlüsselung besorgt -> der Server entschlüsselt jedes PHP-File vor dem Ausführen mittels diesem mitgelieferten PHP-Entschlüsselungsfile.

Auch der Browser kann kein verschlüsseltes HTML/JS interpretieren. Leider gibts keine verschlüsselte Beispielseite (warum wohl...), aber es muss wohl so sein, dass mit dem verschlüsselten HTML/JS-Code auch eine JS-Entschlüsselungsfunktion an den Browser gesendet wird. Damit tut der Browser das gleiche wie der Server, er entschlüsselt den Code vor dem Interpretieren.

Das sind nur meine Annahmen - falls es aber wirklich so ist, wärs für die Katz. Weil jeder, der an die PHP-Files rankommt, mit dem PHP-Entschlüsselungsfile alle anderen PHP-Files entschlüsseln kann - und ebenso kann auch jeder mit der JS-Entschlüsselungsfunktion den HTML/JS-Source entschlüsseln.

Leider hab ich bei mir kein PHP, sonst würd ich mal die Demo runterladen und die generierten HTML-Files ansehen ;-)

Griessli
Irene
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben