So basically I have some ELF binaries compiled on Linux 32 bit.
And I want to analysis it on my Mac 64 bit.
I am trying to use the gnu utils installed by homebrew such as gobjdump and greadelf.
However, when I tried to parser the elf binaries using gobjdump, I got this error:
gobjdump: hello: File format is ambiguous
gobjdump: Matching formats: elf32-i386-nacl elf32-i386-sol2 elf32-i386-vxworks elf32-i386
So my questions are:
is it possible to analysis 32 bit Linux compiled ELF binary on MAC using its gnu utils?
If possible, how to do it ?
Yes, Use the --target=bfdname option to specify the object code format. The option you probably want is elf32-i386.
gobjdump -x --target=elf32-i386 hello
References: man gobjdump
Related
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?
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
I have an object file and am trying to disassemble it. When I use:
objdump -d example.o
I get an assembly in code in the file format of elf64-x86-64.
I am trying to disassemble this into ARM, how do I go about doing this?
If you want to do disassemble of ARM code, you'd better have an ARM tool chain, this is what I got:
http://bb.osmocom.org/trac/wiki/toolchain
After you have this, you can use arm-elf-objdump instead of objdump.
The command I used is
arm-elf-objdump -D -b binary -marm binaryfile.dat
If you look the manpage, you will find "-b" is followed by the file type. Sorry I don't know how to tell -b you want to analyze a .o file. "-marm" will tell the cpu is ARM.
Hope this can help you.
Compile binutils with the right target(s) to get binutils objdump binary that knows how to disassemble ARM.
http://www.gnu.org/software/binutils/
./configure --enable-targets=all for example.
Pick your targets, make and use the new objdump binary that is your-target-aware. See the binutils/README file for more information on targeting.
objdump -D t3c # stock binary
objdump: t3c: File format not recognized
vs.
./../../binutils-2.22/binutils/objdump -D t3c # latest compiled from source with all targets
In archive t3c:
t3c:arm: file format mach-o-le
Disassembly of section .text:
00002d94 <start>:
2d94: e59d0000 ldr r0, [sp]
...
Before disassembling the binary, check the filetype via "file", for example:
file dnslookup.o
dnslookup.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV),
not stripped
So now we know it is an ARM object or ELF file.
To disassemble arm object file use
arm-linux-gnueabi-objdump. In Ubuntu, "arm-linux-gnueabi-objdump" is the default disassembler for ARM binaries - no compilation is needed.
To install it, just do:
sudo apt-get install binutils-arm-linux-gnueabi
There are also other binaries inside this package that can further analyze the ARM binaries for you.
Install the ELDK and use arm-linux-objdump. You're trying to disassemble ARM instructions using a program that only knows x86.
I'm having a hard time understanding the output of ldd - Especially the processor identifiers.
The string in question is this one:
Shortest.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, from ']', not stripped
I have several questions about it:
What does "ELF" mean? I know that's what Linux binaries are called like (Windows Binaries are called PE Binaries, "Portable Executable" Binaries), but isn't ELF an abbreviation for something?
What does LSB mean? I can't even guess it...
I see the string "Intel" there, now I seriously wonder about the portability of Linux binaries, as ldd seems to expect every binary to be compiled on a intel processor... but what if it wasn't compiled on a Intel processor? Or when I attempt to run the binary on a computer that doesn't run ontop of a Intel processor?
Why the ']'? My guess is it should be some sort of Linker identify, but ']' doesn't look much like a Identifier...
Thanks in advance
ELF is executable and Linkable Format - it specifies the format of the library - see Executable and Linkable Format. LSB specifies the endianness of the data. The Intel 386 means it will run on all chips compatible with the 386, which includes Pentiums, and AMD's chips, but not (say) Power PC or IBM/370 architectures.
As for the ']', this library wouldn't have anything to do with the test utility, would it? The one that allows you to say:
if test -x foobar
or
if [ -x foobar ]
in shell scripts.
ELF
LSB
Intel: Linux binaries are not meant to be portable
accros CPUs and achitectures. This one is meant to be used on a CUP able
to run Intel 80386 birary code.
']': ??
Trying to run my program in FreeBSD OS, I have the following results:
$ ./myprogram
ELF binary type "0" not known
./myprogram: 1: Syntax error: "&" unexpected (expecting ")")
$ file myprogram
myprogram: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
not stripped
The program is built In GCC on Ubuntu computer. What can I do? Can I build the program for FreeBSD on my Ubuntu computer by changing some build options, or I need to build it in FreeBSD OS? Maybe there is some way to convert executable to format recognized by FreeBSD?
You can run a lot of Linux programs on FreeBSD, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html.
If this doesn't work, the easiest solution would be to recompile your program on FreeBSD.
2021-06-21: This answer is outdated. As of 2021, FreeBSD includes Linux® binary compatibility, which will run most Linux binaries, save for those which "overly use i386™ specific calls, as enabling virtual 8086 mode".
A large number of Linux programs can be compiled on BSD systems however they are not the same operating system. Linux and BSD are technically not binary compatible.
These days BSD ships with an ABI (Application Binary Interface) for Linux which will translate Linux sys-calls on the fly (Much how WINE operates). This will allow you to run Linux ELF binaries on BSD systems with a small performance penalty.
That being said, they are not the same operating system and your best bet would be to compile for the target system either by gaining access to it or using a method of cross compiling.
Try branding the executable as a linux executable using brandelf (you still need all the dependent libraries setup though, or try linking it statically
http://www.freebsd.org/cgi/man.cgi?query=brandelf&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html
brandelf -t "Linux" and it should work.