Add support for me

[snare]

I looked at this briefly once before and it seemed like a bit of a pain because I want to be able to spin off a background thread for the webserver and still have the user have full interactive access to the r2 CLI, so r2pipe wasn't really the right tool for the job. I've definitely intended to revisit this and I will have a look again soon :)

On 14 Jun 2016, at 3:06 AM, radare notifications@github.com wrote:

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

[radare]

There’s no problem in spawning the webserver from r2pipe:

r2 = r2pipe.open(“/bin/ls”) r2.cmd(“=h&”) …

well. the only problem is that the webserver running in background uses no mutexes at all and can cause race condition and random crashes if using the shell intensively at the same time the webserver receives requests.

On 14 Jun 2016, at 19:12, snare notifications@github.com wrote:

I looked at this briefly once before and it seemed like a bit of a pain because I want to be able to spin off a background thread for the webserver and still have the user have full interactive access to the r2 CLI, so r2pipe wasn't really the right tool for the job. I've definitely intended to revisit this and I will have a look again soon :)

On 14 Jun 2016, at 3:06 AM, radare notifications@github.com wrote:

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

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snare/voltron/issues/152#issuecomment-225950420, or mute the thread https://github.com/notifications/unsubscribe/AA3-lkkVpJMNbW9Bz6IyaL_B9rGdZ18Vks5qLuEagaJpZM4I1KHp.

[snare]

Maybe I'm misunderstanding, but I thought r2pipe was just for remote-controlling a headless r2 instance. Can the user interact directly with the r2 CLI when using r2pipe? Or would Voltron need to implement a line editor and pass commands to r2 etc? I'd rather not do that.

Re: race conditions, Voltron actually does do locking where appropriate. LLDB provides an API for this which Voltron uses, GDB does not (and crashes horribly if you try to do things from a background thread). For this reason Voltron supports sync and async requests. Blocking requests are queued and then dispatched on the main thread when the debugger "stops" again (ie. hits a breakpoint or steps or whatever - the "stop_hook" handler in GDB). Non-blocking requests are dispatched immediately regardless of the debugger state. The LLDB adaptor supports async, but the GDB adaptor only supports sync. The built-in views support both modes, and will use async if it's available (meaning views can be updated immediately upon launch rather than waiting for the first time the debugger stops, etc).

[radare]

r2pipe is the simplest way to talk with r2. And by talking i mean, being able to run a command and get the output. R2Pipe works on several channels and its implemented for many programming languages.

The channels r2pipe can talk are:

• dlopen+dlsym to call r_core_cmd_str()
• stdin/stdout with null terminated strings
• rlang by sharing a pointer of the function
• http
• rap
• tcp
• pipes (socket files)
• ...

and there are probably more ways to use r2pipe that i just dont think of right now :P

you can spawn the r2 webserver in background using the =h& command. this way you can connect blessr2 or any other r2pipe-http powered interface to talk with r2 without blocking the shell.

I have an idea for fixing those race conditions in an easy way... just need to find 5m of spare time to implement and test it properly.

r2pipe api is sync for python, but there's a work-in-progress support for async using promises. async r2pipe works by queieing the pending commands.

if you look at blessr2 you'll see what im talking about :)

[radare]

http://radare.org/r/blessr2.html

[snare]

OK cool I'll have a look, thanks!

[snare]

@radare is there a way I can get a callback each time the debugger is stepped or a breakpoint is hit etc? Voltron relies on the stop_hook mechanisms in GDB and LLDB to be informed when the debugger state has changed so it can update its displays. I looked at blessr2 and it doesn't seem to update if the debugger is stepped from within the r2 console.

If not, I might have to look at writing a C plugin for r2 rather than using r2pipe I guess?

[snare]

I've got about 3/4 of a debugger adapter class for r2 going so Voltron can talk to r2 via r2pipe to get register state, read memory (tho memory read isn't working properly per the issue I opened), etc, but getting a callback to update the view state is gonna be a showstopper if it's not possible.

[radare]

you can use di to know why the process is stopped. adding callbacks in a sync api is usually a bad idea because it can turn into infinite loops and such. if you step or continue, the api will hold you until its done. if you are using r2pipe use the async api for that, so you can get a “callback” when the process stops. and that will be a blocking operation while the process is running

On 15 Oct 2016, at 08:18, snare notifications@github.com wrote:

@radare https://github.com/radare is there a way I can get a callback each time the debugger is stepped or a breakpoint is hit etc? Voltron relies on the stop_hook mechanisms in GDB and LLDB to be informed when the debugger state has changed so it can update its displays. I looked at blessr2 and it doesn't seem to update if the debugger is stepped from within the r2 console.

If not, I might have to look at writing a C plugin for r2 rather than using r2pipe I guess?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snare/voltron/issues/152#issuecomment-253965895, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lo-dChfjrIo5fcl-gC4nPbMeo1mPks5q0HBTgaJpZM4I1KHp.

[radare]

awesome! i have some spare time that i may use for r2 the next week :) will try to priorize your bug reports.

thanks

On 15 Oct 2016, at 08:20, snare notifications@github.com wrote:

