1. Software protection
for BRAINIES
This paper is written with the same objectives as one « for DUMMIES" which is to
get the essential of a subject for non experts. We made it for "BRAINIES"
because software protection is not yet a well-established activity in the I .T
domain with experts and DUMMIES.
Hence, it is an emerging activity for managers aware of the new risks brought by
softwarization and cyber war. This paper content does not require any kind of
background however and could also be for ANYONE
This paper covers the « new » needs and what shall be your objectives. We
discuss the techniques at stake and their relative efficiency. At last, we deliver a
few recommandations.


2. Why should I protect my software and what should be
my objectives? (general survey)
There are several motivations for software protection. They are mainly bound to
securing a business position on the one side (agression comes from the industry)
and to be better protected against a cyber attack on the other side (agression
comes from the cyber security scene). We view the following use cases for your
motivation:
Secure my intellectual property (and future business
position):
In a world where SOFTWARIZATION is the common trend in many industries,
meaning that hardware is used « off the shelves «, the added value of a I.T
systems is exclusively placed on its software. Securing the software is securing
the durability of your business position on the medium term.
The need for protection of software is becoming a growing concern at
headquarters in these industries (defense, telecoms, IoT) which are ported by
this all-software move. Securing software intellectual property becomes a priority
because it mainly represents the company key asset. However in the same time,
it is more exposed technically than the hardware and is less legally protected.
Patents and anti reverse engineering clauses in licence contracts are not strong
barriers (if any...). Setting technical measures for protecting the software
intellectual property is more and more considered, especially when there is no
(full) trust or control on how the users use the software.
Let us also examine two key combining factors boosting the need for
software protection
1. It is no secrete that patents do not fit well (or at all) with software
intellectual property protection. To illustrate it, if a patent would be based
on a sequence of processor instructions (as is your software to protect), it
would just be useless to its owner. Code obfuscation techniques remind us
that there are thousands of possible ways to make the same functionalities
but with different sequences of instructions. Software patents will not work
(per se) because there are no viable way to demonstrate the
counterfeiting. It is always possible to bring a theft software with a very
different shape from the original and obfuscators can make that look-like-
transform automatically. However, the software could be « materializing »
an invention in rare situations. The invention could be high-level and would
describe the global orchestration (type of processing with types of data).

3. This occurs in rare situations which would call for a « high level » invention
patent application. By far, all software are not connected to such
patentable invention.
2. Software is far more exposed to theft than any other part of your system
just because it is a few click operation to extract the software (if you are
not protected) and the analysis can be done using a 500€ standard PC
running IDA Pro, the one tool of reversers.
The objective of the protection is to prevent the analysis as well as the retrieval of
some parts of your code for being re-used elsewhere and typically in competitive
products. Actually the protection objectives are twofold: braking the anti reverse
engineering and braking the tampering of your code. Blocking this activity totally
is often not possible, notably when the attacker can retrieve the code, plug IDA
on the machine that executes it. The objective is to make this work much more
demanding, complex and tedious.
One can consider that a better defined objective is to raise the bar sufficiently so
that it would cost less effort to rewrite the code from scratch than for reverse
engineering your protected code. As a matter of fact, rewriting your code from
scratch can never be avoided since it is always possible for someone to look at
your system (if the system is in front of his eyes), or get your commercial
materials to extract a list of specifications and features and start coding. This is
the bar height one should have in mind when setting the protection level
As a summary, let us remind :
 The threat is coming from the industry (competitor). This competitor may not
be already active on the market at the current time but getting access on
your code could fasten his access, especially on his geographical area of
influence.
 The objective one shall have is to prevent a faster way for the potential
attacker to make an equivalent software than the complete development
from scratch and without aid.
Secure my immediate incomes
In this section, your key objective is to secure your business model, not the
software per se.
The sustainability of your business model is always endangered if one can access
to your software, analyze it and tamper it.

4. Even the supposedly piracy-free business models of the inventive video game
industry are jeopardized by pirates or organized cyber criminals.
Whatever your source of revenues belonging to this list:
1. licence fees, (per user, per company)
2. advertising, (freemium model)
3. additional content sales, (as the « free-2-play » model of the video game)
4. registration for online service
there is no safe place if one can twick the user right management routine or
reappropriate your software (with just minor changes before publishing it on a
store and collect all advertising revenues, …)
Remark on open source model : The 4 item list excludes the open source model
(where one delivers its source code to any recipients). In this case, protecting the
software is non sense… However, protecting one’s model is an issue. With open
source model, support fees are the source of incomes. If you (as the developer)
are the best placed to the make the support job, other ones can do it too since
they have access to your sources and are likely to be more efficient in setting the
infrastructure and services for users (as they might already support other
software and can just re-use existing infra and workforce).
As far as securing your incomes is concerned, one can distinguish several cases
which concentrate on different areas of attacks:
Protection of the external user right management patch routine that deals with
the user’s right (Digital Right Management).
On the PC world, DRM routine shall be the focal point of attacks and shall be as
such strongly protected. This is delivered by the DRM vendor and is external to
the code to protect and acts as the licence policy enforcer. An attack can result
in the removal of the routine, leading your software with no user control and a
free download access on some « Warez » website (for games and PC utilities
typically).
Protection of the software itself : A few « surgery » changes on your software
made maliciously can be very damaging to your revenues.
As examples, one can work them out to:
1. Take ownership on your code : For open and commercial products (games
for PC or for smartphones), slight look-and-feel mods or local market
localizations (by translating user menus) are sufficient to get the same
software distributed on the same app store and to divert the revenue
flow…Typically on the smartphone app stores, there is no control on who

5. are the software real developers before putting the app on the store for
sale. All applications are essentially filtered through quality standards with
no control on who applies for it.
2. Remove your business model anchorings. In a ads-revenue model, the
attack can be to remove the ads, then place the ads-free game on a
Warez site. This new game will collect soon a better user ranking than
the original, thus it will collect a bigger share of the total revenue stream.
As a summary, let us remind :
 The threat is made of underground pirates (with no financial goals) and
organized cyber criminals (with financial goals). The threat wants to modify
your code or the DRM routine for its own interest or for the interest of a
community of potential users.
 Your focus of the protection shall be different according to your business
model (what needs to be protected exactly). However, the goal is more
directed to blocking the modification of the code than it is to blocking the
analysis. Your objective shall be to render the modifications very complex by
use of anti tampering techniques.
Prevent the analysis of the software aimed at finding
vulnerabilities.
Finding vulnerabilities inside a software executable (in the form it is distributed
and accessed by the attacker) is the first step for a cyber attack. The new trend
of Advanced Persistant Treats requires the code to be (statically) analyzed first in
order to extract potential vulnerabilities. The first step paves the way for a
application-specific exploit development. APTs are application specific that rely
and use one of the very few standard vulnerabilities.
If you already know that your code is potentially vulnerable, you would be
interested to remediate these vulnerabilities or at least to hide them. The
remediation requires the developer to make some changes at source code level.
This will remove the vulnerability, no more present on the new version. In practice
it encounters strong (business) obstacles. The first being incurred costs to be
balanced with an uncertain threat (not yet revealed).
Hiding these vulnerabilities could be much easier (and partial) though partial
objective. It will not remove the vulnerability so that if the exploit is already

6. developed, it will reach its target. However, concealing the vulnerability prevent
the development of specific APTs. It could be a temporary gesture to harden the
code before it is being modified and cured by the developer (and the vulnerability
removed).
If you have some kind of doubt with your code, you could start to check which
open source libraries your code integrates since hackers will have their special
care and focus on commonly-used librairies. These ones are important pieces of
code where many vulnerabilities could be found. For a hacker, such vulnerabilities
could be used with a good return on investment since many different applications
would be affected and many different exploits and APTs designed.
When designing an APT, the hackers will be itching typical signatures contained
in their vulnerability database. This detection can be nullified by use of code
protection since the signature of the vulnerable code will not be inside the
database anymore.
As a summary, let us remind :
 The threat is a cyber attack, designed on commonly found vulnerabilities.
 Protecting your code can expand from vulnerability removal, which requires
an access on the source code and the original developers to be acting, or far
less impacting vulnerability concealing done automatically at machine code
level.
Prevent the modification of your software for a system to
be used outside the range of its « sold » operational
conditions.
Some software can be sold only if there is a kind of waranty that it is used in
some kind of « factory parameter conditions ». Defense systems are exported
through export licences delivered according to a specific operational capability
definition. The car industry also makes sure some engine or security parameters
can not be tampered. Typically, a engine max rpm can be software capped and
this high limit shall not be easily modified. The protection is essentially aimed at
blocking system parameter changes.
As a summary, let us remind :
 The threat is coming from your own customer (the owner of a car or a
sophisticate defense system).

7.  The objective is to hide some specific parameters and the chain of processing
which interact with these data.

Reverse engineering and techniques to slow it down.
General
Software protection is not an exact science where someone can state « I am
secured, nothing can happen to my code from now on ». Hence, if someone can
access to the machine and retreive the code, she will be dealing with a sequence
of well-known machine instructions executed on a processor. Provided that you
can not block this situation (and we will see that there are possibilities to refrain
the access to code), code protection is a relative process, not a final lethal one.
As a example, if you are protecting the intellectual property of your software, as
stated above, the objective is to set the bar higher than it would cost to make the
software from scratch, a situation no one can block.
Reverse engineering
The limits of software protection also come from the art of reverse engineering
and software modification. It is important to remind these basic lines which
define how the attacker proceeds :
There are two ways to proceed, two (plus one) types of analysis of the code :
 The first one is static code analysis and it consists in analysing the code by
