Unable to replicate with sana amd64.

root@kali:~# uname -a
Linux kali 4.0.0-kali1-amd64 0000001 SMP Debian 4.0.4-1+kali2 (2015-06-03) x86_64 GNU/Linux
root@kali:~# burpsuite

---burp launches and works then exit---

Deleting temporary files - please wait ... done.
root@kali:~#

I add something similar once. It seems to be a bug in the way jarwrapper registers itself... either it misregisters himself or something else registers badly the entry for jarwrapper.

I managed to fix it once on my computer but was assuming that it was not reproducible. It looks like I'm wrong.

Please give the output of the following commands on the problematic systems:
$ cat /var/lib/binfmts/jarwrapper
$ cat /var/lib/binfmts/jar
$ ls -al /usr/bin/jexec /usr/bin/jarwrapper

Does it work when you call /usr/bin/jexec /usr/bin/burpsuite or /usr/bin/jarwrapper /usr/bin/burpsuite ?

Feel free to implement a work around in the mean time. But it's definitely a bug at the binfmt-support and the way jar files are registered in this system...

Note that there's a single bug open on the Debian side on jarwrapper: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779895

But I don't think it's relevant. Though it drove in towards the usage of update-binftm and I managed to fix it on my computer once at least...

The mystery deepens. On the affected systems, the jar and jarwrapper binfmts aren't even there:

root@kali:~# cat /var/lib/binfmts/jarwrapper
cat: /var/lib/binfmts/jarwrapper: No such file or directory
root@kali:~# cat /var/lib/binfmts/jar
cat: /var/lib/binfmts/jar: No such file or directory
root@kali:~# ls -al /usr/bin/jexec /usr/bin/jarwrapper
-rwxr-xr-x 1 root root 2410 Dec 12 2014 /usr/bin/jarwrapper
lrwxrwxrwx 1 root root 23 Jul 29 14:56 /usr/bin/jexec -> /etc/alternatives/jexec

The output on a properly functioning system:

root@kali:~# cat /var/lib/binfmts/jarwrapper
:
magic
0
PK\x03\x04

/usr/bin/jarwrapper
/usr/bin/jardetector

root@kali:~# cat /var/lib/binfmts/jar
openjdk-7
magic
0
PK\x03\x04

/usr/bin/jexec

root@kali:~# ls -al /usr/bin/jexec /usr/bin/jarwrapper
-rwxr-xr-x 1 root root 2410 Dec 12 2014 /usr/bin/jarwrapper
lrwxrwxrwx 1 root root 23 Jul 29 13:12 /usr/bin/jexec -> /etc/alternatives/jexec

Both systems have kali-linux-full installed on them and are amd4. On the affected system, burpsuite launches with both '/usr/bin/jexec /usr/bin/burpsuite' and '/usr/bin/jarwrapper /usr/bin/burpsuite'

Ah, that's interesting. Were all the VM installed the same way directly into sana? Or were some upgraded from moto to sana?

Given your description, I guess that "apt-get --reinstall install jarwrapper" would fix the issue?

Was burpsuite/jarwrapper installed in the live image that was used to install the VM?

All 3 of the VMs I'm testing were built with live build using variants light, mate, and then the regular gnome without specifying a variant.

The mate and gnome desktops have burpsuite by default since it's in kali-linux-full but with light, after installation, i installed the kali-linux-full metapackage to get the standard set of tools.

When the ISO is booted in live mode, burpsuite still present the same error when it's launched from the command line.

So what's the canonical way to reproduce this problem?

Do we have a test ISO where we have the problem in the live image? Or does it manifest only after initial installation?

If we have a test image that fails, it would be nice to have the associated build log to see if any error appears when binfmt-support and/or jarwrapper is installed...

I have the same issue in the live image and after installation. I will build a new ISO and update this bug report with the logs.

I generated a new ISO today and have attached the build log. The issue is still present in both live and installed modes. The lines of interest related to jarwrapper:

Setting up jarwrapper (0.48) ...
update-binfmts: warning: found manually created entry for jarwrapper in /proc/sys/fs/binfmt_misc; leaving it alone

This is known on the Debian side as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750245

I have pushed a fixed binfmt-support (2.1.5-1+kali1) as well as an improved jarwrapper (0.52+kali1) in kali-dev and sana.

moto is probably also affected. You can avoid the problem by disabling binfmt-support before each ISO build:

echo -1 > /proc/sys/fs/binfmt_misc/status