radare2 icon indicating copy to clipboard operation
radare2 copied to clipboard

Incorrect virtual addresses from ARM binaries in Radare2 v1.7.0 on OSX

Open therealsaumil opened this issue 7 years ago • 7 comments

Recently, I had a strange issue with Radare2. I wanted to print virtual addresses of symbols in an ARM Linux ELF binary (binary is attached at the end of this text). I used Radare2 on OSX, and I got the following output when displaying the address for system():

For OSX:

$ r2 -v
radare2 1.7.0-git 16189 @ darwin-x86-64 git.1.6.0-965-g427fff4
commit: 427fff4f6029d78cdc281da41d280f97f17f3b26 build: 2017-09-30__01:22:51
 
$ r2 file.bin
[0x00009720]> is~system
vaddr=0x00009330 paddr=0x00001330 ord=022 fwd=NONE sz=16 bind=GLOBAL type=FUNC name=imp.system
[0x00009720]> 

As we can see, r2 on OSX reports the address of system() as 0x9330 and the ELF entry point as 0x9720.

These addresses were actually incorrect. Curiously, I tried to run the same commands on Radare2 v1.7.0 on Linux. The Linux version displays the correct addresses:

$ r2 -v
radare2 1.7.0-git 0 @ linux-x86-32 git.1.6.0-964-g87dc54a
commit: 87dc54aa11e36d5f64cc602eb79caee5f1aef6a8 build: 2017-09-29__21:34:54
 
$ r2 file.bin
[0x0000974c]> is~system
vaddr=0x00009350 paddr=0x00001350 ord=022 fwd=NONE sz=16 bind=GLOBAL type=FUNC name=imp.system
[0x0000974c]> 

Comparing with actual addresses using gdb

(gdb)  print system
$1 = {<text variable, no debug info>} 0x9350 <system>
(gdb)  print _start
$2 = {<text variable, no debug info>} 0x974c <_start>

Address of system() is 0x9350 and the ELF entry point is 0x974c.

file.bin.zip

therealsaumil avatar Oct 02 '17 20:10 therealsaumil

Follow up update. This behaviour isn't exhibited on all ARM ELF binaries. For example, here is another binary, where the addresses are accurately displayed. I have been unable to pinpoint what the exact difference is between file.bin and file2.bin yet.

$ r2 file2.bin 
[0x00009870]> is~system
vaddr=0x00009438 paddr=0x00001438 ord=023 fwd=NONE sz=16 bind=GLOBAL type=FUNC name=imp.system
[0x00009870]> 

Comparing with actual addresses using gdb

(gdb)  print system
$1 = {<text variable, no debug info>} 0x9438 <system>
(gdb)  print _start
$2 = {<text variable, no debug info>} 0x9870 <_start>

In this case, r2's addresses match those from gdb. file2.bin.zip

therealsaumil avatar Oct 03 '17 13:10 therealsaumil

cant reproduce, i get ..330 on linux and mac

radare avatar Oct 04 '17 12:10 radare

The correct address for system() is 0x9350 as reported by gdb . I notice that I had an older build of r2 on my linux environment:

darwin-x86-64 git.1.6.0-965-g427fff4 linux-x86-32 git.1.6.0-964-g87dc54a

upgrading to linux-x86-32 git.1.6.0-965-g427fff4 also causes the same problem to appear on my linux environment. I conclude that the problem isn't with radare on mac vs. linux as I once suspected it to be, but overall it is incorrectly reporting RVAs in some ARM ELF binaries, not all.

therealsaumil avatar Oct 04 '17 21:10 therealsaumil

@therealsaumil can you provide the affected binary?

XVilka avatar Oct 12 '17 10:10 XVilka

Its here https://github.com/radare/radare2/files/1350287/file.bin.zip

On 12 Oct 2017, at 12:06, Anton Kochkov [email protected] wrote:

@therealsaumil can you provide the affected binary?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

radare avatar Oct 12 '17 10:10 radare

@XVilka I tested it with radare2 2.1.0-git 16423. The issue still persists.

therealsaumil avatar Oct 31 '17 06:10 therealsaumil

Issue still persists on radare2 3.0.0-git 19597

$ r2 file.bin
 -- Error: cannot yank negative sleep
[0x00009720]> is~system
022 0x00001330 0x00009330 GLOBAL   FUNC   16 imp.system
[0x00009720]>

The correct address for system() is 0x9350, and the correct _start address is 0x974c

therealsaumil avatar Sep 19 '18 02:09 therealsaumil