search

radareorg / radare2

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

Separating `m` commands into the external plugin #17043

Closed XVilka closed 4 years ago

XVilka commented 4 years ago

Currently radare2 relies on GPL-only code from GRUB for any of the "mount" commands (m). On the other hand, most users don't need this feature, moreover it uses quite outdated code (from GRUB). My suggestion is to move it into the separate repository

cc @unixfreaxjp

trufae commented 4 years ago

Just to clarify:

I would like to have non-gpl filesystems supported in r2 master and for them i would say the most important ones to be supported are:

At least those are the ones i have always used. So maybe I can sync code from *BSD instead of GRUB to solve the license problems and avoid to hack on such stuff because kernel code is safe, bootloader one is not.

For routers squashfs and jffs are interesting, but there are over 9000 modified versions of them and i started to implement a tweakeable squahsfs plugin, but i solved my needs before finishing the plugin so that never got merged.

XVilka commented 4 years ago

From my experience there are many various SquashFS, JFFS, YAFFS, EXT, etc modifications. I recommend to use the proper tools for that, e.g.

ret2libc commented 4 years ago

AFAIR there is also a CVE opened for the grub code we ship in radare2.

trufae commented 4 years ago

I based my plugin on this exact project squashfs-tools-ng.

@ret2libc can you point to that specific cve?

ret2libc commented 4 years ago

@trufae https://github.com/radareorg/radare2/issues/11413

wargio commented 4 years ago

we probably need to write down in a comment from which commit and version it comes from so we can track CVEs on these.

unixfreaxjp commented 4 years ago

This is my feedback: @XVilka cc: @trufae

There are two major functionalities in radare2, 1) binary analysis and 2) forensics. In my community many people are using r2 as one of forensics tools for incident handling, and a large amount of people in #R2JP are on DFIR usage. The m command as shell, is helping a lot of DFIR analysis for people in trouble caused by cyber attacks until today. The m command as shell is also being there for us for DFIR purpose for around 10years already.

In forensics on analyzing (raw) images, either on incidents, or, when we found an unknown suspicious objects, we also rely much on the the m commands (m), . For DFIR people it is known as magic shell command more than mount.

The usage for "mount" commands (m) can be as native built on r2 also, if we must install r2 in an instance as hot incident response handling, meaning, we may need to buildr2 (if binary basis can not work) and using "mount" commands (m) afterward, and this is successfully done at this moments in NAS, servers investigation in multiple operating system (which is NOT only desktops), IoT which some of them are in different kind of CPU too.

Dropping the m command, shell in radare2. will drop this popular magic feature, a decision that you may regret in the future. and I see it as the same as your pdc's "stripping off" plan, if you want to push it out to repository, can you commit to DFIR users to maintain it as per it is now? If so announce that and show your commitment. By commitment I means in all CPU that is currently m command works with. And this means also at least Linux, FreeBSD, Windows, OSX and etc OS. Not to mention I even compile r2 on Solaris SPARC for incidents we have in some cases.

It is not political, and this is a simply a downgrade of features to "strip off" main shell functionalities which many of us find it useful. You may don't care, but right now pdc does not work anymore in 32bit platform , yes this goes for Linux, xBSD, maybe Windows too, and I bet you don't see it coming in the CI tests do you? And that caused huge deal of problem already. Nobody from r2dev has made announcement about it. And people are talking already about this matter.

Our community and I at this moment don't see plugin has the same supportive quality on platform as native codes, pdd was working on FreeBSD in r2con2018, and now was NOT. This is also without any announcement what so ever, even you all know I use pdd in my presentation in R2CON2018, right?
Having said those, we have the doubt that m command will be supported as per native quality as right now, unless you make a proper announcement to the users (which we "are" your users too per se) .

With all due respect, please research the wide-rage usage of radare2 by many kind of people, and many ways and platforms, that your users are currently doing before you allegedly think such of "this command is unnecessary for our purpose so let's get it off because (in example) it's not parallel with our GUI plan, so let's put it on plugin and let it rot in there, hahaha!".

Again, I humbly remind the dev people again, please communicate more with your users, which is not only me, by "1. announcement" of what is really under your mind with your road map and what you are going to do with the future. And "2. commitment" to not causing damage in features you think "unnecessary".

What you think "unnecessary" could be "a must have " for your segment of users.

unixfreaxjp commented 4 years ago

additional:

What happened with pdc "stripping-off" plan has been creating some shock wave, and this m shell command "stripping-off" talk is coming up too. Given the moral responsibility I have by introducing radare2 to several communities, this "overhaul plans" is now entering severe area that I can not let it go without , it is not fair for the users to not knowing about your intention, so I will share this discussion to DFIR folks, R2JP folks and others to be prepared of whatever is going to happen in the future.

