Cigital

“Software protection” is “Intelectual Property protection”. It doesn’t make the software itself more secure. And it definitely doesn’t make it possible to properly secure the computing environment where it’s running. It makes software a black box, which is never a good thing for the software users. I usually use the airplane analogy. When you get on a plane to fly somewhere you have to go through a checkpoint where you are screened. Once it’s verified that you’re safe you are allowed to get on board. Now imagine you’d refuse to be screened. You wouldn’t be allowed on the plane… plain and simple. That’s because it would compromise the security of the airplane by allowing a complete unknown element in a secure enviornment. The same is pretty much true with computers. Allowing a black box piece of code to run on your computer (and often worse, when it comes to various software protection implementations, to take over your computer) is a suicide in terms of security. And that’s what software protection does.

hi kyle,

Parts of “software protection” are indeed about IP protection, but not all aspects. As an example, consider the idea of diversity as a security mechanism. I was at a DoD meeting this week with Fred Schneider from Cornell and he claimed that some aspects of diversity (carried out using some of the techniques that Christian talks about in his book) have a demonstrable relationship with type safety.

Put in simple terms, if you’re stuck with crappy languages like C++, then obfuscation may help you with security as much as type safety helps with modern languages like Java. Why would that be? Because attackers can’t script up one attack that works against all instances of a given codebase.

If you want to take a deep dive into this, here is a pointer to Fred’s paper on the idea: http://www.cs.cornell.edu/fbs/publications/punningJrnl.pdf

Regardless of that work, I think if you take a look at the book, you’ll see why the ideas in it go WAY past IP protection.

Thanks for your comment.

gem

Diversity as a security mechanism is indeed a good concept. When application environments are different in each deployment it’s hard to have a reliable exploit. However, this is not the goal of the “software protection” systems. The IP protection is though. Some implementations might use techniques that would introduce this diversity, but I’d claim that these are two different things that sometimes intersect in their low level implementation. The biggest problem with the “software protection” systems is their black box nature that prevents the host environment from properly verifying the safety of the application in question. It is possible to have systems that introduce the divirsity without complete isolation from the host environment. I can use a gun as a hammer, but it doesn’t mean the gun was designed for it

hi kyle,

I think you’re focusing a bit too much attention on the IP protection stuff (which you are right about…). I agree that maintenance and bug fixing is a mess in systems using obfuscation. Imagine the headaches that automatic update would have if commercial systems used more obfuscation! Nevertheless, I think it behooves us to pay attention to this technology and these ideas because we will be living in a world chock full of them soon.

gem

I completely agree that we’ll see more what I’d call “application customization” in the future and we need to be prepared for it. The process has already begun with basic things like ASLR. More “application customization” techniques will be utilized that will customize application environments in many different ways. What I don’t agree about is the role of the “software protection” systems in this process. They were not designed for it. They might have some intersecting features, but these features are simply implementation byproducts of their main goal, which is to protect IP by turning software into a black box. Instead of trying to use the “software protection” systems as “application security” systems I’d focus on “application security” systems that are designed specifically for this purpose. They’d have the “application customization” features necessary to provide the diversity we talked about without the negative features of the “software protection” systems that they used to accomplish their task. For example, for a pure “application customization” software there’s no need for VM detection, debugger detection, SSDT hooks, and file system filter drivers that take over the entire system. Application security, host intrusion prevention systems, and even “software protection” systems are actually some of my specialties, so I’ve been on both sides of the fence. Dealing with black box pieces of code is quite a pain when you need to verify that this “magic” code is safe. And when I designed my last “software protection” system its goals didn’t include software exploitation prevention All I’m saying is that it’s best to leave “software protection” as it to do its job and to have specialized “application customization” products that focus on the application security using various “diversity” mechanisms.

hi kyle,

Yep. I think you’ll find many of the approaches you describe in the book (which is called “Surreptitious Software” and not “Software Protection”.)

Incidentally, as you might imagine I am much more interested in software security than in software protection (or protecting software). Funny how big a difference a word makes. That’s why I had a hard time determining whether to include the book in the series. Too late now!

gem

I’m more interested in software security as well, which is why the book I’m writing is focused on dealing with applications running on people’s computers including the applications that use “software protection”. In a way it’s the opposite of the “Surreptitious Software” book, which is why this topic got my interest

Hi kyle,

Let me know if you would like your book to be considered for the AWL Software Security series as well.

gem

It would have been great to be in the same group as Greg Hogland, who wrote the number one rootkit book, but I ended up going with a different publisher for a number of reasons… including the fact that they are local, which greatly simplifies the process.

I actually own 5 books from this series (including the “Surreptitious Software” book, of course )))

I totally agree with Kyle. I wrote an article for SecurityFocus on obfuscation. The fact that the good guys and the bad guys use it should tell us something.

http://www.securityfocus.com/columnists/498

Excerpt:

“Obfuscation by itself is not good or bad but it has led to the situation where users can’t determine if the behavior of obfuscated software is good or bad. While it would be a controversial measure, perhaps it’s time to treat any code that exhibits unknown behavior as bad.

If obfuscation technology was ever perfected we would have perfect DRM and perfect malware. Yet, that outcome is unlikely. The computer ultimately has to decipher and follow a software program’s true instructions. Each new obfuscation technique has to abide by this requirement and, thus, will be able to be reverse engineered.”

Just a note… The author, Christian Collberg, is a university professor, so his approach is very academic (and he actually had a class on this subject). The book is filled with lots of theory and fancy math formulas )) It’s really good in what it’s trying to do, but if you expect a hands-on manual then the book is not for you. It’s more about “design” then implementation”