Hello,

We're going to migrate from IonCube to NuCoder nearest days
and there are several questions connected with this:

- Does NuCoder uses pseudo-bytecode instead of zend-bytecode?
This is one of advantages in IonCube. It uses internal bytecode
format offering better obfuscation.

- What is probability of decoding encoded product? Is this ever
possible by capturing bytecode?

- Do you only offer standard obfuscation algorythms (lines, etc..)?

- What security measures does PhpExpress implements?

- When do you plan to add encryption functions into API?

- Is there a linux version of nu-licgen?

- Is there an ability to only prepend preamble to a single file (entry script - index.php)?

- Is there an option to encode in ASCII/Binary formats?

- Is there a loader-level error-handling API to display custom errors (for example, when license doesn't match)?

Thanks.

I'm not an expert in ioncube, but I have some strong doubts that they are really using different bytecodes. Perhaps a kind of table-based mixing is what they are talking about, definitely not really new bytecodes with different meaning than zend's. In case of totally new bytecodes, they would need to re-implement whole the php VM, including code-generation, and code execution, and maintain all the changes that php code developers do to the original VM. In other words they would need to reimplement all the features of php, adapting them to their new VM and keep adapting during whole product life. It's extremely hard work. I don't think that they do this and if they do, it would be almost impossible to provide 100% compatibility with original php. You can find a few php implementations that are not based on original php VM (php phalanger as and example) and they all suffer from this compatibility problem.

If I am right and this all is about table-based mixing of the opcodes, it's not strong protection. It's only matter of proper reverse-engineering.


Anyway, in order to run mixed or new opcodes, a new or modified built-in php core (executor and compiler) is needed.

On the other hand, this approach with modified php executor/compiler brings very bad surprise.
As you probably know, there are many critical and non-critical vulnerabilities that were found in php during these years. Engineers in companies like Novell and Redhat, are releasing official patches to the linux that they maintaining (redhat, suse etc). These patches in form of updates are automatically installed on your server. So your server is constantly protected with very little gap (if any gap is there at all).
Now, suppose that some vulnerability is found in php executor or code generator. If you try to google, you'll find many things like that discovered in the past. With redhat-network (or suse updates) you're protected because updates to php will be released and installed fast enough.
But it's not the case with modified php executor/compiler, that remains the same because it is built into foreign extension that is not updated and this non-updated code may potentially contain all the same bugs inherited from the original code, that whole the executor/compiler was derived from.

We carefully explored whole the idea of implementing our own propriatery VM for php, considered pros and cons, and finally decided not to follow it. Potential harm that this approach may bring to our customers outweighed all the benefits that this idea might bring.



It greatly depends on qualification and initial conditions.

If the package is encoded by nucoder with license protection and license itself is not available to the engineer (intruder), he will have to crack AES128 first. This cypher is considered strong:
"The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level"... "an attack against a 128-bit-key AES requiring 'only' 2^120 operations" (see http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)

Totally different case is when the engineer has the license or when whole the package is encoded without any license protection.
In this case, he has everything to execute the code and therefore the code can be executed under certain limitations like hardware ID/software and within licensed time-frame, of course. Once the machine CPU can execute that code in php VM, an engineer can trace that execution and sooner or later discover the algorithm. It's only matter of benefits-to-expenses balance. If benefits that such crack may bring are good enough to cover all the expenses needed to perform this work, the work will be done. Under expenses I mean time-frame needed for the work to complete and it greatly varies depending on the engineer qualification/experience.
I think there are no strong criteria on how to estimate the probability of implementing such crack. Only time will tell for sure. What I can say is that I did my best to make protection strong enough and btw continue doing.



With encoding, the line-number info is dropped off by-default. Phpdoc comments accessible via reflection API, are stripped off too. Nucoder also removes debugger opcodes if they are emitted. Then NuCoder offers "basic obfuscation", it's when names of all the local variables and parameters are replaced with bogus/binary names. After that our own proprietary algorthims are used to produce intermediate binary, on top of which AES128 is applied (it's for the files protected by license).



I'm not sure what kind of security you mean. If it's all about protection, AES128, hashes, crc, and some other more or less strong algorithms are used to protect the code.



I'm not sure of the purpose for such encruption API. If you need an API to cyphers like AES128 or DES3, you can use openssl or crypt php extensions. It's rather standard way. Please let know if you need something else.