reading it. It is however often very much outstanding to what is really useful
to grab since some portion of the code will never be executed in the vast
majority of the software executions.
 The second one called dynamic analysis and consists in a step-by-step
(instruction per instruction) status changes tracing (operations, memory
values, processor register values). This is under-representative of the
program since it relates to only executed instructions at this execution run.
The tracing is done with a desassember such as IDA, the super dominant
tool all reversers work with. IDA shows the diffferent areas of scrutiny
(defined at will of the user) as well as the assembly instructions which are
processed (in case of native executables). The step by step tracing is

8. eased with the presentation of aids such as the execution path tree when
it can extracted.
 Actually, the reversers will work out the analysis using both methods when
they can (this is called the hybrid method) since both brings its
complementary support. The hybrid method combines methods (when
both can be applied) to collect all branches of the code execution path. The
collection of the complete graph requires either a fully representative
execution of the code (which can never be garanteed) or a through static
analysis of all conditional jumps instructions and their predicate
management code (located just ahead the jump). As a matter of fact, a
branch is always accessed (except the main one) by a a conditional jump
instruction.
Once the reverser has collected a supposed good representation of the program
(containing each of its useful branches), the analysis can start. In this complex
and opaque territory, the progress will follow our cognitive strategy, based on
past experience and through compare and contrast steps. To go faster,
reservers are helped with semi automatic search tools called « heuristics ».
To counter the progress of the reversers, the protection shall present a strong
variability to remove any already seen patterns in the protection. This variability
shall be occuring from one protection project to another as well as inside the
same project. The reverser shall not start a work with prior knowledge caught
from a previous analysis. More, inside one project, the protected code shall not
include similar repeated patterns but as many different ones as possible, forcing
the reverser to study each of them separately and preventing the heuristics to
ease the identification and association of code patterns.
Anti tampering technique and its limitations
Anti tampering techniques are all simple patched mechanisms that use the
program own footprint (in its original print) during its execution.
Memory cell reads pointing on the program locations are used by the program
itself.
Changes on the program are likely to modify the retreived cells during the
execution, thus causing abnormal behavior. All of these locks can be
automatically detected since they all refer to a memory read. Once detected, the
mechanism can be inhibited by injected the correct expected value one can
collect on the original (before it was modified).
Software protection complementary techniques
The modus operandi of the reversers lead to the following features for the

9. software protection:
1. The very first attempt when protecting a software should be to
prevent the code to be easily extracted (meaning the image easily
produced and copied) so that the analysis can be done at its own
pace and good working conditions. If the protection installs some
attachment mechanisms that prevent this easy code transfer, it
forces the reverse engineering to be worked out on a specific
machine. This restriction can be a strong hardener in the real world.
2. To block static code analysis, we can encrypt the code so that it is
not intelligible if it dumped in its storage form. This could be a good
start as well but it has its limitation: the encrypted code can not be
used by both the reverser and the machine. This means that the
code shall be decrypted before execution on the machine. At a
sudden point, the hacker has an open door to the code in clear. To
reach this point, the code tracing when the code is loaded before
execution is done until decryption reveals the code in clear. This
requires that a dynamic analysis be processed during exection (at
program start).
3. Tracing the code seems to be the usual mode when one can execute
the software on a machine that also runs IDA. Blocking IDA by
software detection mechanism is sometimes offered but it brings
drawbacks for the code maintainers. In practice, IDA detection tricks
can be quite easily fooled and overcome by reversers.
4. If IDA tracing is the way and constitutes what can be perceived as
the security threat (i.e, the typical and representative use case to
deal with), the protection shall make it more time consuming. This
can be done only by extending the number of executed instructions.
This extension has a direct impact on the program performance
which is its execution timings. It takes longer for both the machine to
execute and the reverser to trace the code.
5. Repetitions in the protected code are the « power boosters » of
reversers. They reduce the efforts to be carried out (« analyze once,
use several times »). They shall be avoided since they still impact the
same way the machine. Said differently, the sofware is slown down
but the reverser effort is not increased in the same proportion.
Repetitions are synonyms of poor efficiency in software protection.
6. Anti tampering techniques shall be widespreadly dissiminated all
over the code, including hidden branches. They do not present a firm
lock on the code and are possibly inhibited. Their impact on the

