Radare2: ELF relocations are wrong when not in paddr space

[ret2libc]

Work environment

| Questions | Answers
|------------------------------------------------------|--------------------
| OS/arch/bits (mandatory) | Fedora 27
| File format of the file you reverse (mandatory) | ELF
| Architecture/bits of the file (mandatory) | x86/64
| r2 -v full output, not truncated (mandatory) | radare2 3.0.0-git 20687 @ linux-x86-64 git.2.9.0-233-g70a651f01
commit: 70a651f019ad9054ae320980559f634e1b7b78f5 build: 2018-09-28__14:36:15

Expected behavior

[Relocations]
vaddr=0x0804affc paddr=0x00001ffc type=SET_32 __gmon_start__
vaddr=0x0804b040 paddr=-------------- type=SET_64 _ZTVN10__cxxabiv117__c@CXXABI_1.3
vaddr=0x0804b080 paddr=-------------- type=SET_64 _ZSt4cout@GLIBCXX_3.4
vaddr=0x0804b10c paddr=-------------- type=SET_64 _ZTVN10__cxxabiv120__s@CXXABI_1.3
vaddr=0x0804b138 paddr=-------------- type=SET_64 _ZTVN10__cxxabiv121__v@CXXABI_1.3
vaddr=0x0804b00c paddr=0x0000200c type=SET_32 __cxa_atexit
vaddr=0x0804b010 paddr=0x00002010 type=SET_32 operatordelete(void*)
vaddr=0x0804b014 paddr=0x00002014 type=SET_32 std::ios_base::Init::Init()
vaddr=0x0804b018 paddr=0x00002018 type=SET_32 __libc_start_main
vaddr=0x0804b01c paddr=0x0000201c type=SET_32 std::ios_base::Init::~Init()
vaddr=0x0804b020 paddr=0x00002020 type=SET_32 std::basic_ostream<char,std::char_traits<char>>&std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>>&,charconst*)
vaddr=0x0804b024 paddr=0x00002024 type=SET_32 operatornew(unsignedint)
vaddr=0x0804b028 paddr=0x00002028 type=SET_32 rand
vaddr=0x0804b02c paddr=0x0000202c type=SET_32 __gxx_personality_v0
vaddr=0x0804b030 paddr=0x00002030 type=SET_32 _Unwind_Resume

15 relocations

Actual behavior

[Relocations]
vaddr=0x0804affc paddr=0x00001ffc type=SET_32 __gmon_start__
vaddr=0x0804b040 paddr=0x00002040 type=SET_64
vaddr=0x0804b080 paddr=0x00002080 type=SET_64
vaddr=0x0804b10c paddr=0x0000210c type=SET_64
vaddr=0x0804b138 paddr=0x00002138 type=SET_64
vaddr=0x0804b00c paddr=0x0000200c type=SET_32 __cxa_atexit
vaddr=0x0804b010 paddr=0x00002010 type=SET_32 operatordelete(void*)
vaddr=0x0804b014 paddr=0x00002014 type=SET_32 std::ios_base::Init::Init()
vaddr=0x0804b018 paddr=0x00002018 type=SET_32 __libc_start_main
vaddr=0x0804b01c paddr=0x0000201c type=SET_32 std::ios_base::Init::~Init()
vaddr=0x0804b020 paddr=0x00002020 type=SET_32 std::basic_ostream<char,std::char_traits<char>>&std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>>&,charconst*)
vaddr=0x0804b024 paddr=0x00002024 type=SET_32 operatornew(unsignedint)
vaddr=0x0804b028 paddr=0x00002028 type=SET_32 rand
vaddr=0x0804b02c paddr=0x0000202c type=SET_32 __gxx_personality_v0
vaddr=0x0804b030 paddr=0x00002030 type=SET_32 _Unwind_Resume

15 relocations

Steps to reproduce the behavior

• $ radare2 ./r2r/bins/elf/class_test
• > ir

