Is there a way to get the physical operand size from a ZydisDecodedOperand?

[jonomango]

Hi,

Sorry for asking so many questions, but I was wondering if there was a way to get the physical operand size (specifically for imm/disp operands) from a decoded operand. I've found myself often working with a ZydisDecodedOperand structure that I need the size of, and it is a bit annoying to have to get this information from the ZydisDecodedInstructionRaw structure. This isn't that big of a problem until you start working with formatter hooks (like ZYDIS_FORMATTER_FUNC_FORMAT_OPERAND_MEM and ZYDIS_FORMATTER_FUNC_FORMAT_OPERAND_IMM) and you don't know which field to access in the raw decoded instruction field (imm[0] vs imm[1], for example).

Any help would be appreciated, and again, sorry for making so many discussion posts 😅

[flobernd]

Hey,

@athre0z is currently working on refactoring the whole .raw stuff. In fact we are trying to remove most of the stuff from ZydisDecodedInstruction and provide a different API to query it. The offsets and sizes to the individual segments (prefixes, imm, disp, ...) will still be available tho and it would be a step in the "wrong direction" to add the raw offset/size to ZydisDecodedOperand.

I'm curious: Is there a particular reason you have to access the raw values in the formatter? Usually the formatter aims to hide any encoding specific details.

To work around your specific problem you could introduce a simple int in your context which you set to 0 when a new instruction is being formatted and increase by 1 everytime an immediate operand is formatted. I admit, it's not a perfect solution as you have to e.g. reverse the order for ATT output, but it's basically the same way the decoder does it internally in e.g. ZydisDecoderDecodeOperand.

[jonomango]

Ah, I think I see where the confusion is coming from. These aren't actually instructions that are meant to be executed, the way they currently are. This is just an intermediate representation for them that is very similar to x86. In this IR, there are no relative instructions at all. Every relative instruction has been modified to use a symbol ID, which is absolute. I'm just using the term "relative offset" to refer to what is now known as "symbol ID."

+000 jnz +04 # loc_1022
+002 jmp +02 # loc_1022

These do not both point to loc_1022, since they have different symbol IDs (remember, these are absolute, not relative). The first instruction points to loc_1022 and the second points to entrypoint.

+000 jnz +04 # loc_1022
+0D8 jnz +04 # loc_8888

These both point to loc_1022 (symbol ID 04).

Again, symbol IDs are absolute, but they're encoded in the same position that normal x86 relative operands would be. When the time comes to produce normal x86 instructions, I just look into the symbol table for the real address (if it has one).

[flobernd]

This is just an intermediate representation for them that is very similar to x86

Alright, that was not clear to me in the beginning.

In this case I don't have a better solution than manually keeping track of the immediate id like I suggested in my first answer. It's similar to what we do internally e.g. here:
https://github.com/zyantific/zydis/blob/master/src/Decoder.c#L1861

[jonomango]

In this case I don't have a better solution than manually keeping track of the immediate id like I suggested in my first answer. It's similar to what we do internally e.g. here: https://github.com/zyantific/zydis/blob/master/src/Decoder.c#L1861

I see. In my situation, I'm only dealing with relative instructions, so I don't actually have to worry about which imm to use. From my understanding (and a decent amount of testing), there can be at most a single relative operand in an instruction and it is always the first imm operand. This means that I don't have to worry about imm[1] ever being relative.

Anyways, thanks for the help, I really appreciate it! The Zydis community has been nothing less than fantastic. ❤️

[athre0z]

The reason I need the physical size is so that I can calculate the unsigned value for the imm/disp operand.

That's also something that we're currently working on making easier, by the way! :)

See discussion here: #336 (comment)

That being said, it most likely won't make it for the v4.0 release, so implementing the suggested workaround is not a waste of time. If only days had more hours .. :p

[jonomango]

That's also something that we're currently working on making easier, by the way! :)

See discussion here: #336 (comment)

I'm glad to see that it is being worked on! I'm looking forward to the new updates.