View Issue Details

IDProjectCategoryView StatusLast Update
0002466Kali Linux[All Projects] Kali Package Bugpublic2016-02-21 13:16
Reporterg0tmi1k Assigned Torhertzog  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version 
Target Version2.0Fixed in Version2.0 
Summary0002466: burpsuite - Java file in $PATH
DescriptionWhen trying to start burp proxy via command line, it will fail due it being a java file. Need to call it differently.

## Example:

root@kali:~# whereis burpsuite
burpsuite: /usr/bin/burpsuite
root@kali:~# file /usr/bin/burpsuite
/usr/bin/burpsuite: Java archive data (JAR)
root@kali:~# burpsuite
/usr/bin/burpsuite: line 1: $'PK\003\004': command not found
/usr/bin/burpsuite: line 2: $'\bTQ\235F': command not found
/usr/bin/burpsuite: line 3SQ�FS͎�META-INF/MANIFEST.MFM���: No such file or directory
/usr/bin/burpsuite: line 3: $'\316\016\252\364\325*\372\2053\316\336PK\003\004': command not found
/usr/bin/burpsuite: line 4:TQ�Fburp/PK: No such file or directory
/usr/bin/burpsuite: line 5:TQ�Fburp/Documentation/PK: No such file or directory
/usr/bin/burpsuite: line 6:TQ�Fburp/Documentation/api/PK: No such file or directory
/usr/bin/burpsuite: line 7:TQ�Fburp/Documentation/api/burp/PK: No such file or directory
/usr/bin/burpsuite: line 8:TQ�F!burp/Documentation/api/resources/PK: No such file or directory
/usr/bin/burpsuite: line 10: syntax error near unexpected token `)'
/usr/bin/burpsuite: line 10: `�]B�E[���ym�>I�'7�Z���[�t�I���}�E��O�-Jo7�g�J�
Additional InformationIf we look at backdoor-factory, it calls the program differently

root@kali:/usr/bin# cat /usr/bin/backdoor-factory

/usr/share/backdoor-factory/ "$@"

## Solution for BurpSuite
we could make a bash script for /usr/bin/burpsuite (see below), and rename the current burp java file somewhere different....


/usr/bin/java -Xmx2g -jar /path/to/burp.jar



2015-08-03 04:31

administrator   ~0003648

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.


2015-08-04 19:16

administrator   ~0003656

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...


2015-08-04 19:19

administrator   ~0003657

Note that there's a single bug open on the Debian side on jarwrapper:

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...


2015-08-04 21:57

administrator   ~0003658

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


root@kali:~# cat /var/lib/binfmts/jar


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'


2015-08-05 19:23

administrator   ~0003661

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?


2015-08-05 23:18

administrator   ~0003662

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.


2015-08-09 13:05

administrator   ~0003664

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...


2015-08-09 13:23

administrator   ~0003665

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.


2015-08-09 14:31


kali-linux-sana-amd64.log (1,199,916 bytes)


2015-08-09 14:32

administrator   ~0003666

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


2015-08-09 22:06

administrator   ~0003670

This is known on the Debian side as

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

Issue History

Date Modified Username Field Change
2015-08-02 18:10 g0tmi1k New Issue
2015-08-02 18:12 g0tmi1k Additional Information Updated View Revisions
2015-08-03 04:31 dookie Note Added: 0003648
2015-08-04 19:16 rhertzog Note Added: 0003656
2015-08-04 19:19 rhertzog Note Added: 0003657
2015-08-04 21:57 dookie Note Added: 0003658
2015-08-05 19:23 rhertzog Note Added: 0003661
2015-08-05 23:18 dookie Note Added: 0003662
2015-08-09 13:05 rhertzog Note Added: 0003664
2015-08-09 13:23 dookie Note Added: 0003665
2015-08-09 14:07 rhertzog Assigned To => rhertzog
2015-08-09 14:07 rhertzog Status new => assigned
2015-08-09 14:31 dookie File Added: kali-linux-sana-amd64.log
2015-08-09 14:32 dookie Note Added: 0003666
2015-08-09 22:06 rhertzog Note Added: 0003670
2015-08-09 22:06 rhertzog Status assigned => resolved
2015-08-09 22:06 rhertzog Fixed in Version => 2.0
2015-08-09 22:06 rhertzog Resolution open => fixed
2016-02-21 13:16 rhertzog View Status private => public