Defeating Guloader Anti-Analysis Technique

The Guloader sample in question uses the control flow obfuscation technique to hide its functionalities and evade detection. This technique impedes both static and dynamic analysis. First, looking at how this threat hampers static analysis. In short, it uses CPU instructions that trigger exceptions, resulting in unintelligible code during static analysis. After peeling away the packer layer of Guloader sample, analysts see that its code is obfuscated. Using static analysis tools such as IDA Pro, analysts observe many 0xCC bytes (or int3 instructions) littered throughout the sample. Following the 0xCC bytes are junk instructions. These added bytes disrupt the static analysis tool's disassembly process, resulting in the wrong disassembly listing. 0xCC bytes are CPU instructions that trigger an exception EXCEPTION_BREAKPOINT (0x80000003), which pauses the execution of a process. The CPU will pass the code flow to the handler function before the execution continues. The handler function is responsible for moving the instruction pointer to the correct address. The presence of these same 0xCC bytes make it so that using a debugger during dynamic analysis would crash the Guloader sample. Debuggers insert 0xCC bytes as software breakpoints to halt the execution of the sample. The debugger handles the exception instead of the handler function. Before understanding what happens in the handler function, analysts first have to locate its address. Guloader uses the AddVectoredExceptionHandler function to register the handler function. The second argument of the AddVectoredExceptionHandler function points to the address of the handler function. Using a debugger, analysts locate the address of the handler function registered by the Guloader sample. With the address information, analysts can examine its code. Notably, this ExceptionHandler is registered with the order of 1, meaning it is the first handler to be invoked.