SlideShare a Scribd company logo
1 of 13
Download to read offline
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.

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).
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.
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
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
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).
 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
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
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
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
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
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
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.

More Related Content

What's hot

Isaca conference threat_modeling_marco_morana_short.pdf
Isaca conference threat_modeling_marco_morana_short.pdfIsaca conference threat_modeling_marco_morana_short.pdf
Isaca conference threat_modeling_marco_morana_short.pdfMarco Morana
 
Comodo advanced endpoint protection
Comodo advanced endpoint protectionComodo advanced endpoint protection
Comodo advanced endpoint protectionDavid Waugh
 
Threat modeling web application: a case study
Threat modeling web application: a case studyThreat modeling web application: a case study
Threat modeling web application: a case studyAntonio Fontes
 
Module 4 (enumeration)
Module 4 (enumeration)Module 4 (enumeration)
Module 4 (enumeration)Wail Hassan
 
Droidcon mobile security
Droidcon   mobile securityDroidcon   mobile security
Droidcon mobile securityJudy Ngure
 
Addressing the Top 3 Real-world Security Challenges for Your IBM i Systems
Addressing the Top 3 Real-world Security Challenges for Your IBM i SystemsAddressing the Top 3 Real-world Security Challenges for Your IBM i Systems
Addressing the Top 3 Real-world Security Challenges for Your IBM i SystemsPrecisely
 
A successful application security program - Envision build and scale
A successful application security program - Envision build and scaleA successful application security program - Envision build and scale
A successful application security program - Envision build and scalePriyanka Aash
 
The Changing Security Landscape
The Changing Security LandscapeThe Changing Security Landscape
The Changing Security LandscapeArrow ECS UK
 
Security engineering 101 when good design & security work together
Security engineering 101  when good design & security work togetherSecurity engineering 101  when good design & security work together
Security engineering 101 when good design & security work togetherWendy Knox Everette
 
Proactive cyber defence through adversary emulation for improving your securi...
Proactive cyber defence through adversary emulation for improving your securi...Proactive cyber defence through adversary emulation for improving your securi...
Proactive cyber defence through adversary emulation for improving your securi...idsecconf
 
What i learned at issa international summit 2019
What i learned at issa international summit 2019What i learned at issa international summit 2019
What i learned at issa international summit 2019Ulf Mattsson
 
A Study on Recent Trends and Developments in Intrusion Detection System
A Study on Recent Trends and Developments in Intrusion Detection SystemA Study on Recent Trends and Developments in Intrusion Detection System
A Study on Recent Trends and Developments in Intrusion Detection SystemIOSR Journals
 
Malware on Smartphones and Tablets: The Inconvenient Truth
Malware on Smartphones and Tablets: The Inconvenient TruthMalware on Smartphones and Tablets: The Inconvenient Truth
Malware on Smartphones and Tablets: The Inconvenient TruthIBM Security
 
Teknisen tietoturvan minimivaatimukset
Teknisen tietoturvan minimivaatimuksetTeknisen tietoturvan minimivaatimukset
Teknisen tietoturvan minimivaatimuksetTeemu Tiainen
 
61370436 main-case-study
61370436 main-case-study61370436 main-case-study
61370436 main-case-studyhomeworkping4
 
QRadar & XGS: Stopping Attacks with a Click of the Mouse
QRadar & XGS: Stopping Attacks with a Click of the MouseQRadar & XGS: Stopping Attacks with a Click of the Mouse
QRadar & XGS: Stopping Attacks with a Click of the MouseIBM Security
 
Risk Analysis Of Banking Malware Attacks
Risk Analysis Of Banking Malware AttacksRisk Analysis Of Banking Malware Attacks
Risk Analysis Of Banking Malware AttacksMarco Morana
 
What is Penetration Testing?
What is Penetration Testing?What is Penetration Testing?
What is Penetration Testing?Rapid7
 
Lecture #12,#13 : Program and OS Security -Part I
Lecture #12,#13 : Program and OS Security -Part ILecture #12,#13 : Program and OS Security -Part I
Lecture #12,#13 : Program and OS Security -Part IDr. Ramchandra Mangrulkar
 

What's hot (20)

Isaca conference threat_modeling_marco_morana_short.pdf
Isaca conference threat_modeling_marco_morana_short.pdfIsaca conference threat_modeling_marco_morana_short.pdf
Isaca conference threat_modeling_marco_morana_short.pdf
 
Comodo advanced endpoint protection
Comodo advanced endpoint protectionComodo advanced endpoint protection
Comodo advanced endpoint protection
 
Threat modeling web application: a case study
Threat modeling web application: a case studyThreat modeling web application: a case study
Threat modeling web application: a case study
 
Module 4 (enumeration)
Module 4 (enumeration)Module 4 (enumeration)
Module 4 (enumeration)
 
Droidcon mobile security
Droidcon   mobile securityDroidcon   mobile security
Droidcon mobile security
 
