I couldn’t quite finish up my last post on anti-disassembly so here are a few more which will be explored in this post

5. Abusing the return pointer (for fun and profit:P )

If you have played around with x86 asm a bit you should know that there are ways other than jmp or calls to a function by which the control of the program can be subverted. Short story : if you have an address pushed on the top of the stack and call a ret instruction your program flow will goto the address on the stack

For instance the following is a code in IDA->

sub do_Evil: push aScumbagAddresstoGoto mov eax,ebp push ebp <…….random instructions…> pop ebp retn

-*also note aScumbagAddresstoGoto might be calculated(derived from) at execution or saved somewhere within the program.

Assume that we have popped all the things on the stack till the first ebp which was pushed at start of the code.Now executing return will pop the aScumbagAddresstoGoto and take the control of the program to that address. Usually malware authors will try to push this slightly earlier onto the stack rather than do something like the following as it would be detected more easily in static analysis -

push aScumbagAddresstoGoto retn

Following this technique would confuse static analysis tools like IDA which would not have generated cross references or even read a particular set of instructions since it is considered as a bunch of irrelevant bytes (remember linear disassembly?, yeah that’s what just happened)

Speculating from this^^ what might happen is that the retn instruction would get executed (pop aScumbagAddresstoGoto ) and the control flow would transfer to memory address 0x04014C0, which would execute a bunch of evil code. In an ideal situation this evil code would probably be scattered across the program somewhere far off to confuse the analyst rather than how it is represented in the above example (duh)

6.Creating/Using your own SEH (Structured Exception Handler)

TL;DR picture version

Structured exception handlers were introduced by ~~intel ~~ microsoft 1 to give programs a way to handle error conditions gracefully ( kinda like try/catch in java). There are many ways that exceptions could be triggered- one of the easiest would be access unknown memory address (0x41414141 :D) or by stuff like divide by zero.

The SEH is like a linked list which has a chain of functions meant to handle an exception, suppose a function doesn’t know how to handle a certain exception it is passed down the line until the program [To get resolved by an exception handler OR!->] crashes and you get an unhandled exception. Using this feature exceptions would be handled gracefully rather than annoy the user with crappy error codes.

To figure out the SEH chain the OS would refer the FS segment register. This contains a selector which will be used to access the TEB (Thread Environment Block). Now the first structure within the TEB is the Thread Information Block which points to the SEH which would be a linked list as shown below -

DWORD handler; }


This works similar to a stack with the prev working as link to the last record and handler points to the handler function.So you could write your own custom exception which points to some code of your choice and then forcefully do some illegal operation so that the control flow goes to the function which was written by you Further reading on this 4

What happens above is pretty darn neat, the location of the function to execute when the exception occurs is pushed, then the SEH record is set to point to esp and an exception is forcefully generated as shown. The printf function block will not run as the control is transferred to the evil_func loc.

Exploring the eviL_func loc we see the following:

In a nutshell the assembly does the following, it unlinks the SEH and removes the exceptions which were pushed from the stack. move eax,[eax] which is dereferencing (similar to C) is done twice because for some weird reason windows puts its own crappy SEH when our cool custom exception handler is created (hmph). Doing the operation twice dereferences our SEH + the win SEH.

Once the dereferencing is done it keeps continuing to execute the rest of the code without any intention of returns etc .Since SEH are not iterated by IDA it becomes another smarty pants way of obscuring the flow

7.Screwing around the stack-frame construction in IDA Pro

This is mostly done with handwritten assembly wherein an author might use techniques mentioned in 1 & 2 (part 1) to fool IDA pro into executing the false conditional branch of jump instructions first.

Consider the following , suppose your stack size was 8…and following code is reached- ….. > xor eax,eax
jnz trick___loc add esp,4 jmp real_code ……….arbitary code?>
trick loc: add esp,200h real code: ..>>>evil stuff

Since IDA does recursive disassembly it has this tendency evaluate the false branch first.Since xor eax,eax is always going to set Zeroflag it can be concluded that code at the trick_loc will never be execute BUT! IDA does not know this and gets confused. Symptoms of this would be IDA showing negative values for the stack pointer. ALT+K would be a good way to fix this issue if ever encountered in IDA.

Links to Samples :


  1. Thanks to Steven Reddie for pointing out my error, it’s actually microsoft who has created the SEH [return]
  2. https://www.exploit-db.com/docs/17505.pdf [return]
  3. https://www.exploit-db.com/docs/17505.pdf [return]
  4. https://www.exploit-db.com/docs/17505.pdf [return]