Initially I was highly skeptical of PHPAudit... primarily because they offered the free trail version of the software, meaning, the license code generated would be available for anyone to see. But I figured, what the heck, figuring some mechanism of "randomization" would be included in it...

First, the system uses fsockopen(), which only supports SSL connections with PHP 4.3+. In otherwords, with Ethereal, I now know the URL of the licensing system... which is very bad for reasons stated below.

Every "integration code" generated for every product, seems to use the same response codes for invalid/expired/suspended licenses. This needs to be emphasized for one reason: I now have the proper response codes for EVERY APPLICATION that uses PHPAudit.

What does all that mean? All I need is the URL for the licensing server and I can spoof the correct response code to make a permanant valid license... this is especially bad for any company offering demos for their applications.

In itself, PHPAudit isn't a "bad" script... but with their licensing methods available for anyone to download, it's effectiveness is rather poor. If PHPAudit makes response codes random, and switches to cURL (with SSL Certificate verification), we'll see.

Hi Justin,

While you do make some very valid points, I would like to add that to date we're not aware of anyone exploiting PHPAudit. While it's possible we don't know about it, we still believe that for $99 you are getting excellent value for money.

PHPAudit v2, to be released in the coming weeks, includes the ability to use cURL amongst other things and will be a lot more flexible as to how you can license your script(s). We've also made a number of other changes which will reduce the 'exploitability' factor.

With licensing you have to find a 'fine line' between protecting your script but also allowing script users to run the script without any problems. Right now we could make PHPAudit more secure, but that would be at the expense of the users who run PHPAudit licensed scripts. It's a fine balancing act and with PHPAudit v2 we think we're nearly there.

We always welcome constructive feedback like your own, and so when PHPAudit v2 is released please feel free to download the trial and give us some more feedback.

Originally posted by tickedon
Hi Justin,

While you do make some very valid points, I would like to add that to date we're not aware of anyone exploiting PHPAudit. While it's possible we don't know about it, we still believe that for $99 you are getting excellent value for money.

I appologize for not writing this, but it was extremely late! I agree wholeheartedly that $99 is certainly cheap for the peace of mind PHPAudit provides. I'm glad to hear there are no known exploits, and I attempted to keep my points pretty vague to prevent that.

PHPAudit v2, to be released in the coming weeks, includes the ability to use cURL amongst other things and will be a lot more flexible as to how you can license your script(s). We've also made a number of other changes which will reduce the 'exploitability' factor.

I look forward to that :)... with a little flexibility and an SSL connection, PHPAudit would be an excellent program.

With licensing you have to find a 'fine line' between protecting your script but also allowing script users to run the script without any problems. Right now we could make PHPAudit more secure, but that would be at the expense of the users who run PHPAudit licensed scripts. It's a fine balancing act and with PHPAudit v2 we think we're nearly there.

I agree with this as well... and I assumed to purpose behind using fsockopen was to prevent end-users from HAVING to have cURL installed.

We always welcome constructive feedback like your own, and so when PHPAudit v2 is released please feel free to download the trial and give us some more feedback.

I most certainly will. I'm in favor of writing my own code when needed, but I truly dislike reinventing the wheel. So if v2 fills in the gaps, you can rest assured I'll be ordering it ;).

OK tell me how youre going to spoof the response since the response have to come from an external website which you have no control over. It takes a high geek to spoof a URL it, its is a lot of trouble and this kinda people only account for maybe less than 1% of your customers to be conservative?
People who do spoofing and stuff are not serious about their business in general. People who are even half serious will do it the right way. Say you tricked the application and upgraded to the next version where the URL has changed, this results in service interruption, shame and other negativities.
There might even be anti-spoofing mechanism in the script that can automatically report to the developer about the illegal activities and list the business detail of the company on the "blacklist page".I have a page like that for my company.
On the extreme side,there might even be a dynamic code within the software to switch licensing variables so that only the service of the honest customers will remain uninterrupted.

If you are even half serious about your business, would you want to go through all these trouble? I guess not

Plus the response codes should be different.
e.g.
valid=1
invalid=2
suspended=3
Unless I misunderstood what you were trying to say.

