Radare2: -m not applied to raw binaries with izz

[guedou]

Work environment

2.5.0 on Debian

Build an example binary

$ r2 - -qc 'w radare2; wtf test.bin 7'
Dumped 7 bytes from 0x00000000 into test.bin

Expected behavior

I would like to see the string address at 0xC00000 not at 0x0

Actual behavior

$ r2 test.bin -qc 'izz'
000 0x00000000 0x00000000   7   7 () ascii radare2

$ r2 test.bin -qc 'izz' -m 0xC00000
000 0x00000000 0x00000000   7   7 () ascii radare2

[XVilka]

2.5.0 on Debian...

[Maijin]

Reproduced in master

[Maijin]

But yeah please test on master the issue you report please

[Maijin]

This issue is https://github.com/radareorg/cutter/issues/516

[guedou]

Sorry, this was a typo and misleading. I meant 2.5.0+
I had the issue on 2.5.0 and also checked on master.

The issue also affects rabin2.

[radare]

Thats expected behaviour. Wtf writes from current seek not from map address if u want this use sparse:// or bigger mallocs

On 12 Jul 2018, at 23:33, Guillaume Valadon [e-mail] wrote:

Work environment

2.5.0 on Debian

Build an example binary

$ r2 - -qc 'w radare2; wtf test.bin 7'
Dumped 7 bytes from 0x00000000 into test.bin
Expected behavior

I would like to see the string address at 0xC00000 not at 0x0

Actual behavior

$ r2 test.bin -qc 'izz'
000 0x00000000 0x00000000 7 7 () ascii radare2

$ r2 test.bin -qc 'izz' -m 0xC00000
000 0x00000000 0x00000000 7 7 () ascii radare2
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[guedou]

wtf works fine.

I think that izz should use the offset specified by the -m flag.

[radare]

Preferibly mever pass flags after the filename. Thats a gnuism. But i see your issue now

On 13 Jul 2018, at 09:36, Guillaume Valadon [e-mail] wrote:

wtf works fine.

I think that izz should use the offset specified by the -m flag.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[Maijin]

@xarkes can you confirm?

[guedou]

@Maijin not fixed on current master.

$ r2 -v
radare2 2.9.0-git 19085 @ darwin-x86-64 git.2.8.0-271-gaa35e11
commit: aa35e11e2eafc40c1beff98c34d287eedcc1965d build: 2018-08-31__12:47:36

$ r2 -qc 'izz' -m 0xC00000 test.bin 
WARNING: using oba to load the syminfo from different mapaddress.
TODO: Must use the API instead of running commands to speedup loading times.
000 0x00000000 0x00000000   7   7 () ascii radare2

[Maijin]

not sure why @radare closed this then, reopened

[radare]

Sorry missread the replies

On 31 Aug 2018, at 13:28, Maijin [e-mail] wrote:

not sure why @radare closed this then, reopened

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

[radare]

the thing is...maps are unlinked to rbin, because thats a mapped binary, so izz works thru rbin and have no way to know in which address has been mapped.

[radare]

better use /z for that case maybe until we refactor rbin to hold io information like associated fd and maps

[guedou]

Thanks for the tip! I use izz with r2pipe so I am currently fixing the offset on my side.

[ret2libc]

Removing 3.0 milestone from this since a RBin refactoring will hardly land in 3 days :)

[radare]

this fix have nothing to do with refactoring rbin.

please discuss the issues before doing those changes. because i have been asking for this feedbackf or 2 weeks and nobody answered anything.

the fix for this is probably 1 line change and requires no changes in rbin

On 12 Oct 2018, at 14:39, Riccardo Schirone [e-mail] wrote:

Removing 3.0 milestone from this since a RBin refactoring will hardly land in 3 days :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/10722#issuecomment-429311542, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lk9go0REuI0aeLV2cCICRtEBGxoNks5ukI2HgaJpZM4VN1i9.

[Maijin]

@xarkes ^

[xarkes]

As a reminder, the Strings widget in Cutter is often broken because of this.
https://github.com/radareorg/cutter/issues/516

[ITAYC0HEN]

What's the plan for fixing this?

$ r2 -m 999999 /bin/echo

[0x000f5a3f]> iz
[Strings]
Num Paddr      Vaddr      Len Size Section  Type  String
000 0x00004902 0x00404902   4   5 (.rodata) ascii echo
001 0x00004907 0x00404907  15  16 (.rodata) ascii test invocation
...
[0x000f5a3f]> px @ 0x00404902
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00404902  ffff ffff ffff ffff ffff ffff ffff ffff  ................
0x00404912  ffff ffff ffff ffff ffff ffff ffff ffff  ................
...

[ITAYC0HEN]

ping - RBin refactoring handles this already?

[radare]

Not solved yet andbyes its part of the required refactoring

On 17 Feb 2019, at 07:23, Itay Cohen [e-mail] wrote:

ping - RBin refactoring handles this already?

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

[ITAYC0HEN]

seems like there are slight improvements in this.
Now at least the mapped address shown under vaddr column. Still, nothing really in this address.

r2 -m 0x999999 /bin/echo
[0x00999999]> iz
[Strings]
nth paddr      vaddr      len size section type    string
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――
0   0x000061c0 0x0099fb59 5   6    .rodata ascii   usage
1   0x000061c6 0x0099fb5f 4   5    .rodata ascii   echo
2   0x000061cb 0x0099fb64 10  11   .rodata ascii   src/echo.c
3   0x000061d6 0x0099fb6f 22  23   .rodata ascii   status == EXIT_SUCCESS
4   0x000061ef 0x0099fb88 15  16   .rodata ascii   test invocation
...
...



[0x00999999]> px @ 0x0099fb59
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x0099fb59  ffff ffff ffff ffff ffff ffff ffff ffff  ................
0x0099fb69  ffff ffff ffff ffff ffff ffff ffff ffff  ................

[0x00999999]> px @ 0x000061c0
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x000061c0  7573 6167 6500 6563 686f 0073 7263 2f65  usage.echo.src/e
0x000061d0  6368 6f2e 6300 7374 6174 7573 203d 3d20  cho.c.status ==