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

Polynomial
  • 1,272
  • 2
  • 12
  • 21
  • 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 01 '20 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 01 '20 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 01 '20 at 16:15

1 Answers1

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

Florian Magin
  • 1,444
  • 6
  • 22
  • Sadly it does not appear that RDMSR gets populated with these constants. – Polynomial Dec 01 '20 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 01 '20 at 17:02