Use the same protocols in =+ and <file> Rizin's parameter

[caribpa]

Is your feature request related to a problem? Please describe.
The =+ command allows connecting to some protocols such as rap, tcp, and upd (among maybe others).

The problem is that it doesn't allow connecting to the same protocols available as <file> Rizin's parameter.

Describe the solution you'd like
Basically the opposite of what was reported #561, be able to do:

• rz -c '=+ gdb://localhost:9090/ ; =!= 0' --
• rz -c '=+ winedbg://localhost:9090/ ; =!= 0' --
• and so on for the other protocols

Describe alternatives you've considered
💔

Additional context
AFAIK, only the RAP protocol can be used as <file> parameter and =+:

• As server: rz rap://:8080
• As client using <file>: rz rap://localhost:8080/rizin
• As client using =+: rz -c '=+ rap://localhost:8080/rizin ; =!= 0' --

The same should be possible for other protocols.

The same limitations exist in radare2.

[ret2libc]

I can see the confusion indeed, but those are different things... gdb, winedbg, file://, zip://, etc. are IO plugins that say how to read/write a file. =+ however is about connecting to a remote rizin/radare instance and forwarding almost all commands as-is to the other instance.

So they do two different things, but, again, I can see the confusion indeed. This might be a good improvement to the book and/or to the help messages?

[caribpa]

I know that you can access to the IO plugins using the o command, but the fact that the following is allowed will always be confusing:

# rz rap://:8080 was executed in /bin in other terminal
$ rz --
> =+ rap://localhost:8080/rizin
# opened as fd = 1658
> o rap://localhost:8080/rizin
# Connecting to localhost, port 8080
# Connected to: localhost at port 8080
# rap connection was successful. open 1739

The point I tried to make (somehow) is that, ideally, these differences (io plugin vs protocol) could be abstracted, so that the user only have to think something like:

• o is for opening something in the foreground. I can have only one thing opened in the foreground.
• =+ is for opening something in the background. I can have multiple things opened in the background.

This protocol/io abstraction could eventually lead to converting the = family into something inside the & family (like &o).

And this conversion could maybe remove code-duplication?

Anyways, this is just me thinking out loud 🙂

[ret2libc]

* `o` is for opening something _in the foreground_. I can have _only one thing_ opened in the foreground.

It's not really like that.. You can have multiple files opened with o. I think this whole remote concept needs to be re-thinked well. Right now it is "forward all commands to a remote instance" AFAIK. Indeed > =+ rap://localhost:8080/rizin does not open a new file "locally", but it allows you to forward all commands to the server and it actually instruct the server to open the rizin binary, while o rap://localhost:8080/rizin actually opens a remote file as if it was local (each read/write operation goes on the network).

I do understand it's even hard to explain... Figure it's harder to understand for users :D I agree we should simplify the whole thing somehow, not sure how yet. Suggestions are welcome.

[caribpa]

It's not really like that..

I know, I said the following:

[...] so that the user only have to think something like:

Also, I didn't mention files in the two bullet points, I used the word something instead.

What I'm trying to say is: Let's unify/abstract the concept of files/io and remote, so that the user can use one single command for opening something in the foreground, and a different command for opening something in the background (and switching between what is currently in the foreground).

Example:

$ rz --
> o /bin/rizin
# Prompt changes to rizin's entrypoint
> o gdb://10.0.0.39:8080
# Prompt changes to the entrypoint of whatever gdb is serving
# A message saying that /bin/rizin was moved to a background fd appears
> &o
# 0 fd:6 /bin/rizin
> &o rap://10.0.0.254:9090/dbg://rizin
# opened as fd = 1146
> &o
# 0 fd:6 /bin/rizin
# 2 fd:8 rap://10.0.0.254:9090/dbg://rizin
> &o 0
# Prompt changes to local rizin's previous seek position
# A message saying that gdb://10.0.0.39:8080 was moved to a background fd appears
> &o
# 1 fd:7 gdb://10.0.0.39:8080
# 2 fd:8 rap://10.0.0.254:9090/dbg://rizin

[caribpa]

Possibly using &o 0 instead of o 0 for moving to the foreground is confusing (probably is better to use o 0 instead). Anyways, it is an example.

[ret2libc]

It's not really like that..

I know, I said the following:

[...] so that the user only have to think something like:

Also, I didn't mention files in the two bullet points, I used the word something instead.

What I'm trying to say is: Let's unify/abstract the concept of files/io and remote, so that the user can use one single command for opening something in the foreground, and a different command for opening something in the background (and switching between what is currently in the foreground).

Example:

