Invalid file bad magic number exec format error

[ubuntu-9.04] запустить jar

Пытаюсь запустить простым ./file.jar, выдает:
invalid file (bad magic number): Exec format error

До этого не работал с jar’ами. ЧЯДНТ?

Re: [ubuntu-9.04] запустить jar

установил jarwrapper и все заработало. спасибо

Re: [ubuntu-9.04] запустить jar

обычно это типа так:
/usr/lib/java/bin/java -jar /путь/к/jar-файлу

Re: [ubuntu-9.04] запустить jar

у меня, кстати, почему-то заработало только после того, как сделал update-alternatives —config java и выбрал там сановскую ВМ.

Re: [ubuntu-9.04] запустить jar

Все jar’ы запускаю так
java -jar /path/to/file.jar

Re: [ubuntu-9.04] запустить jar

как ни печально, но сановская жава пока выруливает у альтернатив. gcj вообще сливает со страшной силой

Re: [ubuntu-9.04] запустить jar

А OpenJDK? Какую реализацию Java следует использовать (из свободных)?

Re: [ubuntu-9.04] запустить jar

тестирую десктопное приложение на жабе и веб-приложение на томкате. openJDK из свободных неплохо показал себя. хотя не вижу проблемы пользоваться сановской реализацией

Источник

Запуск Java классов и JAR-ов не по учебнику

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл.

Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.

Первое открытие

Как оказалось в моей Ubuntu 16.04 уже зарегистрирован обработчик для JAR файлов:

Отдав команду chmod +x foo.bar я радостно потирал руки, но реальность оказалось сурова — запуск ./foo.jar выдал следующее:

Погуглив, я нашел обросший мхом баг bugs.java.com/bugdatabase/view_bug.do?bug_id=6401361 Как оказывается сборка через Maven не добавляет «0xcafe» в начало JAR файла. Не менее безответственно ведет себя и плагин maven-assembly-plugin. Что не нравится /usr/bin/jexec, зарегистрированному обработчику по умолчанию.

Погуглив еще, я нашел решение проблемы через установку пакета jarwrapper. После установки добавляется новый обработчик /usr/bin/jarwrapper и страховка /usr/bin/jardetector (проверяет по META-INF что это действительно JAR). Но изучив код обработчика мне не понравилась куча лишней работы, которую делает скрипт запуская множество вспомогательных программ.

Поэтому решением стал собственный обработчик:

Дальше открываем файл sudo gedit /var/lib/binfmts/jar и регистрируем обработчик заменив строчку с /usr/bin/jexec на /usr/bin/jarinvoke. На самом деле это плохое решение и лучше создать собственную группу (об этом ниже), но для первичного понимания сойдет.

Для вступления изменений в силу может потребоваться выполнить:

После чего можете запускать JAR файлы как любые другие исполняемые файлы.

Исполняемые классы

Теперь можно идти дальше и сделать из Java классов исполняемые файлы, где jarwrapper не сможет помочь. Обработчик будет работать только для классов с пакетом по умолчанию (т.е. классы с отсутствующим package заголовком). Может можно сделать и лучше, но мне хватило такой функциональности для «скриптования» на Java:

После чего регистрируем собственный обработчик (этим же способом можно создать новый обработчик для JAR-ов не редактируя /usr/bin/jexec):

Можно пойти и дальше, сделав более сложный обработчик, который по импорту классов будет определять какие библиотеки добавить в CLASSPATH из

/.m2, но это отдельная история. Сейчас интересен взгляд со стороны, замечания, дополнения, если таковые есть. После чего думаю оформить это в deb пакет и выложить всё на гитхабе.

Источник

trouble installing

Daniel | Last updated: Nov 25, 2020 07:00PM UTC

Hello, Trying to run Burpsuite on Kali (Pi4b, Cortex-A72), running the latest Open-JDK and I keep running into issues. If I run the JAR i get: «invalid file (bad magic number): Exec format error» and if I run the installer I get the same «Exec format error» Unpacking JRE . Starting Installer . ./burpsuite_community_linux_v2020_11.sh: 596: /home/***/Downloads/burpsuite_community_linux_v2020_11.sh.132071.dir/jre/bin/java: Exec format error I’ve googled this to death.. and I’m running out ideas. Any suggestions?

Daniel | Last updated: Nov 25, 2020 07:06PM UTC

