Segmentation fault upon running wsh

[endrazine]

Segmentation fault upon running wsh

[rofl0r]

guys, please use markdown syntax for code snippets when pasting patches so it doesnt get misinterpreted/misrendered.
you can do so by putting 3 apostrophes on an empty line to start a block, and another 3 to end it. thanks.

i'm refering to this apostrophe : `

[diorcety]

@@ -828,6 +830,10 @@ int scan_sections(char *fname, unsigned long int baseaddr)

        fd = open(fname, O_RDONLY);
        data = mmap(NULL, lseek(fd, 0, SEEK_END), PROT_READ, MAP_SHARED, fd, 0);
+       if (data == MAP_FAILED) {
+               fprintf(stderr, "Can't map %s\n", fname);
+               return 0;
+       }
        elf = (Elf_Ehdr *) data;

 //     printf("Entry: %llx\t%s\n", elf->e_entry + baseaddr, fname);

[endrazine]

Hi ovIA, good catch, thanks for the patch :)

[hexhexD]

Hi endrazine, I applied the patch but the error remains. I have tried wsh on other executables but still no luck. I don't think I'm able to fix this problem on my machine since I don't really understand the cause of the problem. I'm wondering if there's any solution to the issue I'm having.

[endrazine]

Hi ovIA, I have a larger commit to push : I refactored all the loading process which was a bit doggy. Let me push this code tonight for you to test, hopefully it'll resolve this use case too :)
Thanks for testing WCC.

[endrazine]

Hi ovIA, this commit ef6e1b0#diff-25d902c24283ab8cfbac54dfa101ad31 should fix the problem. Cheers.

[hexhexD]

Hi endrazine, thank you for taking the time to reply to me. I got a different error message with the new commit.

[SIGSEGV] Read 000200000001 (address not mapped to object)
7f3c12812810 /usr/lib/libc.so.6(+0x120810)
000042007315 wsh()
000042010ac7 wsh(scan_syms+0x159)
00004201117e wsh(parse_dyn+0x2f4)
00004201126d wsh(parse_link_map_dyn+0xec)
00004201889f wsh(wsh_run+0x7e)
00004201db9f wsh(main+0x6c)
7f3c12712291 /usr/lib/libc.so.6(__libc_start_main+0xf1)

[hexhexD]

Hi Diorcet,

I applied the patch and there was no error while I was running wsh, but I
couldn't call any function in the executable that I passed to wsh. And when
i run shdrs() and entrypoints() it says : Total: 0 sections and Total: 0
entry points.

On Thu, Sep 1, 2016 at 3:21 AM Diorcet Yann [email protected]
wrote:

@@ -261,7 +261,9 @@ static unsigned long int resolve_addr(char *symbol,
char *libname)

ret = (unsigned long int) dlsym(handle, symbol);

• dladdr((void *) ret, &dli);

• if (dladdr((void *) ret, &dli) == 0) {

• dli.dli_fname = NULL;

  }

  // Is it the correct lib ?
  if ((dli.dli_fname) && (libname) && (strlen(libname)) && (strncmp(libname, dli.dli_fname, strlen(libname)))) {

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#12 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGjSJwO6jDkZZMsBkYVudHW0mzsy_-Bdks5qln0RgaJpZM4JtmHG
.

[diorcety]

Which file format did you tried?

[hexhexD]

I tried to load a toy executable which I ran wld -libify on it before trying loading it in wsh, and I also tried to load /bin/usr/python2.7 which is shared object file.

[endrazine]

Hi, ovIA, we're going to need a bit more infos to spot the bug. I suspect diorcety's intuition is right and it looks like an issue with dladdr(). May I ask you to run and paste here the output of :

$ cc --version

$ /lib/x86_64-linux-gnu/libc.so.6 --version

$ ldd /usr/bin/wsh

$ file /usr/bin/python2.7

$ wsh -v /usr/bin/python2.7

$ ltrace -Sf wsh -v /usr/bin/python2.7 2>&1

$ strace -vf wsh -v /usr/bin/python2.7 2>&1

It should help a fair bit in getting some context :) Thanks !

[diorcety]

I fixed the issue i had with this patch, until i notice that i needed another target for libbfd for PE executable from linux... until i finally notice "However, rebuilding relocations is currently supported only for Intel ELF x86_64 binaries." :D

[endrazine]

Hi ovIA,
Am I correct in saying that : 1) you built with clang, 2) you libified python2.7 before loading it with wsh ? :)
I dived into it a bit and realized clang was ignoring the linker script. So it's base address would conflict with ET_EXEC binaries produced by the same compiler. I'm pushing a fix that should fix this linker issue. If it's not solving the problem, let's keep digging : the output of the above commands will surely help. Cheers :)

[endrazine]

