Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    sys ri
    @sysri_gitlab
    this looks like a lot , but i dont know what would be considered normal in this case?
    for testing i used the modified binaries and changed "aaaaaa" back to "execve" with lief , there is no size change now, but it still segfaults
    any ideas ?
    maybe some options i'm missing?
    Romain
    @romainthomas
    @sysri_gitlab if you can provide a minimal case to reproduce the error I could take a look!
    sys ri
    @sysri_gitlab
    sys ri
    @sysri_gitlab
    @romainthomas what do you need? i attached the [ython script i used, the old and the new binaries, and a chroot with the new binaries;
    running "chroot /chroot ./busybox" should give an segfault
    running the script on the original binaries should gives the modified ones
    if you want to get the binaries yourself
    https://mirrors.edge.kernel.org/alpine/latest-stable/main/x86_64/busybox-1.32.1-r3.apk
    https://mirrors.edge.kernel.org/alpine/latest-stable/main/x86_64/musl-1.2.2-r0.apk
    should be the right ones
    i build lief on an alpine system, not sure if it makes a difference
    if you need some way to test booting a system with the modified binaries i could maybe tinker together some initrd,
    in my case i just used an alpine testvm, changed the files in the filesystem while the vm is off, booted it, used init=/bin/busybox
    this should also give a segfault
    running "./ld-musl-x86_64.so.1.new ./busybox.new" should work
    a mixed combination of the new and old binaries should give: error relocating binary aaaaaa(or execve): symbol not found
    Derzsi Dániel
    @darktohka
    Is there a way to remove a needed GLIBC version from an ELF .so? I've created a library that exports the same function that is missing. My .so binary has a reference to GLIBC_2.11's __longjmp_chk function, even if I change GLIBC_2.11's name and value to that of an older GLIBC version (namely GLIBC_2.3), dlopen still complains that "version 'GLIBC_2.3' not found"
    Romain
    @romainthomas
    Not yet but it will be doable with the new version of the ELF builder
    Wolowin
    @Wolowin

    Hello everyone! I have a task where I need to add new section to the elf, but I cannot shift the addresses of other sections, so a simple "add" of the new section doesn't do the trick for me (since it expands the program header and shifts the (almost) whole program by 0x1000.

    I thought I would move the program header to the end of the file, so no old segments / sections are moved when I add new sections. Could you give me a hint if its easily achievable and point me into an approach that you would use for this task?

    Wolowin
    @Wolowin
    I am looking at
    Segment& Binary::replace(const Segment& new_segment, const Segment& original_segment, uint64_t base)
    and my idea is to get old program header segment, alternate it slight and use the replace function. I am currently figuring out what I need to change in the old one when creating new one
    Romain
    @romainthomas
    Hi @Wolowin
    Moving the phdr table at the end of the binary raises some errors with recent glibc loader. Nevertheless, you can find "cave" between segment to relocate the phdr table there. I'm currently implementing this technique for non-pie binary in the new ELF builder (not released yet)
    Wolowin
    @Wolowin

    Could you please tell me something more about this error in glibc? I need to be able to input the changes programmatically and I don't think there is any universal way to find a "cave".

    After some trails and errors I got to the point where I got an error (which apparently is in agreement with the ELF format doc) that PHDR segment needs to be before any LOAD segment. But I saw that in one of my .so files, the program header doesn't have its own segment and is instead contained in LOAD segment. I wonder if there is an option to add a LOAD segment at the end of the file and put header there. But I fear it may just fall under the same error category. What do you think?

    Also do you know about any tools that will help me check my modified binaries and give a verbose feedback, why the binary is malformed?

    Romain
    @romainthomas
    Indeed, if you move the phdr table at the end of the binary you need to extend (or add) a LOAD segment so that it is mapped in memory. In the current version of LIEF, extending the closest LOAD segment from the end of the binary raises an error in the loader (I didn't investigate completely why)
    Wolowin
    @Wolowin

    extending the closest LOAD segment from the end of the binary raises an error in the loader

    How about ADDING a new LOAD section? Have you tried that?

    Romain
    @romainthomas
    No I didn't try but I would be curious to know if it works :)
    Wolowin
    @Wolowin
    Well I just tried and I got segfault but there are just so many things I could have done wrong since I am not that experienced in elf and lief
    Wolowin
    @Wolowin
    There is an interesting option -L (--lite, --enable_checks) in newest readelf but it seems to not do anything xD
    You mentioned investigating the loader error. Could you give me some hints how I should attempt to investigate my crash? I have reverse engineering experience but all on Windows and never on a loader application ;p
    Wolowin
    @Wolowin

    one more important question. You said

    Moving the phdr table at the end of the binary raises some errors with recent glibc loader.

    Was it not raising an error with previous versions of the loader?

    Romain
    @romainthomas

    You mentioned investigating the loader error. Could you give me some hints how I should attempt to investigate my crash?

    If the crash comes from ld-XXX.so you can try to compile the loader with debug symbol (c.f. glibc) to know where it fails

    You can use the compiled loader on you modified binary with ld-XXX-debug.so foo.bin
    (it take your program as parameter)
    worked on ~ubuntu 18.04 but does not work on ubuntu 20.04
    I don't know if it's strictly related to the loader but it was my feeling
    Anyway I had to refactor the ELF builder for performances considerations and I plan to describes the new changes in a blog post when it will be ready
    Justin-Kirschner
    @Justin-Kirschner

    Hey all. I just started using lief a few days ago and couldn’t find the following in the documentation.
    Quick question, can I edit a binary's content with lief? For example:

    binary0 = lief.parse("/home/xxx/dbt/add0arm")
    text = binary0.get_section(".text")

    print(text.content[1])
    < 79
    text.content.insert(1,0x99) OR text.content[1] = 0x99
    print(text.content[1])
    < 79
    Still 79 :(
    Seems like I can access, but not edit? I could edit with the C API, though?

    Wolowin
    @Wolowin
    I am adding a new segment on my own (without using LIEF actually). Could you explain me what conditions do the offsets, sizes and virtual addresses need to meet?
    Romain
    @romainthomas
    @Wolowin Yes, and here come the interesting part:
    (also think about the .bss section ;)
    Wolowin
    @Wolowin
    @romainthomas Thanks for all the info so far! You said I can find the "cave" between segments to relocate phdr table there
    does it need to be the cave between 1st and 2nd load segment?
    1. Extending of last segment doesnt work
    2. All the binaries I saw had program header in their 1st load segment
      That could mean it just has to be in the first load segment. Am I correct here?
    Wolowin
    @Wolowin
    also you said that you are doing this for non-pie binary. Is this approach not working for PIE shard objects?
    and I see in the code that you use different add_segment for E_TYPE::ET_EXEC and E_TYPE::ET_DYN. Why is that needed?
    sorry for so many questions but I'm trying to understand it ;p
    Romain
    @romainthomas

    does it need to be the cave between 1st and 2nd load segment?

    Not necessarily, you can use the largest cave as long as it is before the segment that contains the .bss

    also you said that you are doing this for non-pie binary. Is this approach not working for PIE shard objects?

    It should also work for pie binaries but I didn't test

    and I see in the code that you use different add_segment for E_TYPE::ET_EXEC and E_TYPE::ET_DYN. Why is that needed?

    It's all the relocating mechanism (pie vs non-pie)

    Peter Goodman
    @pgoodman
    I have LIEF as a submodule of my project, and I've done add_subdirectory(LIEF) in CMake; what is the easiest way to link against LIEF from within the rest of my CMake project?
    ah, might be LIB_LIEF
    Romain
    @romainthomas
    Hi @pgoodman did you manage to resolve your issue ?
    Peter Goodman
    @pgoodman
    yes!
    worked like a charm :+1:
    jgcodes2020
    @jgcodes2020
    hi, i'm working on a LIEF-based PE parser to extract debug information
    so I'm wondering how I get full section names (i.e. convert /45 into whatever's at the 45th byte of the PE's string table)
    Alexis López Zubieta
    @azubieta
    Hello I would like to add some magic bytes after the elf header for identifying a given ELF file as AppImage. My rationale was to add the magic bytes after the header and displace the rest of the ELF sections by editing the binary header and saving it using LIEF. But I found that the addresses were not corrected properly. Is my use case possible with lief ? Or you would recommend taking a look into linker scripts ?
    Romain
    @romainthomas
    Hi @azubieta I think that it will be easier to do it with a linker script if you control the compilation pipeline. Even though it's not implemented in LIEF, it will fail anyway when the binary is not PIE
    Alexis López Zubieta
    @azubieta
    @romainthomas thanks