search

radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.68k stars 3k forks source link

wrong path when debuging with rarun2 #2146

Closed gozes closed 4 years ago

gozes commented 9 years ago

when I run something like r2 -d rarun2 program=./mybin stdin=123456 the assume path is set to that of rarun2 and not to program. I was using a 2 day old build, but at @XVilka request on irc, I pulled todays build and tested. The issue remains.

this is the output when I start a dbg session

Process with PID 19037 started...
PID = 19037
pid = 19037 tid = 19037
r_debug_select: 19037 19037
Using BADDR 0x400000
**Asuming filepath** /usr/bin/rarun2
bits 64
pid = 19037 tid = 19037

@XVilka referenced this commit on irc before asking me to rebuild. https://github.com/radare/radare2/commit/705e4d56bfede047b81ff7fa085316a1b5ea7ad8

OS: Linux

cvuchener commented 9 years ago

I am still curious about what the r_bin_load_io* functions do (that's where that message comes from).

These functions are not called when the program execve. Still the data remains correct as it comes from ptrace I guess. So why do we need the filepath of the first program started by the command line (that can be irrelevant here with rarun2)?

Do you have any other issue than this filepath and the typo in "Assuming"?

gozes commented 9 years ago

Yes, because rarun2 is loaded instead of the binary I'm trying to dbg. If you run s main you end up in rarun2 main function. In fact, the binary I specify is not even loaded it to the dbg session. If I run db main I will land in rarun2 main if I then do dc I can see that it exist rarun2 and jmp to invalid memory. There is no trace of my binary in the dbg session. In effect, I am debugging rarun2 and not my binary.

cvuchener commented 9 years ago

Does rarun2 starts your program if you run it without r2?

cvuchener commented 9 years ago

I have that issue too.

I made a simple executable that call execve. In radare, the program was interrupted when calling execve and I could see the new code with "pd".

I cannot do the same with rarun2. /proc//exe indicate the correct binary, and i can see printf from my program but I continue to see rarun2 code in radare.

Maybe my test programs were too similar. Something with the analysis?

radare commented 9 years ago

Use r2 -d -e dbg.profile=profile.r2 --

On 26 Feb 2015, at 21:46, Clément Vuchener notifications@github.com wrote:

I have that issue too.

I made a simple executable that call execve. In radare, the program was interrupted when calling execve and I could see the new code with "pd".

I cannot do the same with rarun2. /proc//exe indicate the correct binary but I continue to see rarun2 code in radare.

— Reply to this email directly or view it on GitHub.

gozes commented 9 years ago

I tried this r2 -d rarun2 program=./crkme1sys stdin=123456 -e dbg.profile=profile.r2 -- and r2 -d crkme1sys -e dbg.profile=profile.r2 -- in both cases nothing is loaded.

the r2 prompt is all 0000000

cvuchener commented 9 years ago

The debug profile method works fine for me if I use the binary path instead of "--".

When using "radare2 -d rarun2 program=./myprogram", I was wrong: the data is good but the flags are all wrong. That mislead me. That happen with rarun2 or my test program that use execve.

Is there a easier way to rebuild all that information than sourcing a previously exported flag list?

radare commented 9 years ago

Im not at home so i cant test it properly. But the way rarun2 is suposed to be used from r2 is to spawn it by setting the dbg.profile var.

Obviously the value must be the name of the rarun2 profile, and the file should be the filename or --, it used to work like this few days ago iirc. If you are running rarun2 from r2 it will asume you are analizing this binary and the baddr in case of aslr and bin info will be wrong at the moment of execveing the real program

On 26 Feb 2015, at 22:49, Clément Vuchener notifications@github.com wrote:

The debug profile method works fine for me if I use the binary path instead of "--".

When using "radare2 -d rarun2 program=./myprogram", I was wrong: the data is good but the flags are all wrong. That mislead me. That happen with rarun2 or my test program that use execve.

Is there a easier way to rebuild all that information than sourcing a previously exported flag list?

— Reply to this email directly or view it on GitHub.

cvuchener commented 9 years ago

"--" does not load or run anything for me.

$ r2 -d -e dbg.profile=exec-test1.r2 --
 -- You can debug a program from the graph view ('ag') using standard radare2 commands
[0x00000000]> dc
[0x00000000]>
$ r2 -d -e dbg.profile=exec-test1.r2 exec-test1
Process with PID 7620 started...
PID = 7620
pid = 7620 tid = 7620
r_debug_select: 7620 7620
Using BADDR 0x400000
Asuming filepath ./exec-test1
bits 64
pid = 7620 tid = 7620
 -- This is amazing...
[0x7fd66f7aecf0]> dc
I am Test 1
radare commented 9 years ago

Is the second run honoring the profile rules and loading the proper bin aslr'd vaddr?

On 26 Feb 2015, at 23:09, Clément Vuchener notifications@github.com wrote:

"--" does not load or run anything for me.

$ r2 -d -e dbg.profile=exec-test1.r2 -- -- You can debug a program from the graph view ('ag') using standard radare2 commands [0x00000000]> dc [0x00000000]> $ r2 -d -e dbg.profile=exec-test1.r2 exec-test1 Process with PID 7620 started... PID = 7620 pid = 7620 tid = 7620 r_debug_select: 7620 7620 Using BADDR 0x400000 Asuming filepath ./exec-test1 bits 64 pid = 7620 tid = 7620 -- This is amazing... [0x7fd66f7aecf0]> dc I am Test 1 — Reply to this email directly or view it on GitHub.

cvuchener commented 9 years ago

How do you do that? My profile is just:

program=./exec-test1

Where is the documentation on debug profile? I did not find anything in the book and doc/intro.md contains examples with r2 -d rarun2 ....

radare commented 9 years ago

rarun2 > profile vim profile

On 27 Feb 2015, at 00:00, Clément Vuchener notifications@github.com wrote:

How do you do that? My profile is just:

program=./exec-test1 Where is the documentation on debug profile? I did not find anything in the book and doc/intro.md contains examples with r2 -d rarun2 ....

— Reply to this email directly or view it on GitHub.

radare commented 9 years ago

For doc:

man rarun2

On 27 Feb 2015, at 00:00, Clément Vuchener notifications@github.com wrote:

How do you do that? My profile is just:

program=./exec-test1 Where is the documentation on debug profile? I did not find anything in the book and doc/intro.md contains examples with r2 -d rarun2 ....

— Reply to this email directly or view it on GitHub.

cvuchener commented 9 years ago

rarun2 > profile vim profile

That's not very helpful

For doc: man rarun2

Nothing about "aslr'd vaddr" or dbg.profile in here.

radare commented 9 years ago

About aslrd baddr its a basic concept, not r2 specific. It means that if you have aslr enabled the base address of the program will be different on each execution. Only for PIE programs. R2 rebases all the rbin info when this happens.

About dbg.profile its an eval var, so the help is in e??dbg.profile

On 27 Feb 2015, at 00:29, Clément Vuchener notifications@github.com wrote:

rarun2 > profile vim profile

That's not very helpful

For doc: man rarun2

Nothing about "aslr'd vaddr" or dbg.profile in here.

— Reply to this email directly or view it on GitHub.

gozes commented 9 years ago

I'm confuse, how exactly do get it work or is this a bug?

radare commented 9 years ago

http://radare.tv/a/25

radare commented 9 years ago

It is not a bug. Probably a feature enhacement to make rarun2 usage more accessible from different running methods

On 27 Feb 2015, at 15:15, gozes notifications@github.com wrote:

I'm confuse, how exactly do get it work or is this a bug?

— Reply to this email directly or view it on GitHub.

gozes commented 9 years ago

@radare would it be simpler to have something like r2 --arg=123 --arg=345 or r2 --stdin=23445

radare commented 9 years ago

no getoptlong please. it breaks completely the unix philosophy and better if you dont read how it is implemented by GNU.

getopt is more than enough.

an option would be to launch r2 from rarun2

rarun2 dbgwith=r2 program=/bin/ls arg1=...

another option could be to handle rarun2 properly when launching it from r2, which will be probably more difficult to do. and the usage would be:

r2 -d rarun2 program=/bin/ls arg1=lala

r2 can asume that if you are debugging 'rarun2' it will spawn another process and must use a rarun profile instead of a direct fork+attach. but this is probably a wrong assumption.

the debugger backend in r2 can debug with and without rarun2 api and the switch depends only when the dbg.profile var is set.

On 02/27/2015 04:01 PM, gozes wrote:

@radare would it be simpler to have something like r2 --arg=123 --arg=345 or r2 --stdin=23445

Reply to this email directly or view it on GitHub: https://github.com/radare/radare2/issues/2146#issuecomment-76407499

gozes commented 9 years ago

I like the second option because it consistent with what is on the doc and the cheetsheet

ret2libc commented 4 years ago

I'm going to close this as it was stale for many years and I think there are already alternatives right now. You can use the option -r of radare2 (-r [rarun2] specify rarun2 profile to load (same as -e dbg.profile=X)) or just radare2 -d /bin/ls /home if you want to pass arguments.

Feel free to reopen the issue if you feel the original problem was not addressed.