Additional info on packaging directly from the developers: https://cutter.re/docs/building.html#making-linux-distribution-specific-packages

@kali-team, please could this be packaged up.
@author, If you want to help the packaging process, you can check the documentation here ~ https://www.kali.org/docs/development/public-packaging

Ok will check that

Alright, if no one complains, I would like to contribute. I am following https://www.kali.org/docs/development/intro-to-packaging-example/#licensemaintainers to create the package and I will send some results later next week using my Gitlab account.

Is that ok?

As the developers say here: https://cutter.re/docs/building.html#making-linux-distribution-specific-packages we should also package the other decompiler, jsdec as that is also expected by the "regular" users of Cutter (those who are using the AppImage).

Sure, sounds good to me.

For examples, you can look at the following Kali packages:

• https://gitlab.com/kalilinux/packages/rizin
• https://gitlab.com/kalilinux/packages/rizin-cutter

You can also look at how rizin-ghidra is packaged in other distros, here are some lists:

• https://repology.org/project/rz-ghidra/versions
• https://repology.org/project/rizin-ghidra-plugin/versions

Packaging for Kali is likely to be similar to the package for Parrot, but not exactly the same. However I don't know where to find the sources for this package.

I don't think it's a trivial package, so hopefully you have some packaging skills ;) I mean, it's not the best package to get started with packaging.

See also: https://www.kali.org/docs/development/setting-up-packaging-system/

Indeed, not trivial, but I will try to do it. I am already looking at those packages and the equivalent packages in Parrot.

As I was discussing also here: https://forums.kali.org/showthread.php?123021-How-to-package-a-librizin-cutter-dev-required-to-solve-issue-0008168 we probably need a librizin-cutter-dev package the same way Parrot is doing. This is required to compile the rz-ghidra plugin for cutter, otherwise we can only build it for the rizin CLI which is not enough.