Originally posted by JustinH

First, the system uses fsockopen(), which only supports SSL connections with PHP 4.3+. In otherwords, with Ethereal, I now know the URL of the licensing system... which is very bad for reasons stated below.

Every "integration code" generated for every product, seems to use the same response codes for invalid/expired/suspended licenses. This needs to be emphasized for one reason: I now have the proper response codes for EVERY APPLICATION that uses PHPAudit.

What does all that mean? All I need is the URL for the licensing server and I can spoof the correct response code to make a permanant valid license... this is especially bad for any company offering demos for their applications.

PHPAudit v1 is/was designed to be a "set and forget" system with very little work needing to be done to set it up or integrate it with your script. As such, we chose the most common options such as fsockopen(), as not everyone has cURL compiled in as you mentioned. V2 is still a "set and forget" system but with plenty of advanced options added in for those who want/require them.

If you've any comments, feedback or questions etc.. that aren't suitable for posting publicly feel free to drop us an email - we always aim to act on customer (and non-customer) feedback, and I'd have to say ~70% of the new features in v2 have originated from customer feedback.

I'm an active PHP developer. Here's some advice on PHP licensing:

1. The only PHP encryption algorithm to date that has not been cracked is Zend. Use it, and only it. If you want your scripts to not be cracked, it's the only option. Not 1 person out there has been able to crack Zend's intense encryption of PHP scripts, probably because they developed PHP and know the best way of encrypting it. If you don't beleive me... anyone who has encrypted their scripts with IonCube, send me a locked copy, and I will send you an unencrypted version.

2. Anything you do, anyone else can reverse. So what's the answer? Server checks. License Key's don't mean anything, they can easily fake them. So here's what you do, store your keys via a central database, and when the person is registering your script have them input their client ID and Key, then have your script pull the key that matches that client ID from the server. Make sure they match, and make sure you record the IP of the script in the database so that people can't share keys (That's often forgotten)

3. ENCRYPT EVERYTHING WITH ZEND AND BIND IT TO AN IP ON TOP OF THE DATABASE IP CHECKS!

95% of security holes are because of human error.

Neo3 - care to explain your "decrypting" of ioncube? Ioncube converts PHP to bytecode, so even IF you managed to reverse engineer the bytecode (which you can't) it wouldn't even be the original code.

Please shed some light on your claim (ie, back it up).

Originally posted by Roy@ENHOST
OK tell me how youre going to spoof the response since the response have to come from an external website which you have no control over.

Ethereal and IPTables... web server software always automatically checks LOCALLY for a URL or IP Address before hitting the net, and as such, if a domain exists on the local server, it will be used.

It takes a high geek to spoof a URL it, its is a lot of trouble and this kinda people only account for maybe less than 1% of your customers to be conservative?

Who cares how many, I don't want anyone doing it.

There might even be anti-spoofing mechanism in the script that can automatically report to the developer about the illegal activities and list the business detail of the company on the "blacklist page".I have a page like that for my company.
On the extreme side,there might even be a dynamic code within the software to switch licensing variables so that only the service of the honest customers will remain uninterrupted.

You don't seem to understand the concept behind spoofing. The spoof will send back the exact codes formed as the script needs them. There is no way to "detect" if it's being spoofed.

e.g.
valid=1
invalid=2
suspended=3
Unless I misunderstood what you were trying to say.

I meant dynamically created response codes:

Client 1: valid = 99
Client 2: valid = 3
Client 3: valid = 190

By using this method, there is litterally no way a person could spoof, since they wouldn't even know what the proper response codes are.

Originally posted by Neo3Net
I'm an active PHP developer. Here's some advice on PHP licensing:

1. The only PHP encryption algorithm to date that has not been cracked is Zend. Use it, and only it. If you want your scripts to not be cracked, it's the only option. Not 1 person out there has been able to crack Zend's intense encryption of PHP scripts, probably because they developed PHP and know the best way of encrypting it. If you don't beleive me... anyone who has encrypted their scripts with IonCube, send me a locked copy, and I will send you an unencrypted version.

2. Anything you do, anyone else can reverse. So what's the answer? Server checks. License Key's don't mean anything, they can easily fake them. So here's what you do, store your keys via a central database, and when the person is registering your script have them input their client ID and Key, then have your script pull the key that matches that client ID from the server. Make sure they match, and make sure you record the IP of the script in the database so that people can't share keys (That's often forgotten)

