search

rizinorg / cutter

Free and Open Source Reverse Engineering Platform powered by rizin
https://cutter.re
GNU General Public License v3.0
15.61k stars 1.14k forks source link

No decompilers when using OBS version #3189

Open Tachi107 opened 1 year ago

Tachi107 commented 1 year ago

Environment information

Describe the bug

When installing Cutter via the official OBS apt repository, no decompilers are available.

To Reproduce

Steps to reproduce the behavior:

  1. Add the Debian Testing OBS repository
  2. Install the cutter-re package
  3. Open any random binary

Expected behavior

When using the official OBS repos, the Ghidra and jsdec decompilers should be available out of the box, just like when using the AppImage.

Screenshots

image

Additional context

This is my first time using Cutter, so please keep in mind that I'm a complete newbie!

Thanks for your work :D

ret2libc commented 1 year ago

This is known :( I think I'd prefer to fix this by improving rz-pm so that you can install it that way instead of complicating the OBS builds.

@Tachi107 would it help if you could install the decompiler plugins through rz-pm?

Tachi107 commented 1 year ago

Hi, thanks for the reply! I prefer to use my distro's package manager when possible, and anything else is the same for me; I can also use the AppImage without issues.

Is it possible to install the decompiler plugins separately?

Lastly, since I maintain a couple of packages in Debian I may be able to help here; if you can point me to your OBS' configuration files I could look into adding a new cutter-re-plugins package which contains the exactly what you'd expect. Does it make sense?

ret2libc commented 1 year ago

@Tachi107 that would be awesome!! Even more so, it would be great to have these packages directly in the official Debian/Ubuntu repos. OBS is a bit of a way around that TBH.

https://build.opensuse.org/project/show/home:RizinOrg

XVilka commented 1 year ago

@Tachi107 that would be awesome!! Even more so, it would be great to have these packages directly in the official Debian/Ubuntu repos.

Absolutely agree, maybe you could ping corresponding package maintainer as well - Cutter version and naming is outdated in Debian (and Ubuntu respectively): https://repology.org/project/cutter-re/versions

Instead of radare2-cutter it should be cutter-re like in many other distributions.

Tachi107 commented 1 year ago

Yeah, Cutter is in Debian already, but as far as I can tell it is the old radare2-based version.

According to https://bugs.debian.org/950372 there has been a bit of drama around radare2 in Debian, and that's probably the main reason for its poor packaging state.

It already looks like it is the case, but would things be different for the new Cutter and Rizin?

XVilka commented 1 year ago

I made a new bug about the rename and update: https://bugs.debian.org/1036923

Tachi107 commented 1 year ago

Hi @XVilka, I'd be willing to look into this, but I'd first like to be sure that you (upstream) really are ok with packaging Cutter in Debian.

If the package gets shipped in a stable release (e.g. Debian 12), the version will remain the same during the whole Debian 12 lifecycle (a couple of years), minus bug fixes and security updates. Would you be OK with this?

Some upstreams like MbedTLS are so kind to even ship LTS releases that we (distro developers) can trivially use in stable releases.

XVilka commented 1 year ago

There is one tricky thing about packaging Rizin/Cutter/rz-ghidra/etc - the dependency on capstone. Recenly we invested quite some effort in updating capstone for many architectures, to support all newest opcodes for ARM, PPC, MIPS, etc via the so-called "auto-sync" project, synchronizing the Capstone code with the LLVM via some automation. While the 5.0 version of the capstone library is almost out, with Tricore architecture added, the ARM, PPC, MIPS (and possibly some other architectures) will not make it into 5.0 and will be a part of the next release - 5.1 or 6.0, whichever they decide to do. Rizin, as a base for Cutter, will tie itself to this new Capstone, due to the many missing opcodes and errors in all previous versions, also with some new architectures supported. This whole effort will be a part of the Rizin 0.6.0 and Cutter 2.3.0 upcoming releases which will not happen in 3 months even though.

Tachi107 commented 1 year ago

That doesn't look like an issue for me. If Debian ships e.g. libcapstone 5.0 then we'll just package the latest Rizin version targeting that capstone version.

Does it make sense? Or did I misinterpreted your comment?

XVilka commented 1 year ago

@Tachi107 No issue, you are right — just a thing to remember during the packaging since Rizin is sensitive to the capstone version. We, the RizinOrg team, discussed this today, and we are OK with Rizin and Cutter being packaged in Debian with not being updated during the release life, except for bugfix releases.

XVilka commented 1 year ago

Moreover, as we are working on the next release in the upcoming months, let us know if you meet some bug/issue/problem/patch during the packaging so that we can integrate it mainstream for the next release. We have documents for packagers:

Let us know if you find this documentation missed something.

XVilka commented 6 months ago

To ping you both @Tachi107 and @ret2libc - Rizin 0.7.1 and Cutter 2.3.4 are out, it would be nice to update/package them.

Tachi107 commented 6 months ago

Hi Anton, thanks for the ping! Unfortunately I've stopped using Cutter due to some unfortunate events regarding my rev journey, and I'm not directly interested in packaging it anymore. A friend of mine will start its RE journey in a bit though, so I might use that as an excuse to package the program - I make no promises though ;)