Summary
It would be useful if the Container Browser supported batch importing an entire filesystem/container tree into a Binary Ninja project, preserving the original paths from the container.
A comparable workflow exists in Ghidra, where a filesystem or archive can be imported into a project as a hierarchy of files. This makes it much easier to work with firmware images, extracted filesystems, archives, bundles, and other container-like inputs that may contain many relevant binaries and supporting files.
Motivation
The current Container Browser is useful for inspecting and opening individual entries from a container, but it does not appear to provide a way to import the full contents of a container into a project in one operation.
For firmware and filesystem-style inputs, the path structure is often important context. For example:
/bin/busybox
/usr/lib/libfoo.so
/etc/init.d/service
/sbin/daemon
/opt/vendor/plugin.so
Preserving these paths inside the project would make it easier to organize related binaries, understand runtime layout, identify dependencies, and navigate between related files.
Requested behavior
From the Container Browser, provide an option such as:
- Import All to Project
- Import Selected Directory to Project
- Import Selected Entries to Project
The import should preserve the original container paths in the Binary Ninja project, ideally using the container entry path as the project path/name.
For example, importing a filesystem image or archive containing:
/bin/app
/lib/libfoo.so
/etc/config.json
would create project entries resembling:
/bin/app
/lib/libfoo.so
/etc/config.json
rather than flattening everything into a single directory or requiring each file to be opened manually.
Possible options
It may also be useful to support import options such as:
- Import only files recognized as loadable binaries
- Import all files
- Preserve directory hierarchy
- Skip duplicate paths or prompt for conflict resolution
- Apply existing container transform behavior recursively
- Allow importing only the selected subtree from the Container Browser
Use cases
This would be especially helpful for:
- Firmware images
- Root filesystems
- Archives containing many binaries
- Universal/container formats with nested content
- Vendor update packages
- Malware bundles or unpacked samples
- Projects where the filesystem layout is part of the analysis context
Expected result
A user should be able to open a container, review its contents in the Container Browser, and import the full tree or a selected subtree into a Binary Ninja project while preserving the original paths.
Current workaround
The current workflow appears to require manually opening/importing individual files from the Container Browser, which does not scale well for large firmware images or filesystem containers.
Summary
It would be useful if the Container Browser supported batch importing an entire filesystem/container tree into a Binary Ninja project, preserving the original paths from the container.
A comparable workflow exists in Ghidra, where a filesystem or archive can be imported into a project as a hierarchy of files. This makes it much easier to work with firmware images, extracted filesystems, archives, bundles, and other container-like inputs that may contain many relevant binaries and supporting files.
Motivation
The current Container Browser is useful for inspecting and opening individual entries from a container, but it does not appear to provide a way to import the full contents of a container into a project in one operation.
For firmware and filesystem-style inputs, the path structure is often important context. For example:
/bin/busybox/usr/lib/libfoo.so/etc/init.d/service/sbin/daemon/opt/vendor/plugin.soPreserving these paths inside the project would make it easier to organize related binaries, understand runtime layout, identify dependencies, and navigate between related files.
Requested behavior
From the Container Browser, provide an option such as:
The import should preserve the original container paths in the Binary Ninja project, ideally using the container entry path as the project path/name.
For example, importing a filesystem image or archive containing:
would create project entries resembling:
rather than flattening everything into a single directory or requiring each file to be opened manually.
Possible options
It may also be useful to support import options such as:
Use cases
This would be especially helpful for:
Expected result
A user should be able to open a container, review its contents in the Container Browser, and import the full tree or a selected subtree into a Binary Ninja project while preserving the original paths.
Current workaround
The current workflow appears to require manually opening/importing individual files from the Container Browser, which does not scale well for large firmware images or filesystem containers.