Wrong start address for elf64 ?

[ElCapor]

Hi, I tried loading this sample called "cook"

cook.zip

This is the log when i use the following code :

fn main() {

    let _ = Builder::new().filter_level(log::LevelFilter::Info).init();
    let mut emu = emu64();
    emu.set_verbose(2);

    emu.set_maps_folder("../mwemu/maps/maps64");
    emu.init(false, false);
    emu.load_code("cook");
    emu.enable_console();
    emu.spawn_console();
    //emu.run(None).unwrap();

}

Log:

[2025-08-28T05:29:17Z INFO  libmwemu::elf::elf64] lib: libc.so.6
[2025-08-28T05:29:17Z INFO  libmwemu::emu::loaders] dynamic elf64 detected.
[2025-08-28T05:29:17Z INFO  libmwemu::elf::elf64] section  size is zero, skipping.
relative entry point: 0x1100  fixed: 0x555555556200

And so i press "n" in console to continue next instruction but i get this output :

[2025-08-28T05:29:20Z INFO  hexecution] TRACE: 0x555555556200 (bad) (size=2)
[2025-08-28T05:29:20Z INFO  libmwemu::engine] 1 Unimplemented instruction: INVALID

I disassemble that address with "d" :

=>d
address=>0x555555556200
[2025-08-28T05:32:00Z INFO  libmwemu::console] 0x555555556200: (bad)
    0x555555556202: jne   short 0000555555556210h
    0x555555556204: (bad)
    0x555555556206: add   [rax],al
    0x555555556208: sbb   al,0
    0x55555555620a: add   [rax],al
    0x55555555620c: pushfq
    0x55555555620d: add   [rax],al
    0x55555555620f: add   [rsi-0Fh],cl

This doesn't match with the entry point in ida pro :

.text:0000000000001100  endbr64
.text:0000000000001104  xor     ebp, ebp
.text:0000000000001106  mov     r9, rdx         ; rtld_fini
.text:0000000000001109 pop     rsi             ; argc
.text:000000000000110A mov     rdx, rsp        ; ubp_av
.text:000000000000110D and     rsp, 0FFFFFFFFFFFFFFF0h
etc...

So then I thought : "what if i disassembled the start of the code map ?"

And bingo , it was there :

=> m
[2025-08-28T05:35:17Z INFO  libmwemu::maps] code                0x555555555100 - 0x555555555f85

=> d
=> address
=> 0x555555555100
[2025-08-28T05:36:12Z INFO  libmwemu::console] 0x555555555100: endbr64
    0x555555555104: xor   ebp,ebp
    0x555555555106: mov   r9,rdx
    0x555555555109: pop   rsi
    0x55555555510a: mov   rdx,rsp
    0x55555555510d: and   rsp,0FFFFFFFFFFFFFFF0h
    0x555555555111: push  rax
    0x555555555112: push  rsp
    0x555555555113: xor   r8d,r8d

SO what happened ???

loaders.rs line 389 here THIS CODE

you do self.regs_mut().rip = elf64.elf_hdr.e_entry + text_addr; , the problem here is it sounds like e_entry is offset of entry point from the base of the elf, not the base of .text segement, so instead of adding 0x1100 to elf base to get .text start aka 0x555555555100, we add e_entry to 0x555555555100 , which .text start to get 0x555555556200, which is wrong start point.

Is my executable an edge case and this is intended behaviour, or is this a mistake in the programming of the library ?

Thanks in advance

[sha0coder]

Hello ElCapor,

dyn linking is not very supported, it can emulate libc but not ld-linux that is necesary on dyn linked to create .got automatically and .plt

I fixed the load of dynamic linked samples, but .plt doesn't exist yet and will crash in first call:

[sha0coder]

Is my executable an edge case and this is intended behaviour, or is this a mistake in the programming of the library ?

no, /bin/ls had same issue.

btw if you have radare2 installed you can call it from mwemu:

[ElCapor]

Okay thank you very much for taking your time and checking it out. And when you mean emulate ld-linux, it's emulating it's behaviour , or getting the actual binary to run before the program ?