Digg this story   Add to del.icio.us   (page 2 of 2 ) previous 
Good Obfuscation, Bad Code
Chris Wysopal, 2009-04-17

Story continued from Page 1

The most common obfuscation technique is self modifying code. This allows the binary executable stored on a hard drive or CD to be different than the executable image running in memory. As the code executes it modifies itself. This is designed to thwart the static analysis of files which is used by most AV products. If the bytes on disk don’t look like bad bytes the software is deemed OK.

For each reverse engineering technique developed, a defensive anti-reverse engineering technique has been created in response. Most code analysts will attempt to use static analysis of the binary or code. The next step is to run the software and inspect it in memory. Run-time analysis with a debugger is often the reverse engineer’s most powerful tool.

Yet, anti-debugging techniques can be used to allow obfuscation to survive dynamic analysis. As the software runs, it tests for the presence of a debugger and changes its behavior or simply exits if a debugger is detected.

Time and future developments are on the side of the reverse engineer, because once a piece of software ships, it's obfuscation techniques are fixed. On the other hand, what the software engineer gets by using anti-reversing techniques is time, and sometimes only a small amount of time is enough.

The good news is — even if we can’t determine if software is going to cause harm — it is relatively easy to detect if it is trying to hide its behavior. We can scan binary code statically and detect self modifying code, root kit behavior, and anti-debugging code. By looking for these indications we have a good idea whether or not the software developer is trying to hide something from us, the user.

In the future, we should expect software to clearly document its behavior and let us verify it before running the software. After all we don’t use undocumented crypto algorithms, because we can’t tell if they are weak or contain a backdoor. In the end, the simplest way to break away from the war of attrition is to keep code open and easy to reverse engineer. Only then can obfuscated code always be treated as bad code.



Chris Wysopal is co-founder and CTO of Veracode, a provider of on-demand software security testing services. Chris co-authored the password auditing tool L0phtCrack and was a researcher at the security think tank, L0pht Heavy Industries. He has held key roles at @stake and Symantec and is the author of The Art of Software Security Testing: Identifying Security Flaws.
    Digg this story   Add to del.icio.us   (page 2 of 2 ) previous 
Comments Mode:
Good Obfuscation, Bad Code 2009-04-18
Chris (2 replies)
Re: Good Obfuscation, Bad Code 2009-04-20
Kyle Quest
Re: Good Obfuscation, Bad Code 2009-05-29
Anthony Lai, Hong Kong
Good Obfuscation, Bad Code 2009-04-22
Anonymous
Good Obfuscation, Bad Code 2009-04-23
TimD (1 replies)
Re: Good Obfuscation, Bad Code 2009-04-26
Chris Wysopal
Good Obfuscation, Bad Code 2009-12-28
G. Bernstein


 

Privacy Statement
Copyright 2010, SecurityFocus