Batch import filesystem contents from Container Browser while preserving paths

Start with the Container Browser and its current workflow for opening or importing individual entries; the payload names no implementation files or tests. Define the project-path behavior and scope for full-tree, directory, and selected-entry imports, then verify that a representative container can be imported while preserving its paths.

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.