laserlight;11042485 wrote:You cannot disclose the technique because of legal reasons or because your technique depends on it being unknown? For the former, that's fine; for the latter, it means that you should change technique since even without being able to read the code, an attacker in possession of obfuscated code and who is able to observe the code in action may still be able to discover how it works. The idea here is similiar to cryptography: the security should not depend on the algorithm being unknown.
you can argue different methods of security, nothing is ever that secure.. hence i developed my own, crude way, but yes it depends on it BEING unknown. sure spend a month on it you'll probably crack it.. but if you can't read/decipher my code properly you'l go nuts and find it not worth cracking at all. it's a matter of comparing license file w/ hashes in the project folder, plus machine environment variables etc.. AS LONG AS YOU CAN'T READ MY CODE you wont crack it i can almost guarantee you. i've had people try to already.. in fact i hired some of my peers to, some w/c are even way better than me. but it's just w/ the recent realizations that my weak link is the encoded file being decoded so easily in the first place and w/ an exposed code, it's going to be clear how i mixed things up.
I've been using Zend Encoder, and iONcube to do this and have always slept well , until i decided to dig deeper in the decoding world (just to see how safe my code really was) and hence, my great disappointment.
laserlight;11042485 wrote:
No, I am not missing the point here. I am pointing out that "it's also about SECURITY" is a poor reason for obfuscation. Thinking that "direct database manipulation will certainly cause errors sooner or later" is sloppy where security is concerned. If it is about security, then untrusted personnel should have no access at all, not just "limited access to the system" and worse still, write access to the database.
If the IT staff have access to the server and you have good reason not to trust the IT staff, then the right approach is to convince the customer that their staff cannot be trusted and hence they should outsource the server to you, in which case your problem disappears too since the IT staff would control the infrastructure but have no access to the server in their intranet... but I doubt the customer will be convinced.
Sorry but you are... sort of. you seem to head off to a different direction in the discussion.. for example, we can discuss all day about selecting the right IT Staff , one that can be trusted, forcing the client to let me manage and host it, and other things, but that's not really the point here.. (dont get me wrong i do appreciate the feedbacks still) .... My point is regardless of those things, or try to accept that sometimes WE DON'T HAVE that control over the situation, how do we protect ourselves when our stuff is out there out of our control? Database can always be manipulated if others have access to it.. i can't deal w/ that anymore all i can do is secure my code, my functions,routines, and ultimately my intellectual property.
-- and to answer you quickly about it, NO i dont want to manage the client's IT dept/server/system. I plan to sell this and leave it to client.. i dont make enough profit from each deployment to even bother to.. and i will never be able to guarantee an honest IT admin handling the server .. that part of the war is lost.. i just need to look inward and protect my work, that's all.
laserlight;11042485 wrote:
Did you enable obfuscation on those encoders that you tested, if they provided such an option?
Yes i actually did, and more. i actually generated encoded php files using different techs (zend, ion, sourceguardian), and enabled obfuscation.. and then sent samples to decoders posing as an interested customer.. and sure enough they sent back decoded files.. the bytecode encoding was USELESS and there were no TRACES of it once the files where returned to me.. (even eval and php based crypto obfuscation was useless) .. the only thing that seemed to stick are the plain/simple obfuscation because obviously, there's no way for the crackers to reverse the string, var, function, class, etc obfuscations, and at least that makes it a bit harder for someone trying to figure out my scripts.. that's why i was asking about the worth of these bytecode encoders at all? might as well just plain obfuscate. 🙁
laserlight;11042485 wrote:
Encoding has never been about preventing the code from being read. Rather, it is a form of optimisation for deployment. Consider: if you write a C program, you would compile it and distribute the executable. Generally, it is faster for the computer to execute the executable code than for an interpreter to interpret source code and cause it to be executed. The executable code looks obfuscated, but chances are, it isn't. You could use a tool to turn it into assembly language, and then if you were skilled at reading assembly language, you would have a good chance of understanding the code (though it wouldn't be exactly the same as the source code due to compiler-applied optimisations). Hence, the idea is to turn PHP source code into bytecode that can be more readily executed.
I think you're wrong here.. perhaps at the begining people compiled for performance. but if you're like me who's spent a ton of time reviewing different encoding products, you'll know it's pretty obvious that CODE PROTECTION is #1 priority and performance is #2... at least for PHP it is. in fact, there are options in encoders w/ very strong encoding that slows down performance. CODE PROTECTION is so important nowadays for security (such as my example of IT staff not able to inject their own code in the software) , copyright protection, licensing, etc...
laserlight;11042485 wrote:
EDIT:
Minification of code can be somewhat undone, e.g., by running the minified code through a source code formatter. It is also a form of optimisation for deployment, though in the case of PHP the improvement is negligible. However, if the minification amalgamates source and include files into as few source files as possible (with undescriptive names), then in combination with basic obfuscation techniques like renaming, the code will be difficult to understand because human readable context will have been lost. The thing is, a quick check shows that Zend Guard at least claims to be able to do those basic obfuscation techniques, which leads me to suspect that you simply have not enabled them.
[/quote]
yeh true.. obfuscation can somewhat be undone, at least to a certain level. but I think that's enough for most , or i guess it's the best we got at the moment <- i guess this is the moment.
🙁
