En fait j’ai telecharger une demo d’un script php, et lorsque j’ai ouvert les fichiers j’ai constater qu’il n’y avait que une ligne du genre
[cpp]<?php
hum … le principe doit être comme avec Zend SageGuard …
en gros, le fichier est “encrypté” et ne peut être lu que sur un serveur équipé du module de “décryption” …
cela permet de distribuer des applications propriétaires et d’être sur que le client n’iras pas fouiner dans le code source, pour par exemple faire sauter les protections etc …
Mais ca marche sur n importe kel serveur justement ! c’est un script telechargeable sur le site perso du mec, et on peut l utiliser n importe ou.
donc le code doit vouloir dire quelque chose, eval ca permet d’interpreter du code php non ? j’imagine que la ligne contenant la variable $_ contient en fait des caracteres sous une certaine forme et puis que eval les lit , enfin bref juste un camouflage koi…
Enfin je me trompe peut etre mais j’aimeraien bien comprendre ce truc
je suis en train de travailler là dessus justement :oui:
Edit: mais le code que tu montres n’y ressemble pas trop
en effet, quand on le test, il indique qu’il ne peut pas accéder à une fonction :
Fatal error: Call to undefined function bae() in F:\Inetpub\wwwroot\test.php(13) : eval()'d code on line 1
Donc d’apres toi kisscool la variable $_ pourrait contenir du code binaire php compiler via le module bcompiler, ki est ensuite evaluer par les appel succesif a eval ?
moi je pense plutot que que c’est du code php encodé, et que la fonction bae (que j’arrive pas encore a trouve :D) est chargée de décoder puis d’exécuter
c’est ce que je pensais en plus
$_, ca ressemblais à du base64 je me disais (terminé par un ‘=’)
donc c’est super bien fait ce truc
quand on remplace:
eval("\145\166\141\154\50\142\141\163\145\66\64\137\144\145\143\157\144\145\50\44"."\137\51\51\73");
la connaissance, ça n’as pas de prix … ou alors je n’ai pas compris ce qu’ont m’as appris à l’école :jap: …
s’il ne voulait pas qu’on puisse lire son code, il ne devait pas utiliser une technique de sécurisation “privée”, qui est moins puissante qu’une technique de sécurisation “publique” (c’est du moins ce qu’on apprend dans les bouquins de sécurité informatique :o )
et bon, comme démontrer, le système de “cryptage” du code utilisé ici est juste dissuasif : il n’empêche pas de retrouver le code original …
s’il voulait une protection plus complète, le gars aurait du utiliser bcompiler, qui est relativement efficace (bien que l’extension soit encore un peu “jeune”)
Exemple de code bcompiler :
comme on vois, les données sont en clair … par contre le détail de la fonction ftest :sarcastic:
et s’il voulait vraiment une protection ultime, il aurait du utiliser un soft avec un module sur le serveur web, comme Zend SafeGuard + Zend Optimizer quii permet d’avoir un fichier binaire du source PHP, qui est directement executer par PHP (sans passer par l’interpréteur, mais par l’optimizer) … ça, à ma connaissance, c’est irréversible comme protection (penser à sauvegarder vos sources avant :D) … seul soucis pour cette dernière solution, c’est le coup relativement élever du logiciel de “compilation” …
Exemple de code ZSG (chercher mon mot de pass root là dedans :D) :
oui mais là c’est fait pour protéger des script destinés à être distribués au plus grand nombre, donc ils ne peuvent pas se baser sur des modules serveur ou autre
Donc à partir de là, il n’y a pas de mystère, si le compilo php standard peut comprendre le code, nous aussi
S’ils veulent pas qu’on voit leur code, il ne faut pas qu’ils fassent du php
meme cette histoire de bytecode, ca me fait penser à java et .net, un jour il y aura quelqu’un qui va sortir un décompileur qui nous affichera le code source original (peut etre un peu déformé et décommenté, mais qui fera la même chose)
bah étant donné que t’es obligé d’avoir un Zend Optimizer pour utliser les fichiers “binarisé”, il y’a de toute façon un gain de performance ~40% :oui: