Best way to handle memory operands

[B.R.]

Hello,

I need to trace values written to memory operands and get the written value.

I decided the following scenario (I couldn't get a simpler one):
- At instrumentation time, if memory operands depends on register(s) value:
  * Register an analysis callback before the current instruction in order to get the value of reg(s) and compute memory address
  * Register an analysis callback before the next instruction (ie after the current one) and use the stored computed addresses to get the wanted memory values
- If there is non dependance on registers, address computing and value gathering could both be done before the next instruction

I now need to decide wether a memory operand has some dependance on register(s).
What is the cleanest and most secure way?
1) Using opnd_is_base_disp
2) Using opnd_num_regs_used
3) Any other way

I am not sure I didn't miss any special case in my scenario. The #2 way shoud do the job if I am correct.
What do you think?

Thanks,
---
B.

[Reid Kleckner]

For 32-bit code, the only memory referencing operands are base+disp operands.  For x64, there are rip-relative and absolute references, which can depend on segment bases.  Typically those are used to access TLS.

opnd_num_regs_used(op) > 0 is probably the most reliable way to go.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To post to this group, send email to dynamor...@googlegroups.com.
To unsubscribe from this group, send email to dynamorio-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dynamorio-users?hl=en.

[B.R.]

Thanks for the answer, it helped a lot.

However I encountered another difficulty:
With an instruction like 'mov eax, dword ptr fs:[0]', there is a double dereference fs:[0] --> [address] --> address

So far, when a memory reference dependent on registers is base_disp based, I pass base & disp to the analysis context, with compute the addition based on registers context.
My intuition is that, in that particular case, I need to send to the 'dr_get_dr_segment_base' function the answer from 'opnd_get_base'.
(I had no help intuiting that other than guessing after the 'segment' word in the function I happen to see before btw....)

Is my intuition correct?
How can I tell I need to do that ? Which function or mechanism do I need?

More generally speaking, is there any other specific case I need to know when computing memory operand addresses?
So far I have:
- Address contained in operand (no dependency, address computing can be made at instrumentation time)
- Address dependant on register (quick question: does the reg_id_t value returned by opnd_get_base handles cases with multiple registers like esi+ecx?)
- Address dependant on a segment (the one described above)
- ... Anything else? ...

Thanks,
---
B.

[Derek Bruening]

Use drutil_insert_get_mem_addr() and then you don't need to know all the details of x86 addressing modes.  See the memtrace.c sample for an example that uses it.

- Derek

[B.R.]

Thanks for the piece of advice.

However:
1) Using the drutil (and drmgr) extensions by adding instructions in the BBLs to monitor read and written memory address would mean I refactor the whole code. Since I also want the values read or written from both memory and registers, I'd prefer to keep my way of doing this.

2) I tested a slightly modified version of memtrace.c (to reduce its output to the usercode part) and compared its output with the waited values. The file failed at properly reading the read address in the particular case with the FS segment involved.
This makes me saying that the function you are advertising me is not as simple to handle as it seems.

3) Since drutil_insert_get_mem_addr seems not to get the FS related memory address properly, my initial question finally stills stands :o\
---
B.

[Derek Bruening]

On Mon, Aug 13, 2012 at 11:47 AM, B.R. <reallfqq-...@yahoo.fr> wrote:

1) Using the drutil (and drmgr) extensions by adding instructions in the BBLs to monitor read and written memory address would mean I refactor the whole code. Since I also want the values read or written from both memory and registers, I'd prefer to keep my way of doing this.

Once you have the address it's easy to get the value.

 

2) I tested a slightly modified version of memtrace.c (to reduce its output to the usercode part) and compared its output with the waited values. The file failed at properly reading the read address in the particular case with the FS segment involved.

Obtaining the linear address of far references is one of the main reasons to use this routine, as it's complicated to do manually.  Are you sure it didn't work?  It works in all of our tests.  Please provide details if you believe its reported address is wrong.

- Derek

[B.R.]

Yes, I'm sure it's not working:

I started to trace 'hostname.exe' again with the original 'memtrace.c', untouched.
If you search for the 'wa:0x0007ffb0' string, you'll find it twice.
Each one of them has a previous 'r4' read.

At lest one of them is the memory read which address is computed on the basis of the value of the FS:0 segment.
If you give a quick look at the address gathered by the memtrace code, you'll find out those are not real addresses.

So basically I am mxing near & far memory references...
So I just need to use the 'opnd_is_far_memory_reference' and the 'opnd_is_near_memory_reference' functions. That was the answer I was seeking for! ^^

Thanks,
---
B.

--

[B.R.]

I forgot to mention some details about my development environment if you want to reproduce the problem I am facing:
- Windows XP x86
- Program traced: hostname.exe
- Trace module: memtrace.c (DynamoRIO sample)
---
B.

[B.R.]

Hello,

I managed to get the FS:0 address by using opnd_computed_address on the memory operand at instrumentation time.
However when I try to dereference this address to access the wanted value (ie [FS:0]), I do not find accurate data there, which is supposed to be the address of the next exception handler.

Does DynamoRIO modify the segment data when instrumenting the code? How can I access it?
Thanks,
---
B.

[Derek Bruening]

On Mon, Aug 13, 2012 at 2:56 PM, B.R. <reallfqq-...@yahoo.fr> wrote:

Yes, I'm sure it's not working:

There was in fact a Windows-only bug in dr_insert_get_seg_base() (http://code.google.com/p/dynamorio/issues/detail?id=866) which is now fixed (http://code.google.com/p/dynamorio/source/detail?r=1528).

- Derek

[B.R.]

Do you plan to release something built in the coming times?
Or do you have something like nightly builds?

I just can't make CMake working, following yours intructions on the Wiki. That thing is a nightmare to me.
---
B.

On Tue, Aug 14, 2012 at 2:43 PM, B.R. <reallfqq-...@yahoo.fr> wrote:

Thanks Derek,

I didn't expect any bug from that, I went totally lost trying to find where my code was buggy.
Well, it probably is, but not where I looked ;o)

Do plan any new Windows release in the near future?
I managed to stay aside from the CMake tool but now I am dependent on your builds :oP
---
B.

- Derek

[B.R.]

Thanks Derek,

I didn't expect any bug from that, I went totally lost trying to find where my code was buggy.
Well, it probably is, but not where I looked ;o)

Do plan any new Windows release in the near future?
I managed to stay aside from the CMake tool but now I am dependent on your builds :oP
---
B.

- Derek

[Derek Bruening]

On Wed, Aug 15, 2012 at 1:57 PM, B.R. <reallfqq-...@yahoo.fr> wrote:

Do you plan to release something built in the coming times?

The next release will probably be a few months from now.

 

Or do you have something like nightly builds?

It's long been on our todo list but we do not have them at this time.

I just can't make CMake working, following yours intructions on the Wiki. That thing is a nightmare to me.

If something in the instructions doesn't work please let us know (with specifics).

- Derek