Bonjour,

Je vous présente une petite classe sans prétention qui vous permettra d'obfusquer partiellement une source php. Elle tient compte des dépendances de façon récursive lors de l'obfuscation afin que vos scripts obfusqués restent compatibles avec l'ensemble de votre projet.

Cette classe a été testé sur des projets de taille moyenne, sans soucis. Merci de me signaler d'éventuels bugs que vous pourriez repérer.

Voici le lien vers la classe:

http://www.openbio.fr/php/qkobs.html

Vous trouverez la documentation sur http://www.openbio.fr ou sur http://forum.hackbbs.org/viewtopic.php?t=3758

J'ai également mis une démo en ligne à cette adresse:
http://www.openbio.fr/tools/
Attention, la config de mon hébergeur fait que les quotes et doubles quotes sont automatiquement échappés, d'où l'ajout de slash superflus dans le résultat de la démo.
Je réglerai ça dès que j'ai un moment.

En espérant que ça vous sera utile.

La tortue.

sympa !... par contre, je me ose une question ::

- lors de l'obfuscation des noms de variables, suis tu un algorithme strict ?
=> est-ce que lorsque l'on répète cette opération sur différents fichiers qui vont à un moment donnés utiliser les mêmes variables (includes, ... ) elles vont toutes conserver un nom commun ?
=> sinon, comment faire ?

=> donc cela serait une faille qui permettrait ainsi aisément de réaliser l'opération inverse ^^
=> as tu prévus un fichier annexe ou les utilisateurs pourrais configurer leur propre algorithme servant à encrypter ces dites "variables" ??

je sais, je suis chiant .. mais ça m'intéresse bien

Merci de ton intérêt pour ce projet, Nours.

- lors de l'obfuscation des noms de variables, suis tu un algorithme strict ?

Qu'est ce que tu appelles "algorithme scrict" ?

En fait, l'idée est juste d'avoir une clase qui replace les noms de variables par des chaines aléatoires, histoire de rendre plus ardue la relecture du code. Quelqu'un d'obstiné y arrivera en y passant le temps qu'il faut.

=> est-ce que lorsque l'on répète cette opération sur différents fichiers qui vont à un moment donnés utiliser les mêmes variables (includes, ... ) elles vont toutes conserver un nom commun ?

Oui

=> as tu prévus un fichier annexe ou les utilisateurs pourrais configurer leur propre algorithme servant à encrypter ces dites "variables" ??

Non, a vrai dire, je n'y ai pas pensé du tout.

Pour ce qui est de la première question, j'avais pensé à écrire une sorte d'en tête qui se rajouterai à tous les fichiers. Cette en-tête serait en réalité un trampoline vers un fichier externe ou les variables fonctions etc. seraient remplacés par un certain nombres d'opérations équivalentes toutes concaténées dans un même fichier. L'idée est que le code dans le gros fichier est réecris de telle façon que seulement 5 ou 6 variables différentes sont utilisées pour tout refaire. De cette façon, parvenir à relire le code pour retrouver l'algo de dépard serait particulièrement ardu.

En gros, on génère un fichier "CODE" où tout le code est réecris suivant un algo X (que l'utilisateur pourrai éditer) et on garde juste dans les fichiers originaux une routine qui saute au bon endroit dans le fichier "CODE" afin de concerver l'arborescence.

Un souci possible de cette méthode pourrait être le temps d'éxécution qui pourrait se voir bien augmenté. Enfin bon, ça reste à quantifier, ce sera de toute façon dépendant de l'algo d'obfuscation utilisé et de la quantité de code superflu ajouté.

Qu'est que vous pensez de cette idée?

J'ai l'intention de continuer un peu ce projet à mes heures perdues, je serai heureux de tenir compte de vos suggestions =)

La tortue.

PS.: Est-ce que vous savez comment marche ionCube? Est-ce que c'est la source elle même qui est obfusquée ou est-ce que l'obfuscation a lieu au niveau bytecodes ?

pourquoi t'utilise pas le tokenizer pour parser la source ?
par contre c'est quoi l'intérêt de changé le nom des variables ?

par contre c'est quoi l'intérêt de changé le nom des variables ?

9/10 c'est pour éviter que le gars à qui tu vends un site à bas prix en misant sur du longs-terme rompe le contrat moral et parte à la concurrence ... c'est pas bô, je sais

