21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 12 CHAPTER 12<br />

Anti-Tampering<br />

Protecting software from reverse engineering is an often-overlooked programming<br />

topic with no easy answers. Despite the lack of absolute solutions, it can still be<br />

interesting to explore techniques that may help prevent others from understanding<br />

and modifying a compiled binary. The reasons for protecting compiled code are varied:<br />

you may need to protect proprietary data or algorithms, or you may want to<br />

ensure that the proper execution of a program is not interfered with or bypassed.<br />

In addition, most hostile code that the security professional works with will have<br />

some form of anti-tampering mechanism in it. In binaries left on a compromised system<br />

one will often see encrypted strings, anti-debugger tricks, self-modifying code,<br />

and other techniques intended to prevent one from understanding what the binary<br />

actually does. Misleading information such as fake debugging symbols, unused command<br />

strings, function names that are never dynamically linked, and irrelevant URLs<br />

will be left in plain sight, while the real data is stored encrypted as seemingly arbitrary<br />

data. You must have some familiarity with obfuscation and protection techniques<br />

to have a chance of dealing with such programs effectively.<br />

Where necessary in this chapter, examples are given in inline Intel x86 assembly language<br />

for the GCC compiler. Every compiler uses a different form of inline assembly<br />

language, and it would be impractical to present the code for each; we have chosen<br />

GCC because it supports so many operating systems. If you are converting from<br />

GCC inline assembler to that of another compiler, be advised that the operand order<br />

is reversed in GCC (the operands are in “src, dest” order rather than in “dest, src<br />

order”), * and effective addresses are expressed in AT&T syntax rather than in Intel<br />

syntax. A detailed list of the differences between Intel and AT&T syntax can be<br />

found in “Using as, The GNU Assembler” (http://www.gnu.org/manual/gas-2.9.1/<br />

html_chapter/as_toc.html).<br />

* Really, this is an artifact of AT&T assembly syntax.<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.<br />

647

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!