Hello,

i'm programming scripts using php and buy them as license for each domain

i was using zend gaurd for protecting them from stealing , but as everybody know zend now very easy to decoding .

i'm searching for the new way to keep our copyrights protected.

can anybody please help me?

Regards
Allomani

There is ioncube, but I don't know how easy it is to decode, if possible at all.

the problem of ioncube that it's not supported in most hosting companies...

But it has redistributable decoders. You simply add the decoder folder and everything works.

Not always. I had trouble when installing WHMCS, the redistributables didn't work correctly and I had to compile PHP with IonCube in the end.

Not always. I had trouble when installing WHMCS, the redistributables didn't work correctly and I had to compile PHP with IonCube in the end.

I'm not exacty sure but it has different loaders for different PHP versions. Most people don't have problems, I'm not sure about the specifics.

ionCube :)

It does come with free loaders/readers that will automatically install onto the clients server if it even has to it all :)

It supports licensing to certain domains, ip's, license keys, ect.

A big + to it: It's nearly impossible to decode...

amazing isn't it :)

Anyways, ionCube is the way to go :)

It can be expensive, but if your selling your software then you will easily earn it back.

If there is a way people will break into it. Even with binary data (ie compiled executables) it is still relatively easy to get the code back (a bit not very easy on the eyes).

There isn't going to be a 100% way to protect your intellectual property. My guess is you should continue with zen guard (after all, you forked 300+ dollars for it).

As above it is normally very easy to use the different loaders, as long as it is php 5.2 or below and safe mode is *not* enabled you can dynamically include the loader, but since 5.2.5 you cannot do this and must include the loader in the PHP extension_dir folder - which means the host must do this for you.

The PHP encoders I see as contenders are...

IONCube.com
nusphere.com
sourceguardian.com

I would be interested to hear of any others or other users experiences of these.

Cheers,
Sean

As above it is normally very easy to use the different loaders, as long as it is php 5.2 or below and safe mode is *not* enabled you can dynamically include the loader, but since 5.2.5 you cannot do this and must include the loader in the PHP extension_dir folder - which means the host must do this for you.
.... unless host allows per directory php.ini files in which case you can setup up your own extension_dir.

Anyway at $100 per year, ease of use, quick responses from tech support (which you really need only if you have some very odd situation going on), ability to transfer license from one machine to another - Ioncube is the winer (for me as least).

And last but not the least, What-is-his-name of Ioncube frequents this forum so you have more then one way to get his attention if you ever need to do so (not that I think it will ever be needed, but I reserve the right to post "ioncube suck$" thread here if I cannot get in touch with their support :) ).

ioncube has an online encoder, which encode files with per-code-block pricing. Something around $5 for 10 pages of PHP code.

guys i heared that ioncube can decoded , and the best example Whmcs found nulled.

any explains?

guys i heared that ioncube can decoded , and the best example Whmcs found nulled.

any explains?

No matter what it's going to be possible to decode it because it has to execute at some point (if it was encoded and couldn't be reversed, how would the PHP execute?).

IonCube and Zend Guard are going to be your best bets.

i tried to install ioncube on bluehost hostng account from cpanel , but it's not working

http://www.allomani.biz/ioncube/ioncube.php

It's likely BlueHost already has IonCube installed - I would inquire with their support / knowledge base.

I heard ionCube was nearly impossible to crack... I have been lied to :'(

I heard ionCube was nearly impossible to crack... I have been lied to :'(

It's very difficult - and only a handful (if that) of people have done so. 99.99% of people won't be able to.

Ok :) that's reassuring then :) It's expensive... so that must mean they pay people good money to build it right?

I know I'm not good enough to decode any of ioncubes scripts :P

the main problem now is servers supporting , i tried ioncube on several hosting services and i found about 1 of 10 servers only supporting it !

we are programming company we have to support most servers , any ideas ?

