Problem Description

I am currently working on a project involving shared library reconstruction (on a x64, Linux virtual machine), specifically targeting the musl-libc (verion: 1.1.15).

After reconstructing the musl-libc library, the new library fails to execute (Note that musl-libc itself is also a binary executable).

Specifically, when I run the original musl-libc with:

./libc.so

I expect the following output:

musl libc (x86_64)
Version 1.1.15
Dynamic Program Loader
Usage: ./libc.so [options] [--] pathname [args]

However, running my reconstructed version results in:

bash: ./libc.so.rewritten: cannot execute binary file: Exec format error

Initial Analysis

My goal is to diagnose the problem that causes execution failure. I’ve checked the readelf -aoutput of my reconstructed library and everything looks just “fine”. So further analysis on the loading process is necessary to locate the problem.

As of now, I understand that a binary executable typically contains an .interp section to specify the path of the dynamic loader. However, musl-libc does not come with an .interp section. Here’s the output of readelf -lW ./libc.so for reference:

Elf file type is DYN (Shared object file)
Entry point 0x5d9c4
There are 7 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000188 0x000188 R   0x8
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x08eda4 0x08eda4 R E 0x1000
  LOAD           0x08f980 0x0000000000090980 0x0000000000090980 0x000a70 0x003954 RW  0x1000
  DYNAMIC        0x08fe18 0x0000000000090e18 0x0000000000090e18 0x000130 0x000130 RW  0x8
  GNU_EH_FRAME   0x08ed80 0x000000000008ed80 0x000000000008ed80 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0
  GNU_RELRO      0x08f980 0x0000000000090980 0x0000000000090980 0x000680 0x000680 RW  0x10
...

Questions

• Dynamic Loader Issue: Could the issue be related to the dynamic loader? If so, which dynamic loader is used to load musl-libc? Does it use the glibc dynamic loader or the musl-libc dynamic loader (i.e., musl-libc itself)?
• OS Loading Mechanism: Alternatively, does the OS load musl-libc directly via execve? If this is the case, would adding logs in a specific kernel function (responsible for loading ELF binaries) help in diagnosing the issue?

Any advice or suggestions would be greatly appreciated. Thank you in advance!