Extending capa's capabilities with Ghidra P-code

[fariss]

Hello @mandiant/flare-gsoc (@mike-hunhoff, @williballenthin, @mr-tz) team,

I am starting this discussion to express my interest in applying for this year's GSoC @ FLARE. I aim to share my thoughts on the adoption of P-code analysis by capa to extend its capabilities beyond x86/x64.

For some context, during the analysis of a particular program, Ghidra goes through many steps before it produces a pseudo-like C decompilation of the assembly code:

• In the beginning, SLEIGH is used to define the semantics of machine instructions for a specific processor architecture. It describes how each instruction should be interpreted in terms of its effects on the state of the machine, such as changes to registers and memory. Each processor has its own Sleigh specification file (.sla) that describes the instruction set and how each instruction should be interpreted.
• The output of SLEIGH is a one-to-many translation named Low P-code (less readable), which is later lifted into High P-code (more readable) allowing us to traverse and query the various varnodes.
• Ghidra offers a powerful API (via Jython and Java) to interact with the P-code AST, and with help of these abstractions, reverse engineers can develop scripts and workflows, which automatically target the assembly code in an architecture-agnostic manner.

During this project, I am willing to work closely on the capa integration with Ghidra to extend its capabilites to support P-code-level analysis.

An example that comes to mind involves utilizing the External Functions (exposed by getExternalFunctions() Ghidra API). We can iterate through potentially dangerous APIs commonly employed by malware, such as VirtualAlloc(), VirtualProctect() WriteProcessMemory(), ... etc. By obtaining xrefs (via getReferences()) to the associated addresses (which would match PcodeOp.CALL or PcodeO.CALLIND) and leveraging P-code varnodes, it becomes possible to extract the diverse inputs supplied to these particular APIs (via getInput()). Again, all of this is done in an architecture-independent manner.

Another example involves retrieving calls LoadLibrary() and GetProcAddress() to identify APIs being dynamically resolved. P-code varnodes also allow us to answer questions about the type of the data being passed to these APIs (const, ram, reg?)

Kindly discuss this approach and correct me if I am wrong on anything. Feel free to propose other capabilities that could be designed. I would love to hear your feedback and suggestions.

I would like to share a Draft Proposal including some code snippets, planning and challenges. Do you prefer a Google Docs to be emailed/shared?

Best regards,
S. Fariss

[mike-hunhoff]

Thanks for reaching out @s-ff . It looks like you have a good understanding of how P-code is generated and used during Ghidra’s analysis.

capa can be extended to support new analysis backends. An analysis backend is responsible for extracting program features such as strings, disassembly, and control flow used to detect capabilities. Extending capa to support P-code involves changing its existing Ghidra backend to extract program features from P-code instead of the machine code. As you explained, there are two flavors of P-code, low and high, that can be accessed using Ghidra’s scripting API. Part of the research component for this project involves determining which of these P-code flavors can be reliably used to extract the program features needed by capa. For example, an instruction’s low P-code can be access using Ghidra’s Instruction.getPcode API. The existing Ghidra backend’s logic for iterating functions, basic blocks, and instructions should be able to be reused. Our goal for adding P-code support is architecture-independent analysis so be sure to highlight any issues you see with this in your proposal e.g. program features extracted by capa that are architecture dependent.

Please use a Google Doc shared with [email protected] for your draft proposal. Post any other questions here 😊