Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i386: Relocation incorrectly applied to GOT entry #52

Closed
yifanlu opened this Issue Mar 6, 2019 · 5 comments

Comments

Projects
None yet
5 participants
@yifanlu
Copy link

yifanlu commented Mar 6, 2019

Describe the bug
In an i386 ELF binary, an GOT entry is incorrect which leads it to display the wrong symbol information.

To Reproduce
Steps to reproduce the behavior:

  1. Download the ELF here: http://pwnable.kr/bin/hash
  2. Load into ghidra with all the default options
  3. Go to 0x0804b008
  4. See 0804b008 04 c0 04 08 addr srand = ??

Expected behavior
The GOT entry should point to getchr

Tested with Hopper, IDA Pro, and Cutter, and all produce the expected result. It appears that Ghidra is performing the relocation on that GOT entry but it's doing so incorrectly.

           080486f0 08 b0 04 08 07  Elf32_Rel                         [2]
                    03 00 00
              080486f0 08 b0 04 08     ddw       804B008h                r_offset      location to apply 
              080486f4 07 03 00 00     ddw       307h                    r_info        the symbol table i
           08048208 1e 01 00 00 00  Elf32_Sym                         [3]
                    00 00 00 00 00 
                    00 00 12 00 00
              08048208 1e 01 00 00     ddw       11Eh                    st_name       getchar
              0804820c 00 00 00 00     ddw       0h                      st_value
              08048210 00 00 00 00     ddw       0h                      st_size
              08048214 12              db        12h                     st_info
              08048215 00              db        0h                      st_other
              08048216 00 00           dw        0h                      st_shndx

@yifanlu yifanlu added the bug label Mar 6, 2019

@gibbed

This comment has been minimized.

Copy link

gibbed commented Mar 7, 2019

If I'm reading the code correctly, this type of relocation isn't supported currently.

ghidra\app\util\bin\format\elf\relocation\X86_32_ElfRelocationHandler.java (found in Ghidra\Processors\x86\lib\x86-src.zip):

snip

@rvolgers

This comment has been minimized.

Copy link

rvolgers commented Mar 7, 2019

Nah, relocation type is (r_info & 0xff) == 0x7 == ElfRelocationConstants.R_386_JMP_SLOT, which is handled.

@gibbed

This comment has been minimized.

Copy link

gibbed commented Mar 7, 2019

@rvolgers Oh, I incorrectly went by the output pasted from the second r_info shown (0x12). Oops!

@ryanmkurtz ryanmkurtz added this to the 9.0.1 milestone Mar 7, 2019

@ryanmkurtz

This comment has been minimized.

Copy link
Collaborator

ryanmkurtz commented Mar 7, 2019

This is caused by a bug in the ELFSymbol equals() and hashcode() methods. This bug surfaces when multiple symbol tables are present in the ELF binary and can impact the processing of the GOT, PLT, and relocation processing for any processor. A fix for this will be included in our next release.

@ryanmkurtz ryanmkurtz closed this Mar 7, 2019

kant2002 added a commit to kant2002/Ghidra that referenced this issue Mar 27, 2019

Corrected bug in ELF loader which can improperly process the
GOT, PLT and relocations when multiple symbol tables exist within
the ELF binary
See NationalSecurityAgency/ghidra#52

Signed-off-by: Andrii Kurdiumov <kant2002@gmail.com>
@coverclock

This comment has been minimized.

Copy link

coverclock commented Apr 1, 2019

I installed the 9.0.1 on my x86_64 Ubuntu desktop, created a new project from scratch, and imported a shared object compiled for an ARMv7L target and am still seeing Ghidra get confused about what symbols are where due to the incorrect 0x10000 offset. When I compare the output of objdump for the same file and run the ARMv7L target itself, I can see that Ghidra has the disassembly for the function diminuto_cue_debounce correct, but because of the incorrect offset, it places it in the middle of an entirely different object module (diminuto_controller) and proceeds to interpret the variables as if they were in that module (e.g. "numerator" etc.), not in diminuto_cue. Remarkably, the decompile for diminuto_due_debounce seems reasonable. Maybe this is a different bug... but it sure seems like this bug. Here are links to my screen snapshots.

Ghidra version

nm run on the target

objdump -x -d run on target

Ghidra run on host

EDIT: I similarly analyzed the same shared object but compiled for two different x86_64 targets (one of which was the host on which I ran Ghidra) and both disassemblies seem correct; I don't see the incorrect offset and the disassembly interprets the variables correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.