ionCube Logo
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


 
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder

FEATURE REQUEST: Ability to obfuscate but not encrypt

Author Message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Fri May 12, 2006 3:01 am    Post subject: FEATURE REQUEST: Ability to obfuscate but not encrypt Reply with quote

There is the occasional instance when it is preferable for us to simply use obfuscation instead of encryption.

(ie: For an installer file where we have no idea if ioncube loaders are working, and we want to run a test script, etc...)

The idea here is that we don't need "heavy" encryption of the regular ioncube encoding system, but just basic obfuscation like:

- remove all linebreaks, speacing, and comments, etc..
- obfuscate variable names, function names, etc...

Basically, it would be nice to have a switch in the ioncube encoder where we can turn on/off the actual "encoding". So everything else would be done, except for the final encoding part.

Thanks!
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 12:44 pm    Post subject: Reply with quote

Hi

Noted, however the thing to take on board with obfuscation is that on it's own, it's really a rubbish technique of virtually no merit and more downsides than anything.

There are two main "problems" with pure source code obfuscation:

1) It doesn't stop the code from being copied and run, and so is of no value for that purpose at all
2) Formatting changes are trivial to reverse by using a code beautifier

The only aspect in such a technique that may be impossible to undo is the renaming of functions and variables, but unless the code would need to be heavily modified by someone stealing it, so what! The person in possession of the obfuscated code is simply not going to care.

So whilst obfuscation may seem like a nice idea in principle, it's actually worthless, and with the dynamic nature of PHP may cause problems in the code that need fixing up and that may only occur when end users have problems.

As an auxilliary technique to other mechanism there is more value if the obfuscation affects not just static function calls within the main codebase, and where obfuscated names work just as well as unobfuscated ones, but where calls are made to obfuscated functions in another codebase. The potential value here is that unless the obfuscation mechanism can be reversed, it may be impossible to determine what functions are being called in the external codebase and so prevent reconstruction of a working program. But other than that, whilst obfuscation sounds impressive when you say it, that's about the best of it.
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 2:17 pm    Post subject: Reply with quote

Hi Nick,

I agree with you 100%. But as I mentioned, there are the odd occasions when all we need is for basic obfuscation. In fact, sometimes it's all we CAN do.

ie: We don't need encryption -- we just need a simple "make it harder for the average person to read the code" system. We do this for our autoinstaller program, which then checks to see if ioncube is installed on the server, what version it is, etc... And then fetches the actual encrypted (with ioncube) files IF all is ok..)

For example, I do this right now with this code below, to get a basic obfuscated php file:

Code:
<?php
$code = php_strip_whitespace("autoinstaller-source.php");
if (file_put_contents("autoinstaller.php", $code)) {
   echo "Done. Wrote the autoinstaller.php file.";
}
else { echo "Failed."; }
?>


I would much prefer to use ioncube to do something like this, because I think you'd make a better system. (ie: the php_strip_whitespace() function leaves HTML alone so the user can easily see all html in the code, etc..)

I hope that makes sense. Obviously this isn't supposed to replace encryption, and anyone who uses "obfuscation" instead of encryption is a moron.

But like I said, there are the odd occasions when encryption is all we can use or all we need.

Thanks!
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 3:16 pm    Post subject: Reply with quote

Hi

I understand where you're coming from, but my assertion on this issue is that whilst you could just obfuscate your source, it is a technique where there really is no point on its own as it offers no benefit. Pure naive obfuscation is not only just an illusion of security, it's an illusion where everyone can see how the trick is done!

In the first case and for the vast majiroty of people the source code is most likely of no interest or use anyway and so giving it to them is fine. For those that migjht want to take advantage of the code for their own benefit, it wouldn't stop them at all. This is because formatting changes can be automatically undone in seconds with a code beautifier, and these tools exist freely on the web, and even mangling names doesn't stop someone from changing the code. It's understood that in some cases the illusion of security can be effective, but this technique really doesn't even give that.

Assuming that the core application that gives you your competitive edge and that has your trade secrets is suitably protected, any peripheral code that for one reason or another you don't want to encode will probably not be a business risk if provided in pure source code, and it might be a better business strategy to put the time and effort spent on obfuscating peripheral code into new core features, getting products out sooner etc.
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 3:21 pm    Post subject: Reply with quote

Nick,

You're seeing this in black and white, while in fact there are many shades of gray.

I'm referring to the "users" who might want to see the php code.

You stated this:

