How to inspect a MacOS executable file (Mach-O)?

Question

How to see some basic information about a MacOS binary file, specifically what was used to build it, which frameworks it is linked against and what system calls it is using?

I tried nm and otool -L but their output is only partially useful.

For example, what would indicate that a binary was built with xcode or golang compiler?

^{NB. I am not interested in reverse engineering macos binaries. I just want to know better what is running on my system using just the tools that are already included OOTB.}

Answer 1

The compiler used is not a trivial question. Some compilers embed information about themselves, and you sometimes find that by running strings, but it's not guaranteed. That said, the answer on Mac is almost always clang, so it's not usually that hard to get the basics. As an example:

strings iTunes | grep clang
COMPILER=clang-9.0.0

But that's just luck (and might not even be accurate).

IDA Pro does a good job at this, and is the gold standard for reverse engineering work. If this kind of thing is important to you, then IDA Pro is the tool. It's expensive.

To get a list of frameworks that it links at runtime, otool -L is the tool you want. I don't understand what you mean by "isn't very readable." It just prints out all the frameworks, one per line. It's hard to imagine anything more readable than that. What are you looking for here?

otool -L will not tell you what static libraries were used, so "which frameworks it was built against" may be too broad to answer. You can generally find the symbols for well-known static libraries (OpenSSL for instance), but there is no easy way to know precisely what was included in a binary, particularly if debugging information is stripped. (If there's debugging information, then the filepaths will tend to be available, which can tell you a lot more about how it was built.)

There is no easy static way to get a list of all system calls, since those may be buried in libraries. nm is generally what you want, though. It includes a lot of things that aren't "system" calls, though, since it's going to include every symbol linked from external sources (you probably want something like nm -ju). Again, I'm not sure what you mean by "isn't very readable." It's one symbol per line.

In order to get the list of system calls at runtime, run the application with dtruss. It'll output every system call as it's made, and will focus on actual "system" calls (i.e. syscall).