‘tamper-proof’, also called tamper-resistant.As this paper investigates protection mecha-nisms against malicious analysis and tamper-ing, we will not elaborate on software water-marking.
3.1 Code obfuscation
As software gets distributed worldwide, it be-comes harder and harder to control it from adistance. This means that attackers often cananalyse, copy, and change it at will. Compa-nies however have been inventing techniquesto make this analysis harder. The techniquesrange from small tricks to counter debugging,such as code stripping, to complex control flowand data flow transformations that try to hidea program’s internals. This hiding tries to ad-dress the security objective of
confidentiality
.For example, when Java bytecode was shownto be susceptible to decompilation – yield-ing the original source code – researchers be-gan investigating techniques to protect againstthis [7, 8, 15]. Protection of low-level codeagainst reverse engineering has been addressedas well [25, 19].
3.2 Self-modifying code
While code obfuscation aims to protect codeagainst both static and dynamic analysis, thereexists another technique to protect againstcode analysis, namely self-modifying code.This technique offers the possibility to gener-ate code at runtime, instead of transforming itstatically. In practice however, self-modifyingcode is largely limited to the realm of virusesand malware. Nevertheless, some publicationsconsider self-modifying code as a technique toprotect against static and dynamic analysis.Madou
et al.
[16] for example consider dynamiccode generation. They propose a techniquewhere functions are constructed prior to theirfirst call at runtime. Furthermore, clusteringis proposed such that a common template canbe used to construct each function in a clus-ter, performing a minimal amount of changes.To protect the constant ‘edits’ against dynamicanalysis, the authors propose use of a pseudorandom number generator (PRNG).Our decryption at runtime technique isequivalent with code generation, except thefact that the decryption key can rely on othercode, rather then on a PRNG. Furthermoreminimises re-encryption the visability of codeduring execution, while Madou
et al.
do notexplicitly protect a function template after thefunction executed.
3.3 Tamper resistance
Protecting code against tampering can be con-sidered as the problem of
data authenticity
,where in this context ‘data’ refers to the pro-gram code. In ’96 Aucsmith [1] illustratedin his paper a scheme to implement tamper-resistant software. His technique protectsagainst analysis and tampering. For this,he uses small, armoured code segments, alsocalled integrity verification kernels (IVKs), toverify code integrity. These IVKs are protectedthrough encryption and digital signatures suchthat it is hard to modify them. Furthermore,these IVKs can communicate with each otherand across applications through an integrityverification protocol. Many papers in the fieldof tamper resistance base their techniques onone or more of Aucsmith’s ideas.Several years later, Chang
et al.
[2] proposeda scheme based on
software guards
. Their pro-tection scheme relies on a complex networkof software guards which mutually verify eachother’s integrity and that of the program’s crit-ical sections. A software guard is defined as asmall piece of code performing a specific tasks,e.g. checksumming or repairing. When check-summing code detects a modification, repaircode is able to undo this malicious tamper3
Leave a Comment