Quote:
In the first case and for the vast majiroty of people the source code is most likely of no interest or use anyway and so giving it to them is fine. For those that migjht want to take advantage of the code for their own benefit, it wouldn't stop them at all.


(I added the bold.)

The fact is that simple obfuscation would indeed stop a lot of these users.

I agree that ANYONE who truly wanted to see the correct source code would easily be able to do so.. .but the vast majority of simple PHP coders out there would not be able to "unobfuscate" the code. Smile

Anyway.. It's a simple feature request, and if you don't want to do it then that's your perogotive. As a customer, I'm simply stating my opinion that this feature is something that
would be beneficial to me, for my own reasons.

Cheers!
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 3:52 pm    Post subject: Reply with quote

Quote:
I agree that ANYONE who truly wanted to see the correct source code would easily be able to do so.. .but the vast majority of simple PHP coders out there would not be able to "unobfuscate" the code.


Maybe if they haven't heard of Google, but most people have. As an example, let's take our stock preamble that starts off encoded files, and that looks pretty unfriendly to the casual observer:

Code:
if(!extension_loaded('ionCube Loader')){$__oc=strtolower(substr(php_uname(),0,3));$__ln='/ioncube/ioncube_loader_'.$__oc.'_'.substr(phpversion(),0,3).(($__oc=='win')?'.dll':'.so');$__oid=$__id=realpath(ini_get('extension_dir'));$__here=dirname(__FILE__);if(strlen($__id)>1&&$__id[1]==':'){$__id=str_replace('\\','/',substr($__id,2));$__here=str_replace('\\','/',substr($__here,2));}$__rd=str_repeat('/..',substr_count($__id,'/')).$__here.'/';$__i=strlen($__rd);while($__i--){if($__rd[$__i]=='/'){$__lp=substr($__rd,0,$__i).$__ln;if(file_exists($__oid.$__lp)){$__ln=$__lp;break;}}}@dl($__ln);}else{die('The file '.__FILE__." is corrupted.\n");}if(function_exists('_il_exec')){return _il_exec();}echo('Site error: the file <b>'.__FILE__.'</b> requires the ionCube PHP Loader '.basename($__ln).' to be installed by the site administrator.');exit(199);


Ten seconds on Google for a search of "code beautifier", note I didn't even put in the word PHP in my search, flags up the following site http://www.tote-taste.de/X-Project/beautify/index.html as the second Google result; a side effect of PHP being quite popular.

I pasted in our preamble, and the result was:

Code:
if (!extension_loaded('ionCube Loader')) {
    $__oc=strtolower(substr(php_uname(),0,3));
    $__ln='/ioncube/ioncube_loader_'.$__oc.'_'.substr(phpversion(),0,3).(($__oc=='win')?'.dll':'.so');
    $__oid=$__id=realpath(ini_get('extension_dir'));
    $__here=dirname(__FILE__);
    if (strlen($__id)>1&&$__id[1]==':') {
        $__id=str_replace('\\','/',substr($__id,2));
        $__here=str_replace('\\','/',substr($__here,2));
    }
    $__rd=str_repeat('/..',substr_count($__id,'/')).$__here.'/';
    $__i=strlen($__rd);
    while ($__i--) {
        if ($__rd[$__i]=='/') {
            $__lp=substr($__rd,0,$__i).$__ln;
            if (file_exists($__oid.$__lp)) {
                $__ln=$__lp;
                break;
            }
        }
    }
    @dl($__ln);
} else {
    die('The file '.__FILE__." is corrupted.\n");
}
if (function_exists('_il_exec')) {
    return _il_exec();
}
echo('Site error: the file <b>'.__FILE__.'</b> requires the ionCube PHP Loader '.basename($__ln).' to be installed by the site administrator.');
exit(199);


It did a great job, and maybe it has other deobfuscation features that weren't required to be exercised by our preamble. The only reason we obfuscate our premble is to save space, and that's were the only benefit is.

Your right to want to obfuscate is of course valid, but I'm pretty sure that anyone smart enough to be able to genuinely benefit from the code that one obfuscated beyond a point of pure curiosity is going to be smart enough to deobfuscate it.
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 3:58 pm    Post subject: Reply with quote

Like I said, Nick...

1) It's just a simple feature request. It's something that would be useful to me. If you don't want to do it, then don't.

2) Sure, it's easy for YOU and ME to search google and do this. I realize that. But like I said, the vast majority of people who "code" in php are just script kiddies. I'm simply looking for a basic way to "hide" the code. Nothing more. I realize that they can easily get access to it if they wanted.

