Skip to content
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

ctxp doesn't work when cwatch execute 'p var' #2579

Closed
BigBrotherJu opened this issue Nov 27, 2024 · 4 comments · Fixed by #2617
Closed

ctxp doesn't work when cwatch execute 'p var' #2579

BigBrotherJu opened this issue Nov 27, 2024 · 4 comments · Fixed by #2617
Labels

Comments

@BigBrotherJu
Copy link

Description

If I cwatch execute 'p/z var', ctxp doesn't work correctly.

After I cwatch execute 'p/z var', everytime I ctxp, the history number just increases like this: 17/18, 18/19, 19/20, 20/21. The output of p/z var also changes from $39 = 0x00010001 to $40 = 0x00010001.

Seems like the proper context history is not used, and p/z var is executed over and over again.

The correct behavior is to retrieve the proper context history instead of executing commands.

Steps to reproduce

  1. Debug any binary with GDB.
  2. start
  3. cwatch execute 'p var'
  4. ctxp
  5. Problem occurs

My setup

pwndbg> version
Gdb:      13.1
Python:   3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
Pwndbg:   2024.08.29 build: 64bd3fee
Capstone: 5.0.1280
Unicorn:  2.1.0
@peace-maker
Copy link
Contributor

The problem is with this code

current_output = function(*a, **kw)
if (
len(context_history[section_name]) == 0
or context_history[section_name][-1] != current_output
):
context_history[section_name].append(current_output)
selected_history_index = None

It checks if the current context section is already at the top of the history stack and adds it otherwise. This is run everytime the context is displayed even if no new event happened which could have changed the state. This is fine for other views like disasm, but when evaluating expressions in cwatch gdb changes the $39/$40 variable names making the output look like new data appeared.

The current approach of always rendering the newest context even while wanting to display a cached context from the history isn't ideal, especially for slow remote targets. I just don't know which events to hook to know if the context output might have changed. Just a prompt_hook doesn't help, since the data might not have been modified. Can all possible reasons the context output change be covered by events? memory_changed and register_changed seem obvious, but are those fired after continue/stepping too?

@disconnect3d
Copy link
Member

The memory_changed and register_changed events are only fired when you change the register from within GDB.

I am not sure what the serve_context_history, would have to dig it up, but maybe we should either revert the history or disable it by default and try to fix it with tests etc?

@disconnect3d
Copy link
Member

I mean, there are a few issues that occured recently regarding the context history feature. Or: any chance u could track down those issues @peace-maker ? :<

@peace-maker
Copy link
Contributor

Were there more than this issue?

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

Successfully merging a pull request may close this issue.

3 participants