Currently I am evaluating ioncube for products developed by our company.
When running the encoded product I'm getting
PHP Fatal error: Class '[obfuscated]'
If I have anything like DomDocument in my code I get this error. I feel like if I have any php package installed and used Ioncube throws a error. I contacted Ioncube support and I'm unable to get a solution.
Does anybody know how to use Ioncube with a code contain DomDocument, imagick like package usages?
Obfuscation renames latent symbolic information in the compiled code of ionCube files, using names that are nonsense, or in the case of functions, names that would not even be valid were they used in PHP source. The corollary of this is that any non-encoded context will fail that attempts to use a symbol that has been obfuscated, as expected.
To bridge between the encoded and non-encoded world, an obfuscation exclusion list can be specified to name the symbols that should not be obfuscated. Due to the nature of PHP, in code such as $a->foo(), it is in general unknown what class $a is an instance of, and therefore if excluding foo() from being obfuscated, foo() used in any class context (i.e. all foo()s) would need not to be obfuscated. This isn't really a problem as symbol renaming is much less important than new features such as code encryption with dynamic algorithmic keys, but it is still preferable not to blindly exclude from obfuscation every method that happens to share the same name as a method from a module, which is why methods of module classes are not excluded by default.
The upshot of this is that you should prepare an exclusion file of just the methods that you want to exclude. It would be useful to have pre-prepared lists of functions for all known modules, and this is likely to be available in a future release, but it is easy to produce this oneself either manually or automatically.
Disclosure: I am associated with ionCube.
Related
I would like my Hack code to be broken down to Abstract Syntax Tree. Please advise me on available tools/libraries/github repositories which will help me to parse Hack code into AST.
I have found "h2tp" (hack to php transpiler written by Facebook), however it doesn't parse the code into AST. I also tried this project which does what I want however it is not recognising many of the operators and requires a significant rework, which will quite a lot of time to do.
hhast (HHAST: Low-Level AST Library) lets you do that, you may invoke hh_parse like this : hh_parse --full-fidelity-json $file | jq
taken from (https://github.com/hhvm/hhast/blob/master/docs/ast-lib.md)
The HHVM itself provides a lot of tools to dump the structure of a PHP file. However, the AST dump was removed: https://github.com/facebook/hhvm/issues/1268
What you can do is dump the HHVM assembly language: http://hhvm.com/blog/6323/the-journey-of-a-thousand-bytecodes
HHVM also has a PHP transpiler which may help:https://docs.hhvm.com/hack/tools/transpiler
You could also try to port this extension over to the HHVM: https://github.com/nikic/php-ast
As we know, there are two methods of library loading.
1) Static libraries (.a): Library of object code which is linked with, and becomes part of the application.
2) Dynamically linked shared object libraries (.so), which will link at execution of application and it can be used in two ways.
a) Dynamically linked at run time but statically aware.
b) Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.
After compilation, we can check the library dependency of type 'a' as below
objdump -x usr/bin/flashcp
.....
Dynamic Section:
NEEDED libgcc_s.so.1
NEEDED libc.so.6
My question is how to check/detect type 'b' library dependency ? Please suggest is there any way to detect before execution ?
Thanks in advance
Thiru
There's no way to generally check for libraries that are loaded dynamically and whose functions are called via function pointers.
In some special cases, as a hack, you can attempt various ways of reverse-engineering the executable, e.g. statically analyzing code around the calls to LoadLibrary and GetProcAddress on Windows. You could derive some heuristics that would work on many executables, but there's no way that's guaranteed to work, other than executing the code in a virtual machine and intercepting all calls to LoadLibrary/dlopen as they happen.
Firstly: The "official" (?) node.js externs are located here: https://github.com/google/closure-compiler/tree/master/contrib/nodejs
But i can't use it because the high amount of warnings (and errors sometimes) that are generated. For example: The declaration of "process" module is very "thin"; Only has one property defined on his prototype, besides not inherit from EventEmitter, so i can't register callback when, for example, i want to do a clean job on process SIGINT (process.on('SIGINT', callback)).
When i mix several externs files declaring the core modules of node.js, more and more warnings and errors are raised (i always respect the deps tree between externs). For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
So: What am i doing wrong?
The closure compiler that i am using is the latest git, whit --new_type_inf and --env flags activated, among others.
For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
This highlights the core of the problem - and why they are not well maintained. The compiler doesn't recognize that these variables are in fact NOT global. The compiler currently does not have a method to correctly interpret externs as modules. The were originally contributed and consumed by a fork of the project that could understand externs as modules.
I am currently working on adding support to the compiler for this and hope to some day soon be able to completely rewrite this answer.
In the mean time, you might be able to work around some of this by adding #suppress {duplicate} annotations to the files. However keep in mind that they will still be global types.
If you wish to improve the files (like having process properly extend EventEmitter), I will happily review pull requests for such changes.
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
When using HP-UX I can use the chatr utility to report on various internal attributes of a shared library. It will also allow me to modify the internal attributes of shared libraries that I have built.
The chatr utility can report, and in some cases modify, such things as:
the run-time binding behaviour,
the embedded library path list created at build time,
whether the library is subject to run-time path lookup,
internal names,
etc., etc.
Is such a utility available for Solaris?
Edit: Freaky! Thanks to mark4o's answer below I revisited the elfdump output for a typical system .so (libm.so.2 on Sol 10). However, and here's the freaky part, I mistyped the command to enter:
elfdump libm.so.2 | moe
In an amazing stroke of serendipity, this gave me back the usage message for a utility called moe whose man page description section says:
The moe utility manifests the optimal expansion of a path-name containing reserved runtime linker tokens. These tokens can be used to define dependencies, filtees and runpaths within dynamic objects. The expansion of these tokens at runtime, provides a flexible mechanism for selecting objects and search paths that perform best on this machine.
This will help me resolve why a libm.so.2 shlib is not compatible on both of two different machines leaving my incomplete executable unable to start on one server.
For displaying the information, see the Solaris elfdump and pvs utilities. For debugging binding issues, lari and moe may also be helpful. However, these utilities do not have the ability to modify the library.
Starting with Solaris 11 (and some of the OpenSolaris & Solaris Express releases leading up to it, but not Solaris 10 or older), there is now an elfedit tool for modifying runtime paths and similar attributes.