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

EDB's disassembler needs to be aware of memory context of an instruction #594

Open
10110111 opened this Issue Aug 26, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@10110111
Contributor

10110111 commented Aug 26, 2017

Currently, if you have a sequence of bytes like 18 bf 49 40 in Thumb mode, you'll have as disassembly:

18 bf    it    ne
49 40    eors  r1, r1

This is obviously wrong, since the second instruction is in the IT block and must have a condition:

18 bf    it    ne
49 40    eorne r1, r1

This won't work until EDB starts at least passing something like 18 bytes to cs_disasm (maximum for an IT block). Of course, another problem would be the need to look "back" for a possible preceding IT instruction, especially when CPSR.IT≠0.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Aug 28, 2017

Owner

Yea, I've been thinking that this would be a difficult challenge to deal with. My current thought is that if the user has run analysis on the region (maybe make it just happen auto-magically?) then we could look back to the beginning of the current basic block and and determine the "mode" from there?

Owner

eteran commented Aug 28, 2017

Yea, I've been thinking that this would be a difficult challenge to deal with. My current thought is that if the user has run analysis on the region (maybe make it just happen auto-magically?) then we could look back to the beginning of the current basic block and and determine the "mode" from there?

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Aug 28, 2017

Contributor

Well, if the analysis results are available, this matter is trivial. But analysis is not instant, and it seems there's a possibility to confuse the analyser (although it's just my guess, I've not looked into what the analysis does). Might be a good idea to add a "quick analysis" mode to the analyzer, so that details like this can be easily found out.
Without analysis, EDB can at least check current CPU state and, if CPSR.IT≠0, then try to disassemble the block instead of single instructions.

Contributor

10110111 commented Aug 28, 2017

Well, if the analysis results are available, this matter is trivial. But analysis is not instant, and it seems there's a possibility to confuse the analyser (although it's just my guess, I've not looked into what the analysis does). Might be a good idea to add a "quick analysis" mode to the analyzer, so that details like this can be easily found out.
Without analysis, EDB can at least check current CPU state and, if CPSR.IT≠0, then try to disassemble the block instead of single instructions.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Aug 30, 2017

Owner

Yea, analysis isn't instant, and it certainly isn't perfect. I was just thinking that things such as Ollydbg always do an analysis (as far as I can tell), and while sometimes it does introduce a pause (usually during dll load), user's seem to be OK with that given the usefulness of the results.

So, my thought is that perhaps, if the analysis proves to make this task significantly simpler, then it may be worth it for the average user. I'm a bit torn on this one though, as I am a fan of not wasting the user's time as well.

Owner

eteran commented Aug 30, 2017

Yea, analysis isn't instant, and it certainly isn't perfect. I was just thinking that things such as Ollydbg always do an analysis (as far as I can tell), and while sometimes it does introduce a pause (usually during dll load), user's seem to be OK with that given the usefulness of the results.

So, my thought is that perhaps, if the analysis proves to make this task significantly simpler, then it may be worth it for the average user. I'm a bit torn on this one though, as I am a fan of not wasting the user's time as well.

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Aug 30, 2017

Contributor

In OllyDbg it's always possible to skip analysis (by pressing Space or Esc).

Contributor

10110111 commented Aug 30, 2017

In OllyDbg it's always possible to skip analysis (by pressing Space or Esc).

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Aug 30, 2017

Owner

Agreed, it is cancelable of course. But it is often time consuming and is opt out, as opposed to edb's opt in analysis. We could make it cancelable, and have a config option to auto analyze as needed.

Owner

eteran commented Aug 30, 2017

Agreed, it is cancelable of course. But it is often time consuming and is opt out, as opposed to edb's opt in analysis. We could make it cancelable, and have a config option to auto analyze as needed.

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