How can I open inside shell commands, binaries, and analyze their code?

Question

Just out of curiosity I would like to examine what is inside these commands. Like mkdir or adb command or other things inside /bin or /sbin folder. I know they are binaries so, i searched some answers like below. I found xxd -b <filename> or `strings . But i want more clearer view, is it possible. And is there a way we can know in which language they are written? For example for mac commands, what language they are written?

How to view files in binary from bash?

Answer 1

Practical answer: most binaries are written in 'C', some are written in 'C++'. See below on logic to tell which one. Note that I'm not macos expert - I believe Linux tools will work the same for macos

Most of the files in /bin and /usr/bin are stripped binaries (the minority are symbolic links which create "aliases", or small scripts that implement existing commands, usually using other binaries).

The fact the the binary is stripped means that a debugger (gdb, or other tools like ltrace, etc.) to see function names, variable names, etc. (do man strip to see what is removed). One of the items that can NOT be 'stripped' is the list of shared libraries.

Given this information, possible to get some clues from the list of shared libraries. C++ programs will usually link with the 'standard C++' shared library (libstdc++.so.N, where N is the version, currently at 6). Most other languages have their own run-time shared library that will be linked. Most 'C' programs will link with the standard C runtime (/lib.c.so.N).

Bottom line: consider the following process:

• Do file -L /bin/sh (or any other binary):
• If output contain 'script' in the output, the program is implemetned a s script
• If output indicates a binary (ELF shared object, or similar):
• Run 'ldd /bin/sh`
• If output contain 'libstdc++.so' - code contain SOME c++ - most like C++ source
• If output contain 'libc.so.' - program contain SOME c - most like C program

owner@vm1:~/Projects/SO/ff1$ file /bin/bash
/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=452da38d6212b692cd80eb0dd1c99cf853da31ae, stripped
owner@vm1:~/Projects/SO/ff1$ ldd /bin/bash
    linux-vdso.so.1 (0x00007ffcb87fe000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f5e7cd8e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5e7cb8a000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5e7c799000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5e7d2d2000)



wner@vm1:~/Projects/SO/ff1$ file /usr/bin/zlib-flate 
/usr/bin/zlib-flate: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=bbc1bc3fbbb71c7ae3cf9ef9f2876098df3fd752, stripped
owner@vm1:~/Projects/SO/ff1$ ldd !$
ldd /usr/bin/zlib-flate
    linux-vdso.so.1 (0x00007fffeb3be000)
    libqpdf.so.21 => /usr/lib/x86_64-linux-gnu/libqpdf.so.21 (0x00007f2f8ee45000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2f8eabc000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2f8e8a4000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f8e4b3000)
    libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f2f8e24b000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2f8e02e000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2f8dc90000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2f8f313000)

Note: * Technically, possible to "trick" this logic with static linking, but most (all) binaries will use dynamic linking.