5

I'd like to get the inferred value of a register at a particular point in the disassembly listing in a Ghidra script.

In my case the target instruction is a rdmsr or wrmsr instruction, which reads or writes the MSR at ecx. While I could walk back through the previous instructions and look for a simple mov ecx, const pattern, there are significantly more ways to set ecx to some known value that the decompiler is capable of inferring.

I've tried calling getRegisterValue on the rdmsr instruction, passing in a Register type describing ecx, but this just returns None. Is there a way to infer register values at a particular instruction?

Here's the disassembly:

disassembly

And the decompiled result:

decompiled code

Here's the P-Code:

disassembly with p-code

Improve this question
3
  • Can you post a screenshot of the actual code you are trying this with? I assume that your issue is that you are getting None for a case where it should be obvious, but adding an image would make this clearer.
    – Florian Magin
    Dec 1, 2020 at 12:34
  • Also, what getRegisterValue method are you talking about specifically? IDE tells me there are 11 methods with that name, with varying signatures on different classes, none of them available by default in the Jython context (which I assume you are using because you say None instead of null)
    – Florian Magin
    Dec 1, 2020 at 12:44
  • @FlorianMagin I've tried a number of different variants of that method, but primarily the Instruction one and the ProgramContext one.
    – Polynomial
    Dec 1, 2020 at 16:15

1 Answer 1

Reset to default
2

After looking into this a bit, I think that it will heavily depend on the exact context.

The decompiler can definitely do a basic form of this: enter image description here

In this cases the PCode operation for the call instruction is already: (register, 0x0, 4) CALL (ram, 0x125180, 8) , (const, 0x1, 4) , (const, 0x5413, 8)[0] i.e. it contains the propagated constants already, without any references that they were read from a register.

If you are lucky the associated PCode operations for a rdmsr or wrmsr contain this information already. I don't have a binary to test how these instructions are handled exactly though. If they in any form contain the information that they depend on the value of ecx then I would expect that the decompiler will optimize the PCode instruction to directly use the constant as the PCode argument instead if possible, like in the attached image. A quick glance into x86.sla seems like RDMSR is indeed defined in a way that should allow this to happen.

The general results of any kind of value analysis that happens inside the decompiler is not exposed in a way that I know of though.

[0] This is not the PCode from the instruction but from the decompiler token. You can get this by clicking on a token (like ioctl in the decompiler and then accessing currentLocation.token.pcodeOp in the Jython shell

Improve this answer
2
  • Sadly it does not appear that RDMSR gets populated with these constants.
    – Polynomial
    Dec 1, 2020 at 16:12
  • Can you tell me the PCode OP of RDMSR instruction and the surrounding code? There are cases where the decompiler has this information but it doesn't get propagated to the PCode OP but might still be available with a little scripting. Getting RDMSR to lift as something that depends on ecx should be possible in some way if this really isn't the case yet.
    – Florian Magin
    Dec 1, 2020 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.