I am looking at both NuCoder and SourceGuardian.

SourceGuardian is more mature in the market and includes license manager + obfuscation, while the price is just $175.

I personally like PHPed so much, and would like to see a powerful encoder integrated with my IDE. So when will the above features available in Nu-Coder?

Not sure how much effort and $$ you are willing to expend to ensure your scripts are protected, but what I did was surf the web for the sites that claim to be able to crack encoded/obfuscated scripts. Most of them will do it for about $5, so I submitted various scripts encoded with different products to see how secure my scripts really were. I used NuCoder, IonCube (both the online encoder and IonCube 6.5 -- the online encoder does not use their latest algorithm), Zend Guard, and Source Guardian.

I think I ended up spending about $50 to get my answer. Since I sell about a dozen or so protected scripts every day, it was worth it to me.

This really isn't the platform to publish my results, but I will say this:

- NuCoder gives the crackers a run for their money. I was asked to submit additional $$ by 2 sites for NuCoder encoded scripts (also for IonCube 6.5 encoded scripts).

Depending on the demographic I was distributing to, I would feel comfortable using NuCoder.

Best of luck ~ RLR

Hi LovinItAll,

I'm looking at both NuCoder and Dock...after reading your recent Dock post (rant), I must take this post at face value and not just a plug for NuSphere. Your insight is valuable and appreciated.

Randy

Hey Randy,

I've got no vested interest in NuSphere products, but I've not found a better editor for PHP than PhpED. As for Dock, it's a great idea, but ultimately the developer is still strapped to PHP. It's so easy to write code in PHP that I understand why developers want a product that provides an application 'feel' and a deployment solution that is simple, but if one is going to stay in the PHP realm and develop desktop PHP-based applications for a broad maket, PHP-GTK is the really the way to go. After all, it's why PHP-GTK exists.

My users have a hard time finding hosts that support my encoded scripts, so many of them are simply downloading xampp or wamp, but then there are the security issues (real or imagined) of running a server OS on a desktop PC. I tried to make it easy on them by creating a 'custom' distribution of Apache/PHP/MySQL that included the config changes necessary in php.ini and the additional loaders. It works, and they're happy, but I thought I'd take it one step further and distribute my scripts with Dock. Ultimately, I will have to take the time and either rewrite in VB/VC++, or wrap PHP-GTK around the scripts that users wish to run as desktop apps. Dock, for me, was intended to be a short-term solution to enhance the end-user experience.

The whole 'rant' came about this way:

- A script that I have been selling for a long time has never experienced any problems under Xampp, Wamp, or IIS (under Windows), and certainly not under any linux distribution. It has ALWAYS 'crashed' in PhpED. I never concerned myself with the issue because my users were not running the script in PhpED.

- Dock uses the same set of files as PhpED for executing scripts in cgi, so naturally it became a problem when I began testing Dock, but quite frankly it was a problem that I solved pretty quickly. I should have just left it at that -- apparently no one else is having a problem, and I hope it stays that way.

As they say, no good deed goes unpunished.

Best regards,

Lee

Hey guys,

Don't want to hijack this thread, but I was following it and I have a small suggestion to make to you, LovinItAll. If the intention is that your clients can run the scripts without too much hassle, have you looked at PHP Compilers? Those compile php scripts into self sustained binary files. One of those is RoadSend. Just my $0.02, could be handy and easier for you.

Hi,

I did look at RoadSend, but if I remember correctly, it requires a user to have a server OS installed like the other solutions. From a security standpoint, there were two things I remember thinking:

- Hey, this is Open Source -- Great!
- Hey, this is Open Source -- how long before someone makes a good, open source decompiler?

I know we don't live in a perfect world, and I would much rather write a piece of code, run it through a compiler, and let it go. Also, I use a licensing system that depends on (obviously) license files, and I'm pretty sure I couldn't compile a license and then read it -- but then again, maybe I could. I'll have to go back and take another look.

