das-labor / panopticon

A libre cross-platform disassembler.
https://panopticon.re
GNU General Public License v3.0
1.43k stars 78 forks source link

Mach Fat binary needs a file picker/popup #281

Open m4b opened 7 years ago

m4b commented 7 years ago

Currently, can't load a mach fat binary (because which one do we load?), so we need some kind of picker/selector, which presents the user a list of the architectures, which the user selects, which then loads that binary.

This seems mostly a QML issue (which I'm not good at, hoping someone will grab this issue).

So to sketch out a basic approach (which I haven't thought too consciously about), for starters, once a mach fat is selected (which should sent the mach-fat request kind), can iterate through arches with something like:

            Hint::MachFat(_) => {
                let multi = mach::MultiArch::new(&bytes)?;
                let arches = multi.arches()?;

And then display the arches as appropriate to the user (need a new UI selector or something here)

The user will then select the architecture (which can simply be an index), and the mach-o binary can then be extracted and loaded via:

// this is the ith arch
let bytes = arch.slice(bytes)?;
loader::load_mach(bytes, 0, NameOfBinary)

which gets routed appropriately somehow ;)

Or something like that; there are several possible avenues here

flanfly commented 7 years ago

Why not load all of them? A Project can contain multiple Program instances.

m4b commented 7 years ago

Hmmm yea that's probably the easiest. Perhaps we should make the disassembly step after loading lazy though as loading several architectures eagerly probably doesn't make a lot of sense. Perhaps disassembler fires when a program element first receives focus ?

flanfly commented 7 years ago

Well, for there is no PPC disassembler anyway. Starting with x86 is the best we can do for now.

m4b commented 7 years ago

Yea, I was specifically worried about the i386 and x86_64 fat binaries, which are usually the system libraries like libSystem_B.dylib, et. al. Seems a waste to load the i386 and x86_64 eagerly, especially for larger binaries.