CYT 341 Add basic Mach-O file info extractor

[Czatar]

Summary

If merged this pull request will add an info extractor for Mach-O files

Proposed changes

For now, all "MACHO" file types are covered, but I haven't looked into splitting these into cases (line 17).
Out of the ones I've looked at, the LIEF library looks more promising than macholib, macholibre, machofile, and kaitaistruct because of the ability to easily iterate through the various binaries in the FAT file.

[Czatar]

Sample output so far:

{
      "OS": "MacOS",
      "numBinaries": 1,
      "binaries": [
        {
          "format": "MACHO",
          "cpuType": "x86_64",
          "cpuSubtype": 2147483651,
          "fileType": "EXECUTE",
          "flags": [
            "TWOLEVEL",
            "NOUNDEFS",
            "DYLDLINK",
            "PIE"
          ],
          "numCommands": 16
         }
      ]
}

Haven't tested on those that have multiple binaries, but it's set up to output a list of binaries in the "binaries" key

[Czatar]

I've been using https://github.com/JonathanSalwan/binary-samples to test. Let me know if there are any more good mach-o files to run this on.

[Czatar]

out.txt
This is a sample output file after testing it on the 7 Mach-O files in here and main_sha256 from here.

[nightlark]

Can you also generate an SBOM from running it in the files from this HELICS archive? https://github.com/GMLC-TDC/HELICS/releases/download/v3.5.2/Helics-3.5.2-macOS-universal2.zip

[Czatar]

Can you also generate an SBOM from running it in the files from this HELICS archive? https://github.com/GMLC-TDC/HELICS/releases/download/v3.5.2/Helics-3.5.2-macOS-universal2.zip

output.zip
The process took about 3 minutes and the output file is almost 23 MB large. The longest part was waiting for LIEF to load the files into Binary objects.

I haven't tested much with large files and entire projects. Is this roughly how long it should take? From the output, the bindings and exports are by far the largest sections. Should including that be a user configurable setting as well or keep it in?

[nightlark]

Looking at the output, I think the bindings and exports are definitely things that should be a user configurable setting that is off by default -- my take from looking at them is that the addresses alone aren't very useful without knowing what symbol they resolve to.

For the Linux and Windows HELICS releases, Surfactant takes less than a second to run -- macOS universal binaries are basically two binaries in one so I'd expect it to take longer, but probably still less than 2 seconds.

---

I did notice issues in the lief repository about performance regressions. As a test, I ran pip install lief==0.13.2 so I wouldn't get the latest 0.14 release -- with bindings and exports it took 10 seconds, without bindings and exports it took 1.6 seconds. With the 0.14.1 release of lief, the same bindings + exports SBOM took 2 minutes, 50 seconds... close to 20x slower.

I think the quick option is to pin lief to version 0.13.2, and replace use of __name__ attributes with name, though it should probably be made an optional dependency because lief doesn't provide a source distribution, and the binary distributions are specific to specific Python versions (+ architectures/OSes). I get that the author is trying to minimize issues about lief not working on unsupported systems, but in doing so created some (IMO) major issues:

• new versions of Python (e.g. 3.13) won't work until they upload new binary distributions built for that new version (and old lief versions will probably never get update wheels)
• users are forced to upgrade their Python version to use newer lief versions when lief drops support for an older Python version (e.g. 3.8)
• if the lief maintainer(s) ever become inactive for an extended length of time, the lief Python bindings will gradually stop working as users upgrade to new Python versions, but lief doesn't release new binary distributions (there was a ~1 year gap in development around 2020, and it looks like there may only be a single maintainer that can publish updates)