Prolog in general, but SWI-Prolog in particular is an transparent
environment. Prolog's “code is data” point of view makes
this natural as it simplifies development and debugging. Some users
though want or need to protect their code against copying or reverse
engineering.
There are three ways to distribute code: as source, as .qlf
file and in a saved state. Both QLF files and saved states contain the
code as virtual machine code. QLF files capture the predicates
and directives, while saved state capture the current state of the
program. From the viewpoint of protecting code there is no significant
difference.
There are two aspects to protection. One is to make sure the attacker
has no access to the code in any format and the other is to provide
access to a non-human-readable version of the code. The second approach
is known as code obfuscation. Code obfuscation typically remove layout
and comments and rename all internal identifiers. If an attacker gets
access to the SWI-Prolog virtual machine code this can be
decompiled. The decompiled code does not include layout
information variable names and comments. Other identifiers, notably
predicate and module names are maintained. This provides some protection
against understanding the source as Prolog code without meaningful
variable names and comments is generally hard to follow.
For further protecting the code, there are several scenarios.
- If the user has unrestricted access to the file system on which the
application is installed the user can always access the state or QLF
file. This data can be loaded into a compatible emulator and be decompiled.
- If the user can run arbitrary Prolog code or shell commands the
state can be protected by embedding it as a string in the executable
deny read access to the executable. This requires a small C program
that includes the string and uses
PL_set_resource_db_mem()
to register the string as the resource database. See PL_set_resource_db_mem()
for details. This protection should be combined with the protect_static_code
described below.
- Some extra protection can be provided using the Prolog flag protect_static_code,
which disables decompilation of
static predicates. Note that most Prolog implementations cannot
decompile static code. Various SWI-Prolog tools depend on this ability
though. Examples are list_undefined/0, autoload/0,
show_coverage/1,
etc.
If the option obfuscate(true) is used with qsave_program/2,
certain atoms in the saved state are renamed. The renaming is performed
by library library(obfuscate). The current implementation
is rather conservative, renaming atoms that are used only to define the
functor that names a predicate. This is a safe operation, provided the
application does not create new references to renamed predicates by
reading additional source code or constructing the atom that names the
predicate dynamically in some other way such as using atom_concat/3.
Predicates that are called this way must be declared using public/1.
Note that more aggressive renaming is possible, but this requires
more detailed analysis of the various roles played by some atom. Helpful
and descriptive predicate names tend to be unique and are thus subject
to this transformation. More general names tend to collide with other
roles of the same atom and thus prevent renaming.