XVilka commented 4 years ago

This is why I CCed you, to ask your opinion.

XVilka commented 4 years ago

And for pdc not working on FreeBSD please open an issue. It's hard to track everything. If we create tests for it, it will be checked on all supported platforms by our CI infrastructure.

unixfreaxjp commented 4 years ago

And for pdc not working on FreeBSD

Nope. It is in both recent FreeBSD and Linux too on 32bits, maybe embedded cpu are affected too!

Anton, you know me and my intention well along this time. I told you many times that CI will miss stuff.

The PoC: click this link to see Image saved in Imgur

unixfreaxjp commented 4 years ago

@wargio

we probably need to write down in a comment (etc)

Hi Giovanni, humbly hope you are well during Covid. But before go to this issue (see above), would you please care to see why pdd was worked in R2CON2018 in Latest FreeBSD and why NOW is it not ? It's a serious downgrade for users, if you leave it as it is.

If you don't want to support FreeBSD anymore, say it by announcement in r2dec page please.

unixfreaxjp commented 4 years ago

reference: https://github.com/radareorg/radare2/issues/6773

wargio commented 4 years ago

@wargio

we probably need to write down in a comment (etc)

Hi Giovanni, humbly hope you are well during Covid. But before go to this issue (see above), would you please care to see why pdd was worked in R2CON2018 in Latest FreeBSD and why NOW is it not ? It's a serious downgrade for users, if you leave it as it is.

If you don't want to support FreeBSD anymore, say it by announcement in r2dec page please.

i'm sorry to hear that. i had no clue about this issue. can you open an issue under r2dec repo with the exact issue and logs, etc.. ?

unixfreaxjp commented 4 years ago

I will make release of the report in overall for the test results as per finish overall tests for current as discussed by @trufae , the image of the report is something similar to this one (the data is old, up to April tests only) but more thorough by adding embedded platforms and including ESIL as per discussed w @condret too. I am busy in upgrading servers, hypervisors or emulation instance for this purpose with overhaul a lot of host servers in IDC for this purpose (which was delayed do to Corona/Covid19 until June 1st re-opening).

The link above contains list of platform to test/support and not to support, and the tests or bug issue from me will be based on supported ones, this means the features, the installation, the built and compatibility up to continuous-built version.

@wargio Hi Gio. Yes, certainly will bring this up as issue, we are in the same page of what has to be supported and not. Just a quicky snip is as below:

$ r2pm update
HEAD is now at ef8733e Remove pyc (#101)
Updating ef8733e..1c4339a
Fast-forward
 db/r2taint | 16 ++++++++++++++++
 db/yara    |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 db/r2taint
Updating /home/test/.local/share/radare2/r2pm/db ...
Already up to date.
$ r2pm install r2dec
Already up to date.
Install Done For r2dec
cc  -I/home/test/.local/share/radare2/prefix/include -g -O3 -std=c99 -Wall -fPIC -I./duktape -c duktape/duktape.c -o duktape/duktape.o
cc  -I/home/test/.local/share/radare2/prefix/include -g -O3 -std=c99 -Wall -fPIC -I./duktape -c duktape/duk_console.c -o duktape/duk_console.o
duktape/duk_console.c:13:10: fatal error: 'r_cons.h' file not found
#include <r_cons.h>
         ^~~~~~~~~~
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/home/test/.local/share/radare2/r2pm/git/r2dec-js/p
$ uname -smor
FreeBSD 12.1-RELEASE-p1 amd64
$ date
Fri Jun 12 02:38:28 JST 2020
$ r2 -v
radare2 4.5.0-git 24737 @ freebsd-x86-64 git.4.4.0-253-gae883f0cd
commit: ae883f0cd3b12da0272f1471cab82c2e75cd1575 build: 2020-06-10__19:54:43

@XVilka yes, roger that, that is also goes to pdc matter. I'll bring the issue up. Please give me time.

XVilka commented 4 years ago

Looks like people against this.

unixfreaxjp commented 4 years ago

Looks like people against this.

If my opinion counts, if I may suggest:

@XVilka I am not against it. There is no pro or con here. But with considering the current situation of r2pm, that may initiate disability of m command on some systems that previously & natively can use m command, it will lead to degradation to users that depends on it. Don't you think so?

Suggestion: Upon improved r2pm that can support all plugins to run on any desired OS, more modular plugins can be more delegated under r2pm than radare2. Right now, r2pm is just not ready yet, need a bit more brush up, and each plugins may need a bit more of serialization (same methods) in installation, staging and testing.