Closed Ruturaj4 closed 4 months ago
Handling corrupt binaries is out of scope for pyelftools
Handling corrupt binaries is out of scope for pyelftools
I agree as it makes perfect sense (And, it is just my speculation that the binary might be corrupted).
However, objectdump and readelf work just fine:
$readelf -wi sshd.elf | less
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length: 0x2694 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): clang version 3.4 (tags/RELEASE_34/final 249356) (llvm/tags/RELEASE_34/final 249354)
<10> DW_AT_language : 12 (ANSI C99)
<12> DW_AT_name : (indirect string, offset: 0x55): sshd.c
<16> DW_AT_low_pc : 0x0
<1e> DW_AT_stmt_list : 0x0
<22> DW_AT_comp_dir : (indirect string, offset: 0x5c): /home/vvdveen/src/typearmor-runtime/apps/openssh-3.5p1
<1><26>: Abbrev Number: 2 (DW_TAG_variable)
<27> DW_AT_name : (indirect string, offset: 0x93): config_file_name
The binary, and the DWARF in it, looks fine to me.
The error happens in the method CU.get_DIE_from_refaddr(), as called from get_parameters() in yali.py:156. The surrounding script is trying to follow a DIE reference. That call might be miswritten - passing a bogus DIE offset, one that causes the library to look in the wrong place. For one thing, I can tell that it treats whatever attribute contents are there as a CU-relative offset, which may not be the case.
It's yali.py that needs debugging, not pyelftools proper.
@Ruturaj4 : what's the status of this? I won't mind taking a look at yali.py, if you care to share.
@Ruturaj4 : what's the status of this? I won't mind taking a look at yali.py, if you care to share.
Yeah, I can't open source yali.py now, but I am working on some other things and don't have time to take a look at that, thanks nonetheless
If you think the issue may be closed, please do. It does not seem like a problem with pyelftools anyway.
Failed to run
pyelftools
on:I have a suspicion that it is possible that the binary is may be corrupted.
I am using following binary:
https://github.com/vusec/typearmor/blob/master/server-bins/sshd
Is there a way to circumvent this error?
Backtrace: