PureBoard

Dadido3 hat geschrieben:Meine Vorgehensweise:

danke! Anhand Deiner Anleitung konnte ich das jetzt auch mit wenigen Klicks nachvollziehen.

Auf die Idee, den Browser in den Pausenmodus zu setzen, um dann das Button-Click-Event abzufangen, bin ich gar nicht gekommen.

Hintergrund der Aktion: Diese 'Verschlüsselung' ist eine Art Zusatz-Feature eines Transpilers, den ein befreundeter Programmierer geschrieben hat. Er hat mich darum gebeten, eine Einschätzung abzugeben, wie schwierig es ist, an den unverschlüsselten JS-Code zu kommen. Da ich das selber nicht beantworten konnte, habe ich diese simple Seite erstellt.

Mir ist natürlich klar, dass sensible Daten nichts im clientseitigen JavaScript verloren haben.

Nochmals Danke an alle Mitwirkenden für den Input & Grüße ... Peter

So ganz verstehe ich nicht, warum selbst heute noch das unendliche Bedürfnis besteht, Quellcodes von z.B. Javascript oder auch PHP verschlüsseln zu müssen. Das Problem an diesen Sprachen ist, das sie zu den neuesten Generationen gehören und Runtimes sowie Paketmanager einen extrem großen Teil der Funktionalitäten stellen. Dadurch wird der eigentliche Anwendungscode in den Hintergrund rücken. Ich weiß, das man versucht seinen Code zu schützen. Aber wirklich Sinn macht das nur bei kompilierter Software. Bei JS oder auch PHP kann man nahezu jede Funktionalität binnen weniger Minuten nachprogrammieren.

Man liefert den Schlüssel dem Browser zwangsläufig mit aus. Außerdem landet bereits der entschlüsselte Code im RAM und da Browser die Debug-Tools dabei haben, ist das analysieren des Codes keine Herausforderung mehr.

Das beste ist eine Mischung aus Kompression und Obfuscator. Es verschwendet keine Performance und es bedarf schon einiges an Kleinarbeit, um einen nachvollziehbaren Code zu erhalten. Es ist aber dennoch nicht wirklich sicher. Es erhöht nur den Aufwand. Wenn es aber um Strings im Code geht, dann würde ich schauen, auch nur die zu verschlüsseln und anstatt Schlüssel direkt in den Code zu schreiben, den Schlüssel aufwendig errechnen zu lassen. Aber auch hier gilt: Wenn mit den Daten gearbeitet wird, liegen sie irgendwann unverschlüsselt im Speicher!

Ich gebe dir Recht, TroaX, aber ich verstehe das Beispiel mit PHP nicht. Das läuft ja nicht clientseitig. Das kann also niemand einfach so auslesen. Höchstens der Betreiber des Servers selbst, aber das wäre dann ja bei allen Skriptsprachen so.

NicTheQuick hat geschrieben:Ich gebe dir Recht, TroaX, aber ich verstehe das Beispiel mit PHP nicht. Das läuft ja nicht clientseitig. Das kann also niemand einfach so auslesen. Höchstens der Betreiber des Servers selbst, aber das wäre dann ja bei allen Skriptsprachen so.

Das kommt idR dann zum Tragen, wenn man Software verkauft.

Du hast ein tolles Programm, wie z.B. so ein Forum (gibt ein paar, die was kosten), oder ein Ticketsystem oder,... Du verkaufst die Software und willst natürlich nicht, dass jeder Horst deine Ideen klauen kann.
Ggf. kann man sogar die Lizenzierung darüber ablaufen lassen, wie weiter oben erwähnt: Der gesamte Code ist mit "12345" verschlüsselt, was gleichzeitig auch der Lizenzschlüssel ist. Kunde B bekommt eine Version, die mit "98765" verschlüsselt ist.

Das selbe hast du doch hier auch. Dieser Ruf nach einem "static lib"-compiler, so dass man den Code seiner Includes nicht preisgeben muss, der Endanwender aber trotzdem keine nervige DLL einbinden muss.

Genau darum geht es. Vertrieb der Software. Ohne verschlüsseltem Code gestaltet sich der Vertrieb nur wenig gewinnbringend. Bei PHP wurde lange Zeit der IonCube-Loader verwendet, um die Anwendung zu ver-/entschlüssen. Das Problem dabei ist nur, das man heute für nahezu jeden Einsatzzweck das passende Schwergewicht an Framework zur Verfügung hat und dadurch jede Funktionalität mit wenig Code nachempfinden kann.

Im Grunde schützt man damit nur die Fingerübungen für versierte Programmierer. Und das ist mit Javascript nicht anders.