by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Romain
    @romainthomas
    @greek-stasia Nop, add_library() just adds the library as a dependency of the binrary. It means that the library will be loaded in the memory space of the process but you need to manage yourself the functions you want to use
    Anastasia Bourlas (Stasia)
    @greek-stasia
    Not sure what you mean by "manage the functions" but thank you - love the repo! You guys are brilliant
    BlipsAndChitz
    @Blips_and_Chitz_twitter
    Hi, I'm trying to add a shared object into an ELF file and a symbol from the shared object. But I'm somehow stuck how to get the address of the loading symbol. Any idea how to achieve it ?
    I'm adding a segment and a relocation that should write the symbol address into this segment.
    LIEF::ELF::Relocation *R = new LIEF::ELF::Relocation(
        Sec_VA, LIEF::ELF::RELOC_x86_64::R_X86_64_JUMP_SLOT, 0, true);
    R->purpose(LIEF::ELF::RELOCATION_PURPOSES::RELOC_PURPOSE_PLTGOT);
    R->symbol(&Sym);
    binary->add_pltgot_relocation(*R);
    but the address is always 0
    Anastasia Bourlas (Stasia)
    @greek-stasia
    Does anybody notice how big the binaries get compared to the original especially with small modifications. I'm assuming it's just meta data? is there a way we can reduce this?
    Anastasia Bourlas (Stasia)
    @greek-stasia
    Sorry I just realize that I was adding a segment but it still increases my binary from 8k to 73k is there a way we can reduce the bloat?
    Katharina Bogad
    @mistressofjellyfish
    apparently adding symbols to a binary I have lying around destroys my .symtab. Any idea how I could debug this? as long as I don't write the binary to disk it seems to be fine (at least thats what iPython3 tells me)
    Romain
    @romainthomas
    @mistressofjellyfish Adding a static or a dynamic symbol?
    Katharina Bogad
    @mistressofjellyfish
    I added it via the dynamic symbol method
    but actually I want to add an import
    I found a workaround using objcopy to add the symbol and then lief to modify it so that it'll be bound by the linker later
    so it's not a huge deal, but it's still strange
    Nico Feulner
    @nico151999
    Hi, I have tinkered around for hours but have not achieved a working result. I hope you guys know some more than I do, so I would like to kindly ask you to help me. I am trying to add a Segment to an ELF. To be precise, I am trying to add a PHDR segment. However, the PHDR segment is added at the last position, after the LOAD segments. However, as far as I know PHDR entries must be located at some point before the first LOAD's appearance. My code is as follows:
    import lief
    binary = lief.parse("elf.so")
    segment_to_add = lief.ELF.Segment()
    segment_to_add.type = lief.ELF.SEGMENT_TYPES.PHDR
    segment_to_add.alignment = 0x4
    segment_to_add.flags = lief.ELF.SEGMENT_FLAGS.R
    binary.add(segment_to_add)
    binary.write("patched_elf.so")
    And the output of readelf -l prints:
    readelf: Error: the PHDR segment must occur before any LOAD segment
    Thanks a lot in advance!
    Anastasia Bourlas (Stasia)
    @greek-stasia
    @nico151999 did you try specifying a certain address for the segment to be mapped? just an idea :)
    Nico Feulner
    @nico151999
    @greek-stasia first I'd like to thank you for your answer. Maybe I'm getting you wrong or maybe I'm doing something wrongly. Anyway, setting the virtual_address and the file_offset to 0 seems not to have any effect. The offset remains 0x03c000 and the virtual address remains 0x000bc000. I do not have an idea why it is set to these values at all. I would greatly appreciate any more suggestions!
    Nico Feulner
    @nico151999
    Oh and one more thing to mention is that it appears like the addresses do not have an impact on the position a segment occurrs. Just look at the following extract of the readelf -l output:
    Entry point 0x1784
    There are 5 program headers, starting at offset 52
    
    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      EXIDX          0x0332b0 0x000332b0 0x000332b0 0x00660 0x00660 R   0x4
      LOAD           0x000000 0x00000000 0x00000000 0x33914 0x33914 R E 0x8000
      LOAD           0x033914 0x0003b914 0x0003b914 0x06194 0x06204 RW  0x8000
      DYNAMIC        0x033eb8 0x0003beb8 0x0003beb8 0x00100 0x00100 RW  0x4
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
    Nico Feulner
    @nico151999
    Well, for anyone having the same problem: I wasn't able to manage it using lief alone. Instead I added the segment using lief, opened the binary in a hex editor, moved the segment I added to offset 52 and edited its contents so that they are valid. That's the only way I could make it work.
    Đỗ Minh Tuấn
    @HarDToBelieve
    image.png
    Hi, has anyone struggled with Catalina's linker update? I see some new checks, maybe
    nopa12
    @nopa12
    hello
    any way to make lief for android smaller? i compiled it and it's >100mb. don't understand why
    Romain
    @romainthomas
    Hello @nopa12
    If you only need ELF support for Android,
    you can use this configuration:
    cmake ..                                \
      -DLIEF_DOC=off                        \
      -DLIEF_PYTHON_API=off                 \
      -DLIEF_EXAMPLES=off                   \
      -DLIEF_C_API=off                      \
      -DLIEF_PE=off                         \
      -DLIEF_MACHO=off                      \
      -DLIEF_OAT=off                        \
      -DLIEF_DEX=off                        \
      -DLIEF_VDEX=off                       \
      -DLIEF_ART=off                        \
      -DLIEF_LOGGING=off                    \
      -DANDROID_ABI="arm64-v8a"           \
      -DANDROID_PLATFORM=android-24         \
      -DCMAKE_INSTALL_PREFIX=$(pwd)/install \
      -DCMAKE_BUILD_TYPE=RelWithDebInfo     \
      -DCMAKE_TOOLCHAIN_FILE=${ANDROID_SDK}/ndk-bundle/build/cmake/android.toolchain.cmake
    r0anne
    @r0anne_gitlab
    Hello
    I have a packed PE file which has sections with a a virtual size larger than their on-disk size. Once it is unpacked in-memory, a larger part of the virtual size is consumed. I am trying to write a static unpacker with LIEF. I would like to know whether there is a way to extend the on-disk section size using LIEF, so that I can put directly the larger, unpacked contents (through successively using the PE.parse and pe.write functions)?
    r0anne
    @r0anne_gitlab
    It seems that when modifying only the "content" attribute of the PE section, LIEF crashes, and when modifying the "size" then "sizeof_raw_data" attributes, then the "content" attribute, LIEF does not crash but the section is not extended in the produced binary. I am using LIEF with Python, I precise.
    Romain
    @romainthomas
    Hello @r0anne_gitlab , I'm not sure to understand what you aim to do. Do you want to extend a section like .text ?
    suletm
    @suletm
    hello everyone, I am following the demo to transform an ELF executable into a library: https://lief.quarkslab.com/doc/latest/tutorials/08_elf_bin2lib.html
    all looks good to me, the function is exported into the library (as evidenced by readelf & nm commands against the created library), however dlsym reports no such symbol found when I try to use it from another executable
    I thought maybe there is a problem with my dlsym() logic, but after using the same code and testing it against libc's malloc, I realized there is probably something wrong with LIEF's function export. Is there a way to double-check if the function is really exported (other than seeing it in the nm output in the library) ?
    I am on gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) and GNU ld (GNU Binutils for Ubuntu) 2.30
    suletm
    @suletm
    I can reproduce the issue with the demo as well
    suletm
    @suletm
    filed a new issue: lief-project/LIEF#392
    Romain
    @romainthomas
    Hello @suletm
    Thanks for the report I'll look at this issue tomorrow
    suletm
    @suletm
    @romainthomas no worries, happy to help
    suletm
    @suletm
    has anyone tried to use LIEF against a larg-ish C++ binary ?
    Romain
    @romainthomas
    @suletm you could have performance issues on large binaries. Especially if there is a lot of relocations
    genuine_
    @blaquee
    quick, can lief be used to process PEs in memory?
    erh quick question*
    Romain
    @romainthomas
    @blaquee nop but it would be an interesting feature
    Marcos Álvares
    @mabj
    Hello every one. I'm taking a look on LIEF's examples and I'm trying that pe_from_scratch script to create a PE changing the virtual_address of .data to any other value than 0x2000 and I'm getting back an invalid Win32 application according to Windows 7 x86. I'm updating the code with the right addresses to the functions and to strings pushed to MessageBoxA call. Could you give me a hand with this, please? I'm using LIEF "0.10.1".
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    
    # Description:
    # Create a PE which pop a MessageBox
    # with the message "Hello World"
    
    from lief import PE
    
    title   = "LIEF is awesome\0"
    message = "Hello World\0"
    
    data =  list(map(ord, title))
    data += list(map(ord, message))
    code = [
            0x6a, 0x00,                         # push 0x00 uType
            0x68, 0x00, 0x50, 0x40, 0x00,       # push VA(title)
            0x68, 0x10, 0x50, 0x40, 0x00,       # push VA(message)
            0x6a, 0x00,                         # push 0 hWnd
            0xFF, 0x15, 0x54, 0x60, 0x40, 0x00, # call MessageBoxA
            0x6A, 0x00,                         # push 0 uExitCode
            0xFF, 0x15, 0x4C, 0x60, 0x40, 0x00  # call ExitProcess
            ]
    
    binary32 = PE.Binary("pe_from_scratch", PE.PE_TYPE.PE32)
    
    section_text                 = PE.Section(".text")
    section_text.content         = code
    section_text.virtual_address = 0x1000
    
    section_data                 = PE.Section(".data")
    section_data.content         = data
    section_data.virtual_address = 0x5000
    
    section_text = binary32.add_section(section_text, PE.SECTION_TYPES.TEXT)
    section_data = binary32.add_section(section_data, PE.SECTION_TYPES.DATA)
    
    print(section_text)
    print(section_data)
    
    binary32.optional_header.addressof_entrypoint = section_text.virtual_address
    
    kernel32 = binary32.add_library("kernel32.dll")
    kernel32.add_entry("ExitProcess")
    
    user32 = binary32.add_library("user32.dll")
    user32.add_entry("MessageBoxA")
    
    
    ExitProcess_addr = binary32.predict_function_rva("kernel32.dll", "ExitProcess")
    MessageBoxA_addr = binary32.predict_function_rva("user32.dll", "MessageBoxA")
    print("Address of 'ExitProcess': 0x{:06x} ".format(ExitProcess_addr))
    print("Address of 'MessageBoxA': 0x{:06x} ".format(MessageBoxA_addr))
    
    builder = PE.Builder(binary32)
    builder.build_imports(True)
    builder.build()
    builder.write("pe_from_scratch.exe")
    Marcos Álvares
    @mabj
    I managed to sort this out guys. Lots of PE header adjustments and alignment missing. Thank you very much anyway and sorry for polluting the channel here with a dumb question :)