ionCube has one of the largest web host supported bases out there for a PHP / Zend extension. I'm very surprised by your statement, considering that most web hosts will allow you to use the included ionCube Loaders through the top of your PHP files (using the dl() function.)

In that case I'd contact those hosts who you have found to be incompatible with ionCube and ask if there is anything that you are doing wrong, if their servers block the dl() function or if you can have it installed by asking. :)

Even if you have to ask for it to be installed, or your clients do, it's better than (in my opinion) the money lost through your scripts getting cracked easily.

Hope that helps,

If someone is wanting to steal your code or product, they will likely find a way to do so. Concentrating ones efforts on customers that want to buy the product may be more worthwhile than scrambling to find a stronger encoder.

Dark Light , yes of course it is a good solution now but i'm afraid after all this the scripts cracked again

coz there is already some websites supporting ioncube decompiling like : [url removed]

EasyGoingGuy , actually we are not facing only customers ! the most people who want to decode are people who want to sell the scripts in lower price to get some money !!

Code is similar to content; if the computer can process it, it can be harvested back, either in a neat or an ugly way, I'd say the only real solution would be to offer something back to encourage buying the script, such as decent support and a lot of upgrades/patches.

EasyGoingGuy , actually we are not facing only customers ! the most people who want to decode are people who want to sell the scripts in lower price to get some money !!

Surely this only accounts for a very small fraction of people though?

Code is similar to content; if the computer can process it, it can be harvested back, either in a neat or an ugly way, I'd say the only real solution would be to offer something back to encourage buying the script, such as decent support and a lot of upgrades/patches.

That is how I look at it.

Dark Light , yes of course it is a good solution now but i'm afraid after all this the scripts cracked again

coz there is already some websites supporting ioncube decompiling like : [url removed]Wow, that's interesting - it may be worth asking IonCube sales about it, I notice on qinvent forum they mentioned yesterday that they can not decode SourceGuardian now?
As mentioned by others I think it would only be a very small %age of people that would even try this - but I agree you need to protect your intellectual property.

Cheers,
Sean

If someone has easily cracked your ionCube protected PHP script in such a short time and assuming the ionCube protected code is all you distribute; personally I would be contacting ionCube to ask about it as xoozoo suggested. It's unusual for someone discussing these issues to find their scripts cracked so quickly or at all; I'd be interested in hearing the resolution to this if you are willing to update with more facts.

Thanks!

i bought ioncube and we will start using it...

Code is similar to content; if the computer can process it, it can be harvested back, either in a neat or an ugly way, I'd say the only real solution would be to offer something back to encourage buying the script, such as decent support and a lot of upgrades/patches.

This is spot on. Also, the most valuable thing is often an underlying idea or concept, and the only way to avoid people copying ideas is not to tell anyone about them, but no one ever got rich by keeping their ideas to themselves. Unless you seek to protect it with patents, once you've released an idea into the wild it's then ripe for being copied and adapted by others simply based on observation, and even patents may not help.

Hackers may try to steal code with a view to incorporating it into their own products, but it's relatively unlikely, and code theft is more commonly from people who simply don't want to pay for software. It's those characters that are primarily served by warez sites courtesy of "hackers" with no creativity and talent for software development themselves. The absence of a hack is definitely not enough to make warez residents pay for software instead of using a hack.

Once an idea has been seen, competitors are likely to have sufficient skill to implement and incorporate the idea into their own product by themselves, possibly improving upon it or making some differences. Unless a self contained module with a well designed API, taking stolen code from someone else would be relatively difficult and more than likely impossible to shoehorn into a product due to differences in database design and code structure in general. Copying an idea and providing ones own implementation is far more likely.

For software developers, encoding PHP scripts is primarily about keeping the honest people honest and giving potential customers a need to purchase, which is something that is difficult if full featured evaluations are provided in source form. Enforcing licensing models is also difficult if not impossible where the licensed code is in source form, and would generally need to be trust based. Having encoded files offers a more satisfactory solution to licensing by allowing techniques such as domain locking, and while there will always be some end users who seek to trick and defeat licensing systems, most aren't going to.