Addressing the Top 3 Real-world Security Challenges for Your IBM i Systems
Addressing the Top 3 Real-world Security Challenges for Your IBM i SystemsAddressing the Top 3 Real-world Security Challenges for Your IBM i Systems
Addressing the Top 3 Real-world Security Challenges for Your IBM i Systems
 
A successful application security program - Envision build and scale
A successful application security program - Envision build and scaleA successful application security program - Envision build and scale
A successful application security program - Envision build and scale
 
The Changing Security Landscape
The Changing Security LandscapeThe Changing Security Landscape
The Changing Security Landscape
 
Anajli_Synopsis
Anajli_SynopsisAnajli_Synopsis
Anajli_Synopsis
 
Security engineering 101 when good design & security work together
Security engineering 101  when good design & security work togetherSecurity engineering 101  when good design & security work together
Security engineering 101 when good design & security work together
 
Proactive cyber defence through adversary emulation for improving your securi...
Proactive cyber defence through adversary emulation for improving your securi...Proactive cyber defence through adversary emulation for improving your securi...
Proactive cyber defence through adversary emulation for improving your securi...
 
What i learned at issa international summit 2019
What i learned at issa international summit 2019What i learned at issa international summit 2019
What i learned at issa international summit 2019
 
A Study on Recent Trends and Developments in Intrusion Detection System
A Study on Recent Trends and Developments in Intrusion Detection SystemA Study on Recent Trends and Developments in Intrusion Detection System
A Study on Recent Trends and Developments in Intrusion Detection System
 
Malware on Smartphones and Tablets: The Inconvenient Truth
Malware on Smartphones and Tablets: The Inconvenient TruthMalware on Smartphones and Tablets: The Inconvenient Truth
Malware on Smartphones and Tablets: The Inconvenient Truth
 
Teknisen tietoturvan minimivaatimukset
Teknisen tietoturvan minimivaatimuksetTeknisen tietoturvan minimivaatimukset
Teknisen tietoturvan minimivaatimukset
 
61370436 main-case-study
61370436 main-case-study61370436 main-case-study
61370436 main-case-study
 
QRadar & XGS: Stopping Attacks with a Click of the Mouse
QRadar & XGS: Stopping Attacks with a Click of the MouseQRadar & XGS: Stopping Attacks with a Click of the Mouse
QRadar & XGS: Stopping Attacks with a Click of the Mouse
 
Risk Analysis Of Banking Malware Attacks
Risk Analysis Of Banking Malware AttacksRisk Analysis Of Banking Malware Attacks
Risk Analysis Of Banking Malware Attacks
 
What is Penetration Testing?
What is Penetration Testing?What is Penetration Testing?
What is Penetration Testing?
 
Lecture #12,#13 : Program and OS Security -Part I
Lecture #12,#13 : Program and OS Security -Part ILecture #12,#13 : Program and OS Security -Part I
Lecture #12,#13 : Program and OS Security -Part I
 

Similar to linkedin brainies

Software potential code protector
Software potential code protector Software potential code protector
Software potential code protector InishTech
 
10 Best DevSecOps Tools for 2023
10 Best DevSecOps Tools for 202310 Best DevSecOps Tools for 2023
10 Best DevSecOps Tools for 2023SofiaCarter4
 
Asset Discovery in India – Redhunt Labs
Asset Discovery in India – Redhunt LabsAsset Discovery in India – Redhunt Labs
Asset Discovery in India – Redhunt LabsRedhuntLabs2
 
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...Jose Lopez
 
A Survey of Keylogger in Cybersecurity Education
A Survey of Keylogger in Cybersecurity EducationA Survey of Keylogger in Cybersecurity Education
A Survey of Keylogger in Cybersecurity Educationijtsrd
 
Application security (APP) and CRM or ERP extension solutions
Application security (APP) and CRM or ERP extension solutionsApplication security (APP) and CRM or ERP extension solutions
Application security (APP) and CRM or ERP extension solutionscharly simon
 
Tips To Protect Your Mobile App from Hackers.pdf
Tips To Protect Your Mobile App from Hackers.pdfTips To Protect Your Mobile App from Hackers.pdf
Tips To Protect Your Mobile App from Hackers.pdfFuGenx Technologies
 
Cybersecurity Basics for Non-Techie Startup Founders
Cybersecurity Basics for Non-Techie Startup FoundersCybersecurity Basics for Non-Techie Startup Founders
Cybersecurity Basics for Non-Techie Startup FoundersKristian Melquiades
 
HackInBo2k16 - Threat Intelligence and Malware Analysis
HackInBo2k16 - Threat Intelligence and Malware AnalysisHackInBo2k16 - Threat Intelligence and Malware Analysis
HackInBo2k16 - Threat Intelligence and Malware AnalysisAntonio Parata
 
