Avira Scout and Exploit Mitigation Technologies

Exploit Mitigation Technologies and Avira Scout

There are two very interesting technologies for exploit mitigation: Address space layout randomization (ASLR) and data execution prevention (DEP). I’ll explain what they do a bit further down. Anyway, they were researched by computer scientists, integrated into the current compilers by the compiler teams, and activated in the build process by the Chromium team. To have this kind of security in our Chromium based Avira Scout, we have to do one simple thing: Just don’t touch it!

When ASLR and DEP are enabled during the build process, they change flags in the portable executable (PE) header of the compiled files. Writing a script that verifies success just before a new version of Scout gets released should not be too complicated. So we sent our padawan Lars on the quest to create a script that is executed after the build and right before release. It makes sure that everything went ok with the ASLR/DEP settings in the compile step.

Like a true padawan he didn’t rest until he succeeded. That means that it is not possible anymore to release an Avira  Scout version where ASLR/DEP is not at least on the same level as in Chrome. You will benefit from the guaranteed ASLR/DEP with the Scout based on Chromium 49.

ASLR and DEP – what are they good for?

Let me try to simplify it as much as possible: When a vulnerability in a software (say, Avira Scout) is abused by hackers, they inject specific binary program code into the heap. Manipulating a function pointer / return address will then redirect execution to said code.

The attacker’s goal is to control the program flow, call existing functions, and glue them together in a way that for example triggers “Download from URL http://foo.bar” then “Execute downloaded file”.

Exploit mitigation is making it more complicated for the hacker to complete his desired task, alas not impossible. (As soon as they find new tricks they are back in the game – but the game just got more complicated and the exploits are going to work less reliable).

ASLR (address space layout randomization):

When parts of an executable (for example an .exe or dll file) are loaded into memory they are not loaded to the same address every single time, but to random addresses. That makes finding the functions the attacker wants to glue together much more complicated, because the attacker does not know where in the memory to look for them.

DEP (data execution prevention):

Parts of the memory are either marked as data (can be changed while the program is running, but not executed. This is “heap” memory) or code (can be executed). You get the idea. DEP simply prevents the execution flow from being re-directed to the heap.


As already explained above: By combining those two methods most of the exploits can be killed that way (but not all) so that’s something you definitely want to have.


If you should happen to develop software, please check your compiler for the switches to activate ASLR and DEP!


Never break existing security features. Ever.

This post is also available in: GermanFrenchItalian

I use science to protect people. My name is Thorsten Sick and I do research projects at Avira. My last project was the ITES project where I experimented with Sandboxes, Sensors and Virtual Machines. Currently I am one of the developers of the new Avira Browser