Loading in 5 sec....

Software Tamper Resistance: Obstructing Static Analysis of ProgramsPowerPoint Presentation

Software Tamper Resistance: Obstructing Static Analysis of Programs

Download Presentation

Software Tamper Resistance: Obstructing Static Analysis of Programs

Loading in 2 Seconds...

- 78 Views
- Uploaded on
- Presentation posted in: General

Software Tamper Resistance: Obstructing Static Analysis of Programs

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

- 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

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

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

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

a=1 b=2

b=a+b

if(!(b>10)) goto L2

b--

L2: a++

goto L1

L4: use (b)

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

- Dynamic computation of branch targets.
- The introduction of non-trivial aliases into the program.

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

*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>

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

- 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?

- 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!