Lastly, I appreciate you showing me all this, and how easy it is to get the unobfuscated source, etc.. But like I said, this is a feature I'd like to see (for my own reasons) and if you don't want to do it, then don't. As a customer, it's something I'd like to see, and that's why I took the time to visit your forums and make my request.

Smile
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 4:05 pm    Post subject: Reply with quote

Posting the feature request and discussing the idea is certainly welcome, so thanks for that!

Even though not every feature can be implemented and may not hold up on analysis,
bringing thoughts to the table is what leads to further innovation and development in
one direction or another, and even if not in the way first invisaged, so it's all good
stuff and we're definitely not knocking the input Smile
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 4:11 pm    Post subject: Reply with quote

Thanks Nick!

Ioncube has really been a great tool for us. It's MUCH easier to use the the Zend system, and is also easier for our customers to get running.

Another suggestion that might be cool (not sure how easy to implement) would be some kind of system that works like this:

1) User uploads a "install-loaders.php" script.

2) script asks for ftp un/pw.

3) Script runs and checks what ioncube loaders are needed.

4) Latest loaders for the OS are auto-retrieved from ioncube.com and dropped into the folder, using FTP un/pw so the ownership is correct, etc... (and no worry about permissions).

That would be fantastic. We could then grab the code from that script and incorporate it into our own scripts..

As I have it now, I have an autoinstaller script that checks to see if Ioncube will work (cost taken for your own check script), and if so, grabs the ioncube version of my application and ftps it to their server, etc. The ioncube version includes loaders for linux, freebsd, and windows.

The problem is that the package size is over 5mb,and users complain about that. So it would be great if I could somehow detect what loaders are needed and then grab only those ones.

Smile

Just an idea. I think the only "difficult" thing about any encryption system is getting the right loaders installed, so anything to make that easier is good, imho.
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 4:23 pm    Post subject: Reply with quote

Our IPF system is one way to go for this. IPF created installed handle deployment of packages
to remote or local servers, can automatically setup custom file and folder permissions,
can run an interactive or batch post install script, allow local editing of any configuration
files with transparent and automatic reupload of the files, and handle the installation of
the correct Loaders into the users area for runtime install or installing via the php.ini file.
Furthermore, IPF installers can be custom branded with your own product graphics,
look like a familiar type installer to end users, and can be localised into different languages.
You can also create the installers not only from Windows, but also from Linux, which is
ideal for on the fly creation on the web server.

Whilst not everyone runs a windows client, statistically almost everyone does, and an IPF
created installer for web apps can make a good product look even better when compared
to those competitors still using the old world and unfriendly zip file approach to pushing out
their web products.
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 4:28 pm    Post subject: Reply with quote

I have tried the IPF previously and found it was pretty good.

The only thing that stopped me from using it was that most of our customers don't "understand" where the ioncube folder should be installed.

It would be fantastic if we could place a "special" file on the server (part of my installer sequence) and then the user runs the IPF, logs into their account, and "finds" the special file.

This way, the files are installed into the correct location, and everyone's happy.

Or perhaps some other way for the IPF to "speak" to the script on the server, so it knows where the loader files need to go.
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2801

PostPosted: Sun Jun 25, 2006 4:43 pm    Post subject: Reply with quote

IPF handled the ioncube folder for Loaders automatically and the user doesn't need to
know or care where the ioncube folder goes. Actually this has always been the case
so perhaps there was a misunderstanding there.

Pretty much all the user does is enter their FTP details, specify the
remote folder where the package should be installed (and they can browse remotely for this
if necessary, and specify the remote URL that corresponds to the install directory.
As a convenience, heuristics and server probing allow for the remote directory and URL
to be correctly determined by the installer and offered as defaults.

The package creator can also produce different types of install, such as those that have
no top level product folder, and packages where the top level folder can or cannot have
the name changed. The UI adapts as necessary to present the user with the correct
interface based on the requirements of package.

The remote target part of the installer UI went through a number of critical design
iterations based on user feedback from the early adopters and before arriving at an
interface that was both as straightforward for the end user as was possible given the requirements of the system, and also flexible enough to cover the requirements of the
different types of packages that people most typically create. There are extra features
on the wishlist, but at the core level it covers the deployment aspect very well now.
_________________
Community Admin
Back to top
View user's profile Send private message
electric



Joined: 10 Apr 2006
Posts: 27

PostPosted: Sun Jun 25, 2006 4:46 pm    Post subject: Reply with quote

I'll definately download the trial again and give it another shot. I wasn't aware that it was possible to auto-determine the appropriate folder.

Thanks Nick!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum