Vector35
Container formats support
Handle files which have embedded files. Allow users to select the file they would like to edit/analyze.
Does this also cover things such as jar files (zips) and similar as well?
Sorry just to be clear, will this support Ghidra style multiple binaries in a single project, with references between them etc?
We're actually working on a better laid out plan with specific features and common language for describing several sets of (potentially) related things. One being nested formats, another being the ability to have related binaries in the same memory address space, and another being the ability to link/click between related binaries even if not the same address space (but also, when they are!). It's gonna take us a bit more time to polish off the plan, but we'll update this ticket when we do.
We'll either make new tickets or adapt this one to include the set of features ad potentially a bit more concrete of a timeline than the current ones.
As of 4.0 'Project Support' #226 is complete. This issue tracks handling of container formats. .zip, .ar, .jar, .lib, perhaps this has relevance to #290 and MH_FILESET. We don't know yet as we've not fully designed the feature.
After extended discussion today, we are moving forward with this specifically for containers of linked files (goal is to get DSC, kernel cache, etc) and putting aside the desire for general purpose archive files (like .zip, .ar, etc) in a first-party implementation. APIs and details probably won't exclude them, but we don't see a need to handle formats that can be easily extracted and don't need richer integration.
As the main impetus for this feature was to get Dyld Shared Cache and MH_FILESET support, and we've been able to achieve this without container support, we're deprioritizing this feature for now.
For those looking for more information on this feature, see: https://dev-docs.binary.ninja/dev/containertransforms.html