Repository navigation
Unable to parse ELF file because VMA is not being honored #8660
Description
Version and Platform (required):
- Binary Ninja Version: 6.0.10601
- Edition: Free
- OS: Arch Linux
- OS Version: up to date :)
- CPU Architecture: x64
Bug Description:
Binary ninja does not analyze my .elf file. It contains debugging symbols and I have checked with objdump that the sections and symbols are correct. It seems that it doesn't honor the VMA of the .text section and nothing got disassembled.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:
- open my provided elf file with binary ninja
Expected Behavior:
expect any functions to be present (example: start). expect .text segment to contain code. expect .text segment to start from 0x02000380
Observed behavior
no function present. .text segment contains yet-to-be-disassembled hex data.
.text segment starts from 0x454
this contradicts what llvm-objdump --syms and llvm-objdump --section-headers would output
Binary:
hello.zip
Additional Information:
This is an arm/thumb code, intended for baremetal application, produced with rust.
Activity
zznop commentedon Oct 14, 2026
This ELF is wrong under standard ELF semantics. Its
e_entryis0x02000000, which points to the.mcs_headerdata. The actual executable entry isstartat0x02000380.Also in this ELF
p_paddr = 0x2005658is being used as the load-memory address (LMA) or the flash location from which startup code copies.datainto RAM. Binary Ninja does not create the additional flash alias, so_sidata = 0x2005658appears unmapped. The ELF specification only givesp_paddrmeaning on systems where physical addressing is relevant, so a generic userspace ELF loader cannot safely treat everyp_paddras an LMA. Unconditionally doing so could mis-map ordinary ELFs.The device is highly unlikely to run this ELF as is. This is more than likely a build artifact and there is a build stage where the tooling converts this ELF to a MCS/flat image. Then the PocketStation firmware loads that flat image at
0x2000000, parses the MCS header, reads the application entry field at the MCS offset0x5cand branches to0x2000380(the realstartroutine). The startup code appears to initialize the RAM/stack and transfer control to the app.The .data initialization bytes also appear in the flat image at offset 0x5658, corresponding to load address 0x02005658. At runtime they can be copied to their RAM VMA at 0x200.
I've fixed up the ELF file you supplied so you can load it into Binja. But if you want to load other ELFs similar to this one without having to fixup the ELFs then you'll need to write a custom binary view plugin as these ELFs are non-standard build artifacts of your embedded toolchain.
hello-fixed-mapped.zip
EvansJahja commentedon Oct 14, 2026
sound.zip
this one can be read normally by binja even though it shares the same build process, but contains more code
zznop commentedon Oct 14, 2026
It doesn't appear to be loaded correctly either. The
e_entryis still wrong which is making it think that the entrypoint is in the MCS headerEvansJahja commentedon Oct 14, 2026
entry_is_now_after_mcs.zip
I think I got it