What is the problem? (Here is where you provide a complete Traceback.)
The ofrak_ghidra backend package only supports analyzing one file with Ghidra at a time. However, in OFRAK, components (including Ghidra components) are allowed to run concurrently in some situations. It is possible for OFRAK to try to run multiple Ghidra analyses concurrently, which end up clobbering each other and causing a hard error.
The exact traceback logs will vary a bit depending on when the Ghidra processes are clobbered, but it should end with something like this:
File "/root/repos/rbs-ofrak/ofrak/disassemblers/ofrak_ghidra/ofrak_ghidra/components/ghidra_analyzer.py", line 109, in analyze
program_name = await self._do_ghidra_import(ghidra_project, full_fname)
File "/root/repos/rbs-ofrak/ofrak/disassemblers/ofrak_ghidra/ofrak_ghidra/components/ghidra_analyzer.py", line 154, in _do_ghidra_import
"Disconnected from Ghidra repository before file import succeeded!"
ofrak_ghidra.ghidra_model.GhidraComponentException: Disconnected from Ghidra repository before file import succeeded!
Please provide some information about your environment.
At minimum we would like the following information on your platform and Python environment:
Platform:
If running in one of the OFRAK Docker images, say which image it is (for example, redballoonsecurity/ofrak/ghidra).
If not running in an OFRAK Docker image, please provide the output of python3 -m platform.
Python environment: Please provide the output of python3 -m pip freeze.
This likely happens in any environment. For sure it occurs in the dev Docker image.
If you've discovered it, what is the root cause of the problem?
The ofrak_ghidra backend package only supports analyzing one file with Ghidra at a time. However, in OFRAK, components (including Ghidra components) are allowed to run concurrently in some situations. It is possible for OFRAK to try to run multiple Ghidra analyses concurrently, which end up clobbering each other and causing a hard error.
How often does the issue happen?
Consistent OFRAK starts Ghidra analyses concurrently. For example, unpack_recursively is one call that runs components in parallel. Recursively unpacking a filesystem that has multiple executables at the same level (e.g. in the same directory) will trigger this error as those executables will be unpacked concurrently with Ghidra.
What are the steps to reproduce the issue?
Ideally, give us a short script that reproduces the issue.
The follow script creates two ELFs in the same directory in a tar archive, then unpacks them recursively with Ghidra, replicating the error:
How would you implement this fix?
The ofrak_ghidra backend should ideally support analyzing multiple files, not clearing all existing analyses when a new file is added.
Are there any (reasonable) alternative approaches?
Alternatively, the OFRAK auto run infrastructure could be made more complex to handle categories of components that cannot be run in parallel. However this is more complex and leaves the ofrak_ghidra backend still with strict limitations.
What is the problem? (Here is where you provide a complete Traceback.) The
ofrak_ghidra
backend package only supports analyzing one file with Ghidra at a time. However, in OFRAK, components (including Ghidra components) are allowed to run concurrently in some situations. It is possible for OFRAK to try to run multiple Ghidra analyses concurrently, which end up clobbering each other and causing a hard error.The exact traceback logs will vary a bit depending on when the Ghidra processes are clobbered, but it should end with something like this:
Please provide some information about your environment. At minimum we would like the following information on your platform and Python environment:
redballoonsecurity/ofrak/ghidra
).python3 -m platform
.python3 -m pip freeze
.This likely happens in any environment. For sure it occurs in the
dev
Docker image.If you've discovered it, what is the root cause of the problem? The
ofrak_ghidra
backend package only supports analyzing one file with Ghidra at a time. However, in OFRAK, components (including Ghidra components) are allowed to run concurrently in some situations. It is possible for OFRAK to try to run multiple Ghidra analyses concurrently, which end up clobbering each other and causing a hard error.How often does the issue happen? Consistent OFRAK starts Ghidra analyses concurrently. For example,
unpack_recursively
is one call that runs components in parallel. Recursively unpacking a filesystem that has multiple executables at the same level (e.g. in the same directory) will trigger this error as those executables will be unpacked concurrently with Ghidra.What are the steps to reproduce the issue? Ideally, give us a short script that reproduces the issue.
The follow script creates two ELFs in the same directory in a tar archive, then unpacks them recursively with Ghidra, replicating the error:
How would you implement this fix? The
ofrak_ghidra
backend should ideally support analyzing multiple files, not clearing all existing analyses when a new file is added.Are there any (reasonable) alternative approaches? Alternatively, the OFRAK auto run infrastructure could be made more complex to handle categories of components that cannot be run in parallel. However this is more complex and leaves the
ofrak_ghidra
backend still with strict limitations.Are you interested in implementing it yourself?