Have you ever seen code that you know belongs to a function, but IDA refuses to create a function out of it? If so, you're probably familiar with disassemblies that look like this:


http://malwareanalysis.com/CommunityServer/blogs/geffner/2005_06_28_1.gif

Figure 1. If IDA doesn't interpret code as a part of a function, then all references to variables on the stack are shown as numeric offsets.


Not only does IDA's initial auto-analysis not create a function out of such code, but even right-clicking on the first instruction and selecting "Create function..." doesn't work. In fact, doing so for the above example yields the following error in IDA's log window:



Figure 2. Error message when trying to manually "Create function...".


This error is displayed because the jmp at 0040104D is trying to jump to 0040104C, which is invalid.

Of course, we could patch the file or database to manually nop-out the bad jmp, but this is a rather un-elegant solution. Instead, we can force IDA to create a function out of the above code by selecting the instructions up until the erroneous instruction, and then doing a "Create function..." on that selection:

http://malwareanalysis.com/CommunityServer/blogs/geffner/2005_06_28_2.gif

Figure 3. Select the instructions up until the erroneous instruction.


http://malwareanalysis.com/CommunityServer/blogs/geffner/2005_06_28_3.gif

Figure 4. After forcing "Create function..." on the selected region, references to stack variables are now named.


We now have named stack variables and can more easily analyze our target.


http://malwareanalysis.com/CommunityServer/blogs/geffner/archive/2005/06/28/2.aspx ("http://malwareanalysis.com/CommunityServer/blogs/geffner/archive/2005/06/28/2.aspx")