Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I use ionCube to keep the code I write concealed for my customers.

If I would store a password inside the code and compile (not encrypt) it with ionCube encoder, would it be possible for a potential hacker to get hold of that password?

For example, is it possible to reverse engineer parts of the PHP code, that was compiled with ionCube?

Or, could you send commands like get_defined_vars() in a page that was compiled, if you have the complete encrypted source-files?

share|improve this question
    
What do you mean by "encrypt with ionCube"? It doesn't encrypt the code, but encodes PHP scripts with compiled bytecode. Encoding (or compiled code) is in no way encryption. While the package has capabilities to encrypt arbitrary external files, they would have to be decrypted at run time by the compiled executable to be used. Meaning, you'd have to distribute the key along with it in the compiled code. This key can be extracted from compiled executable, either by direct inspection of its bytecode, or loading it in disassembler and checking it when in memory and used to decrypt files. –  TildalWave Jun 25 '13 at 11:47
    
ok I corrected it to "compiled" (and I meant concealed, not "revealed", sorry my english). So how could I create a secure place to deliver a password with the code, that is conceiled to the customer that gets the compiled code? –  rubo77 Jun 25 '13 at 12:15
1  
Impossible, at least by including it within the code. Any nosy customer wouldn't have much problems extracting the encryption key from your compiled code, and that goes the same for any compilers out there. You could consider different methods of distribution for your encryption key(s), but including it within the code (no matter how obfuscated the code is and/or keys fragmented) is nearly as bad as writing it down in plaintext along your compiled code. –  TildalWave Jun 25 '13 at 12:22
    

3 Answers 3

Yes, it's possible to reverse engineer anything that is running inside a computer. It will always be loaded, at some point, into memory, at which point it will be unencrypted / decoded / unzipped / e.t.c., so the processor can handle such code.

In your case, a password that is hard-coded in a variable will eventually be used. And so it can be used, it will first be unencrypted...

share|improve this answer
    
Is it only possible to get hold of the variable by analysing the running code in some really sophisticated Runtime analysing tools? Or is there a simpler way in the case of ionCube? For example a decompiler that gives you back direct unformatted PHP code? –  rubo77 Jun 26 '13 at 22:06
    
in general, it isn't that easy to read the code that a decompiler produces, since the "compilation" process of PHP + ioncube will produce some optimizations. Your costumer won't have a nice, easy to read and understand, code. But he can hire someone that will understand the bytecode, or the assembly code... –  woliveirajr Jun 27 '13 at 14:12
    
was afraid of something as simple as this demo. there you can see all the variables as they were defined in the uncompiled files –  rubo77 Jun 27 '13 at 18:31
    
I don't think so, but never tryed that program... and given your questions, and how much that security would mean to you, I'd go with some external hardware (java card, basic card) that would process part of the task, and access it from php or from any other language + php exec(). –  woliveirajr Jun 27 '13 at 19:52

Not very secure, but you can use it for avoiding outside interference. I will say it's less than 50% secure out of 100%. There are plenty of tools on the Internet for partially decompiling older versions of ionCube.

An example - ionCube decoder

I recommend you to choose some other encryption tools for protecting your code.

share|improve this answer

Notice: The author of this answer is affiliated with ionCube. Please keep in mind that answers and comments submitted by ionCube employees, whilst with good intent, may be subject to conflicts of interest.


The answers here are good, though thoughts such as "any nosy customer wouldn't have much problems extracting the encryption key from your compiled code" stretches things somewhat because end users and even most PHP developers typically lack the knowledge required in terms of modifying the PHP engine to expose runtime data in any useful way.

Bytecode protection is based around compiling code to a different language, the bytecode, and making best efforts both to make the bytecode and metadata hard and expensive to discover as well as understand if one gets it. ionCube compiles the code, uses various techniques to protect the bytecode, and uses a non-standard PHP execution engine in order to be able to use bytecode that differs to the bytecode that PHP would normally produce. This accounts for the relatively large size of the runtime Loader component when compared to the same from some other solutions.

Using PHP functions such as get_defined_vars() that you mention may not be possible because files can be encoded so as to work only with encoded files produced by the same copy of the Encoder, and to fail if an encoded file were replaced with a non-encoded one. Similarly, using obfuscation of variables can disrupt the results of such functions.

There are limitations to what is possible with PHP being opensource though, as well as tradeoffs in balancing the goal of protection with runtime performance and compatibility with standard installations in particular, shared servers. While passwords to mysqli_connect(), for example, may be well protected, a hacker could modify the mysql library or the PHP mysqli library wrapper and recompile PHP to expose the password at runtime. This may not be an issue in practice however, and if it were, there are ways to increase security provided that compatibility with default PHP installations is not required. Contacting ionCube for advice is recommended to get insight into strategies that best suit your use case, and you may learn of non-publicised possibilities that you would not be aware of.

share|improve this answer
5  
It's a dangerous mindset to think your compiled application is safe from inspection and any secrets held within it (code itself or heavens forbid - encryption keys or passwords to remote services) won't be revealed just by assuming most users haven't a clue how to go about extracting such information. What's stopping them from taking the executable to someone that they know can fiddle with disassemblers/debuggers? There is no such thing as bytecode protection, it doesn't matter what marketing people tell you. But reading your answer, I have to ask to please disclose, if you are one. –  TildalWave Jun 29 '13 at 21:20
    
Bytecode can certainly be protected, just as your house, car, etc. can be, but this does not mean that such protection is impenetrable. As I mention in a reply to the OP's other question, any software or hardware can be reverse engineered to try and understand how such protection works with a view to bypassing it, just as the locks on your car and house can be bypassed easily by a master locksmith. While a protection mechanism may potentially be bypassable, this does not mean that such a mechanism will be ineffective in what it is required to do however, and it could be 100% effective. –  Nick Jun 30 '13 at 19:46
2  
That is, as much as my house or my car can be protected, if I move them over to your place and let you do whatever you want to them while I'm not in or near them. See the difference? You don't need to be a master locksmith, if nobody is watching you and you don't risk detection. And it's a bad analogy anyway, because the ones you'll be protecting your house from will already be living in it and driving your car around while you're stuck on protecting their doors. And again - please disclose, if you're associated with the solution provider you're endorsing. –  TildalWave Jul 1 '13 at 8:39
    
It's tempting to think that way, but while if you left the door open to your car then some would take that as invitation to step inside and perhaps have a play, with the door closed and locked, most would leave well alone and not even try the handle being honest and having better things to be doing with their time. There are always risks from the criminal element, but protection can be a game changer, it can eliminate misunderstandings or wrong assumptions about what is permitted activity, and risks may be reduced to an acceptable or manageable level, even though they may never be eliminated. –  Nick Jul 1 '13 at 9:01
2  
@Nick As a matter of professional and academic courtesy, and to avoid a conflict of interest problem, please disclose whether or not you are affiliated or associated in some way with ionCube. Until you do, people cannot make an informed decision about your statements, and your contributions here risk being detrimental rather than helpful. –  Polynomial Jul 1 '13 at 9:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.