Obfuscation of Abstract Data-Types - Rowan
Obfuscation of Abstract Data-Types - Rowan
Obfuscation of Abstract Data-Types - Rowan
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
CHAPTER 3. TECHNIQUES FOR OBFUSCATION 47<br />
Array (α)<br />
Array α :: [0..N ) → α ∪ {Null}<br />
access :: Array α × [0..N ) → α ∪ {Null}<br />
update :: [0..N ) × (α ∪ {Null}) × Array α → Array α<br />
new :: Array α<br />
access(update(i,x,A),i) = x<br />
i ≠ j ⇒ access(update(i,x,A),j) = access(A,j)<br />
(∀ i :: [0..N )) • access(new,i) = Null<br />
∣<br />
Figure 3.1: <strong>Data</strong>-type for Arrays<br />
14]). As Haskell is a purely functional language there are no side-effects, which<br />
can complicate pro<strong>of</strong>s. Since we using Haskell as a modelling language we should<br />
ensure that we can convert our operations in other languages. Thus we will not<br />
exploit all the characteristics <strong>of</strong> Haskell and in particular, we will use finite,<br />
well-defined data-types and we will not use laziness. We could have chosen a<br />
strict language such as ML but the syntax <strong>of</strong> ML and the presence <strong>of</strong> reference<br />
cells means that it is not as elegant a setting for pro<strong>of</strong>s as Haskell.<br />
Often, obfuscation is seen as applicable only to object-oriented languages (or<br />
the underlying bytecode) but the use <strong>of</strong> a more mathematical approach (by using<br />
standard refinement and derivation techniques) allows us to apply obfuscations<br />
to more general areas. Since we use Haskell for our (apparently new) approach<br />
we have the benefits <strong>of</strong> the elegance <strong>of</strong> the functional style and the consequent<br />
abstraction <strong>of</strong> side-effects. Thus our functional approach will provide support<br />
for purely imperative obfuscations.<br />
When defining data-types, we usually give operations which act on the local<br />
state <strong>of</strong> the data-type and so they have type D → D. We will insist that<br />
all operations are deterministic and are functions rather than relations (which<br />
mirrors the use <strong>of</strong> functional programming as our modelling language). This<br />
means that we can take a more mathematical view and define functions for<br />
abstract data-types. Also we will use functional composition (·) rather than<br />
sequential composition (;).<br />
Can we match this mathematical view up with the traditional data-type<br />
view? Consider the length function for lists which takes a list as input and<br />
returns a natural number as the output. Imperatively, using linked lists we