Closed RCECoder closed 10 months ago
Thanks for your quick response.
How to determine if this operand contains an address like in first instruction?
instruction.operands->mem.type
returns 0x25 (ZYDIS_REGISTER_EAX) for the first instruction.
instruction.operands->mem.type returns 0x25 for the first instruction.
This is not a valid ZYDIS_MEMOP_TYPE_*
value, so probably you are accessing the wrong operand (it should be instruction.operands[1]
in your case).
You can detect addresses in memory operands by calling ZydisCalcAbsoluteAddress
and checking if it fails or not. If you really want to do this manually check for displacement (mem.disp.has_displacement
) and base register (must be EIP
/RIP
for relative addresses, for absolutes base
and index
must be ZYDIS_REGISTER_NONE
).
Yes, you are correct.
I used this function and got back the address in result_address.
I also found a small bug in the disassembly loop logic. Some opcodes are returning invalid.
ZydisDisassembleIntel
really returns error but the loop must continue until consumed the size of disassemble buffer.
Because it can happen that an instruction is invalid but later on there are valid instructions.
Ollydbg he is able to disassemble this successfully but only if analyze code (CTRL +A) applied.
Here how Ollydbg looks without analyzing code
After analyzing looks different
So we must continue looping through all buffer to avoid this situation.
Thanks for your help, mappzor 👍
@RCECoder A small addition regarding "relative" instructions: You can check if the ZYDIS_ATTRIB_IS_RELATIVE is set in the attributes field of the decoded instruction, if you need to know about relative memory AND branch instructions.
Regarding your other problem: If you do a linear sweep disassembly pass, you will often encounter data mixed with actual instructions which leads to the situation like in your first Olly screenshot. There are techniques to get better analysis results, but most of them are complicated.
Result:
How can I retreive the address 0x000000014012D540 as a ZyanU64?