Ransomeware : A High Profile Attack
Ransomeware : A High Profile AttackRansomeware : A High Profile Attack
Ransomeware : A High Profile AttackIRJET Journal
 
IRJET- Obfuscation: Maze of Code
IRJET- Obfuscation: Maze of CodeIRJET- Obfuscation: Maze of Code
IRJET- Obfuscation: Maze of CodeIRJET Journal
 
Next Generation Endpoint Prtection Buyers Guide
Next Generation Endpoint Prtection Buyers GuideNext Generation Endpoint Prtection Buyers Guide
Next Generation Endpoint Prtection Buyers GuideJeremiah Grossman
 
ransomware keylogger rootkit.pptx
ransomware keylogger rootkit.pptxransomware keylogger rootkit.pptx
ransomware keylogger rootkit.pptxdawitTerefe5
 
Webinar Security: Apps of Steel transcription
Webinar Security:  Apps of Steel transcriptionWebinar Security:  Apps of Steel transcription
Webinar Security: Apps of Steel transcriptionService2Media
 
How to Build Secure Mobile Apps.pdf
How to Build Secure Mobile Apps.pdfHow to Build Secure Mobile Apps.pdf
How to Build Secure Mobile Apps.pdfvenkatprasadvadla1
 
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...Mobodexter
 
Computer Software Attacks
Computer Software AttacksComputer Software Attacks
Computer Software AttacksSusan Cox
 

Similar to linkedin brainies (20)

Software potential code protector
Software potential code protector Software potential code protector
Software potential code protector
 
SentinelOne Buyers Guide
SentinelOne Buyers GuideSentinelOne Buyers Guide
SentinelOne Buyers Guide
 
10 Best DevSecOps Tools for 2023
10 Best DevSecOps Tools for 202310 Best DevSecOps Tools for 2023
10 Best DevSecOps Tools for 2023
 
Asset Discovery in India – Redhunt Labs
Asset Discovery in India – Redhunt LabsAsset Discovery in India – Redhunt Labs
Asset Discovery in India – Redhunt Labs
 
Security overview 2
Security overview 2Security overview 2
Security overview 2
 
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...
Is Using Off-the-shelf Antimalware Product to Secure Your Medical Device a Go...
 
A Survey of Keylogger in Cybersecurity Education
A Survey of Keylogger in Cybersecurity EducationA Survey of Keylogger in Cybersecurity Education
A Survey of Keylogger in Cybersecurity Education
 
Application security (APP) and CRM or ERP extension solutions
Application security (APP) and CRM or ERP extension solutionsApplication security (APP) and CRM or ERP extension solutions
Application security (APP) and CRM or ERP extension solutions
 
Tips To Protect Your Mobile App from Hackers.pdf
Tips To Protect Your Mobile App from Hackers.pdfTips To Protect Your Mobile App from Hackers.pdf
Tips To Protect Your Mobile App from Hackers.pdf
 
Cybersecurity Basics for Non-Techie Startup Founders
Cybersecurity Basics for Non-Techie Startup FoundersCybersecurity Basics for Non-Techie Startup Founders
Cybersecurity Basics for Non-Techie Startup Founders
 
HackInBo2k16 - Threat Intelligence and Malware Analysis
HackInBo2k16 - Threat Intelligence and Malware AnalysisHackInBo2k16 - Threat Intelligence and Malware Analysis
HackInBo2k16 - Threat Intelligence and Malware Analysis
 
Ransomeware : A High Profile Attack
Ransomeware : A High Profile AttackRansomeware : A High Profile Attack
Ransomeware : A High Profile Attack
 
IRJET- Obfuscation: Maze of Code
IRJET- Obfuscation: Maze of CodeIRJET- Obfuscation: Maze of Code
IRJET- Obfuscation: Maze of Code
 
Next Generation Endpoint Prtection Buyers Guide
Next Generation Endpoint Prtection Buyers GuideNext Generation Endpoint Prtection Buyers Guide
Next Generation Endpoint Prtection Buyers Guide
 
ransomware keylogger rootkit.pptx
ransomware keylogger rootkit.pptxransomware keylogger rootkit.pptx
ransomware keylogger rootkit.pptx
 
Webinar Security: Apps of Steel transcription
Webinar Security:  Apps of Steel transcriptionWebinar Security:  Apps of Steel transcription
Webinar Security: Apps of Steel transcription
 
How to Build Secure Mobile Apps.pdf
How to Build Secure Mobile Apps.pdfHow to Build Secure Mobile Apps.pdf
How to Build Secure Mobile Apps.pdf
 
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...
Top 10 Software to Detect & Prevent Security Vulnerabilities from BlackHat US...
 
Robust Software Solutions.pptx
Robust Software Solutions.pptxRobust Software Solutions.pptx
Robust Software Solutions.pptx
 
Computer Software Attacks
Computer Software AttacksComputer Software Attacks
Computer Software Attacks
 

linkedin brainies

  • 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.