Thanks for the suggestion. It's always nice to know there are folks on the look-out for goodies to add to their bag of tricks!

Best ~ RLR

Even if you compile your script with a php compiler, it won't present you with a GUI until you use either GUI library like gtk, or webbrowser. First one is far from being trivial to use. Latter way is much simplier. You can find a lot of ready scripts and adapt them to your needs. But it comes up with its requirement of a web server to work.
That's why PhpDock exists. It hosts browser (in all windows, including popups and dialogs), implements trivial to-use-web-server and can start background jobs (non-UI scripts).
BTW, did you know that you can create CD-based (distributed on R/O media) demos with PhpDock 2.0?


if we talk about protection to prevent others from getting your php sources, there are two set of php encoders. I'd call them compilers and packers.
Packers simply remove extra spaces, line ends and use propriatary scheme to pack original sources. In this case original sources can be captured with a tool that intercepts php compiler. It's a matter of knowing php api. I see only one reason why people are still using them: they are cheap and does not require any extensions.

On the contrary, compilers first compile php into bytecodes and distribute them in serialized form. To execute such script, you'd need no sources, just these bytecodes. Finally it's what php executor gets in its input. In this case to get the sources back, you'd need a tool knows all possible bytecodes and all their possible combinations (patterns) that php compiler can ever generate. Otherwise recovering will not be complete or adequate.

Regarding open-source, personally I see absolutely no reason why would anybody make them open-source. It's a kind of hacking tool and until somebory woud decide to create a community over it (like in case of rootkits), it won't be opensource.

I'm not quite sure what you're saying here, but if you're asking the hypothetical "Why would anyone write a decompiler and make it open souce?", the answer is that some people, like you said, are all about hacking -- they don't care WHAT they hack, just that they hacked it. It's like the sites that offer to decode encoded scripts --some of them want $2, others want a bunch of money, and I found one site where a guy offered to do it for free. I didn't fnd any that offered the source for the decoder, but some idiot will post it some day.

I've used MANY decompilers in my day, and you're right, the resulting code is often incomplete, or at least not very easily comprehended. Often a company will write a program, go out of business, and it's necessary to get to the code to try and fix a bug, add a feature -- whatever. The C, Visual C++, and VB (hell, even Clipper) decompilers I've used in the past rendered results that were usable....maybe not EASILY usable, but usable nonetheless.

Of course, a big advantage of a compiler is the stripping of comments. I don't know if NuCoder strips comments or not.

Is this what you were talking about?

If you do not have sources it means that you did not purchase them or lost them. In the first case it's a matter of the license. Most of them (if not all) do explicitly prohibit re-engineering (it's what decompiling finally is). In other words, it may be (and in most cases it is) illegal to decompile 3rd party programs.
But certainly, it will not stop people who instead of your and ours way of creating software, just want to steal something ready to-use.


No comments remain in the bytecodes, except ones created in phpdoc form and they will remain only if you explicitly allowed this. For example, you may want to enable this option if your software depends on the reflection api and uses phpdoc comments.


There is no program in the world that can not be re-engineered. It's not the true purpose of php encoders either. Their purpose is to make this process complicated, unstable, and requiring too much efforts and time.
For example, if you compare protection in MSWord files to AES512-encoded files, you'll see that the first ones require <1sec to crackdown while latter ones will probably survive for years.

Just wan't to bring to your attention that the original question that started this remains unanswered.

Sorry...I was the hijacker....

OP:

DISCLAIMER: I don't work for NuSphere.

The use of terms varies widely, but Nucoder already obfuscates your code, so that leaves license management. I have it on good authority the time frame is around EOM March 08 for that feature set. Knowing how they roll out products, they will roll out the feature set incrementally so they can do it with quality from the outset. If you think about that for three minutes, I hope you might realize that's why you like your NuSphere s/w so much.

So full-blown scheduled licensing may or may not be there at first, but licensing is on the way soon and it will integrate with PHPEd.

That's the best I know.

Hope this helps.

Randy