Unable to execute binary file - linux

I recently heard about Breach, a Node.js based browser. I was following the instructions on http://codeforgeek.com/2014/08/download-install-breach-browser-ubuntu-14-04/ to install it but got the following error :
breach-v0.3.22-alpha.6-linux-x64/__AUTO_UPDATE_BUNDLE__/exo_browser/exo_browser: cannot execute binary file: Exec format error
After some googling, I found that it is because I am trying to install the 64 bit package on the 32 bit Ubuntu installation. I tried to find 32 bit package of the same but ended up with no luck. The browser is only available in 64 bit packet(as far as i know).
So, My question is :
Is it possible to somehow install it on the 32 bit OS or if any program available which can run 64 bit applications on the 32 bit OS.
I have been googling around and found no help. Can anyone help me?
I am using Ubuntu 14.04 (32 Bit).
Thank You

I have faced similar problem with c files .I think it has some thing to do with the compiler which we use
My kernel version is
3.13.0-40-generic
which you get by executing the command uname -r in terminal .
I had a code file which does file operations. When I used GCC with appropriate flags and created an object file called "fileop" and tried running it
I got the following error .
"bash: ./fileop: cannot execute binary file: Exec format error"
My executable linkable file was 32bit which you can see by using command
"file fileop"
fileop: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
But when I used "CC" instead of GCC, It created a out file called a.out and I was able to execute it without any issues.
The "file" operation yielded the following ouput
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1] =13b7ad302580a0c7f5c7931ec2d80155d7915fa9, not stripped
Hope the above Description sheds more light in to the issue.

It is not possible to (directly) run 64 bit binaries on the 32 bit system.
You could try to use VMWare to run 64 bit Linux on the 32 bit host. See this answer for details.
Also, by inspecting Breach's landing page, I found this:
if(arch === 'ia32') {
$('#download').html('Available on <span class="fa fa-linux"></span> x64');
$('#download').attr('href', '#');
/*
$('#download').html('<span class="fa fa-linux"></span> Download Breach Alpha v0.3 (ia32)');
$('#download').attr('href', 'http://bit.ly/1kWWjmF');
*/
}
This indicates that they are working on the 32 bit Linux support. Maybe ask developers on Twitter/Github on status of that?

Related

"Cannot execute binary file: Exec format error" x84-64 bit program running on aarch64 processor Debian 10

Basically I'm trying to run eclipse's 64bit linux installer on a 64 bit linux machine, but it's giving me an exec format error. All other solutions I've seen say it's usually an error with it not being the right processor speed.
My question is twofold. 1) What is going on here? 2) How do I properly download and install Eclipse?
I'm running linux through chromebook
Here is the output of a few command line statements
uname#loc:~/Desktop/eclipse-installer$ ./eclipse-inst
-bash: ./eclipse-inst: cannot execute binary file: Exec format error
uname#loc:~/Desktop/eclipse-installer$ file eclipse-inst
eclipse-inst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b621fbc20e80d7ac375ece11a5775fc6686b71c7, with debug_info, not stripped
uname#loc:~/Desktop/eclipse-installer$ uname -m
aarch64
To answer your first question I think this could help:
You are trying to execute a program designed to run on a "x86_64" based processor using a processor designed based on "aarch64" architecture. These are two distinct architectures although they both may be using 64-bits for addressing and so forth, but it's not the matter of the bits. They are two completely different CPU designs.
For your second question I can not help because I don't use Eclipse.

Eclipse cross compiling in Ubuntu 16.04

My end goal is to write a C based application to run on a 32-bit linux ARM board as an embedded system. I am running a virtual 64-bit Ubuntu OS with Eclipse Neon and I am struggling with getting a useable executable file.
I have setup the cross compiler and I have made sure to build in 32-bit.
To check the file type and get more information on it I have used the command
> file hello.elf
I got sample hello world executable that does work and the output of the file command is
hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armf.so.3, for GNU/LINUX 2.6.32, BuildID
This program runs just fine, the output of the file command for my program (be-brave) is as follows, side note it's a simple hello world, I called it be-brave for motivation
be-brave.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/LINUX 3.2.0, BuildID
My guess is that the issue is the GNU/LINUX differemce meaning my cross compiler is not set right but I don't know for sure and even if that is the case I don't know how to fix it.
Any and all pointers/suggestions are greatly appreciated
I was able to find a workaround using the command line following this tutorial
Installing ARM cross compiler
I would still like to be able to use Eclipse so I will leave this question open in case anyone can help with that. I have a new issue, I am going to edit the original question to ask that