3. ENCRYPT EVERYTHING WITH ZEND AND BIND IT TO AN IP ON TOP OF THE DATABASE IP CHECKS!

95% of security holes are because of human error.

PHPAudit works roughly as you described in point 2. It's a call home system based on a license key that identifies the user.

If I remember correctly, ionCube have/had offered $10k to anyone who's able to crack their encryption. As far as I know, it's never been claimed. Lots of people claim they can break ionCube, but I've never seen anyone able to prove it - all talk and no action.

I know the concept of spoofing.
But it is a lot of trouble and there are so many ways I can counter this kind of problem as a developer. I know coz I lost a lot of hair thinking about licensing architectures.
Say if your script has a dynamic code to switch to another domain for license callback on one particular day, and report the user who failed the "alternate server" check, you are screwed.

Do you want to put your reputation on the line for a few hundred bucks?

OK cool. You have a different approach. Read up on the famous 80-20 rule.
You can spend 80 percent of your effort to deter 20% of the non-legitimate user when you can spend that time on something way more productive, in our case it might be 99-1. You might end up spending 99% of your effort to deter 1% of the script kiddies who can't pay for the license anyway.
I am not saying that you are wrong but I am explaining a concept that I believe, buy it or not its up to you.

Originally posted by JustinH

Who cares how many, I don't want anyone doing it.


Anyway neo3net,

Part of a very famous hosting script (M*******LL) was decoded by Russian hackers months ago. The Russian decoded the Zend version instead of the Ioncube version.
Send me an email, I will send you my Ioncube encoded script.
If you can decode it, send a resume to Zend or Ioncube.
Your talent shouldn't go to waste.
Nick of Ioncube can't even decode his own script.
You're trying to say that your understanding of the Zend engine is more superior than his?

Originally posted by neo3net
The only PHP encryption algorithm to date that has not been cracked is Zend.

Here is my script I encoded seconds ago, decode this for me please.