I would like to add that I am running a 64bit version of Kali. I have tried install/reinstalling/varying versions thereof of Open-JDK, and I am running both the jar and install script with sufficient permissions. 🙂

Michelle, PortSwigger Agent | Last updated: Nov 26, 2020 09:28AM UTC

Could you send us the output from uname -a, please? Also, which versions of java did you try during all your testing? Did they all give the same error when you tried to launch the JAR file?

Daniel | Last updated: Nov 26, 2020 04:24PM UTC

Linux kali 4.19.118-Re4son-v81+ #1 SMP PREEMPT Thu May 7 02:54:03 UT 2020 aarch64 GNU/Linux The jar gives «Bad Magic Number», the script just gives «Exec format error» but doesn’t elaborate. I’m guessing it’s the same? My java version is currently: openjdk version 11.0.9.1″ 2020-11-04 OpenJDK Runtime Environment (build 11.0.9.1+1-post-Debian-1) OpenJDK 64-Bit Server VM (build 11.0.9.1+1-post-Debian-1, mixed mode) thank you for following up with me 🙂

Michelle, PortSwigger Agent | Last updated: Nov 27, 2020 11:47AM UTC

We’ve been doing some investigation and other users with a similar setup to yourself have sometimes found that they’ve had issues getting the installer to run but have been able to start Burp using the JAR file, so it’s probably worth us doing a few more tests using that method. The issues we’ve had reported have generally seemed to relate to the version of Java being used. I know you’ve already tested a number of different versions of java but could you give it a try using Java 14 and the JAR file, and check if that gives the same result, please? If it does, could you check what versions of Java you have installed (‘sudo update-alternatives —config java’ will give us a list) and send over the details, please?

Michelle, PortSwigger Agent | Last updated: Nov 27, 2020 12:20PM UTC

