[SOLVED] How to remove Library Paths from project's .elf file

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] How to remove Library Paths from project's .elf file

    Hi,

    when I build my project with Segger embedded studio the produced .elf file also includes the SDK library paths.
    I want the paths not to be visible/ written in the .elf file.
    I want to be used (obviously) but not displayed in .elf file after building the project because I want to share my .elf file
    with other people.

    So, I was wondering if there is some configuration in Segger Embedded studio that does that
    Any ideas?
    Thank you
  • ELF is basically the debug format, i.e. contains all the information for debugging (with the respective flags enabled).

    Why not doing a post-build step, and convert the ELF output into an *.HEX or *.SREC file ?
    These formats contain nothing but the actual code + const data.
    Segger's objcopy tool (part of the binutils) could do that, for instance.
  • My colleagues need to pass the code to a fuzzing tool. That tool accepts only .bin files. So, as you said I converted the .elf to hex file and then to .bin file but the library paths can still be seen through the tool.
    So I was thinking maybe if I could somehow remove them from the beginning (?)
  • > My colleagues need to pass the code to a fuzzing tool.

    Assuming you talk about what I know as obfuscator tool, I don't know what want to achieve with that step.
    Such a tool tries to hide certain details of the file from third parties, such as path names, libraries, variable and object names.
    Commercial Dot-Net projects e.g. use to hide internals through an obfuscator, to impede reverse engineering.

    There is no such thing present in HEX or S19 files.
    All debug metadata have been stripped in the conversion process.

    Nor do *.BIN files, at least those used to contain MCU firmware.
    Those files consist of the raw values to program to each Flash cell, without any metadata (which means, not even addresses).
    This implies *.BIN files must cover all addresses from the first to the last byte, and thus usually carry a large amount of superfluous data (0xFF) for all the gaps in the text / const data section.
  • Hello Lef,

    Thank you for your inquiry.

    As Frank correctly wrote the ELF format does include debug information, while binary and hex only include the image itself.
    Instead of using an external tool, the binary or hex output may also be generated directly in ES by using the "Code > Linker > Additional Output Format" project setting.

    In case the paths can still be read in the binary, the paths are part of the application itself, e.g. because of exception handling or macros like __FILE__.
    Please see here for further information: forum.segger.com/index.php/Thr…cluded-in-hex-image-file/

    Best regards,
    SebastianB
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi guys, thank you for your support. Actually I asked my colleagues and they told me that the tool they use also accepts .elf files.
    That is why they were able to see the paths... Ok so we will search for a tool that accepts .hex and see how it goes.

    Thank you again!