<?php //003b1
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((@$__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();
}die('The file <b>'.__FILE__.'</b> has been encoded with the <a href="http://www.ioncube.com">ionCube PHP Encoder</a> and requires the free '.basename($__ln).' <a href="http://www.ioncube.com/loader_download/">ionCube PHP Loader</a> to be installed.');

?>
0y4hYDgmgtilcX1ypGW+M6z0r90IreX/GpFh5iqauXWRxyDxYTogqRI9/lJCt72FgNrRbkL4SLkq
oDQtHNognPFYX1v1xthD69XwHJLhUM6L8civjA/1eXwV+SkDXnJ4v2KsCYH0U+E/Uu38WYzwRqf3
VQ1Yj8WsXzary0b0DzIrXo/UOXCcUs4ZnNrJLQNzoVlH3+Mtw9st2SkNWeqlEjRdHRkdRRCJJmzK
66gNJr2gJM3IGlbozAkqp8djnsKZFUtpGWnGykVuLlBX39Hl6a7MS3gvHMg9eJiZW3y40vf38Gi5
X+l1V8GcMkZBThS8F/CU

Originally posted by Roy@ENHOST
I know the concept of spoofing.
But it is a lot of trouble and there are so many ways I can counter this kind of problem as a developer. I know coz I lost a lot of hair thinking about licensing architectures.
Say if your script has a dynamic code to switch to another domain for license callback on one particular day, and report the user who failed the "alternate server" check, you are screwed.

That's exactly what I'm talking about, adding those extra layers to prevent problems. Now, any basic Linux guy could break a licensing structure that is overly simple. A call over a non-ssl connection with the exact same response codes doesn't take a rocket scientist.

Implementing random variables, an SSL connection and even perhaps an alternate server, would give ample security to your system.[/B][/QUOTE]

Ah!. I'm terribly sorry, I was reffering to SourceGuardian not IonCube. I confused the two. SourceGuardian is very easy to decode, I have no evidence of the strength of IonCube though. Sorry for the misunderstanding. I can definately decode SourceGuardian though :)

Yeah every men and his dog is an encryption master on the internet.
NATO(No Action Talk Only)
The moment I publish a SG file you are going to say "Ooops my bad, I meant mmcache" or "oooops I meant the ancient 1999 version of SG"
I know that the ancient version of SG is highly decryptable.

Are you for sure its SG this time? And are you sure its the latest SG instead of some ancient version?I will publish an encoded SG script on this thread and have all the WHT members watch you decrypt it while eating their popcorn.
I might even buy a sticky for this thread .:D

Roy

Originally posted by Neo3Net
Ah!. I'm terribly sorry, I was reffering to SourceGuardian not IonCube. I confused the two. SourceGuardian is very easy to decode, I have no evidence of the strength of IonCube though. Sorry for the misunderstanding. I can definately decode SourceGuardian though :)

I don't keep tabs on it, and I'm not sure what version they're up to but if it's SourceGuardian II I can definately decrypt it.

I'm not trying to prove my skills. I'm trying to say that what people think is full proof isn't, I made an honest mistake, I apologize deeply.

BOOO Neo3net !!!
LOL

Yeah I have never trusted SG.
Ioncube is one of the most secure encryption application for PHP.
They did a better job than Zend but you can't go wrong with any of them. I am in no way affiliated with Ioncube by the way.
You see Zend&Ioncube versions for most applications.
You dont see Zend&SG or Ioncube&SG tag team partners very often.

Originally posted by Neo3Net
I don't keep tabs on it, and I'm not sure what version they're up to but if it's SourceGuardian II I can definately decrypt it.

I'm not trying to prove my skills. I'm trying to say that what people think is full proof isn't, I made an honest mistake, I apologize deeply.

I need to look into IonCube more. I've never used it, but from what I hear it's quite strong.

You should note that SourceGuardian 1 and 2 did not encode but obfuscated. SG4 (their latest version) actually encodes in a similar manner to ionCube and Zend. Unfortunately, SG has the repuation that it can be cracked which isn't the case with the latest version.

Oh, well this I knew, however I did not know that the newer versions are encrypted. Thanks for the heads up.

Originally posted by Olate
You should note that SourceGuardian 1 and 2 did not encode but obfuscated. SG4 (their latest version) actually encodes in a similar manner to ionCube and Zend. Unfortunately, SG has the repuation that it can be cracked which isn't the case with the latest version.

The question is, does it encode to the same standard as Zend or ionCube?

Zend and ionCube have been going strong for many versions now, and with SourceGuardian working out more expensive than an ionCube encoder Entry license ($200 vs $250), I can't see why anyone would take the risk on 'unproven' software.

I beta tested SG4 and it performed well. It has similar features when compared to ionCube Encoder (such as on demand loaders) but also includes the option to have an external license file.

Having said that, Zend and ionCube have a very good repuation and have stood up against (probably) many attempts to crack the encoding. SG4 is real encoding using bytecode like ionCube and Zend so in theory, it should be as strong. However time will tell.

Originally posted by Olate
However time will tell.

Thats my point exactly. Both Zend and ionCube are proven solutions. Anyone who uses SourceGuardian risks that 2/3 months down the line it's cracked, and all of a sudden every SourceGuardian encoded script is suddenly at risk. Is that something people should be taking risks with? I don't think so - I'm sure others will agree.

You don't see Modernbill offering SourceGuardian encoded scripts - you see ionCube and Zend versions. Same goes for WHM.AutoPilot. Most people use ionCube and Zend - and if the big guys don't trust them, why should the little guys trust them until it's a proven solution?

Indeed. I use ionCube myself. The problem is that a solution cannot be proven until lots of people use it without problems. But lots of people won't use it until it has been proven :p

Originally posted by Olate
Indeed. I use ionCube myself. The problem is that a solution cannot be proven until lots of people use it without problems. But lots of people won't use it until it has been proven :p

Yep. The horrible catch 22 situation.

ionCube previously claimed to be able to decode SourceGuardian encoded scripts (v1/2). Maybe they'll come up with a way to decode the latest version, who know's :)