Software tamper resistance obstructing static analysis of programs
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

Software Tamper Resistance: Obstructing Static Analysis of Programs PowerPoint PPT Presentation


  • 58 Views
  • Uploaded on
  • Presentation posted in: General

Software Tamper Resistance: Obstructing Static Analysis of Programs. Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson at university of Virginia This presentation consists of 4 parts: Introduction Techniques employed to hinder static analysis

Download Presentation

Software Tamper Resistance: Obstructing Static Analysis of Programs

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software tamper resistance obstructing static analysis of programs

Software Tamper Resistance: Obstructing Static Analysis of Programs

  • Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson at university of Virginia

  • This presentation consists of 4 parts:

    • Introduction

    • Techniques employed to hinder static analysis

    • Theoretical foundation and experimental results

    • Conclusion


Introduction

Introduction

  • Problem addressed: protecting trusted software against tampering on untrustworthy hosts.

  • The solution: tamper resistant software. Why is access control infeasible?

  • One aspect of software tamper resistance: prevention of static analysis of programs.


Static analysis of programs

Static Analysis of Programs

  • “Static analysis refers to techniques designed to extract [semantic] information from a static image of a computer program.”

  • Entails two steps: control-flow analysis and data-flow analysis.

  • Can be defeated by making the program control-flow data-dependent.


Control flow transformations

Control-flow Transformations

  • Modify high-level control transfers to obstruct static detection of branch targets and call destinations.

  • Two steps of transformation are illustrated in the following figures.


Dismantling of high level constructs

int a,b;a=1;b=2;while(a<10){b=a+b;if(b>10)b--;a++;}use(b);

L1: if(!(a<10)) goto L4

Dismantling of High-level Constructs

a=1 b=2

b=a+b

if(!(b>10)) goto L2

b--

L2: a++

goto L1

L4: use (b)


Transform to indirect control transfers

Transform to indirect control transfers

swVar=1

switch(swVar)

L1: a=1;

b=2;

swVar=2;

L2: if(!(a<10))

swVar=6;

else

swVar=3;

L3: b=b+a;

if(!(b>10))

swVar=5;

else swVar=4;

L4: b--;

swVar=5;

L5: a++;

swVar=2;

L6:

use(b);

goto switch


Data flow transformations

Data-flow Transformations

  • Dynamic computation of branch targets.

  • The introduction of non-trivial aliases into the program.


Dynamic computation of the switch variable

dynamic computation of the switch variable

int global_array[];

switch(swVar)

switch(swVar)

L3: b=b+a;

if(!(b>10))

swVar=5;

else

swVar=4;

L3: b=b+a;

if(!(b>10))

swVar=global_array[f1()];

else

swVar=global_array[f2()];

goto switch;

goto switch


Introducing aliases through pointers

Introducing aliases through pointers

*p = a;

a = a +b;

*p = b

b = 3;

L1: *p = a;

a = a+b;

swVar = f1();

L2: *p = b;

b = 3;

swVar = f2();

A

<*p,b>

A

<*p,a><*p,b>


Complexity evaluation

Complexity Evaluation

  • Theorem 1: in the presence of general pointers, the problem of determining precise indirect branch target addresses is NP-hard.

  • Proof: constructing a polynomial time reduction from 3SAT problem to it.

  • Cannot be solved in polynomial time under the assumption that P!=NP.


Experimental results

Experimental Results

  • Transformations considerably hindered the optimization that the compiler(gcc) is able to perform.

  • Defeated PAF which is a static analysis tool from Rutgers university.

  • Replacing 50% of the branches will result in an increase of a factor of 4 in the execution time and a factor of 2 in program size.

    Does the runtime cost justify the protection we gain?


Conclusion

Conclusion

  • We have shown that static analysis can be defeated by making the control-flow analysis dependent on the data in the program.

  • Future work includes establishing the practical lower bound on the time needed to analyze a transformed program.

  • Thank you!


  • Login