Hex-Rays: JUMPOUT statements inserted due to incorrect autodetected function boundaries

Question

I'm trying to RE a Windows executable compiled with VS 2008. After the initial autoanalysis most functions are detected correctly; however, some have wrong end address — for some reason IDA places the end of the function earlier, leaving a chunk of code not associated with any function. The undetected function gets noreturn attribute and often has sp-based autoanalysis failed message. I have fixed most of these problems by hand. The problem is that Hex-Rays seems to use autodetected function boundaries and therefore the decompilation fails after a jump inside the function, which looks like a jump outside to Hex-Rays.

Example hex-rays output:

void __thiscall sub_403CE0(void *this, unsigned int a2, int a3)
{
    sub_407F30(this, a2, a3);
    JUMPOUT(locret_403CFD);
}

As you can see, there is a JUMPOUT statement at the end of the function. This was correct before the function boundaries were adjusted, but now locret_403CFD belongs to the function itself and is not a jump “out”. Is there a way to tell hex-rays the function doesn't end here and pass a correct function start/end addresses to it?

Answer 1

Yes there is. HexRays takes function boundaries from IDA disassembly, so as far as you can change the function boundaries in disassembly view, you can manage function boundaries as follows (the solution is for you specific case, solving this problem in common may be more complicated):

1. Find the function in the disassembly window
2. Go to the end of the code not associated with any function but should be in function you are workung with, press your cursor there.
3. Press E. This will mark the current position as an end of the function before the area
4. Go back to decompiler window. Press F5. JUMPOUT should disappear if the address it jumps to now belongs to the function you are working with.

Answer 2

After some work with the database I figured out the reason of the strange behavior of IDA. The binary I'm trying to decompile is a GUI application that uses MFC; I have imported a number of MFC types from a PDB file obtained from Microsoft Symbol store. It's either an IDA bug or corrupted PDB — if I don't import types, all functions are detected correctly and decompilation works as expected, if I do — many function boundaries go wrong, decompilation fails, function attributes are ignored by Hex-Rays and so on.

One of possible workarounds is to export the database as IDC file and then run the resulting script on a clean database. This way, function prototypes and type information are kept intact. Hex-Rays decompiled results will differ, though (variable mapping information is lost, and so are local variable names).

Answer 3

1. check if jump destination is a continuous area behind the function, if true, alt+p, adjust function range.
2. if not, first undefine target area, then use IDA-built-in function "append_func_tail" to add that chunk to owner function. here is the IDA-reference doc link
3. one jump out done. if there is too many, then write a script to automate it.