Enough said you can check it here:
Method for bypassing EMET EAF (Export Address Table Access Filtering)

While doing some of my research I was often wondering how big the typical basic block is - how many instructions it typically includes. Since I was unable to find any reputable results in this area I have decided to make my own observations...

Following table presents statistics about number of instructions in typical basic block (including the average number of instructions per basic block and the maximum number of instructions found in a single basic block). This simple research was driven mostly by curiosity and some additional questions I have encountered while building my own software. All of the analysed files (over 1500) come from Microsoft and are a part of Microsoft Windows XP operating system.

After hearing some good reviews about Pin DBI framework I have decided to give it a chance. I have downloaded the version for MSVC9 and tried to compile a sample project with MSVC9. That was the point where my problems started. Actually there is very minimal amount of information at the Pin website regarding using it with Microsoft Visual Studio (and the sample project file is pretty useless). Of course I have built the sample tools with "nmake" command successfully but I wanted to do the same straight from my MSVC. So I have spent line an hour (or two) fighting with massive numbers of compiler, linker (unresolved externals) errors until the build was done correctly. Surprisingly after running Pin with my PinTool it returned another error: "Pin 2.9 kit 39586E: Failed to load tool DLL. System error: Unknown error.". Well at this point I'm still not really sure what was wrong but after doing a lot of trial and error tests I have managed to create a MSVC configuration that actually works (at least for me). So here it is maybe someone will find it helpful. (Please note it may contain some redundant switches but it should be good enough for a start point.) For release configuration simply remove the "\DEBUG" switches.


So here are the steps:
"E:\pin" is the pin base directory.

Include directories:
E:\pin\extras\components\include\
E:\pin\extras\xed2-ia32\include
E:\pin\source\include\gen
E:\pin\source\include


Library directories:
E:\pin\ia32\lib-ext
E:\pin\extras\xed2-ia32\lib
E:\pin\ia32\lib


Preprocessor Definitions:
TARGET_IA32;HOST_IA32;TARGET_WINDOWS;USING_XED


Compiler options:
/MT /EHs- /EHa- /wd4530 /DTARGET_WINDOWS /DBIGARRAY_MULTIPLIER=1
/DUSING_XED /D_CRT_SECURE_NO_DEPRECATE /D_SECURE_SCL=0 /nologo /DTARGET_IA32 /DHOST_IA32


Linker options:
/DLL /EXPORT:main /NODEFAULTLIB /NOLOGO /ENTRY:Ptrace_DllMainCRTStartup@12 ntdll-32.lib libxed.lib pin.lib pinvm.lib libcmt.lib libcpmt.lib /DEBUG



Who knows maybe this will work for you :)

Today I had a chance to fast-read two interesting papers. I want to mention them here on this blog post for two reasons. First of all to not forget about them (so as a personal memo :-)) and secondly because maybe someone will find them interesting as well.

The first one called "Control-Flow Integrity Principles, Implementations, and Applications" describes the CFI (Control-Flow Integrity) mitigation technique. Security policy used in CFI dictates that software execution must follow a path of a Control-Flow Graph (CFG) which is determined ahead of time. They provide the CFG information in this case by using static analysis. The rest of the process is pretty standard (static binary rewriting + code instrumentation). In the static binary rewriting part they are using a tool called VULCAN (also from Microsoft), which apparently is much more advanced that my own engine and in my humble opinion looks pretty awesome. As for the code instrumentation part it seems they are using emitted magic values (aka IDs) and runtime ID checks. So for example before the jump indirect gets executed the first four bytes of the destination-4 address are checked for the emitted value. If the magic value is not found the "error handling" procedure will be executed. Otherwise the control is transfered to the destination address. Similar technique was also described by the PaX guys as a mitigation against ret2libc attacks. I found this one really interesting since lately I was working on something similar. Anyway I'm not sure how this magic bytes emission (IDs) is synchronized among other modules since for me this seems like a pretty troublesome part. Maybe someone can give some hints here? :-)

Second paper called "Efficient Validation of Control Flow Integrity for Enhancing Computer System Security" utilizes some hardware features. Among other features they are using Last Branch Recording (LBR). So according to the paper they are monitoring every mis-predicted indirect branch instruction and every return instruction (because return instruction may not generate return address mis-prediction). Each time an indirect branch mis-prediction event happens their filtering interrupt-handler is executed. When security policy is violated (Table 3.1) the process gets terminated. For example the call indirect policy states: allow only if the destination address is a function entry point. And here it gets problematic since to obtain function entry points (or to be exact the Indirect Branch Pairs) they need to either use static analysis of the control flow graph of the program or perform the program profiling (something like running a learning process on a clean machine). I think this may cause some false-positives cases since in both of those solutions there is no guarantee that all paths will be traversed. Finally the most problematic things appears to be a fact that you can't use any of those hardware features in virtualized environments like VMmare etc. Obviously it heavily depends on hardware plus the performance is questionable.
I must confess I was also wondering about using this hardware feature in my engine (just limiting it to ring0) however it seems that disadvantages of this method are too significant.

Ok that would be all for today! Cheers!