You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During analysis when using analyzeHeadless libraries need to be copied into a specified folder using -loader-libraryDestinationFolder MY_LIBRARY_FOLDER in order for Ghidra to look for these libraries when a binary that is being analyzed imports it. Most of the time when importing a filesystem the libraries are in mulitiple different folders (/lib, /usr/lib etc). Instead of preserving the directory structure of the imported filesystem Ghidra instead copies the libraries to the destination folder passed in with the option -loader-libraryDestinationFolder.
This creates a disconnect from the libraries in the filesystem and the libraries Ghidra has imported into other binaries when they were being analyzed. A better solution would be to preserve the structure of the imported filesystem and find the libraries from there instead of copying the libraries to another folder.
Following on from this, another issue presents itself. Often, a binary will import a shared object such as /lib/libc.so.6 which is actually a symlink in the filesystem to something like /lib/libc-2.17.so. Since Ghidra doesn't import/process symlinks it breaks the analysis of a binary that depends on the symlinked binary (Ghidra fails to open the real shared object that is pointed to by the symlink)
During analysis when using
analyzeHeadless
libraries need to be copied into a specified folder using-loader-libraryDestinationFolder MY_LIBRARY_FOLDER
in order for Ghidra to look for these libraries when a binary that is being analyzed imports it. Most of the time when importing a filesystem the libraries are in mulitiple different folders (/lib, /usr/lib etc
). Instead of preserving the directory structure of the imported filesystem Ghidra instead copies the libraries to the destination folder passed in with the option-loader-libraryDestinationFolder
.This creates a disconnect from the libraries in the filesystem and the libraries Ghidra has imported into other binaries when they were being analyzed. A better solution would be to preserve the structure of the imported filesystem and find the libraries from there instead of copying the libraries to another folder.
Following on from this, another issue presents itself. Often, a binary will import a shared object such as
/lib/libc.so.6
which is actually a symlink in the filesystem to something like/lib/libc-2.17.so
. Since Ghidra doesn't import/process symlinks it breaks the analysis of a binary that depends on the symlinked binary (Ghidra fails to open the real shared object that is pointed to by the symlink)Some further info here: #6955
The text was updated successfully, but these errors were encountered: