New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make disassembler more process-memory-oriented #599

Open
10110111 opened this Issue Sep 10, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@10110111
Contributor

10110111 commented Sep 10, 2017

I'm thinking of making a couple of DebuggerCore variants, which would use unusual (when compared to ptrace and kernel32 debugging API) backends like GDB and Bochs. But to take a better advantage of this, namely to be able to find out how the backend sees an instruction, it'd be good if CapstoneEDB (or something better named) had an interface like Instruction(pid,address) instead of the current Instruction(bytesInDebuggerMemory,address) (in this case we'd of course lose the ability to inspect the instruction, but this mode can still be useful).
Do you see any reasons why this shouldn't be done to the EDB's disassembler interface?
OTOH, this is only needed for QDisassemblyView I think, so maybe it's better to just have an overloaded constructor for Instruction and just use it inside the disassembly view code?
In any case I guess the disassembler API should be made more extensible — something similar to the plugin-based IDebugger API.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Sep 10, 2017

Owner

Firstly, I like the idea of finding a good way to make the disassembler more of a plugin. I've thought about this for a while, but never settled on what felt like a good API for it.

That being said, this is interesting. Is it really just a matter of efficiency? Or is it something deeper?

I ask because even with the current API, we can read arbitrary memory from a PID using any API into a block of memory, and then disassemble it. Is the idea that we just want to be able to ask things like GDB "how would YOU disassemble this address?" Is there a specific goal you are striving for?

Just trying to figure out what the use case we're going after is.

Owner

eteran commented Sep 10, 2017

Firstly, I like the idea of finding a good way to make the disassembler more of a plugin. I've thought about this for a while, but never settled on what felt like a good API for it.

That being said, this is interesting. Is it really just a matter of efficiency? Or is it something deeper?

I ask because even with the current API, we can read arbitrary memory from a PID using any API into a block of memory, and then disassemble it. Is the idea that we just want to be able to ask things like GDB "how would YOU disassemble this address?" Is there a specific goal you are striving for?

Just trying to figure out what the use case we're going after is.

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Sep 10, 2017

Contributor

Yes, the idea is to ask the backend how it would disassemble the address. I've not seen any easy way to disassemble bytes neither in GDB nor in Bochs — all one could do is write the bytes into debuggee address space and then use disassemble command.
The general use case is supporting an arch which EDB doesn't even know of — e.g. for comparison when porting etc.. But this would also be useful in Bochs because it'd show how Bochs interprets the instruction at hand (after its new disassembly engine becomes the default).

Contributor

10110111 commented Sep 10, 2017

Yes, the idea is to ask the backend how it would disassemble the address. I've not seen any easy way to disassemble bytes neither in GDB nor in Bochs — all one could do is write the bytes into debuggee address space and then use disassemble command.
The general use case is supporting an arch which EDB doesn't even know of — e.g. for comparison when porting etc.. But this would also be useful in Bochs because it'd show how Bochs interprets the instruction at hand (after its new disassembly engine becomes the default).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment