Can directory script theft be avoided?

I'd beg to differ when calling it 'support'. Besides, the duval could not 'quantify' with what I had done. but anyways moving on...

I prefer to try and help my fellow directory owners and peers, without them having to be ripped-off into purchasing a *hidden* fee of phpld to be helped.

I always thought that once you buy a script you should be supported. Apparently it does not work that way, but rather instead, you will be swiftly prompted to (optionally) 'purchase' additional support, whereas the 'optionally' means you either buy it or you don't get support, which means no pay no support for a script you just bought. hehe... comedy gold.

I wonder what my peers think; Should I open up a supporters forum of my own? (i'm curious)

 

Absolutely gutted
​

 

warez can help to promote your software.
If your script is pirated then your script is good

But i think people not to buy only to get the script, but also to get support which warez thing can't offer

Don't get be mad if your script is in warez site, there are many of people who willing to buy your script legally!
warez is for school boy and hobbies, they are not your market. So think it's as free promotion fee.

 

What an absolute load of rubbish. If you script is pirated it means it is vulnerable and being abused. Doesn't mean your script is good at all, it means its stolen nothing more. Remember, the only ones who go to warez sites however you wish to dress the issue are thieves end of story.

 

I'm not promoting or supporting warez.
But rather let see the good thing. Warez can't be stopped, unless you encode protect your script and set good callback function to your server for customer database! The downside, the script is not open and you stop your user creativity to develop mod

 

Perhaps dont bother with open source, and leave it as it is for now, time always sorts the issues. Could you not perhaps have a developers section, allowing the customers to request personal mods for a small fee ( you may already have this ? )

 

If I knew how to do it I would hold back a few or one core engine file/s on a main server that could handle the load. Kinda like the call back checker, some line of magic code that without it the directory wouldn't function. <?php include( something like that... would something like that be possible ?

 

You can do it easily with a socket or curl connection, silently send a small pocket of data which contain something like the domain name or license key. Then check the return value from your server whatever domain/key is registered in your database


For fopen or file_get_contents, as I understand, some webhost disable to open file remotely

 

You can use full urls/or/ips to files.php, but your right yeah curl or fopen, fopen I think is the most popular as standard, not sure.

 

Interesting concept guys, all feedback taken on board.

 

wahahaha ... It's a piece of cake, mate.
Should I charge you a few dollars for consultation fee, lol!

 

Sure if you p.m me with something interesting that I could use I'd be happy to have a chat. I never expect anything for nothing.

 

Sadly this issue would be around for a long time and every darn thing from movies, softwares and scripts are being cloned, warezed or cracked. A quick search even here in DP forum under Content section will show just how much interest are placed into this piracy nature. As with everything in life, I'm sure a solution will be found sooner or later but at the end of the day... consumer will win hands down.

The internet evolution has changed many business structures and it will surely do so for the script industry as well. What some time ago a paid service or usage are now offered totally free and that my brothers and sisters is the POWER of the Internet.

All the best Jamie in getting it fixed to your preference.

Cheers!

 

Jamie,

Your original question: Can directory script theft be avoided?

The answer is no, it doesn't matter how many attempts you make to stop them it simply cannot be avoided. As daryllau pointed out it has been around for a long time and it will continue to be around for a long time. As long as there is any form of encryption there will continue to be decryption, period.

I have sent you a PM with the name of a product and a link to the web site, I will post neither publicly and request that you do not either. However I will state that the person who owns that web site has been decrypting for at least three years that I know of (I found him as he decrypted one of my Zend encoded products but he did not remove the license tracking before my server picked it up). The fact that he has been around for so long and no one has managed to get rid just goes to show that it is a never ending problem.

The first part is correct, warez cannot be stopped. But encoding and callbacks just make it more difficult, it doesn't stop it.

I wouldn't say that it means it is vulnerable, but being abused certainly.

It can still be cracked even as it is now. It is not a question of time resolving it, as soon as an encryption method is released whether it is software, movies, government... they instantly attract the people who are going to attempt to crack it.

@Mikey and Marty...

You can use the include() and require() PHP functions to access remote files using the http or ftp protocols but it is not a recommended way to do things. You would need the "allow_url_include" and "allow_url_fopen" PHP settings switched on; this poses a problem because it can only be done at php.ini level and a lot of virtual hosting providers switch both off for security.

The default settings are that url_include is switched off and url_fopen is switched on which is why many would go down the fopen() route when requesting remote files. But again, I would question doing so because as I say, a lot of virtual hosting companies do switch off the default setting for security reasons.

If you go back to the code which an0n posted you will note a couple of references to a function called get_url(). This is an internal function which can be found inside the 'includes/functions.php' file around line 1168 depending on your version. The line of code which actually performs the opening of the URL looks like this:

$fp = @ fsockopen ($urlArray['host'].'.', $urlArray['port'], $errno, $errstr, $timeout);

Code (markup):

So for non programmers this means they are using the fsockopen() PHP function. However this function is also restricted by the same setting that effects the fopen() PHP function, so if "allow_url_fopen" is switched off this function will fail. If you note the @ symbol which precedes the function call, this instructs PHP to fail silently. So if a undesirable person were to upload phpLD to a server which has "allow_url_fopen" switched off the code which an0n posted would never function and it would just fail silently. So phpLD's callback fails and they are never notified.

PS: Removing the code an0n posted is still the best option if you are having issues with the admin login, do not remove the function get_url() from within the functions file as it is used in other areas of the script.

As for the cURL functions, in order to use these the cURL library must be installed on the server AND compiled into PHP. This is not always the case especially on virtual host systems although a larger number do now make it available upon request.

So to summarize, all of the functions which can be used for licensing callbacks are all fallible and require specific environments to operate in. None of them are full proof and none of them will work 100% of the time.

If I had to pick one, I would go with fopen() because it is less complex than fsockopen() for performing a simple URL request.

And back at Jamie... as I originally stated when either you or the previous guy who was here about Lynx asked about opening the source.

The best way to do this is to follow Kayakos' example. If you look at the pricing page, the only versions which come with the source code are those which end 'Owned' all of the others are fully encoded. Now I am not sure if you are interested in going down the lease options that they have, but lets assume you are not... you could use it like so (been a while since I was at lynx so these might not match anymore ) :

$20 Trial Version
$50 Encoded Version (explanation of what they can and cant do)
$100 Decoded Version (explanation that certain files remain encrypted)

So in order to obtain any version of your script it would HAVE to ultimately originate with a sale through your system. So if there comes a time when one of your products is cracked, you will at least know you have the originators details and attempt to track him/her down so that you can take action against them.

So about that fee?

Now, I have got to get back to packing boxes... moving house ::sigh::

 

I'd probably have to go along with that and its the only reason we're delaying on the release of our code.

As inevitable as it is that these people will rise to the challenge of decoding the companies like zend and ioncube will fight back. We're working on a totally different route which hopefully won't take long.

It's a damn shame people have to suffer because of a few people who have no regard for the law. I said it before I'll say it again, I bet these type of people would be the first to cry foul if someone stole from them.

 

I had a killer swing on the Rounders field in my youth, and will happily hunt the bastards down and run them over, then reverse, just to make sure

 

@SilkySmooth
What a very well explaination. JamieG is better to out source this thing to you.

Try phpaudit.com, their licensing system is very good. With a combination with ioncube, it's perfect!

 

Silkysmooth is heavily involved with another script seokicker so that rules that out.

As for phpaudit.com and ioncube, good idea although we are probably going down a different route. +Rep for the input though.