adds a mach 32/64 bit loader

[m4b]

• updates to goblin 0.0.9 (which gets panopticon a PE64 bit loader for free, with no changes)
• adds a mach non-fat loader, for 32 and 64 bit x86 binaries.
• adds mach imports to import table, for whenever this gets used

FUTURE TODO: will need a popup selector choosing which architecture to load if a fat binary is selected, and then use https://docs.rs/goblin/0.0.9/goblin/mach/struct.MultiArch.html#method.get to extract the binary (and then load as normal in loader::load (except we'll have to export the load_mach function, or add a load_bytes api endpoint)

ref #268

[m4b]

uhhhh, i cannot repro these build errors on rust 1.16 stable, but can on 1.15.1, this is extraordinarily annoying:

error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
  --> C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\goblin-0.0.9\src\mach\exports.rs:94:41
   |
94 |             let lib_symbol_name = bytes.pread::<&str>(offset)?;
   |                                         ^^^^^
   |
note: first, the lifetime cannot outlive the lifetime 'a as defined on the body at 79:117...
  --> C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\goblin-0.0.9\src\mach\exports.rs:79:118
   |

again, above compiles fine on 1.16; i don't see anything sticking out in release notes. This is lame

[m4b]

Fat elf ? Please tell me that was a typo and you meant fat Mach - o? I don't want to support fat elf...

So I have this old Mach o binary with stupid symbol names but it covers various components of the Mach binary system. I can commit that if you like though I think in the future we should have: libfoo and bar, a library with various permutations of symbol visibility and bar which uses foo, and standard libs, all with same c source code but compiled into different formats.

As for fat is it allowed to include libSystem_B.dylib in panopticon or will there be license issues ?

[flanfly]

fat elf

My bad.

[flanfly]

libSystem_B.dylib in panopticon or will there be license issues ?

Depends on the license. You definitely need the add a line to AUTHORS that states who has the copyright to it.

[flanfly]

We use stable on the CI now

[coveralls]

Coverage decreased (-0.3%) to 59.878% when pulling 02e05a9cbdf7f9f63e8629dda8117e4d5ca65702 on m4b:m4b/mach_loader into 762f86d4a1f44b92d2fd6ff52ae9861130c13c7a on das-labor:master.

[coveralls]

Coverage increased (+0.2%) to 60.41% when pulling fb9e9a358b665e1665ec367446bbc3151123627d on m4b:m4b/mach_loader into 762f86d4a1f44b92d2fd6ff52ae9861130c13c7a on das-labor:master.

[m4b]

P.S. mach exports don't distinguish between function/data, which is cool. so, for example libbeef.dylib has several data object exports which just get disassembled as usual as garbage; i'm wondering if this is the cause of certain loops

[m4b]

I don't have a mach fat multi architecture binary on hand besides libSystem.B.dylib which I don't know if I can distribute (I don't know what the license for it is); is it ok to proceed without the fat (which we can't load anyway)?

[flanfly]

Amazing work, thanks a lot.