It appears (and empirically seems to be born out in gdb) that there is a lack of proper handling of endian-ness in the debugedit.c code which generates a build ID hash from the ELF data.
The summary is that while the gelf_* functions are used to read data from the ELF file, the elf*_xlatetom are then called on the data returned from those functions. If you look at elfutils source, you'll see that the gelf_* calls already handle file->machine endian byte swapping (if necessary). Therefore, when the elf*_xlatetom(..) calls are used, if byte-swapping is required, it now swaps the memory-proper data back to on-disk endianness, causing any operations on the in-memory data to be suspect given it will be byte-swapped improperly.
The end result in my case is that if I use debugedit against a big endian binary from a little endian machine, I end up with SIGSEGV given that the check :
if (u.shdr.sh_type != SHT_NOBITS)
fails even when the section is really a NOBITS section (.bss, .sbss..). Given that these sections have a size but no proper offset, the call to process() this data will cause the beecrypt hash update functions to try an access at zero (for the memcpy).
To test my theory (beyond just dumping data from gdb to prove the endian swapping is happening twice), getting rid of the xlatetom for the shdr causes a build ID to be generated for a big endian binary. I would generate a patch to just remove the three main xlatetom calls (on ehdr, phdr, and shdr), but would like someone with more understanding of what I might be missing to take a look and validate my claims..