$ rz --
> o /bin/rizin
# Prompt changes to rizin's entrypoint
> o gdb://10.0.0.39:8080
# Prompt changes to the entrypoint of whatever gdb is serving
# A message saying that /bin/rizin was moved to a background fd appears
> &o
# 0 fd:6 /bin/rizin
> &o rap://10.0.0.254:9090/dbg://rizin
# opened as fd = 1146
> &o
# 0 fd:6 /bin/rizin
# 2 fd:8 rap://10.0.0.254:9090/dbg://rizin
> &o 0
# Prompt changes to local rizin's previous seek position
# A message saying that gdb://10.0.0.39:8080 was moved to a background fd appears
> &o
# 1 fd:7 gdb://10.0.0.39:8080
# 2 fd:8 rap://10.0.0.254:9090/dbg://rizin

I'm not following you... You already have o that supports multiple something opened at the same time and only one of it is "current". Again, I see a need for improving the remote concept, but I am not sure how it relates to "foreground"/"backgroud" you are talking about here.

You also already have the & to execute some task in the backgroud (and by background here I mean background :D)

[caribpa]

Apologies for the poor explanation, clearly I am not expressing the idea in an understandable way.

I'll try to do it one last time 🙂

Step one: forget everything you know about rizin because you just traveled to a parallel dimension where a different rizin exists 🚀

In this other dimension, rizin uses the same command for opening files/io, remote connections, listening servers... everything! (Say: o)

Other dimension's rizin has the concept of "foreground" and "background" (or active/inactive, or current/not-current, or showing/not-showing... I'm not sure, they speak a slightly different English over there).

The thing is that other dimension's rizin applies the commands (s, pd, etc) to whatever is in the "foreground", updating the prompt seek accordingly (and the result/effect of the shell commands: ls, cd, etc).

Other dimension's rizin has only one command for listing everything that was opened (without caring if they are files, connections, remote files, etc, like listing opened buffers in emacs or vim). This command is also o without parameters. Things opened through remote connections show their file descriptor prefixed by their parent fd:

$ rz rap://10.0.0.50:8080/--
> o
# * 0 fd:6 rap://10.0.0.50:8080/--
> o /bin/rizin
> o
#   0 fd:6 rap://10.0.0.50:8080/--
# * 0.0 fd:7 /bin/rizin
> &o tcp://:9090//opt  # Starts in the background a TCP server serving remote /opt
> o
#   0 fd:6 rap://10.0.0.50:8080/--
# * 0.0 fd:7 /bin/rizin
#   0.1 fd:8 tcp://:9090//opt

Of course, other dimension's rizin figured out an easy way for opening things in the local machine (or in a different, previously opened, remote connection) if what's in the "foreground" is a remote connection. Though I'm still not sure what that "easy command" is 🙂

Returning to our dimension, the io/file and remote is confusing:

$ rz --
> o /bin/rizin ✅ 
> o rap://localhost:8080/malloc://512 ✅ 
> o http://localhost:8080 ✅ 
> o udp://localhost:8080 ❎ - Hmm
> o tcp://localhost:8080 ❎ - wat? http worked
> =+ tcp://localhost:8080 ✅ - Hmmm
> =+ http://localhost:8080 ✅ - mmmm
> =+ rap://localhost:8080/malloc://512 ✅ 
> o rap://:8080 ✅ 
> o tcp://:8080 ❎ - waa
> o http://:8080 ❎ - aaat?
> =t 8080 ✅ - 💣  
> =h 8080 ✅ - 💥  
> =: 8080 ✅ - 🤯  

For a newbie (who likely wouldn't care about if http is a plugin or tcp is not), this is way too chaotic and inconsistent.
Rizin newbies are happier and sleep better in the other dimension 😃

[ret2libc]

Thanks for the longer explanation.

Can I suggest that =+ is what emacsclient is to emacs? So you have one emacs server and potentially multiple emacsclient connecting to the same server. Do you think that emacsclient should connect to the emacs server the same as you open a file in emacs? That's what is for me the difference between =+ and o.

[caribpa]

Can I suggest that =+ is what emacsclient is to emacs? So you have one emacs server and potentially multiple emacsclient connecting to the same server. Do you think that emacsclient should connect to the emacs server the same as you open a file in emacs? That's what is for me the difference between =+ and o.

Sure think you made a good point here 🐃

Anyways, IMO modern emacs doesn't need the server-client functionality (same way the modern X server is 99.99% of the time used by one client, thus the reason Wayland will hopefully take over when some graphic card manufactures stop being annoying).

In emacs, the whole reason this was relevant (in sane practice) was due to poor/incomplete terminal implementations, so you could use your super-terminal for your sysadmin tasks allowing opening the files in emacs without suffering the slowness and bugs from the firsts built-in emacs terminals. Of course you could start the server and control it from remote machines, but exposing your system to the internet like that is not worthy considering the modern alternatives:
Nowadays, thanks to vterm.el and (the correct configuration in the shell-side), you can forget about this server-client mode (it tracks the current directory even in remote hosts). In the case of non-POSIX systems, you can continue the party with eshell, which supports out-of-the-box integration with Tramp (remote capabilities). And for all other non-shell related tasks, Tramp allows you to send the emacs powers over the wire without the need of a server.

After all this emacs talk, what I want to say regarding Rizin is more or less the same: I really don't see how Rizin ("modern" radare2) benefits from this (attempted) separation of o and =+ (considering there are exceptions for rap and some other inconsistencies), without providing really any upside other than confusing the user.

[ret2libc]

After all this emacs talk, what I want to say regarding Rizin is more or less the same: I really don't see how Rizin ("modern" radare2) benefits from this (attempted) separation of o and =+ (considering there are exceptions for rap and some other inconsistencies), without providing really any upside other than confusing the user.

Now, I don't know all those emacs stuff... But it seems to me you are saying that nowadays the client/server implementation is not used/worth. Now, independently of whether I agree or not, that's the same as saying "client/server in rizin shall not be used/shall be removed". It is not the same as saying "client/server rizin is the same as opening a file remotely". I hope it's clear what I mean.

Again, we might think whether it's worth having this client/server possibility within Rizin (and I believe I've heard people saying in some cases it is useful, but I would indeed be happy to think more about this) and making it better, but I do not think it is a good thing to mix "client/server concept" with "opening a remote file".

