Previous | Next | Up | Table of Contents

5.4. Reflection & Keys

The Reflection and Keys tab in the Project Settings dialog is illustrated below:

This tab encompasses settings related to reflection operations and key-based security features.

Reflection

Several PHP reflection functions require the bytecode of a function to be present so that the reflection operation can be performed. Due to security features in encoded files, some reflection functions might not function as expected, however a project can be configured in a way to support reflection.

If reflection is not utilised in your application, the default option of None should remain selected. Opting for All indicates that any function in the encoded scripts might be referenced by PHP reflection functions. While this approach is straightforward, it's not the most efficient.

For more granular control, the Functions listed in file option can be used. This requires providing a file listing patterns that identify specific functions or sets of functions. Patterns must be one per line, and the following syntax can be used:

• myfn
  An ordinary function.
• MyClass::foo
  A method within the MyClass class.
• MyClass::*
  All methods inside MyClass.
• Lang\Translate\*
  All functions or methods under the Lang\Translate namespace.

If reflection functions may be performed on parts of your code, it's advisable, when feasible, to use a file with patterns to pinpoint the relevant segments of your codebase.

Dynamic and External Keys

Dynamic and External keys can be used to enhance the security of encoded files. A Dynamic key protects a PHP function and requires an expression to be evaluated before the function can be decoded and run. The result of this evaluation is then used in a decryption step by the ionCube Loader. An External key is separate from the encoded file but is crucial for its proper decoding and execution. For a detailed understanding of these features, refer to the External and Dynamic Keys chapter in the User Guide PDF. The main points are summarised below.

Dynamic Keys

Dynamic keys are specified as comments directly above the function they protect. This comment has a format recognised by the Encoder, and may include a URL, variable name, or function name, along with the expected value. The screenshot at the start of this section provides an example. The Encoder utilises the expected value during the encryption of the function's bytecode. At runtime, the key's source must produce this exact value, or decryption will fail. A significant advantage of this approach is the absence of a decryption key within the encoded file. As this relies on comments in the source code, there are no specific project settings associated with this feature.

Detection of Dynamic Keys During Encoding

When a Dynamic Key is detected during encoding, the relevant information will be recorded in the Event Log. As illustrated in the image below, you can see an example of a dynamic key associated with the myfn function.

External Keys

An External key is data separate from the encoded files, and is required for successful decoding of files encoded to use it. Such a key can either be a string value or the contents of a file. If you're using a file as the external key, this file is used by the Encoder during encoding. Additionally, guidance must be provided on how the ionCube Loader can determine the path to a file on the run-time server with identical content when executing the encoded files.

External Keys Configuration

The run-time location options for the key include:

• The path to a file containing the key on the run-time server.
• A property in a php.ini file. This can be the key's string value or the path to the key file on the server. The property name follows the format ioncube.loader.key.propname
  e.g.
  ioncube.loader.key.v = "key value"
  or
  ioncube.loader.key.p = "/var/www/html/scripts/key.txt"
• A property within a license file. The property's value can be either the key's string value or the path to the key file on the server.

If a file on the system running the encoded files supplies the key during runtime, a local file with identical content must also be specified for use when encoding.

Below are some examples illustrating how to configure an external key using each of the three supported methods.

• Example 1: Specifying the run-time path for an external key during encoding.

  

• Example 2: Configuring an external key using a php.ini property where the value is a string. The full name of the php.ini property at runtime should be ioncube.loader.key.name so in this example the php.ini file should have a line:
  ioncube.loader.key.keyprop = "Secret text"

  

• Example 3: Configuring an external key via a php.ini property where the value is a full file path. The name of the php.iniproperty at runtime should again be ioncube.loader.key.name
  The file referenced by the ini property should match the contents of the file used during encoding.

  

• Example 4: Configuring an external key via a license property where the value points to a file. In this example, a license should be generated having the property name keylicprop with the value being the full path for a file that matches the content of the local file used during encoding.