Convert PIE ELF binary into No-PIE

Question

Is it possible changing few bytes for converting an elf binary from PIE to No-PIE (ELF)? I know that in the header if e_type is: - 3 then the program is PIE - 2 then the program is No-PIE

So I tried to change that byte and in fact readelf -h shows me:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x630
  Start of program headers:          64 (bytes into file)
  Start of section headers:          6576 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Then I changed the e_entry from 0x630 to 0x400630.

readelf -h output:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x400630
  Start of program headers:          64 (bytes into file)
  Start of section headers:          6576 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

However if I try to launch the program it crashes.

$ strace ./elf-patched.exe 
execve("./elf-patched.exe", ["./elf-patched.exe"], 0x7ffe0c2b88c0 /* 66 vars */) = -1 EPERM (Operation not permitted)
+++ killed by SIGSEGV +++
[1]    7239 segmentation fault (core dumped)  strace ./elf-patched.exe

What other bytes should I change (If it's possible with few modifications) ?

Answer 1

It is not possible with few modifications.

https://www2.cs.arizona.edu/~debray/Publications/disasm.pdf

2.2 Position-Independent Code

Many compilers can be instructed to emit code that does not rely on being bound to any particular position in the program’s address space. These code sequences are often referred to as position-independent code(PIC). In particular, PIC sequences do not contain any relocatable addresses embedded in the instructions. This property enables the code to work regardless of its memory location at runtime. Furthermore, PIC does not need to be patched by the loader, enabling it to be mapped as read-only data—which is useful for shared code such as dynamically linked libraries [14]. When a compiler is emitting position-independent code it typically creates jump tables that are also position-independent. These tables are usually embedded in the text segment of the executable and consist of a sequence of offsets rather than virtual addresses. A jump that uses the offset table first loads a nearby address,¹ then uses this to index into the table and retrieve an offset. The offset is added to the address that was previously loaded and then used in an indirect jump to reach the desired destination. The problems posed by position-independent jump tables are three-fold: (i) the offset tables, which are really no different than data, appear in the instruction stream; (ii) the code sequences that perform the indirect jumps are often complicated and may not adhere to a single pattern that is easily recognizable; and (iii) it is entirely possible that an offset table does not contain relocation entries. Taken together,these properties make the task of disassembling PIC sequences involving jump tables more difficult than standard code.