[caribpa]

Sure thing I understand the usefulness of the server/client Rizin capabilities. I went so far with the emacs argument that I ended up communicating the wrong thing.

[...] but I do not think it is a good thing to mix "client/server concept" with "opening a remote file".

If this is indeed the intention, then it is really confusing that o opens files (and other stuff) locally and remotely, but also o can be used to create a listening server: o rap://:8080

[caribpa]

So, for consistency's sake, either:

• Completely separate o from = (rap, and maybe others), though no longer this conveniency will exist: rz rap://:8080
• Unify everything in one place (abstracting files vs client/server), thus this will be possible: rz tcp://:8080

[ret2libc]

but also o can be used to create a listening server: o rap://:8080

I think this is the problem indeed! I see no reason why o rap://:8080 should create a listening server. So yes, I see an inconsistency here. Probably we should clearly have a separate flag (if there isn't one already) to start rizin in server mode.

How does that sound?

[caribpa]

It was a hit and miss but we finally got there, thank you for your patience! 🙂

[...] Probably we should clearly have a separate flag (if there isn't one already) to start rizin in server mode.
How does that sound?

Honestly, I don't know, because there are already 48 flags 😆

Also, to make things amazingly confusing, using a = as <file> parameter when starting Rizin will make Rizin read from stdin (when, traditionally, - in the shell world, even POSIX, means to read from stdin); then = in the interactive command line, refers to the client/server family 🤯

Now, will this be 1 flag per server type, or just one flag for the rap server? How about the raps server, another flag?

How would it look like when starting a listening server? Does the user have to pass -- or something else as a file (even though it won't be used in rap)?
Example with the -S as the "listening server mode" and r as "rap": rz -Sr 8080 --

Somehow the current behavior looks less cryptic: rz rap://:8080 🤷‍♂️

Man, it looks like I'm mad after re-reading what I just wrote. Don't take it that way plz 👼

[ret2libc]

I think it is alright to have the form <protocol>://<address>:<port> but that would have to be specified after a flag and not directly as a file. So for example rizin --server rap://:8080.

[caribpa]

Certainly, that syntax clearly conveys what rizin is doing 👍

Though unsure why <address> should be necessary, as I don't think anybody would want to create a server only to be limited to localhost (unless this is how Cutter works or I am missing something, I don't know).

Assuming <address> is not necessary, it could make sense to remove the :// so that the command looks like:
rz --server rap:8080

[ret2libc]

Certainly, that syntax clearly conveys what rizin is doing 👍

Though unsure why <address> should be necessary, as I don't think anybody would want to create a server only to be limited to localhost (unless this is how Cutter works or I am missing something, I don't know).

Assuming <address> is not necessary, it could make sense to remove the :// so that the command looks like:
rz --server rap:8080

It's common in all tools to give the possibility to specify the listen address. I don't see why we should limit ourselves.

[caribpa]

Sure thing.

I'm just questioning the use-case 🙂

[ret2libc]

Sure thing.

I'm just questioning the use-case 🙂

I think there are use-cases for every network service to be limited on a particular network. I do that with different tools every time (e.g. a dns server only on one network, another dns server on another network, etc.).

Anyway, I would either close this issue or transform it into: "Enforce usage of -S/--server flag to use rizin in server mode", or something like that.

[caribpa]

Fair enough 👍

Now, to be consistent, the user should be able to specify <address> when creating all servers from the interactive command line, this doesn't seem to be possible/not documented in:

• =h
• =g
• =&:

[ret2libc]

Thanks for creating the specific issues. I'd suggest we close this issue as we are not going to use the same protocols in =+ and <file>.

And yes, I think all protocols should be able to specify the specific address to listen to. By the way, additional context about why that might be necessary is: you want a localhost only server or a server accessible on the network to debug from other machines (or maybe from another VM attached through a virtual network).