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

Timeout value is not configurable in ghidra_bridge_server.py #55

Open
mshockwave opened this issue Jan 28, 2021 · 1 comment
Open

Timeout value is not configurable in ghidra_bridge_server.py #55

mshockwave opened this issue Jan 28, 2021 · 1 comment

Comments

@mshockwave
Copy link

mshockwave commented Jan 28, 2021

Hi,

This is actually more like a follow up of #48 : Currently we can configure the timeout value using either response_timeout parameter for GhidraBridge, or timeout_override parameter for remote_eval.

However, when I set both values to -1 on client side (which should disable any timeout threshold) , a BridgeTimeoutException exception was still raised when I try to run a pretty large function using remote_eval. After some simple debugging, I found that the exception was actually raised from ghidra_bridge_server.py. More specific, it's the timeout value setup when constructing a jfx_bridge.BridgeServer object (line). And apparently this timeout value is fixed when using ghidra_bridge_server.py with analyzeHeadless.

I'm wondering if we can just set the timeout value here to -1 and let the client decide which timeout to use (using the existing response_time and timeout_override)? Or add a command line flag for ghidra_bridge_server.py to configure the timeout?

@mshockwave mshockwave changed the title Timeout values are not configurable for both ghidra_bridge_server.py and ghidra_bridge_server_background.py Timeout value is not configurable in ghidra_bridge_server.py Jan 28, 2021
@justfoxing
Copy link
Owner

Sorry, got distracted and didn't ever comment on this. This is particularly risky, because the server is pushing callbacks to the client fairly regularly in interactive mode (e.g., every time you scroll), from the GUI thread - if the client disconnects and there's no timeout, the whole Ghidra environment would lock up.

Ghidra's GUI script environment doesn't provide a great way to take arguments.

Taking the values from the connected client is probably the best idea, and the response_timeout is contained in the BridgeConn associated 1:1 with each client, so multiple clients shouldn't affect each other. I just need to find some time to write the code and tests.

As a quick hacky fix for this:

def set_remote_bridge_timeout(connected_bridge, new_timeout):
    """ Gross hack to set the response timeout on the remote bridge end. """
    # get the remote bridge conn, by getting the frame inside local_eval, then the frame that called that (f_back), then the locals of the caller, which include the BridgeConn as self
    bc = connected_bridge.remote_eval("__import__('inspect').currentframe().f_back.f_locals['self']")
    bc.response_timeout = new_timeout

b.set_remote_bridge_timeout(b, -1)

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

No branches or pull requests

2 participants