ghidra: improve instruction string and bytes feature extraction #1885
Conversation
| else: | ||
| break | ||
|
|
||
| yield to_addr |
There was a problem hiding this comment.
is the yield only per reference intended here?
where we expect multiple references from an instruction?
There was a problem hiding this comment.
is the yield only per reference intended here?
Yes - the intention is to follow nested pointers until data (as defined by Ghidra) is reached or max_depth is reached resulting in a single yield per memory reference from an instruction.
where we expect multiple references from an instruction?
Yes - an instruction may have multiple references from it. Here we restrict our search to memory references that reference data (as defined by Ghidra).
There was a problem hiding this comment.
Ok, I think the IDA equivalent works differently or am I confusing the functions?
What's an example of an instruction with multiple data references?
There was a problem hiding this comment.
perhaps symbolic analysis might resolve a set of candidate references for an indirect read/write like mov [eax], 1?
also perhaps ghidra supports an architecture with a complex memory to memory copy? (just guessing).
There was a problem hiding this comment.
For example,
MOV dword ptr [EBP + -0x8],0x469be6
op[0]: RefType.WRITE
op[1]: RefType.DATA
Ghidra tracks many different reference types so to be complete we must check them all for each instruction. This level of reference tracking can be really useful.
|
i love the algorithms and methods that are being created here for capa + ghidra! i hope they serve as good documentation for the future |
|
@colton-gabertan when you have a moment can you review and see if I missed anything obvious with these changes? |
Checklist