As for hosts supporting different encoding solutions, searching WHT will reveal numerous hosts offering support for Zend and ionCube encoded files, although support is usually not there for other products that have server side modules. There are certainly some companies such as Yahoo! for whom hosting is not their core business and who do not support Zend, ionCube or any extension modules, and some of the smaller resellers may similarly not do so. However most reputable hosting companies whose core business is hosting are likely to support Zend and ionCube already or if needed as both products are very well established and well known in the industry and have been for many years now. Hosts should also recognise and be aware that many of their peers offer similar support, and they would probably want to offer good support for their customers. I don't know about other companies, but we're also very happy to spend time answering any queries from hosting companies about installation choices and implications, and this willingness to cooperate with the hosting market may help too.

A good product, ideally protected, good support that might even include a telephone number, and regular updates at least while the product is young and not so mature, gives a developer every chance of being successful and plenty of reason for those potential customers who are quite happy to purchase to actually do so.

I've been using IonCube for a while now and have been very happy with it, never had an IonCube release of my scripts nulled.

Guys about license requist generator , it generate for 12 interface without any ip, how can i know which file i have to send ?


Generating license requests for computer "ALLOMANI-Dell".
Please ensure that this is the correct computer to license.

A license request for interface eth0 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth0.txt

A license request for interface eth1 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth1.txt

A license request for interface eth2 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth2.txt

A license request for interface eth3 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth3.txt

A license request for interface eth4 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth4.txt

A license request for interface eth5 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth5.txt

A license request for interface eth6 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth6.txt

A license request for interface eth7 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth7.txt

A license request for interface eth8 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth8.txt

A license request for interface eth9 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth9.txt

A license request for interface eth10 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth10.txt

A license request for interface eth11 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth11.txt

A license request for interface eth12 (0.0.0.0) was written to file
C:\Program Files\ionCube PHP Encoder 6.5\licreq-eth12.txt

Please select a license request file for ONE network interface and send
the file to licenses@ioncube.com for processing.

Press any key to continue . . .

There is ioncube, but I don't know how easy it is to decode, if possible at all.

True. But if you are recommending your script for a person owning a vps/dedi, then I suggest use it with ioncube like what ihostdev is using.

about binary or ASCII encoding mode ? which better ? ot they are same ?

about binary or ASCII encoding mode ? which better ? ot they are same ?

Use ASCII.

PHP files are usually text files, as they normally aren't compiled. As a result, FTP clients will automatically default (in 99% of cases) to uploading them in ASCII.

If you have only used a binary format, e.g. what Zend Guard produces, or not asked ionCube to produce the ASCII version, when your user does that they'll corrupt the file and it won't work. Users then need to delete everything, set the FTP Client to 'forced binary' and re-upload. It's annoying for users, and really annoying for people selling the product - the number of support tickets that are generated by "it is saying corrupt", despite FAQ's, forum posts, instructions etc.... detailing what to do is quite unbelievable!

Using the "ASCII wrapper" in ionCube will produce a file that can be uploaded by FTP software in ASCII straight away, it won't corrupt, and users won't be any the wiser what's going on.

Plus points for you and plus points for the user. I can't think of any negative points to not using it, except perhaps it makes the files slightly larger.

I have used Ioncube on several projects and scripts I have worked on since December 2007 but for the first time just a few days ago my script was decoded! And I use the latest version of Ioncube in PHP5 too! Ioncube is now useless for me and Nick of Ioncube will not refund me and claims its not his fault it can be decoded.:angry:

I have used Ioncube on several projects and scripts I have worked on since December 2007 but for the first time just a few days ago my script was decoded! And I use the latest version of Ioncube in PHP5 too! Ioncube is now useless for me and Nick of Ioncube will not refund me and claims its not his fault it can be decoded.:angry:

