1

I have a function MyFunc in an obfuscated program as follows:

Start address: .text:000000014219FC5D
End address: .text:000000014219FD0E

MyFunc starts off by jumping to .text:000000014143C159, which is recognized correctly by IDA as FUNCTION CHUNK FOR MyFunc.

This basic block jumps to .text:000000014000B524, which is not recognized correctly by IDA. IDA recognizes it as a completely unrelated function. There are 0 other xrefs to this block in the program.

I'm guessing the problem is that the basic block is lower in address than the function start, so IDA can't consider it as a basic block of MyFunc. I'm guessing that the obfuscator splits basic blocks and then shuffles them (mixing them together with BBs from other functions).

What is the recommended approach to take in order to get analysis working?

Improve this question

1 Answer 1

Reset to default
1

You can use Edit->Functions->Remove function tail to remove the block from whichever function is claiming it as a tail, and Append function tail to add it to the other one. However, this might be a waste of time. Given that the program is obfuscated, it might well be the case that IDA's ordinary analysis techniques and data abstractions for functions aren't very useful -- this is commonly the case for obfuscated code. Do you have a specific reason for wanting the function boundaries to be correct? Is it interfering with something else you're trying to do?

Improve this answer
5
  • I am interested in viewing the pseudocode, which cannot work without successful sp-analysis (which requires IDA to "see" the entire function properly). Is there a better solution?
    – P. Private
    Feb 26, 2021 at 7:59
  • Depending on the degree of obfuscation, decompilation might be a lost cause (e.g. if the obfuscation involves indirect branches to addresses that are computed at runtime, or certain forms of obfuscation involving the stack pointer). But, I can't say without looking at the program. Give what I said a try; it might fix your problem, or at least get you closer to a solution. (For one example, you might have to manually fix the stack pointer.)
    – Rolf Rolles
    Feb 26, 2021 at 8:05
  • Yes, of course, I was just performing a little bit of recon to see what to expect later. BTW should the start address and end address in IDA be ignored once you start manually changing the function tail?
    – P. Private
    Feb 26, 2021 at 8:24
  • I have some code that will follow a function come hell or high water, until it has resolved (using an optional library of de-obfu patterns) and forcefully followed the code (removing false functions, chunks, and such like) as it goes -- ultimately relocating in a contiguous chunk at another (new) address -- provided it is satisfied that the stack pointer will be balanced (or if forced). Unfortunately it's thousands (and thousands) of lines of terribly written python code and uses 3 disassembler and assemblers. It's targeted at Arxan obfuscation, so I'm hesitant to release it even as is.
    – Orwellophile
    Mar 1, 2021 at 10:51
  • 1
    Sounds cool. In my case I was able to use instruction-level tracing to link all the function chunks together.
    – P. Private
    Mar 2, 2021 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.