Posted by: Eric Hansen
when relevant content is
added and updated.
I read an interesting article talking about how a piece of malware placed a very interesting blockade in being figured out by hooking into Windows’ debugging functionality itself. The article itself can be found here: http://blog.malwarebytes.org/intelligence/2013/07/zeroaccess-anti-debug-uses-debugger/ but this raises an interesting point in malware analysis.
According to the article, debuggers are used heavily to analyze what is going on behind the scenes, which makes sense. A debugger is a tool that allows you to browse memory and most will decompile programs into bytecode or convert the program into assembly best it can. This allows analysts to be able to see what’s going on and also browse various aspects of binaries such as text strings.
This program however prevents a lot of this functionality from happening by debugging itself on start up so nothing else can. This is a fault in the Windows API itself as it only allows 1 program access to debug another at a time.
So, why am I talking about Windows on a Linux-centric blog? Because this is also about security. After what feels like years of the same old methods just being renamed, something new…something interesting…happens. Now, this technique isn’t exactly new in the realm of programs, because a lot of programs in the 90′s, when cracking and pirating was all over the news, put in place measures to prevent people from debugging their code like this. I dabbed into this side of security when I was younger so I have a fair understanding of what went on.
I don’t see this being a major turning point in malware, but it definitely makes the field that much more interesting.