I do not mean to be rude, but, I do not believe Nick has ever guaranteed that ionCube will offer 100% protection.

If Microsofts billions cannot make Windows pirate-proof, I think it is ludicrous to expect a $199-350 software package to offer bullet-proof protection.

If you search this forum, Nick has been very good at explaining the weaknesses with different solutions (including ionCube's).

The point with any anti-piracy solution is to, ultimately, have more people buying and paying than if you did not use an anti-piracy solution. I imagine the $199 you paid ionCube (or whatever) has already been made back several times :)

I do not mean to be rude, but, I do not believe Nick has ever guaranteed that ionCube will offer 100% protection.

If Microsofts billions cannot make Windows pirate-proof, I think it is ludicrous to expect a $199-350 software package to offer bullet-proof protection.

If you search this forum, Nick has been very good at explaining the weaknesses with different solutions (including ionCube's).

The point with any anti-piracy solution is to, ultimately, have more people buying and paying than if you did not use an anti-piracy solution. I imagine the $199 you paid ionCube (or whatever) has already been made back several times :)

Yes that is true but I am not saying it should offer complete protection I am just saying that if it can be cracked and they know it can then refund my money if your not going to do anything about it. Instead Nick gives me an excuse that updating loaders it to much of a hassle for people and that he may not release an updated Ioncube encoder.

Zend has been decoded, Ioncube has been decoded but I have yet to see SourceGuardian 7.0 be decoded.

Zend has been decoded, Ioncube has been decoded but I have yet to see SourceGuardian 7.0 be decoded.

It will only be a matter of time. The most popular things normally get 'cracked' first. Older SourceGuardian files have also been cracked, and I see no reason why 7.0 won't suffer the same fate eventually.

It will only be a matter of time. The most popular things normally get 'cracked' first. Older SourceGuardian files have also been cracked, and I see no reason why 7.0 won't suffer the same fate eventually.

What makes you think that?

What makes you think that?

Nothing is foul-proof. Given the interest, time and motive anyone could figure out how to crack the files to bypass the protection. Whether it be by hooking the functions or writing your own translator. Encrypters/scramblers just prevent mild interest in redistribution. Given a greater motive people will try and often do succeed.

Nothing is foul-proof. Given the interest, time and motive anyone could figure out how to crack the files to bypass the protection. Whether it be by hooking the functions or writing your own translator. Encrypters/scramblers just prevent mild interest in redistribution. Given a greater motive people will try and often do succeed.

I know that but what I was trying to ask was do you think SourceGuardian is easier to crack then Ioncube?

I asked SourceGuardian similar questions and was happy with their responses, but as others have said here (as did SG) none of this is 100% infallible and it can't be due to it's very nature - but there are levels in making it harder, SG seems to have some more, along with them not being so widely spread which also make them less of a target - but as I said I have been happy with their response so far, and I like the look of their software so that is the one I am considering going for now.

Cheers,
Sean

I know that but what I was trying to ask was do you think SourceGuardian is easier to crack then Ioncube?

Nobody said that. They pointed out that previous versions had been cracked and that is was likely future versions might be also.

Also the same in my case. SourceGuardian has answered questions I have asked and seems to be a little less known but still the host I am with has their loaders installed. I am most likely going with SourceGuardian now that Ioncube has been cracked.

Unlimited Hoster: Chris, having been active in the hacking scene yourself and putting your name to decompiled versions of peoples commercial PHP scripts that you distributed, you should know better than most that any software such as the compiled and optimised C code of components such as the Loader and Zend Optimiser can be analysed at a low level, analysed with algorithm search tools, traced and reverse engineered to pseudo code or the original language (e.g. C), and then modified by patching to behave in a way that wasn't intended such as to bypass logic or reveal runtime data for further analysis. That this is possible is not the fault of developers of software, and unavoidable without code protection at the hardware level (which even then may not be infallible).

