Uniscan: loadable library and perl binaries are mismatched

Uniscan is a tool for scanning websites which comes in kali linux and other pen tests distros. I used to use it weekly to test my applications but after some updates of my linux tools it is now giving the following error when I run it:

xs/Moose.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080)

My current perl version is 5.24.0. I read somewhere that this problem can be bypassed if I downgrade perl version but I didn’t found to which version it should be downgraded, I also tried all versions that are available at my package manager cache, none worked, it actually changed the .c file that got the handshake mismatch. I also tried updating Uniscan to the most recent version (6.3.1), also nothing.

Anyway, does anyone know how to solve this? Thanks in advance.

Answer

This error message is coming from the perl interpreter’s Perl_xs_handshake function. From a comment:

implement the various XS_*_BOOTCHECK macros, which are added to .c files by ExtUtils::ParseXS, to check that the perl the module was built with is binary compatible with the running perl.

In short, this means that the Moose perl module is built against an incompatible version of the perl interpreter (i.e. downgrading perl is a possible option, but this has its own set of issues).

Moose is an object oriented extension framework for perl. It’s common enough that some distros pre-build it and include it in the distro as a separate package (e.g. Under fedora, there is a perl-Moose fedora package).

But, Moose is also available as a CPAN package.

So, if your distro (kali) was set up correctly, things should take care of themselves (which they didn’t). That is, if kali upgraded perl, they should have rebuilt the various perl module packages (Moose being one of them).

Or … Moose was never installed from the distro, but was installed from CPAN (e.g. as part of something else).

Another way to go is to invoke cpan and download, rebuild, and install the Moose package from there.

One thing to look for is to find the place where the current Moose is installed (e.g. /usr/lib64/... or /usr/local/lib64/..., etc.) by doing perldoc -lm Moose. This may help with configuring cpan as to install directories.

---

UPDATE:

I couldn’t find out how to use cpan to rebuild Moose alone, I tried “cpan Moose” (with -c, -m, also tried to download and install using -g, none worked) so I ran a cpan -u to update all installed modules. After that the problem persists.

There are two types of packages: distro packages (e.g. kali packages) and CPAN packages. If a given perl module has been installed from the distro, it is unlikely that cpan will try to update it. What we’ll need to do is to get cpan to install it (from CPAN).

When I use cpan, I usually do /full_path_to/perl -MCPAN -e shell. The reason I use a full path is that I have multiple different perl versions installed. For background as to why I have these [and had to have them], see my answer https://serverfault.com/questions/741186/cpan-is-using-old-perl-version-to-install-modules/741216#741216

After that, at the prompt, I usually do something like install Moose. It will look for package dependencies and I usually say yes to all.

cpan allows a few different install “modes”. Notably, installing system-wide (i.e. you are a sudo user) or installing to a subdirectory under your $HOME directory. This allows a non-root user to install a CPAN module even if the local sysadmin won’t allow the install to /usr/lib64/...

Look in $HOME/.cpan Of particular interest is $HOME/.cpan/CPAN/MyConfig.pm. In that text file, look for the install related information: 'make_install_make_command' => q[sudo /usr/bin/make]. It may or may not have the sudo on it. There are a few other similar options in there (mbuild_install_build_command). If they don’t have sudo on them, you can hand edit the file.

We’ll get back to this in a bit. But, the first thing to do is to run uniscan under strace. No matter how things are configured, versioned, etc. this will record what is going on. Here’s a script with the options I’d recommend for strace:

strace -ttt -i -f -ff -etrace=all -o /anyplace/log/whatever.spysys 
-eread=0,1,2,3,4,5,6,7,8,9,10 -ewrite=0,1,2,3,4,5,6,7,8,9,10 
-eread=11,12,13,14,15,16,17,18,19,20,21 
-ewrite=11,12,13,14,15,16,17,18,19,20,21 
-eread=22,23,24,25,26,27,28,29,30,31,32 
-ewrite=22,23,24,25,26,27,28,29,30,31,32 
-eread=33,34,35,36,37,38,39,40,41,42,43 
-ewrite=33,34,35,36,37,38,39,40,41,42,43 
-eread=44,45,46,47,48,49,50,51,52,53,54 
-ewrite=44,45,46,47,48,49,50,51,52,53,54 
-eread=55,56,57,58,59,60,61,62,63,64,65 
-ewrite=55,56,57,58,59,60,61,62,63,64,65 
-eread=66,67,68,69,70,71,72,73,74,75,76 
-ewrite=66,67,68,69,70,71,72,73,74,75,76 
-eread=77,78,79,80,81,82,83,84,85,86,87 
-ewrite=77,78,79,80,81,82,83,84,85,86,87 
-eread=88,89,90,91,92,93,94,95,96,97,98 
-ewrite=88,89,90,91,92,93,94,95,96,97,98 -eread=99 -ewrite=99 -x 
/usr/bin/whatever

Replace the /anyplace/... with something suitable for your system. Replace /usr/bin/whatever with the uniscan command that is failing. If you normally run uniscan as root, you can prefix strace with sudo

Note that these options to strace generate a lot of output but they don’t leave anything of value out. Eventually, the uniscan command will abort [as you’ve already been experiencing], but, now, the strace output will have the reason why.

Specifically, by sifting through the log output, you can find the exact full path of the failing Moose.so. That is, perl will open a Moose related file (successfully) and soon thereafter output the failure message to stderr. The moose file might be in /usr/lib64/... or it might be in some totally strange place like /usr/local/lib64/... or, even stranger, /usr/lib64/uniscan/lib/Moose/.... But, this now tells us where we want to rebuild and install moose to.

Note: As you may have noticed, my original answer got edited [pedantically] for grammar, but, materially to replace my recommendation for using find [which I didn’t approve of].

Anyway, to match up the cpan and strace stuff. When you used cpan, it may have run in the “install to $HOME/...” mode, which, IIRC is the default. So, if that were the case (i.e. check MyConfig.pm), you may find the updated packages under your home directory rather than the desired system-wide directories. So, to help verify this, do find $HOME -name '*Moose*' and see what comes up.

So, based on the strace filenames, the timestamps on the files should match up with the time that you did your cpan commands. But, I’m betting they won’t.

Under $HOME/.cpan there is a subdirectory $HOME/.cpan/build. This is where the cpan command downloads and stores the package files. It also builds the packages there. If your invocation of cpan touched on Moose, there should be some *Moose* files and directories there.

Whenever I’ve had a “bad” package, IIRC, I just removed it from $HOME/.cpan/build (and some of the dependent packages) and then did install again. Things get redownloaded, rebuilt, and reinstalled.

From the strace we now know which perl interpreter was used (probably /usr/bin/perl), where it got the moose file from. The moose file should be under one of the @INC directories. If so, fine. If not, this means that the “wrapper” script for uniscan is setting up a non-standard path for Moose, which is the reason to do the strace: to confirm this or not.

Then, fix the MyConfig.pm if needed. If it was missing sudo, that may be all you need. Then, just do install Moose.

You could remove $HOME/.cpan/build first if you wanted.