mais quand tu signes un contrat de maintenance sur 5 ans et que le gars t'envoies boulet au bout de six mois car il à le fils d'un collègue qui sais faire des sites internet et qui va s'en occuper ... pour qu'ensuite, tu doive passer un mois à nettoyer toutes les M@rdes que le mino à foutus en plein milieu ... même si t'es mieux payer ... c'est pas cool !...
Donc, tu masque au maximum ton code et reste seul détenteur de la clé ... durant la durée de ton contrat ...

Qu'est ce que tu appelles "algorithme scrict" ?

Ben en faite, je me poses 2/3 questions :

si l'algo n'est pas "strict" et suivant une combinaison définie et qu'il utilises des variables aléatoire pour transformer ne nom des variables, je conçoit qu'il puisse conserver le même nom "masqué" durant une session donnée pour utiliser systématiquement le même nom "masqué" aux mêmes variables. mais je ne vois pas comment faire pour réaliser cette opération en plusieurs étapes !... ou plus précisément : j'ai obfusqué tout mon logiciel (500pages) il tourne sur le serveur sans soucy ... et je me rends compte qu'à un endroit il manque une virgule ou je ne sais quoi !
je prends mon dossier source, trouve le fichier et la variable à modifier et :: suis-je obligé de tout re-obfusquer ? ou puis-je simplement encrypter ce script et les noms de variables seront toujours correspondant avec ceux traités le mois dernier ??

donc si il y a un algo avec une clés précise, rien n'empêche le codeur de modifier et garder "secret" cette clés pour éviter que quelqu'un arrive à affecter une opération inverse et retrouver ainsi aisément les noms des variables.

Merci

pourquoi t'utilise pas le tokenizer pour parser la source ?

Ca aurait été beaucoup plus propre, effectivement. Je me suis dit qu'avoir un parseur perso basés sur des regex me permettrait d'avoir plus de flexibilité si je devais effectuer des opérations directement pendant le parcours du fichier.
J'avoue qu'en me relisant je m'aperçoit que j'ai probablement mal pensé. C'est terriblement brouillon.

Faudra que je refasse ça.

+1 nours, en fait c'est exactement ce pourquoi cette classe a été codée.

L'objectif n'est pas d'avoir une source complètement obscure, au quel cas il aurait mieux vallu bosser au niveau des bytecodes. C'est juste de la rendre très difficilement maintenable par quelqu'un qui ne l'a pas écrite.

Pour répondre à ta question, pas besoin de réobfusquer. Si tu dispose de la source en clair, tu dois pouvoir retrouver sans trop de problèmes l'endroit qui bug et y apporter directement les modifications nécéssaires.

La tortue.

par contre c'est quoi l'intérêt de changé le nom des variables ?

9/10 c'est pour éviter que le gars à qui tu vends un site à bas prix en misant sur du longs-terme rompe le contrat moral et parte à la concurrence ... c'est pas bô, je sais

mais quand tu signes un contrat de maintenance sur 5 ans et que le gars t'envoies boulet au bout de six mois car il à le fils d'un collègue qui sais faire des sites internet et qui va s'en occuper ... pour qu'ensuite, tu doive passer un mois à nettoyer toutes les M@rdes que le mino à foutus en plein milieu ... même si t'es mieux payer ... c'est pas cool !...
Donc, tu masque au maximum ton code et reste seul détenteur de la clé ... durant la durée de ton contrat ...

oui je vois, mais pour ca y'a phar, zend guard ou bcompiler qui existe depuis longtemp, et la c'est du vrai code caché
mais la solution proposé la est intéressante, je sais pas si y'a des packages pear équivalent

phar, zend guard ou bcompiler

Oui, mais comme je l'ai précisé, le but n'est pas d'avoir un code impossible à réverser, mais de rendre suffisement difficile tout procédé de maintenance par quelqu'un qui n'a pas écrit les scripts originaux, d'où l'intérêt d'obfusquer directement la source. Je ne pense pas qu'un véritable chiffrement (et toutes les contraintes qui vont avec) soit nécessaire dans ce cas.

je sais pas si y'a des packages pear équivalent

Non, pas à ma conaîssance. Il y a deux applications qui proposent de faire la même chose que cette classe, mais toutes les deux sont payantes et à code fermé (mmm la bonne arnaque).

La tortue.