IDA backend: include api features of renamed calls

[mr-tz]

Summary

After renaming dynamic calls in IDA, the backend should emit the respective API calls.

Most often the dynamic calls will be to global addresses, but calls via registers or even local variables are also possible.

Motivation

Malware often contains obfuscated API calls as shown below.

Before

After

Describe alternatives you've considered

Alternatively, an additional analysis engine could try to automatically recover/identify API calls, e.g. using emulation. This could then work in the standalone version as well.

[mike-hunhoff]

+1 for this feature. I'm analyzing some shellcode that dynamically resolves all API calls and stores the addresses in a large structure. We should investigate solutions to include these sorts of API calls as well.

[mike-hunhoff]

maybe can adapt code here -> https://github.com/arizvisa/ida-minsc/blob/master/base/instruction.py#L819 to extract API calls from user-defined structures.

[mike-hunhoff]

After doing additional research it appears that attempting to pull structure member names from a user-defined structure using IDAPython can get messy real quick - especially when working with large, nested structures.

A simpler solution may be to check if a call/jmp references a structure offset using something like idaapi.is_stroff and then parse the structure member using a regular expression, something like (call|jmp)\s+\[.+\s*\+\s*(.+)\].

I don't like the idea of parsing the disassembly like this but it's the simplest solution and may require less overhead then attempting to go through IDAPython.

[mike-hunhoff]

Another problem to tackle - how do we map something like GetMessageW to user32.GetMessageW? Most capa rules specify the DLL name as part of the rule which means we can't match with just GetMessageW.

One option is to only support specific annotation formats e.g. WIN.api.user32_GetMessageW

[Ana06]

@mike-hunhoff

Another problem to tackle - how do we map something like GetMessageW to user32.GetMessageW? Most capa rules specify the DLL name as part of the rule which means we can't match with just GetMessageW.

I think in the extractor we only use the API name:

capa/capa/features/extractors/ida/insn.py

Line 83 in bb86d14

yield API(name), ih.address

(I think this has been changed after you wrote this comment)

[Ana06]

Adding support for calls to global variables can be implemented by getting the name of the call/jump operand. I'll send a PR to support it. 😉

[Ana06]

@mike-hunhoff

I'm analyzing some shellcode that dynamically resolves all API calls and stores the addresses in a large structure.

Can you share the hash of the sample?

A simpler solution may be to check if a call/jmp references a structure offset using something like idaapi.is_stroff and then parse the structure member using a regular expression, something like (call|jmp)\s+[.+\s*+\s*(.+)].

I think this could work. But I understand this would need that the structure has been applied in the disassembly. If the pseudocode view work well, I often apply the structures only in the pseudocode view and it wouldn't work in that case. We could also parse the pseudocode view with code like the following which returns the pseudocode line corresponding to the call instruction:

cfunc = ida_hexrays.decompile(ea)
item = cfunc.body.find_closest_addr(ea)
coord = cfunc.find_item_coords(item)
cfunc.get_pseudocode()[coord[1]].line 

But I am not sure how efficient parsing the pseudocode is. We likely would want to ensure we only decompile every function once.

[Ana06]

Registers are also tricky, as they are often the value returned by a function that resolves the APIs (and this function could be very different). An example of a sample I analysed yesterday:

I often add a comment in the call instruction with the API. Not sure if this is a standard practice, but if it is, getting the API from the comment should be easy. Parsing the pseudocode could also be used for this case.

[Ana06]

Does someone has a sample where the resolved APIs are stored in local variables? I think this case could also be tricky if the variable is reused.

[mr-tz]

closed via #2201