In the PHP code protection arena, products such as Zend and ionCube in particular require significant amounts of RE before being able to get any information useful for decompilation of PHP bytecode to recreate source; for others such as SG, including version 7.0, no reverse engineering is required to reveal native bytecode from encoded scripts. Having modified the standard PHP source to capture the bytecode, a PHP decompiler could then recreate functionally equivalent source code, and the decompiler in the opensource xcache project might well be up to the job (we've obtained bytecode from encoded SG 7.0 files but we have not tested the xcache decompiler so do not know what the quality of that is like).

an excuse that updating loaders it to much of a hassle for people

This isn't an excuse but simply something that based on experience needs to be considered. At first glance, to keep hackers on their toes it might be nice to roll out changes to encoding techniques quite often, and with some work up front, the encoding techniques might even be auto-generated. Great, however this would require new Loaders each time, and a problem is that for some good reasons, shared hosts in particular can be slow to update server software, and they can be reluctant to do so too often. As a result, for many this could render the solution impractical, a major inconvenience at best, but at worst and more likely, unusable.

From past experience we learnt that even when there are undoubted benefits in a major release, where this mandates a server side change as would be the case with new Loaders to support a new encoding method, some end users tell us that this causes problems for them to the extent that in the past and many who updated their product version then wanted to downgrade. Amazingly, some downgraded even though many of their users were using runtime Loaders and so could have updated themselves without needing the host to do so.

Particularly from PHP 5.2.5 where hosts other than those running CGI must have the Loader installed themselves, new Encoder users in particular could have a stream of people complaining that their encoded files don't work because the Loaders on a host were too old. For the Encoder user, the potential impact from script hackers, which is probably negligible or non-existent, would be insignificant when compared to the problems caused to and by their genuine paying customers being unable to run the files that they'd paid for because the server side support needed to be updated. Even if an end user knew that they had selected a host that supported encoded files, they still wouldn't know if the support was compatible with files that they needed to run.

Now this is not to say that product changes should never be made that require updated server components, and the need for a host to update a server component should not stifle new innovation, but to avoid user problems and alienation of hosts, it is best if changes that require an update are made occasionally and preferably so that no further update is required for a significant time after that.

Based on customer feedback, there are also other user sensitive factors such as performance that must be considered, and this can pose limitations on techniques used.

We've been exploring and evaluating interesting new techniques that we may introduce, but some of these would have the tradeoff of increased complexity for the Encoder user in terms of setting up their projects to gain maximum benefit, and this is something that we want to avoid if possible. Introducing minor changes that demonstrably could be reverse engineered and understood within perhaps a matter of days would be pointless though, and cause more harm than good.

Something else to keep in mind is that while any persons targeting PHP script developers are undeniably despicable and irresponsible in their actions, producers of scripts that have been targeted in the past often continue to go from strength to strength with their products. If they weren't encoding their scripts at all then it could be very hard for them to kickstart their revenue stream and maintain their business as they would be providing the latest versions of the source code at every sale, to say nothing of the huge dilemma about how to handle evaluation copies; not so bad if they can host an evaluation themselves, but if their product doesn't lend itself to being hosted for evaluation what then? License restrictions would also be impossible given a source code license. Someone who would never have purchased anyway finding an old copy of a product on a warez forum is one thing, but a developer consistently and perhaps increasingly losing sales as a result of giving out their latest source code because they had not encoded it is quite another.

why not just liscense it under GPL? The problem with encoding PHP is, PHP was never plan it to be compiled like .Net or Java from the start. PHP started out as server-side script such as ASP. These encoder that produce bytecode seem to be an after though/forced soultion. For example, .Net(ASP.net) compiled into MSIL (.dll) which can be decompile as well but your customers will need to have the knowlege in order to do that and you can also use .net obfuscating tool on your source code before compiling into .dll/.exe.

Another problem is not every host have encoder like Zend or IonCube installed because it's another piece of software that they have to mantiance. I'm pretty sure these encoder are very wide spread but still...

of course every software can be cracked but i think if you want to protect your apps then pick a tool that can be compiled then apply obfuscator on it before you ship.

just my two cents.

why not just liscense it under GPL?

Opensource based licensing code is likely to be as useful as a chocolate teapot because whatever it does, for example testing the computer clock to decide whether files have expired, can then be knocked out.

The problem with encoding PHP is, PHP was never plan it to be compiled like .Net or Java from the start. PHP started out as server-side script such as ASP. These encoder that produce bytecode seem to be an after though/forced soultion.

While there isn't compilation to native code as standard, with the introduction of the Zend engine and PHP 4, PHP has always compiled internally to bytecode, just as Java does. PHP as it was before PHP 4 is long forgotten, and to most people never known in the first place, so we can say that the PHP runtime as it is today was and always been designed to be compiled. Bytecode based encoding tools such as ionCube, Zend and a few others, as well as bytecode caches, are actually a good fit with how PHP works internally, and leverage the compiled nature of PHP by utilising the bytecode compiler in their solutions. Bytecode also has the significant advantage over native code in that it's cross platform.

At runtime, when files are requested to be compiled by the PHP core, the PHP extension components of encoding tools and caches override the default compiler to skip the default compilation step that would normally produce bytecode on the fly, and instead retrieve pre-compiled bytecode from shared memory or files. The runtime of some encoding technologies such as Zend and ionCube also contain alternative execution engines for reasons such as processing new opcodes or obfuscated/proprietary bytecode that cannot be processed by the default executor. The process is seamless.

In a way PHP is also setup for executing native compiled code through its modules mechanism, although there is less opportunity to exploit this to maximum potential since PHP 5.2.5. There are solutions that can produce native code from PHP, albeit via the convoluted route of translating PHP first into another language and then into C, but even if one had cross compilers to hand, the process of producing native code ready for use on the 10 or so server platform and architecture combinations in common use would be laborious and difficult to manage at best.

Worth noting too is that while decompilers for PHP are relatively new, and in most cases of no use on their own without significant amounts of reverse engineering to obtain bytecode in the first place, good quality decompilers for Java have existed for almost as long as Java has itself. They were also easy to apply to the JAR (ZIP) archives and class files of applications and applets because there was no protection (encoding) given to Java bytecode.

For example, .Net(ASP.net) compiled into MSIL (.dll) which can be decompile as well but your customers will need to have the knowlege in order to do that and you can also use .net obfuscating tool on your source code before compiling into .dll/.exe.

Someone would need to have the knowledge, but it need not (and generally would not) be the customers as reverse engineering is a very specialised field. Real-world end users of software be it .net, PHP, Java etc. would almost certainly not have the skills and time required to reverse engineer most compilation and/or encoding technologies by themselves, and for that matter the majority of developers wouldn't either as the skill set and knowledge required is very specialised. The relative complexity of the task is therefore an excellent barrier, but there may be little to prevent malicious persons who do have such skills from making their knowledge available in some form or other to those who do not. It can be difficult to take such persons out without the commitment and support from those organisations best placed to act swiftly and directly, or alternatively by stepping outside the law.

Another problem is not every host have encoder like Zend or IonCube installed because it's another piece of software that they have to mantiance. I'm pretty sure these encoder are very wide spread but still...

Correct on both counts. I think that it's fair to say that most hosts these days will provide support if required, but there will always be some who don't.

Theres no way to make it 100% secure, but you can make it a bitch to null.
Obfuscate it, then ioncube it.
Also include an encrypted callback, NOT as a function, but a block of code on each page, with different variable names etc on each one.Most of them will search through code until they find the callback function, and then remove / edit the function - or theyl find a line of code / variables from that function and search the project files for it. If the callback code is different on each page, its going to take them a lot longer to find them all. Its a messy approach, but it helps a fair bit