I've got about 3/4 of a debugger adapter class for r2 going so Voltron can talk to r2 via r2pipe to get register state, read memory (tho memory read isn't working properly per the issue I opened), etc, but getting a callback to update the view state is gonna be a showstopper if it's not possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snare/voltron/issues/152#issuecomment-253965938, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lvzfLqv_Imf-rkN0Vhntdr9xSpYaks5q0HCegaJpZM4I1KHp.

[snare]

OK thanks, I'll try the di command. Voltron doesn't really use callbacks as such - the requests on the webserver block until the stop_hook calls the Voltron server's dispatch_queue() function to dispatch any blocked requests. Sounds fairly similar to the way the r2 API works, so that should do the job. Will have a go at it tomorrow.

[snare]

Does the Python r2pipe support async? This page indicates it doesn't. If I call di from the web server while the process is running, it doesn't block and I just get something like this returned immediately:

[http://localhost:9090/cmd/]> di
type=unknown
signal=SIGINT
signum=2
sigpid=15443
addr=0x0
inbp=false
pid=15443
tid=1
uid=-1
gid=-1
cmdline=/voltron/tests/inferior_linux
stopreason=12

[snare]

And in the r2 console:

[0x00400667]> dc
[HTTP] 127.0.0.1:50466 /cmd/di

[snare]

BTW just to be clear, I mean stepping or continuing the process from the r2 CLI. Voltron does not issue the commands that do the stepping or continuation. It is designed such that it bolts onto the "side" of the debugger, rather than sits on top of it, so the user still has their normal interactions with the debugger's CLI. So a use case would be

1. Load binary into r2
2. Launch r2 web server
3. Launch r2->voltron proxy (this is prob gonna have to be the way it works for now until I maybe rework the Voltron client to support talking to the r2 web server directly)
4. User sets a breakpoint in r2 CLI
5. User continues process in r2 CLI
6. Debugger stops at breakpoint - something here has to notify Voltron that the debugger has stopped and the views need to be updated (as I said, in GDB and LLDB, the stop_hook function calls into Voltron and goes "yo debugger has stopped, dispatch any queued requests")
7. Voltron's views that had blocked requests queued have their requests returned with the new data to update the views

[snare]

The way that it works with GDB/LLDB is:

1. Voltron view makes a request to the web server, which blocks
2. User steps in debugger
3. Stop hook calls dispatch_queue which fulfils blocking requests which are then returned to the views to render the new data
4. View then immediately issues a new blocking request, waiting for the next debugger stop

[radare]

Re

On Oct 16, 2016 4:30 AM, "snare" notifications@github.com wrote:

Does the Python r2pipe support async? [This page]( https://github.com/radare/radare2/wiki/R2PipeAPI] indicates it doesn't. If I call di from the web server while the process is running, it doesn't block and I just get something like this returned immediately:

The async python inplementation is in a separate module, its done for py2 and py3 but it should be merge into the main python r2pipe implementation

Check the r2pipe repo for the python-async directory

[http://localhost:9090/cmd/]> di type=unknown signal=SIGINT signum=2 sigpid=15443 addr=0x0 inbp=false pid=15443 tid=1 uid=-1 gid=-1 cmdline=/voltron/tests/inferior_linux stopreason=12

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

[radare]

Yeah it doesnt block bwcause you arw running the webserver in a thread

On Oct 16, 2016 4:30 AM, "snare" notifications@github.com wrote:

Does the Python r2pipe support async? [This page](https://github.com/ radare/radare2/wiki/R2PipeAPI] indicates it doesn't. If I call di from the web server while the process is running, it doesn't block and I just get something like this returned immediately:

[http://localhost:9090/cmd/]> di type=unknown signal=SIGINT signum=2 sigpid=15443 addr=0x0 inbp=false pid=15443 tid=1 uid=-1 gid=-1 cmdline=/voltron/tests/inferior_linux stopreason=12

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snare/voltron/issues/152#issuecomment-254023356, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-ljvrI6IUV9GwTPY3SH2eq9oywD7Wks5q0YwqgaJpZM4I1KHp .

[snare]

Ah ok, I'll check the python-async implementation. Thank you.

[radare]

cool! would you like to do the merge of both apis?

On 16 Oct 2016, at 11:58, snare notifications@github.com wrote:

Ah ok, I'll check the python-async implementation. Thank you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snare/voltron/issues/152#issuecomment-254037845, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-llDXXmF_XPp9wYVVk6_xhI_bx4adks5q0fVggaJpZM4I1KHp.

[snare]

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "r2pipe/open_base.py", line 202, in cmd
    return self._cmd(cmd, **kwargs)
TypeError: _cmd_http() got an unexpected keyword argument 'callback'

So I gather the async API only works with the pipe method or something else?

[cr0hn]

Hi| @snare are you using Python 2 or 3?

In Python 2, currently, async is not implemented. We're working on that. I hope this feature are implemented soon

[snare]

Oh my bad @radare said that earlier. I was using Python 2. I can try it with 3 for development (Voltron supports both).

[ysf]

I'm looking to use voltron with radare2, is this possible yet? Is there a way to help? Thanks for all your work!

[duraki]

Any update on this @snare, pretty please?

[duraki]

@radare / @snare can we help somehow?

[radare]

Ask if u need anything from me in order to make that integration happen

On 7 Nov 2018, at 15:05, ❂ notifications@github.com wrote:

@radare / @snare can we help somehow?

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

[duraki]

@snare could you at least PR your changes for @radare so others can continue where you left off?