debug.Registers

[Shaddy]

I've seen that the actual Registers implementation doesn't follows the line of sark library (human and pythonic ida usage). I still find it as ugly as the actual ida c++ interface to get registers.

So I came up with this implementation, it doesn't walks the deepness of chained registers, but it wouldn't be hard to implement it.

class Registers(object):
    def __init__(self):
        self._schema = idaapi.dbg_get_registers()
        self._registers = [s[0].lower() for s in schema]

    def __getattr__(self, name):
        return idc.GetRegValue(name)

    def __setattr__(self, name, value):
        if hasattr(self, "_registers") and name in self._registers:
            idc.SetRegValue(value, name)
        else:
            self.__dict__[name] = value

    def __dir__(self):
        return self.__dict__.keys() + self._registers

This allows you to easily access registers, and assign values. Also you can TAB on your ipython ida instance and you will get all the possible registers to work with.

Tell me what do you think about it and if we can improve this section.

[tmr232]

I agree that the current registers API is not on par with the design goals. I will look into your suggestions as soon as I have time. Thank you!

[tmr232]

Finally had the time to take a proper look at things.

The current handling of registers within Sark (as is the rest of the code) is oriented towards static analysis and not debugging (not a design choice, it was simply what I needed at the time). So the current register handling is meant to tell you which regs are used in a given instruction. What you're suggesting here is register access while debugging.

I'd be happy to add debugger support to Sark. I guess it will go under sark.debug or something similar.
Does that direction seem relevant to your request, or did I misunderstand?

[Shaddy]

Well, I felt that it had a debug intention as well by looking at Registers comment.

Enables easy querying of the debug registers API (idaapi.dbg_get_registers) to get
register info, such as the names of the instruction pointer and the stack pointer.

Usage (on x86):
>>> print Registers().ip.name
eip

>>> print Registers().sp.name
esp```

Anyway, I would love if we sarkify the Debug layer as well. So yes! that's exactly the direction I was thinking on :).

[tmr232]

Well, this is a bit embarrassing... I completely forgot this code exists. I added it when working on DIE, and never used it since.

In this regard, looking at my code again, your suggestions make a lot of sense 😄

[Shaddy]

Hahaha, we found it!

I think that we should extend the debug events class DBG_Hooks so user can have sark objects (sark.Line) instead of just "ea".

Also a stackwalker/stackapi would be useful on these event contexts.

Debug memory api => Dbg<Type>(...) should have a more pythonic methods.

I'm not writting this to force you to spent time on this; just to have a list of "requisites" of the debug layer. I'll try to contribute as well :)

[tmr232]

Honestly, I never used to debug APIs, so I don't have any idea what to build there.

If you want, feel free to submit pull requests (preferably with basic use cases) and I'll take a look.

[tmr232]

Say, does your example code support partial registers (AL vs EAX)?

[Shaddy]

Yes! As long as GetRegValue supports it, it will, and this actually works: GetRegValue("al"). The schema is built by self._registers = [s[0].lower() for s in schema] then any client can query every register by pressing tab in ipython so magic __dir__ will expose self.__dict__.keys() + self._registers.

The limitation is in the second level of the schema, I didn't built the recursiveness but shouldn't be hard, just because I only had this need.