Additional Logs, screenshots, source-code, configuration dump, ...

There are 2 bugs here.
1) R_386_COPY relocations are not correctly parsed, because there aren't the symbols names
2) the paddr of those relocations shouldn't be visualized because it doesn't exist! 0x0804b040 and the others are just in the virtual space, but they don't come from the file, so it doesn't make sense to have a paddr there.

[XVilka]

cc @08A

[08A]

cc @08A

I will look at this later i have a lot of work lately.

[08A]

On master we have:

❯ r2 test/bins/elf/class_test
 -- Don't do this.
[0x08048740]> ir
[Relocations]

vaddr      paddr      type   name
―――――――――――――――――――――――――――――――――
0x0804affc 0x00001ffc SET_32 __gmon_start__
0x0804b00c 0x0000200c SET_32 __cxa_atexit
0x0804b010 0x00002010 SET_32 operator delete(void*)
0x0804b014 0x00002014 SET_32 std::ios_base::Init::Init()
0x0804b018 0x00002018 SET_32 __libc_start_main
0x0804b01c 0x0000201c SET_32 std::ios_base::Init::~Init()
0x0804b020 0x00002020 SET_32 std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
0x0804b024 0x00002024 SET_32 operator new(unsigned int)
0x0804b028 0x00002028 SET_32 rand
0x0804b02c 0x0000202c SET_32 __gxx_personality_v0
0x0804b030 0x00002030 SET_32 _Unwind_Resume
0x0804b040 0x0804b040 SET_64 vtable for __cxxabiv1::__class_type_info
0x0804b080 0x0804b080 SET_64 std::cout
0x0804b10c 0x0804b10c SET_64 vtable for __cxxabiv1::__si_class_type_info
0x0804b138 0x0804b138 SET_64 vtable for __cxxabiv1::__vmi_class_type_info


15 relocations

[0x08048740]> !r2 -v
radare2 4.5.0-git 24723 @ linux-x86-64 git.4.4.0-243-gae2754a99
commit: ae2754a99ba178129d971a5e01e1ea40762c982d build: 2020-06-05__17:13:41

Does the expected behavior has evolved?

[ret2libc]

Does the expected behavior has evolved?

Yes, I think some things have changed since I opened the bug.

There are 2 bugs here.

1. R_386_COPY relocations are not correctly parsed, because there aren't the symbols names

This thing seem to be solved now.

1. the paddr of those relocations shouldn't be visualized because it doesn't exist! 0x0804b040 and the others are just in the virtual space, but they don't come from the file, so it doesn't make sense to have a paddr there.

However this part is still relevant AFAIK. Those symbols should not have any paddr associated, because there is no file offset associated with that virtual address (you can check it by looking at the program headers table).

[08A]

However this part is still relevant AFAIK. Those symbols should not have any paddr associated, because there is no file offset associated with that virtual address (you can check it by looking at the program headers table).

Do you have a cmd (like readelf) to test those symbols?

[ret2libc]

However this part is still relevant AFAIK. Those symbols should not have any paddr associated, because there is no file offset associated with that virtual address (you can check it by looking at the program headers table).

Do you have a cmd (like readelf) to test those symbols?

I don't :( I just check the LOAD segments.

$ readelf --segments <bin>
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0x0151d 0x0151d R E 0x1000
  LOAD           0x001ef4 0x0804aef4 0x0804aef4 0x00148 0x00274 RW  0x1000

This means that these parts of the file are mapped:

• virtual [0x8048000, 0x804a000] is mapped to [0, page_roundup(0x151d)] == [0, 0x2000]
• virtual [0x804a000, 0x804c000] is mapped to [page_rounddown(0x1ef4), page_roundup(0x1ef4 + 0x00148)] == [0x1000, 0x3000]

And..... this actually means this issue can be closed as I was wrong and the addresses for those symbols are indeed mapped in the file :( :( sorry.