Obfuscation of Abstract Data-Types - Rowan
Obfuscation of Abstract Data-Types - Rowan
Obfuscation of Abstract Data-Types - Rowan
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
CHAPTER 8. CONCLUSIONS AND FURTHER WORK 138<br />
8.2.1 Deobfuscation<br />
We have not mentioned how easy it is to undo our obfuscations. Since we have<br />
considered obfuscation to be a functional refinement, we have an abstraction<br />
function which maps the obfuscated data-type back to the original data-type.<br />
So, the abstraction function acts as a “deobfuscation” and therefore it is important<br />
to keep this function secret from an attacker. In particular, where possible,<br />
traces <strong>of</strong> the abstraction function from the definition <strong>of</strong> our obfuscations should<br />
be removed. This is a particular problem with operations that convert an obfuscated<br />
data-type to another data-type. For instance, the definition <strong>of</strong> flatten 3<br />
in Section 7.2.3 gives away some knowledge <strong>of</strong> the abstraction function (to2).<br />
To prevent this, further obfuscations (such as using split lists) should be added.<br />
The resilience <strong>of</strong> our obfuscation to reverse engineering should be explored.<br />
One simple technique for reverse engineering is to execute the program and then<br />
study the program traces. If random obfuscations (see Section 8.1.4) are used<br />
then different program traces can be created. Another technique is refactoring<br />
[27] which is the process <strong>of</strong> improving the design <strong>of</strong> existing code by performing<br />
behaviour-preserving transformations. One particular area to explore is<br />
the refactoring <strong>of</strong> functional programs — [35] gives a discussion <strong>of</strong> a tool for<br />
refactoring Haskell called HaRe. What happens to our obfuscations if they are<br />
refactored? Could HaRe be used to specify obfuscations?<br />
8.2.2 Other techniques<br />
In Chapter 2, we have discussed a language with which we can specify obfuscations<br />
for IL and so can generate obfuscations automatically. Is it possible to<br />
develop such a system for our obfuscations? One possible approach could be<br />
to write operations and abstraction functions as folds or unfolds. As stated in<br />
Section 3.5, an abstraction function can usually be written as an unfold and<br />
a conversion function as a fold. If folds are used then derivations and pro<strong>of</strong>s<br />
can be calculated using fusion and so an automated system, such as the one<br />
described in [15], could be used. A concern <strong>of</strong> some <strong>of</strong> the matrix operations in<br />
[19] that were derived using fusion was that traces <strong>of</strong> the splitting functions can<br />
be seen in the definition.<br />
Functional programming and data refinement have been used to specify obfuscations<br />
for abstract data-types. In our objectives (on Page 7), we have stated<br />
that we wanted to use simple, established techniques and to be able to generalise<br />
obfuscations. While it is certainly true that our approach has used simple<br />
techniques, is it general enough? For more generality categories could be obfuscated<br />
and concepts such as hylomorphisms [38] could be used. Barak et al. [6]<br />
provide a formal cryptographic treatment <strong>of</strong> obfuscation by obfuscating Turing<br />
machines. How does our approach and, in particular, our definition compare<br />
with their approach? In Section 3.2, we restricted ourselves to functional refinements.<br />
More general notions <strong>of</strong> refinement [16] could be studied instead and<br />
in doing so partial and non-deterministic operations can be considered. What<br />
would be gained by using these more general methods? To what extent will<br />
these methods support obfuscation <strong>of</strong> imperative programs?