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
Fat Mach-O files are a collection of binaries in one file, separated by architecture. Some of the tools can read the containers and analyze them, while others fall over, even if they could analyze the inner Mach-O. Similar happens with archive libraries (.a). It would be nice to have some way to "thin" the files for the decompilers with less capable loaders.
The text was updated successfully, but these errors were encountered:
Reko maintainer here. The Reko decompiler has support for "drilling into" archives and disk images. I implemented a custom URI scheme to cope with the issue of being able to name nested paths within archives. The URI scheme is described in the comments in this file: https://github.com/uxmal/reko/blob/master/src/Core/Loading/ImageLocation.cs
This is a WIP and I'm open to suggestions for improvements on the syntax etc.
Fat Mach-O files are a collection of binaries in one file, separated by architecture. Some of the tools can read the containers and analyze them, while others fall over, even if they could analyze the inner Mach-O. Similar happens with archive libraries (.a). It would be nice to have some way to "thin" the files for the decompilers with less capable loaders.
The text was updated successfully, but these errors were encountered: