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

b.bridge.remote_shutdown() starting server of different programs #51

Closed
TylerKann opened this issue Aug 6, 2020 · 5 comments
Closed

Comments

@TylerKann
Copy link

whenever i have b.bridge.remote_shutdown() it always ends the headless server of this current program, but then instantly just launches headless of another program (sometimes the exact same program, sometimes random). It is really annoying and usually is hard to truly end. Is there any way to fix this problem

@justfoxing
Copy link
Owner

Hi, Tyler, I'm unable to reproduce this problem based on your description. I'll note that ghidra_bridge has no control over the headless analysis restarting - my guess would be that the most likely issue is something to do with the command you're using to run the analyzeHeadless script.

If you can provide the commands you're using to run analyzeHeadless and the bridge, I can attempt to reproduce the problem to see if it is in fact related to ghidra_bridge.

@TylerKann
Copy link
Author

ghidra_9.0.1/support/analyzeHeadless ./ headlessRepo -import ./ lebiniou -scriptPath /ghidra_scripts -postscript ghidra_bridge_server.py &

libinou is my binary name
I dont really understand the 'project' part, so i just made a folder called headlessRepo, so that may be the issue

@TylerKann
Copy link
Author

@justfoxing On a side note, is there anyway i can integrate that command above into a shell script? Something like
ghidra_9.0.1/support/analyzeHeadless ./ headlessRepo -import ./ lebiniou -scriptPath /ghidra_scripts -postscript ghidra_bridge_server.py &
&& python useBridge.py $1
&& python endBridge.py
Thats what i have but it isnt working too well. Any thoughts on how to improve that?

@justfoxing
Copy link
Owner

Yeah, this isn't a ghidra_bridge problem, your command as written is incorrect. The problem is with this part: -import ./ lebiniou. Note that you have a space between ./ and lebiniou.

If you look at the documentation for analyzeHeadless (as mentioned in the response to your previous issue), you will see that -import can take multiple arguments to import, and that these can be either files or directories. If you import a directory, it will attempt to import every file it finds in that directory.

Because you have -import ./ lebiniou instead of -import ./lebiniou, you're telling analyzeHeadless to import everything in ./ as well as ./lebiniou a second time. The ghidra_bridge_server gets run for every file that's imported, so when you send shutdown, it's stopping and analyzeHeadless will import the next file and rerun ghidra_bridge_server on it, which is the issue you're seeing.

analyzeHeadless is complex - I really recommend you take the time to read the documentation and play around with it without ghidra_bridge in the mix to understand how it works. As always, hit up the ghidra project for support with it.

@justfoxing
Copy link
Owner

WRT your second question, here's the relevant lines in the automated test system for this project:

/opt/ghidra/support/analyzeHeadless /tmp TestProject -import /bin/bash -noanalysis -scriptPath /tmp/ghidra_bridge/test_server -preScript ghidra_bridge_server.py >/tmp/script.log 2>/tmp/script.err & # Run the ghidra_bridge_server in a headless ghidra - we use non-background server, otherwise the script would exit before we could test
( tail -f /tmp/script.err & ) | grep -q "_bridge.bridge:serving!" # pause until we see the ghidra_bridge_server start logging messages
python3 -c "import ghidra_bridge; b = ghidra_bridge.GhidraBridge(namespace=globals()); print(getState().getCurrentAddress())" # run a quick test for ghidra_bridge - we do this before nose, because the last nose test shuts down the bridge

The trickiest part is waiting until the bridge server has been started before attempting to connect to it, which is what the tail/grep combo provides.

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