ccx - calculix: why occurs an error when I want to execute ccx?

I've installed ccx (Calculix solver programm) to solve a physical problem. The preprocessor cgx works fine, but when I run ccx with an .inp file (abaqus) in terminal, there comes an error:
ccx: symbol lookup error: ccx: undefined symbol: _gfortran_internal_malloc
when I only run ccx without a flag or .inp file, the result is:
Usage: CalculiX.exe -i jobname
I have libgfortran3 installed on my ubuntu 14.04 computer (64 bit: x86_64) and link the "libgfortran.so.3.0.0" file in "/usr/lib/x86_64/" with a created reference object file "libgfortran.so.2" (calculix needs that file 'cause the application runs on 32 bit). Without that reference file ccx doesn't work completely and thats why I had to link it. I use Calculix 2.8p2.
If your application is 32 bit, it needs 32 bit libraries to work. What you've done is install 64 bit libraries and then symlinked them to where the 32 bit library should be. This satisfies that the library "exists" but it will be unusable for the 32 bit program.
My library locations will differ from yours, but observe that they are different:
64 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
32 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
Secondly, if your program needs libgfortran.so.2, then symlinking a version of libfortran.so.3 in its place will not work. The change in library version number is a good signal that they are not compatible and not interchangeable. You will need to find a package that provides the older library for i386 architecture. This might mean installing a package from an older version of ubuntu.

How to execute the CMU binary bomb in Ubuntu Linux?

I'm trying to do CMU's binary bomb as an independent project to learn some x86 Assembly and reverse engineering. (It's not an auto-graded version tied to a class.)
I downloaded bomb.tar from http://csapp.cs.cmu.edu/public/labs.html.
From CMU's lab description:
A "binary bomb" is a program provided to students as an object code
file. When run, it prompts the user to type in 6 different strings. If
any of these is incorrect, the bomb "explodes," printing an error
message and logging the event on a grading server. Students must
"defuse" their own unique bomb by disassembling and reverse
engineering the program to determine what the 6 strings should be. The
lab teaches students to understand assembly language, and also forces
them to learn how to use a debugger. It's also great fun. A legendary
lab among the CMU undergrads.
Here's a Linux/IA32 binary bomb that you can try out for yourself. The
feature that notifies the grading server has been disabled, so feel
free to explode this bomb with impunity.
After saving it into an appropriate folder I ran this command in the Terminal:
tar xvf bomb.tar
It did extract a file called bomb (no file extension), but I thought it would also give me bomb.c, which would also be helpful for reference.
I can't get "bomb" to run. Here's what I've tried:
bomb
bomb: command not found
./bomb
bash: ./bomb: No such file or directory
While I realize solving it requires stepping through it in gdb, I can't even run it in BASH and blow myself up with wrong answers yet! A little help would be fantastic.
As the other answers have suggested, this appears to a CPU architecture compatibility issue. I was able to resolve this on Ubuntu 15.04 64-bit by installing the packages located at AskUbuntu.com How to run 32-bit programs on a 64-bit system [duplicate]
Specifically, the following command helped.
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
Since Fabio A. Correa ran file on the bomb and found out that it was a 32-bit LSB executable, it seems that is is caused by some missing LSB scripts which should be loaded at startup.
Simply running sudo apt-get install lsb-core will fix this. After doing so, ldd bomb will also work.
Update:
Further ldd (after getting the LSB things ready) shows that it is actually caused by some inexist libc.so.6 => /lib32/libc.so.6, which is the libc of the i386 architecture. You can try installing the libc6-i386 package directly instead.
After that, you can run disassemble func_name in your gdb directly. With all the symbols preserved, you can see the names of the functions directly. strings might help you too.
Btw, this question should be placed in Unix&Linux, I guess.
file bomb informs:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
You should be able to run it on bash by typing:
tar xvf bomb.tar
chmod +x bomb
./bomb
It worked in my 64-bit Kubuntu 14.04.

unable to run a binary in mac,running on Linux

I am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp

Resources