radare2
radare2 copied to clipboard
Incorrect virtual addresses from ARM binaries in Radare2 v1.7.0 on OSX
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.
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
cant reproduce, i get ..330 on linux and mac
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 can you provide the affected binary?
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.
@XVilka I tested it with radare2 2.1.0-git 16423
. The issue still persists.
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