nu-coder and nu-licgen are available under all supported platforms, including Linux, except Mac OS X. Latter will be supported too.



If you mean code part that will be protected, the answer is no, there is no such ability in nucoder2.0, but may I ask you way would you need it? Is there anything that nucoder should add for you that you can't add yourself beforehand?

If you mean non-protected part, it can be easily achieved. You can encode your project in two phases. First encode all files with one header, then encode index.php with another header.



Only binary format is supported at the moment.
So, additional precautions should be taken when files are transferred over FTP.



I'm not sure how would a built-in error handler display custom errors. Probably you mean i18n. No it's not supported at the moment, but we have some plans in this direction. Meanwhile you can use existing API, install your own error handler and display appropriate messages.

If you experience any difficulties, please don't hesitate to contact NuSphere support.

Dmitry,

Thanks for your answers.



I primarily mean reverse engineering protection.



IonCube offers not only encoding but also has an encryption algorythms for files. For example, if we have sensitive config-file with passwords, this matters. Unfortunately, relying on mcrypt may limit our compatibility. Using php-based function will dramatically affect performance. Especially when we deal with configs that are read upon every request and config cache files.



That's great!




I mean PhpExpress loading preamble which is prepended to the encoded file to automatically DL it. Generally developers use one entry script and do not want to maintain two passes. For example, with IonCube we have to use command-line encoding tasks instead of their great UI-based encoder. All because of they got no option to prepend this preamble to a single file. I wish you to support both: multi-passes + UI or single-file-preable + UI. Hopefully, your customers will appreciate it.




In IonCube we simply specify an external file (unencoded) which contains error-handling function. When IonCube loader detects an error (and files are still unencoded due to an error), we can handle those errors and use our custom error UI.

P.S.

I'm still not sure about migrating to PhpExpress and NuCoder since this might become a painful process. However, there are two primary advantages in NuCoder. First, decoding sites still refuse to decode your files. And second, you have embedded runtime bytecode caching. Your competitors have not. I will probably need to check the demo and decide then. Will I be in position to ask for 30% discounts being PhpEd Pro user for 3+ years?

Don't be fooled. You can protect from regular php users, not from reverse-engineering. From this perspecitives, it's not a protection at all. Why bother to decrypt anything if it decrypts itself and the API functions like mysql_connect are called with plain passwords and it can be easily hooked by replaciung mysql extension with specially crafted version that only dumps out the arguments.



relying on any extension limits the compatibility.



dl()-based loader for phpexpress extension is what nucoder adds by-default.



Seems you didn't try nucoder because what you're asking for is available there.

Relying on required encoder extension is not more limiting comparing to relying on encoder + encryptor.



First, those who can replace php extensions do not have problems accessing mysql at all. I mean saving sensitive information such as
passwords to payment gateways. Yes, it's possible to replace curl and intercept the password. This protection is not from such a case.
Imagine someone having an access to an FTP and nothing else.
- Having an unencoded settings file is definitely weak.
- Having php-based functions is too slow, config loads on every request.
- Using mcrypt affects our potential customers covering.
- Functions embeded into encoder is probably the best way.



Yes, I know this from the docs. The question in fact was if it is possible to specify single file requiring this preamble?
You said this will require two encoding passes. Do, does PhpEd GUI supports multiple passes with dirrerent configs?



Downloaded. Testing.

Well, I almost see the point
Seems you want to store the settings in php file and encode it. No?
You will read these settings from php, then have them store in php would serve you best.
In this case, I don't see any reason why you'd need to have an extra encryption with its API.



sorry, nope, but why don't you leave it intact and have all the headers with dl feature enabled?
Suppose we have apache, php, and dl() is available, while phpexpress is not loaded in php.ini.
If user first launches the file with dl() header, it will load phpexpress. Therefore all further launches of any other files (without dl) will successed because phpexpress remains in memory until apache child process has been stopped. It worked this way in some php versions. Then php developers changed dl and all dynamically loaded modules are forced to unload after the request is finished. So it will behave differently. But why would you need this? Why not to follow regular way and have define('SOME STUFF') in the dispatching file(s) and check whether this 'SOME STUFF' defined in all other (included) files. This adds extra flexibility because your file gets executed and may through human-readable error or redirect to appropriate link depending on the settings.
With fixed header you can't get this flexibility.