Diorcety : Yes, currently wcc will allow you to create an ELF from a PE : the mappings of the sections will be the same (addresses, size, permissions). Data and control flow relocations within the binary should already be handled too. So you could run pure functions that have no imports already (that's not very interesting). To run the ELF and port Windows binaries natively under linux, we need the API of a Windows NT kernel built as ELF shared libraries. Luckily, this does exist with the wine API. Now the work of "connecting" the calls within the assembly with those share libraries is not done. That's what the missing relocations should really handle. If you want to work on this with me, that'd be fun. I'm not sure whether having a custom dynamic linker will be required or not, I'd need to look into the wine source code a bit to see if we can run the existing shared libraries as is or if some custom handling is required. Cheers.

[endrazine]

Hi ovIA,
Loading python2.7 should work with the latest commit, irrelevant of your C compiler.
Example here : http://pastebin.com/2kfeapkT
Thanks and regards.

[diorcety]

Yeah can be fun, i'm already work on on stuff like this. How add code to an existing shared object ((https://github.com/diorcety/mazda3/tree/master/media)

[endrazine]

Very cool 👍 :)

[hexhexD]

Hi endrazine,

I'm having the same issue with the new commit. Here is the link to the output of commands you listed out: https://ghostbin.com/paste/hvx83. Please let me know if you need any other information from me to hunt down the bug. I'd love to be able to use wsh.
Thanks

[endrazine]

Hi ovIA,
I'm unsure where /usr/lib/libgcc_s.so.1 comes from. It seems to crash right after. Could you also please paste me the output of :
$ ldd wsh

When you're applying diorcety's patch below, your wsh stops crashing ?
- dladdr((void *) ret, &dli);
- if (dladdr((void *) ret, &dli) == 0) {
- dli.dli_fname = NULL;

If so, it's definitely an issue with dladdr(). Thanks.

[t11230]

Hello all,
I was helping ovlA earlier and noticed a problem with dladdr too. The issue appeared to be that dladdr was returning a struct with dli_fname pointing to 0x2000000001. The address varies from around 0x2000000000 to 0x2000000100. I'm not sure why/where this value is coming from. The man page doesn't give a lot of information about cases like this...
On an aside, we are both running Arch.

Thanks, Tayler

[hexhexD]

Hi endrazine,
After appying the diorcety's patch below with the newest commit wsh works for me and I can reproduce the same result in your link earlier: http://pastebin.com/2kfeapkT.

• dladdr((void *) ret, &dli);
• if (dladdr((void *) ret, &dli) == 0) {
• dli.dli_fname = NULL;

And the problem that t11230 had was resolved as well. Thank you very much for the help!

Alvin

[endrazine]

I'm glad it's working for you. I'd still take a look at the output of ldd, as I'm not sure if I should merge the said patch. Cheers.

[hexhexD]

ldd /usr/bin/wsh
linux-vdso.so.1 (0x00007ffc02f6d000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f3c507d3000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f3c50435000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3c509d7000)

Hi endrazine,
I have a question, It's not a issue with wsh. You can email me if you prefer that way since my Github email is public I believe.I wanted to use the wsh on the toy executable I have, and I tried wld -libify it before load in in wsh. When i try to search one of the function in the executable named test with functions("test") it says 0 functions matched.

Thanks,
Alvin

[endrazine]

Hi ovIA,
When you compile a binary as ET_EXEC, the linker doesn't export internal functions. So when you transform it into a shared library, those function symbols do not exist in the dynamic symbol table, and do not end up in the dynamic linker cache (which is where wsh finds the functions available in the address space).
You can solve it a number of ways. Since you're compiling from source, adding the -rdynamic compilation flag should solve the issue (by copying symbols from the symbol table in the dynamic symbol table).
When this happens and you don't have the source code, you can do at least two things :

1. use wcc to refactor the binary into a relocatable object file, and then link it using gcc. wcc automatically unstrips the binary, exporting internal functions, as well as any object listed in the symbol table if available.
2. since the binary you libified is always loaded at the same base address, you can simply disassemble this binary, and find the vma address of the start of the function (let's say your function foobar is loaded at 0xdeadbeef). Then when loading this libified executable inside wsh, you can call foobar like this:

libcall(0xdeadbeef, arg1, arg2, ...)

where arg1, arg2, ... are optional arguments you'd like to pass to foobar.

If you want to cleanly export foobar to lua, you can define a lua function like this :

function foobar(arg1, arg2):
    libcall(0xdeadbeef, arg1, arg2)
end

Then from the wsh interpreter, you can simply call :

foobar("whatever", "you like")

Cheers.

[hexhexD]

Hi endrazine.

I'm wondering if it was possible to build wcc for 32bit , so I'd be able to load a 32bit shared object file with wsh.

Thanks,
Alvin

[Silur]

@ccc12 I'm having the same issue on x86_64 Arch, latest commit, and I don't fully understand how did you manage to overcome the segfaults, can you make a patch snippet (or a pull request) for it please?