Hello,

I have a PHP script encoded with Ioncube and now i want to rent this script.

The problem is that i have no idea of how to make a secure license system.

First, i'll use curl + ssl to connect directly to the license server.

Important: i'm using an IP in order to avoid users from resolving a name to another IP.

Them send the license + domain that the script is running as a post variable and return an encrypted reply that will say if the license is valid or not for this server.

Is this secure? Is it easy to crack?

Should i always check the license? Or should i check from time to time?

Thanks for your attention.

Save yourself some time and use PHP Audit....

Save yourself some time and use PHP Audit....

Agreed - can't go wrong there :)

I'll third the notion for PHP Audit :)

Yes, PHP Audit is the saver for licensing :)

Zending is now obsolete. I know alot of websites which crack IonCubed scripts and what not. PHP Audit all the way.

PHP Audit too

Thanks everyone for your support of PHPAudit!

Zending is now obsolete. I know alot of websites which crack IonCubed scripts and what not. PHPAudit all the way.

While I would agree Zending is now 100% useless, ionCube is not quite in the same position. Both can be reversed back to source to a large extent - the problem being, Zend files can be reversed automatically and in seconds, ionCubed files still require manual work and I've yet to see any automated process for restoring those to source yet. I spend quite a bit of time following the situation and discussing it with the relevant parties, and so far, 95% of the ‘nulled’ scripts I’ve seen have been reversed from Zend encoded files - and only a tiny fraction from ionCubed files. It’s always telling when companies with a large PHP presence, such as Invision Power, remove the Zend encoded version of their products and rely on ionCube as the only option.

The way to always look at this is that Microsoft, Adobe etc... cannot secure their software, and they have budgets in the millions. Anyone who is determined enough will break through whatever barriers have been put up – the key though is to ensure that the people who’ll purchase your software do so, and can’t easily find a ‘warez’ copy they can freeload from.

At the end of the day, we’re all here to make money. Any tools that make that easier are to me very welcome :)

that will be $100 in advertisement fees lol :P

Hello,

Well, i guess the best way is to go with Php audit ( as everyone recommended it ).

From what i have seen php audit is a complete system with billing etc. Is it possible to use it only for license control?

I would like to have my own billing/sign up system.

yes i also would be interested in this. Is it possible to use it only for license control?


thanks

There's a remote API in PHPAudit which allows you to remotely issue licenses (among other things), and so you could use it with a seperate billing system if you wanted to. It's designed to be pretty flexible so you can use it how you want.

I don't like any license system now really because they all callback at one time or another to check for a license. Thats why I am making my own license system where everything for the license system to check is stored in the users license key which is encrypted in a custom algorithm i made. My script works the following way...