Would you mind running a specific test with Java 15 too (https://jdk.java.net/15/), please?

Stefan | Last updated: May 05, 2022 01:38PM UTC

I have the same issue: java -version openjdk version «11.0.14.1» 2022-02-08 OpenJDK Runtime Environment (build 11.0.14.1+1-post-Debian-1) OpenJDK 64-Bit Server VM (build 11.0.14.1+1-post-Debian-1, mixed mode, sharing) (root. kali)-[/bin] └─# burpsuite invalid file (bad magic number): Exec format error

Ben, PortSwigger Agent | Last updated: May 06, 2022 06:53AM UTC

Hi Stefan, Have you update the version of Burp on your Kali machine and, if so, how did you carry this out?

You need to Log in to post a reply. Or register here, for free.

Источник

invalid file (bad magic number): Exec format error

Bug Description

The package contains debian/links file which links /usr/share/ ditaa/ditaa. jar to /usr/bin/ditaa. In my ubuntu version, the jar can not be executed directly, «/usr/bin/ditaa» results in the following error:

invalid file (bad magic number): Exec format error

After creating a simple wrapper:

#!/bin/sh
exec java -jar /usr/share/ ditaa/ditaa. jar

My package version is: 0.9+ds1-3 but it the link file (in debian/*) is still present in version ditaa_0. 10+ds1- 1.debian. tar.xz.

I’m on Ubuntu 15.04.

Status changed to ‘Confirmed’ because the bug affects multiple users.

This bug is present on Trusty, too.

It doesn’t seem to be a ditaa problem but an openjdk problem? I also get the error when I try to start other java apps on 14.04 without exec — but on 15.10 (openjdk version «1.8.0_91») it is ok.

I just ran into this issue with a self-compiled jar file and confirmed that I have the same issue with ditaa on Debian. Checking the binfmt_misc configuration may be useful. To see what interpreters will be tried by binfmt_misc, run `/usr/sbin/ update- binfmts —find /usr/bin/ditaa`. Then try running the interpreter with the jar file directly (e.g. `/usr/bin/ jarwrapper /usr/bin/ditaa`) to see if it works.

If update-binfmts does not print anything, that suggests either corruption of the JAR file (check `od -An -tx1 -N4 /usr/share/ ditaa/ditaa. jar` is `50 4b 03 04`) or that jarwrapper is not correctly registered (check `/usr/sbin/ update- binfmts —display jarwrapper` prints `jarwrapper (enabled)`).

If update-binfmts prints `/usr/bin/jexec` (or anything else) in addition to `jarwrapper` and those interpreters do not work, this suggests conflicting binfmt_misc registrations. Check the output of `/usr/sbin/ update- binfmts —display` to find out which package installed it. You can then remove it by running something like `sudo update-binfmts —package openjdk-8 —remove jar /usr/bin/jexec`.

Источник

Запуск Java классов и JAR-ов не по учебнику

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл.

Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.

Первое открытие

Как оказалось в моей Ubuntu 16.04 уже зарегистрирован обработчик для JAR файлов:

Отдав команду chmod +x foo.bar я радостно потирал руки, но реальность оказалось сурова — запуск ./foo.jar выдал следующее:

Погуглив, я нашел обросший мхом баг bugs.java.com/bugdatabase/view_bug.do?bug_id=6401361 Как оказывается сборка через Maven не добавляет «0xcafe» в начало JAR файла. Не менее безответственно ведет себя и плагин maven-assembly-plugin. Что не нравится /usr/bin/jexec, зарегистрированному обработчику по умолчанию.

Погуглив еще, я нашел решение проблемы через установку пакета jarwrapper. После установки добавляется новый обработчик /usr/bin/jarwrapper и страховка /usr/bin/jardetector (проверяет по META-INF что это действительно JAR). Но изучив код обработчика мне не понравилась куча лишней работы, которую делает скрипт запуская множество вспомогательных программ.

Поэтому решением стал собственный обработчик:

Дальше открываем файл sudo gedit /var/lib/binfmts/jar и регистрируем обработчик заменив строчку с /usr/bin/jexec на /usr/bin/jarinvoke. На самом деле это плохое решение и лучше создать собственную группу (об этом ниже), но для первичного понимания сойдет.

Для вступления изменений в силу может потребоваться выполнить:

После чего можете запускать JAR файлы как любые другие исполняемые файлы.

Исполняемые классы

Теперь можно идти дальше и сделать из Java классов исполняемые файлы, где jarwrapper не сможет помочь. Обработчик будет работать только для классов с пакетом по умолчанию (т.е. классы с отсутствующим package заголовком). Может можно сделать и лучше, но мне хватило такой функциональности для «скриптования» на Java:

После чего регистрируем собственный обработчик (этим же способом можно создать новый обработчик для JAR-ов не редактируя /usr/bin/jexec):

Можно пойти и дальше, сделав более сложный обработчик, который по импорту классов будет определять какие библиотеки добавить в CLASSPATH из

/.m2, но это отдельная история. Сейчас интересен взгляд со стороны, замечания, дополнения, если таковые есть. После чего думаю оформить это в deb пакет и выложить всё на гитхабе.

Источник

Время прочтения
3 мин

Просмотры 17K

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл.

Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.

Первое открытие

Как оказалось в моей Ubuntu 16.04 уже зарегистрирован обработчик для JAR файлов:

update-binfmts --display
...
jar (enabled):
     package = openjdk-8
        type = magic
      offset = 0
       magic = PKx03x04
        mask = 
 interpreter = /usr/bin/jexec
    detector = 

Отдав команду chmod +x foo.bar я радостно потирал руки, но реальность оказалось сурова — запуск ./foo.jar выдал следующее:

invalid file (bad magic number): Exec format error

Погуглив, я нашел обросший мхом баг bugs.java.com/bugdatabase/view_bug.do?bug_id=6401361 Как оказывается сборка через Maven не добавляет «0xcafe» в начало JAR файла. Не менее безответственно ведет себя и плагин maven-assembly-plugin. Что не нравится /usr/bin/jexec, зарегистрированному обработчику по умолчанию.

Погуглив еще, я нашел решение проблемы через установку пакета jarwrapper. После установки добавляется новый обработчик /usr/bin/jarwrapper и страховка /usr/bin/jardetector (проверяет по META-INF что это действительно JAR). Но изучив код обработчика мне не понравилась куча лишней работы, которую делает скрипт запуская множество вспомогательных программ.

Поэтому решением стал собственный обработчик:

#!/bin/sh
#/usr/bin/jarinvoke

JAR=$1
shift

exec java -jar $JAR $@

Дальше открываем файл sudo gedit /var/lib/binfmts/jar и регистрируем обработчик заменив строчку с /usr/bin/jexec на /usr/bin/jarinvoke. На самом деле это плохое решение и лучше создать собственную группу (об этом ниже), но для первичного понимания сойдет.

Для вступления изменений в силу может потребоваться выполнить:

sudo update-binfmts --disable jar && sudo update-binfmts --enable jar

После чего можете запускать JAR файлы как любые другие исполняемые файлы.

Исполняемые классы

Теперь можно идти дальше и сделать из Java классов исполняемые файлы, где jarwrapper не сможет помочь. Обработчик будет работать только для классов с пакетом по умолчанию (т.е. классы с отсутствующим package заголовком). Может можно сделать и лучше, но мне хватило такой функциональности для «скриптования» на Java:

#!/bin/sh
# /usr/bin/clsinvoke

CLASS_FILE=$1
shift

ABSOLUTE_PATH=`readlink -f $CLASS_FILE`

CLASS=`basename $ABSOLUTE_PATH`
CLASS=${CLASS%.*}
CLASSPATH=`dirname $ABSOLUTE_PATH`

exec java -cp $CLASSPATH $CLASS $@

После чего регистрируем собственный обработчик (этим же способом можно создать новый обработчик для JAR-ов не редактируя /usr/bin/jexec):

sudo update-binfmts --package clsinvoke --install clsinvoke /usr/bin/clsinvoke --magic 'xcaxfexbaxbe'

Тестируем:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
}

javac HellWorld.java
chmod +x HelloWorld.class
./HelloWorld.class
Hello, World

Можно пойти и дальше, сделав более сложный обработчик, который по импорту классов будет определять какие библиотеки добавить в CLASSPATH из ~/.m2, но это отдельная история. Сейчас интересен взгляд со стороны, замечания, дополнения, если таковые есть. После чего думаю оформить это в deb пакет и выложить всё на гитхабе.

The definitive answer to «how programs get run» on Linux is the pair of articles on LWN.net titled, surprisingly enough, How programs get run and How programs get run: ELF binaries. The first article addresses scripts briefly. (Strictly speaking the definitive answer is in the source code, but these articles are easier to read and provide links to the source code.)

A little experimentation show that you pretty much got it right, and that the execution of a file containing a simple list of commands, without a shebang, needs to be handled by the shell. The execve(2) manpage contains source code for a test program, execve; we’ll use that to see what happens without a shell. First, write a testscript, testscr1, containing

#!/bin/sh

pstree

and another one, testscr2, containing only

pstree

Make them both executable, and verify that they both run from a shell:

chmod u+x testscr[12]
./testscr1 | less
./testscr2 | less

Now try again, using execve (assuming you built it in the current directory):

./execve ./testscr1
./execve ./testscr2

testscr1 still runs, but testscr2 produces

execve: Exec format error

This shows that the shell handles testscr2 differently. It doesn’t process the script itself though, it still uses /bin/sh to do that; this can be verified by piping testscr2 to less:

./testscr2 | less -ppstree

On my system, I get

    |-gnome-terminal--+-4*[zsh]
    |                 |-zsh-+-less
    |                 |     `-sh---pstree

As you can see, there’s the shell I was using, zsh, which started less, and a second shell, plain sh (dash on my system), to run the script, which ran pstree. In zsh this is handled by zexecve in Src/exec.c: the shell uses execve(2) to try to run the command, and if that fails, it reads the file to see if it has a shebang, processing it accordingly (which the kernel will also have done), and if that fails it tries to run the file with sh, as long as it didn’t read any zero byte from the file:

        for (t0 = 0; t0 != ct; t0++)
            if (!execvebuf[t0])
                break;
        if (t0 == ct) {
            argv[-1] = "sh";
            winch_unblock();
            execve("/bin/sh", argv - 1, newenvp);
        }

bash has the same behaviour, implemented in execute_cmd.c with a helpful comment (as pointed out by taliezin):

Execute a simple command that is hopefully defined in a disk file
somewhere.

1. fork ()
2. connect pipes
3. look up the command
4. do redirections
5. execve ()
6. If the execve failed, see if the file has executable mode set.
   If so, and it isn’t a directory, then execute its contents as
   a shell script.

POSIX defines a set of functions, known as the exec(3) functions, which wrap execve(2) and provide this functionality too; see muru’s answer for details. On Linux at least these functions are implemented by the C library, not by the kernel.