I am preparing a PR for rizin-cutter first (that, I guess from your nickname, it's your package, right?), adding the libfuzzer-cutter-dev package into the existing package.

Once we have this we can go with the rz-ghidra package in a similar way as Parrot OS is doing.

This is how Parrot is doing rizin-cutter: https://git.parrotsec.org/packages/tools/rizin-cutter

Yep I did the packaging for Kali. Feel free to open a MR and ping here as well. I might not have time until next week though.

FIrst MR for librizin-cutter-dev here https://gitlab.com/kalilinux/packages/rizin-cutter/-/merge_requests/2.
This is the first step before creating an actual rz-ghidra package that will depend on librizin-cutter-dev for builds.

Plus, I have created the repo for packaging rz-ghidra here https://gitlab.com/turbopapero/rz-ghidra which will work properly only once the MR above will be merged.
Here I need some inputs for you on how to proceed.

I didn't find the time this week, sorry about that. I'll try next week but no promise.

Just to understand the procedure on the new rz-ghidra package: someone has to create an rz-ghidra package in https://gitlab.com/kalilinux/packages and then I can create the MR from my own repo https://gitlab.com/turbopapero/rz-ghidra right?

MR are not always practictal for packaging. A packaging repo has different branches (2 at least, one branch with upstream code, and one branch with packaging), and you can't create a MR with 2 branches. You could create 2 MR, one for each branch, but that's getting complicated...

So, for a new package, just work in your own repo https://gitlab.com/turbopapero/rz-ghidra, then we'll review that, and then push it to gitlab.com/kalilinux.

Now that librizin-cutter-dev has been merged, I am going back to work on the rz-ghidra plugin from my repo https://gitlab.com/turbopapero/rz-ghidra
WIll come back with an update when ready for review after some tests.

Sounds good, thanks a lot!

Some updates.

The rizin (CLI) plugins are loaded (in the current rizin kali package) from:

/usr/lib/x86_64-linux-gnu/rizin/plugins
/home/kali/.local/lib/x86_64-linux-gnu/rizin/plugins
/home/kali/.local/share/rizin/plugins

To run rz-ghidra for Cutter we also need the CLI plugin to work otherwise it won't work.
This means that we need to decide between 2 possibilities:

• EASY: store the rizin (CLI) plugins in /usr/lib/x86_64-linux-gnu/rizin/plugins (the current default directory for rizin cli plugins in kali).
  --- This will violate the rule that we discussed in the rizin-cutter MR where we don't want to use the multiarch directory x86_64-linux-gnu.
  --- For consistency we should also re-align the rizin-cutter (the last MR) as it makes no sense to have two different places for plugins.
• CLEAN: Edit the rizin package with an additional pull request so that the /usr/lib/rizin/plugins will be set as default plugin directory to follow the same approach of rizin-cutter.

I would go with the clean approach. Other distros like Parrot OS seem to ignore the problem and just use the default directories violating the rules.

What do you want to do?

Hello, sorry for the delay. I prefer the clean solution, and I just pushed https://gitlab.com/kalilinux/packages/rizin/-/commit/e81842ebdfbc99265586adbb6aaa33bc8aba4d60 to this effect.

Please ping me when https://gitlab.com/turbopapero/rz-ghidra is ready

Cool, will try to close this within this weekend. I will ping here when ready.

Hello,

With your last modification, the code works now.
You can check the package at https://gitlab.com/turbopapero/rz-ghidra.

For the remaining lintian errors, I don't know what's the best approach for Kali.

missing-notice-file-for-apache-license => This seems to be a false positive as the file is simply in another place
source-is-missing => All these files are not installed, they are just examples and tools that are not required
source-contains-prebuilt-windows-binary => Same as above

Should we remove such files from the initial source using a patch?

Ola, I opened a merge request, please review, if you're happy with those changes, please merge, and I'll upload that in Kali.

missing-notice-file-for-apache-license => This seems to be a false positive as the file is simply in another place
source-is-missing => All these files are not installed, they are just examples and tools that are not required
source-contains-prebuilt-windows-binary => Same as above

Most of those message are related to the ghidra directory (you surely noticed that rz-ghidra embeds a complete copy of ghidra). So I just had a look at the Kali package for ghidra, and followed the same approach: override most of those lintian messages. You can always run lintian-explain-tags, usually explanations are pretty good.

Should we remove such files from the initial source using a patch?

No, we'll live with that, no worries.

Hello again, the package was just uploaded to kali-dev, it should enter kali-rolling shortly afterward. GitLap repo at https://gitlab.com/kalilinux/packages/rz-ghidra

Thanks again for submitting this package and following up until the end!

Bonus question: do you know of a way, from the command-line, to test if the rz-ghidra plugin is enabled / functional? Maybe rizin has a command to list plugins for example, or maybe we can even run a simple test to exercise rz-ghidra and validate that it's functional. It would be be very useful to add such a test to the package, so that we can catch regressions for example.

As explained here:

https://book.rizin.re/plugins/intro.html?highlight=plugin#listing-plugins

the Ghidra plugin shows up by executing

rz-asm -L
Maybe that's a possible way to check that the plugin was succesfully loaded at rizin startup.

Can also be checked within the rizin interactive cli using

e asm.arch=?

as described below in the same page.

rz-asm -L works, but it gives a warning that was not there before I installed rz-ghidra:

<pre>
┌──(kali㉿kali)-[~]
└─$ rz-asm -L | grep -i ghidra

WARNING: Cannot find plugin constructor
_dAe 8 16 32 64 ghidra LGPL3 SLEIGH Disassembler from Ghidra (by FXTi)
</pre>

So something is not quite right with rz-ghidra, it seems. Or maybe it's just a harmless error message. Who knows.

This command also works to show the ghidra plugin. This time, there's no warning message:

<pre>
┌──(kali㉿kali)-[~]
└─$ rizin -q -c "e asm.arch=?" | grep ghidra
ghidra
</pre>

I have executed the same command (rz-asm -L | grep -i ghidra) on Arch Linux (rz-ghidra is already available there) and I get no warning.

Apparently their package does not have this flag that you added in the merge request:
https://gitlab.com/turbopapero/rz-ghidra/-/merge_requests/1/diffs#8756c63497c8dc39f7773438edf53b220c773f67_23_22

They only have:
https://github.com/archlinux/svntogit-community/blob/5673048aa50f47801f69ba6d5ae1f0c24eed4cb5/trunk/PKGBUILD#L36

I can do some investigation later but I am a bit busy for this week.

Still, it looks like the flag is default to ON anyway: https://github.com/rizinorg/rz-ghidra/blob/301f5e86fdc4646cf33ec500cc18b758f99a3a3d/CMakeLists.txt#L16 so probably this is not the reason.