1. Customer buys script
2. Customer is then given a form to input the domain they will use the script on and then a license key is generated for them
3. Customer installs the script on their domain
4. Customer inputs license key they were given
5. When script is ran the script decrypts the license key and reads it (the page where the license key is decrypted is encoded so the customer can't figure out how to crack the key.)
6. If there is a problem with key script displays error and doesn't work, if everything is fine script works normally.

The only thing my license method lacks is the ability to disable a license.

I don't like any license system now really because they all callback at one time or another to check for a license. Thats why I am making my own license system where everything for the license system to check is stored in the users license key which is encrypted in a custom algorithm i made. My script works the following way...

1. Customer buys script
2. Customer is then given a form to input the domain they will use the script on and then a license key is generated for them
3. Customer installs the script on their domain
4. Customer inputs license key they were given
5. When script is ran the script decrypts the license key and reads it (the page where the license key is decrypted is encoded so the customer can't figure out how to crack the key.)
6. If there is a problem with key script displays error and doesn't work, if everything is fine script works normally.

The only thing my license method lacks is the ability to disable a license.


The other thing it lacks is security. There two issues:

1. A custom encryption algorithm.

2. The fact that the encryption key is stored on the page (albeit encoded).

The only thing my license method lacks is the ability to disable a license.

Which can easily be achieved by coding in an 'expiry date' (with grace period) when it has to go and fetch another key. So if you later did require to disable a key (refund, chargeback, change of domain etc...) then you know it would only work until the next key check date. It's not instant, but, far better than nothing :)

You'll find most of the commercial solutions can work this way.

There is no way in my method to trick the key. Before being encrypted in my custom way the key is like this...

{info_spot1} - {info_spot2} - {info_spot3} - {info_spot4}

Then it will look something like this once encrypted.....

å ³èËÇÐÔÌØÍÓ


Then its base64'd to look neat when given to customer and will look like this...

5QUaEiCz6MvH0NTM2M3T

I will also be implementing a cheat check method so if a person tries to make a license key written in human text by filling in the spots on the license key before its encrypted it will reject the license key.

Also when i use this system license keys will only be issued to the buyer 24 hours after purchase for there can be a fraud check and funds can be secured.

And since the file that decrypts the the license key to read it will be encoded in ioncube the only way to defeat my license system is to crack ioncube.

There is no way in my method to trick the key. Before being encrypted in my custom way the key is like this...

{info_spot1} - {info_spot2} - {info_spot3} - {info_spot4}

Then it will look something like this once encrypted.....

å ³èËÇÐÔÌØÍÓ


Then its base64'd to look neat when given to customer and will look like this...

5QUaEiCz6MvH0NTM2M3T

I will also be implementing a cheat check method so if a person tries to make a license key written in human text by filling in the spots on the license key before its encrypted it will reject the license key.

Also when i use this system license keys will only be issued to the buyer 24 hours after purchase for there can be a fraud check and funds can be secured.

And since the file that decrypts the the license key to read it will be encoded in ioncube the only way to defeat my license system is to crack ioncube.

The problem is nothing is unhackable. Eventually, if it hasn't been done already someone will break ionCube. I know that ionCube versions < 6.5 were vulnerable, I don't know about newer versions. But it is really just a matter of time.

I'm not trying to get on ya here. Your method will probably work fine, especially if you aren't a high profile company whose software is a hot target for crackers.

PHPAudit is definitely worth considering in conjunction with an encoding tool. Initially our product did not have license file features and required locking of scripts directly to target machines. PHPAudit built on what we provided and added the license file features, as well as lots of other useful administrative functionality. Native license file support was added to the product later, and this is harder to attack than licensing implemented by PHP scripts. PHPAudit does offer some features that we chose not to include though such as remote checking, and even if you use the native licensing that encoding tools provide (or a home brew solution), the other features of PHPAudit are definitely worth a look, and they may very well save large amounts of time and money by helping you get to market sooner.

For anyone using secret data in PHP itself, we do advise to keep in mind that the core of PHP, including all of the standard library functions, are open source. Provided that PHP scripts can be run, the implication is that the parameters to any built-in functions can be exposed at runtime relatively easily with a few minor changes to the PHP engine by someone proficient in C programming. Whether this matters in practice is another matter, but securing code cannot eliminate this risk.

With regards to security in general and as several people mentioned, nothing can be totally secure. No DRM solution has ever survived the scrutiny of people such as DVD Jon (http://en.wikipedia.org/wiki/Jon_Lech_Johansen), software licensing for popular Windows software packages always gets broken in one way or another, and emulators were even developed for syncrosoft hardware dongles. Perhaps lacking the skill and creativity to write any worthwhile software of their own, there are always going to be people who will spend their time instead on patching other peoples work for one reason or another.

On the basis that those unwilling to purchase will not purchase no matter what, the realistic aim when releasing software is to do ones best to ensure that the people who are willing to purchase actually need to, and that steps are taken to enforce license conditions. Those not wanting to pay for software register on warez forums, perhaps seek our and install a file sharing tool or two, and maybe even get suckered into paying a few USD to join a software cracks site having been promised that a hack exists even though in most cases they don't.

As long as code such as evaluations is not given out in source form and ideally not licensed in source form, and code is locked to specific machines if this is the licensing policy, then those prepared to pay will generally do so if they like a product and perceive sufficient value in the product and other areas (support, bug fixes, updates, etc.).

Ni Nick,

Good to see you around. Since you bring up phpaudit, have you had a chance to work extensively with them? I've dealt with Alasdair in the past, but didn't get a chance to mine him for data!

Last I checked, it's a simple callback that reports, via a simple API, a status that has to do with "good" or "bad", etc.

Is this overview correct?
Alex

There is no way in my method to trick the key. Before being encrypted in my custom way the key is like this...


"My custom way" is the problem. Are you a cryptologist? Encryption is hard. *Really* hard. As in the-sum-total-of-WWII-German-wartime-cryptographic-engineering-was-routinely-defeated hard. A good cryptanalysis - even a semi-gifted amateur - could conceivably break your encryption in a very short time.

Even the NSA routinely does peer review of cryptographic algorithms - they do it inhouse, of course, but it's still done, and the NSA has, reportedly, some of the best cryptographers on the planet. If *they* aren't this confident, why should you be?

Take it easy,

David Berube

The thread poster's idea for licensing might be quite effective for the most part, however if elements of $_SERVER are being tested, I wonder what steps have been taken to protect against $_SERVER being tampered with. If a plain text PHP script was loaded at any point before the license testing, such as with the auto prepend feature of PHP, that script could modify $_SERVER to reflect the domain that a given license was issued against. The same goes for server IP address checking. In practice this might not matter, but the ease with which it might be possible to make an unlicensed installation look like a licensed one would be my concern and focus of attention.

Alex: PHPAudit does have a remote check mechanism but I'm not aware of the implementation details. Where I see particular value in a system such as PHPAudit is not necessarily the licensing as most encoding tools offer some kind of licensing natively, but in everything else that it offers in terms of managing products and releasing them to customers. If someone needs to get infrastructure in place for managing customers, handling orders, products, and perhaps licenses, and they can buy a sensibly priced and easy to setup pre-made solution that does all that and helps to get them to market quicker, then that could be a very good deal.

I've never heard of PHP Audit, but it sounds like some people have good experiences with them. The problem is this; any encoded script has to be decoded at some point to be parsed. Some are easier than others to reverse and get large parts of the code or all of it. The good thing is, few of the normal users that will pay the license fees will bother or care to try and grab your source code.

I recall back about 8 or 9 years ago, a company had recently hired me on and at one point said they hired a coder to create a control panel for them, but left after they pre-paid him. They asked if I could decrypt the source. I said I'd give it a shot and had the full source code in about 2 minutes. Not all types can be so quickly decrypted/decoded, but if it's an interpreted language, like Perl, Python, Ruby, PHP, and so on, at some point it has to return to its natural form to work (in a manner of speaking), so there's always the breaking point.

That product, at the time, by the way, was one of the earlier versions of Cpanel (I hadn't heard of them before that), and that's why they moved to a perlcc version, where it turns Perl code into a colossal mess of "interpreted" C code and then is compiled. It's inefficient and buggy for what it is (bastardized C that's incomprehensible), but other than cracking the compiled program itself or trying to grab what you can from strace and strings, etc., it's a workable solution. All that said, real, genuine, efficient C programs would be a far shot superior.

Anyway, if you put a lot of hard work and time into a project and want to reap the rewards, you have to worry about some ill intended competitor reverse engineering your encoded scripts and create a clone or similar or derivative work based upon it and make money off of your hard work (and keep the credit for themselves). Still, the majority of people will pay and be honest, luckily, but they will not perhaps use your product and use the scripts your competitor has ripped you off for.

This is why I recommend any serious programs be coded in C, C++ or some compiled language. Not that someone can't crack those programs themselves to try and rebrand and resell, but it's safer. There are ways to code it so it makes it very difficult to crack a compiled program though. However, and again, you shouldn't worry about it too much, because most people will just pay and use it, and the vast majority will not try and decode your scripts, so just complete your project and push it out there and reap whatever benefits you can from your hard work.

In other words, don't like the worry hold you back too much, if you are. I have some licensing methods that are very effective, though I can't disclose them as they are being used and I'd rather keep that extra few steps out of people's minds that might one day license one of my products and have ill intentions, but there are workable solutions. Anyway, it looks like people have a lot of repeated recommendations for the php audit people, so maybe check that out and save some time?

The problem is this; any encoded script has to be decoded at some point to be parsed. Some are easier than others to reverse and get large parts of the code or all of it.

This is not necessarily the case with PHP as it is a compiled language. Systems such as ionCube, Zend and a few others exploit this and they precompile scripts into bytecode at encoding time, and then munge the possibly transformed bytecode into the final encoded form. At runtime there is no sourcecode and hence no parsing as the scripts are decoded into the compiled form. Some of the bytecode systems will then hand off standard PHP bytecode to the regular PHP engine, while others will use their own execution engine that is based on the standard engine but perhaps modified; both Zend and ionCube use this approach with modified engines. The systems that rely on hiding source code are indeed easily worked around as they rely on calling eval(), and the source passed to eval() is easily exposed with a minor patch to the PHP engine.

most people will just pay and use it, and the vast majority will not try and decode your scripts, so just complete your project and push it out there and reap whatever benefits you can from your hard work.

This is good advice. The sooner you get to market, the sooner you can build your brand and gain product recognition.

Pardon, I didn't read the thread very closely and I was speaking of encoded scripts (compiled is compiled after all) Anyway, yes, there's no decoding a compiled script to get the source -- though there is still the cracked software potential, it's a far cry better than people being able to get the source itself.