Interview: Die Zukunft von PHP-Beschleunigern

Golem.de: IonCube hat sich zunächst auf einen Encoder konzentriert, der es erlaubt, PHP-Scripte zu veröffentlichen, ohne deren Quelltext herauszugeben. Wie ist der aktuelle Status dieser Bemühungen?

Nick Lindridge: IonCube ist einer der Marktführer im Bereich von Encoding-Technologien für PHP. IonCube wurde im Jahr 2002 gegründet, um der Nachfrage nach einer bezahlbaren und qualitativ hochwertigen Encoding-Lösung nachzukommen. IonCube hat den Markt seitdem zunächst mit einem innovativen und einzigartigen Online-Encoding-Dienst angeführt und kurze Zeit später ein eigenständiges Encoding-Werkzeug veröffentlicht. Seit der ersten Version im Winter 2002 hat der eigenständige Encoder einen neuen Standard für Encoding-Software gesetzt. Bevor ionCube auf den Markt trat, gab es nur eine sehr teure, unzuverlässige Encoding-Software, die viele wirklich notwendige Funktionen vermissen ließ. Der ionCube Encoder hingegen wurde zu einem bezahlbaren Preis angeboten und mit nützlichen Funktionen ausgestattet, die funktionieren. Sicherheit ist eines der fundamentalen Design-Ziele von Encoding-Werkzeugen. Bei den meisten PHP-Encoding-Tools, die derzeit auf dem Markt sind, geht es vor allem darum, den Quelltext zu kodieren und während der Ausführung wieder zu dekodieren, um diesen dann mit Hilfe des eval()-Ausdrucks von PHP ausführen zu lassen. Zwar bieten diese Tools einen deutlichen Kostenvorteil gegenüber den teuersten Alternativen, allerdings darf man eben nicht nur diesen Kostenvorteil betrachten, da sie kaum oder gar keine Sicherheit bieten. Es mag einige Leser überraschen, aber der Mangel an Sicherheit von solchen Quelltext-basierten Produkten liegt vor allem daran, wie einfach es ist, die PHP-Engine dazu zu bringen, den wiederhergestellten Quelltext wieder sichtbar zu machen, wenn er kompiliert werden soll. Eine zusätzliche Zeile C in der PHP-Engine reicht aus, um den Quelltext bei diesen Produkten wiederherzustellen, was wir als großes Problem ansehen.

Unsere Encoding-Werkzeuge hingegen verwenden einerseits einen optimierten kompilierten Code, bei dem der Quelltext eliminiert wird noch bevor das Encoding stattfindet, zum anderen eine spezielle Ausführungseinheit innerhalb des Loader. Dies führt dazu, dass die kodierten Dateien nur in Form von Binärdaten, nicht als Quelltext wiederhergestellt und dann innerhalb des Loader ausgeführt werden statt in der Open-Source-Ausführungsroutine von PHP. Auch wenn kein System immun gegen Angriffe von Hackern ist, stellt dies doch eine signifikant größere Hürde für ein Reverse Engineering dar.

Golem.de: Könnten Sie sich ein allgemeines Framework vorstellen, das in die offizielle PHP-Distribution integriert verschiedene Encoder unterstützt und somit die Hürde eliminiert, zunächst einen Loader installieren zu müssen?

Nick Lindridge: Zunächst einmal ist es wichtig zu erkennen, dass es letztendlich aus Sicherheitsgründen notwendig ist, einen Closed-Source-Loader zu haben. Ein "One-Loader-Fits-All-Produkt" ist technisch möglich, aber es ist realistisch gesehen unwahrscheinlich, dass so etwas passiert. Ein Ansatz wäre aber, die Loader-Komponenten der wichtigsten Anbieter standardmäßig mit jeder PHP-Distribution auszuliefern, einschließlich der offiziellen Distribution der PHP-Group. Es gäbe zwar einige kleine logistische Herausforderungen, um dies umzusetzen, aber prinzipiell wäre dies ein gangbarer Ansatz, der der PHP-Community zugute kommen würde.