10. performance degradation is however minor. Multiplying their
occurrence increases the reverser effort linearly since each one
demand manual operation on the code. A uniform distribution of anti
tampering technique is the good approach. It is deterrent since the
reverser never knows if the job is completed and the code removed
from any anti tampering checks.
Remark on Trusted Execution Environment. Recently adopted techniques
developed by processor manufacturer (INTEL and ARM) are hardware-based
trusted execution environment. These execution environment are not accessed
by the user (reverser) and by any of its tool. There is no more means to follow the
instructions and their working space (memory). As long as they are not broken,
these hardware-based protections for software are the strongest solution for
securing the portion of code placed there (a sub-part of the whole software). The
software to be placed there shall be minimal since it will not be accessed
thereafter and the communication link between both protected and unprotected
zones can be spied and fooled. The good use of these TEE requires some kind of
expertise that will probably not be widespread in the industry. It is therefore more
to be viewed for securing some sensible data used to check the integrity and
authentication of a code. These security routines could be placed there and could
belong to the operating systems or security vendors solutions.

Efficiency of the techniques.
Code encryption
Code encryption prevent the static analysis when accessing the code stored.
Reverser with a background will be able to make the code in clear extraction
extraction if IDA can be run on the machine that executes the protected
application. Attaching the code decryption to a machine through a machine
binding routine restricts the margin of maneuver of the reverser who needs to
be on that specific machine to make the code in clear extraction job.
Code encryption presents various types of costs according to the frequence of
the encryption/decryption. It can be seamless if it is decrypted only at the first
execution (for ever) but the same timing cost can be added if decryption is
applied at each run. The cost depend on the encryption algorithm. We would not
recommand to use sophisticate and time-consuming ones since the key will

11. always be accessed by the reverser. The strength does not depend on the
encription algorithm.
Graph over complexification techniques
Several techniques can be offered and the most used is junk code.
Junk code are never executed branches but the predicate that driveS the
conditional jump is a counter intuitive and complex. The complexity is such that
the reverser will prefer to start the analysis of the branch and loose time.
This technique has no effect on performance (since the code is never executed) ;
This technique must be switched off/on since junk code are not accepted in
some industries.
Code obfuscation
Variability is the key word for efficiency. It translates the code expansion into
extra effort with the highest ratio.
Code obfuscation is not a lethal technique. The good question is not to guess if it
can be broken (since we already know the answer) but to make sure that,
according to your budget (code expansion) it can still be sufficient to deter a
reverser.
Code expansion shall not be viewed as the burden of the code obfucation but
more as its objective. However, since it impacts performance, you need control
and precision in your adjustment. With today processing power available, code
obfuscation can generate a massive code expansion (meeting your protection
efficiency objective) at no real impact on performance. The basic objective of
making the reverse engineering work more complex and long than the code
rewriting from scratch is very reachable.
Anti tampering
Each individual locks requires a manual operation to be inhibited by the reverser.
They can not be automatically removed. One can estimate that the global
resilience to code modification is a linear function of the anti tampering technique
occurrences.
The ideal is hide some in hidden branches or with effects that happen only at
some specific conditions. If the anti tampering measure has not been activated in
one execution trace, it can not be circumvented by the reverser. It is therefore a
domain where smart paths can be forged to fool the reverser. Since no

12. completion can be acheived when testing the modified code (no one can say : it
exactly works as the original), the dissimination of anti tampering traps can be
deterrent since it gives the impression that the code can still be trapped
somewhere.
Code hardening technique
If your code contains a known vulnerability, concealing the vulnerability can be
very simple done using code obfuscation. The signature of the vulnerability will be
different to all stored variations. The efficiency of the technique depends more
on :
1. How can it be applied ? (with a very large preference to solutions that do
not require source code modifications… )
2. What kind of attacks are we supposed to be protected against ? (a blind
brute force attack or a target attack ?). A blind attack will probably go
through your defense since the vulnerability is still present.

A few considerations
 It is important to start understanding what are your threats and objectives:
The key questions are : What shall I protect against which threats (piracy,
loss of intellectual property and competitive edge, cyber attack, …). This
paper may bring a few hints.
 Be selective on what you want to protect and on the associated
technique (encryption, obfuscation, anti tampering). There is always a
machine cost attached to each software protection which varies
significantly among techniques. Restricting the perimeter to specific areas
and protect them according to their severity (exposure) is good practice.
 Consider solutions that give you the control you need : precised control in
the setting, control in selected various features, and control on the
performance impact on your code since this will be your yellow line. You
need to get a general understanding on how the solution works and how
you can articulate the different features (and their gradations).
 Consider the workflow and the software life cycle management in whole.
This includes the future maintenance. Priviledge solutions that have no
impact on the workflow and on the way your team develop, test, distribute

13. and maintain its code as well as any of your tools (development, build
process, compilation).
 Consider the solution that deliver « positive » granularity meaning that you
can select the piece of code that is protected and you know that the rest is
totally unchanged. Reversely, some techniques commonly offered by
vendors bring this kind of « negative granularity » which means that the
modifications brought on the code (typically renammed variable or function
names) need to be exported outside, meaning on other segments of code
interacting.