I have hit a problem working with the ELFsh library, specifically when attempting to use the example in the testsuite which demonstrates injecting compiled C code into an existing binary.
What I've done so far is:
Checkout ELFsh from SVN (svn checkout http://svn.eresi-project.org/svn/trunk/ eresi)
./env.sh, ./configure --enable-32-64 --enable-m64, make, sudo make install. Also tried sudo make install64. After installing dependencies, the library built and installed fine.
eresi/testsuite/elf/etrel_inject/etrel_original contains the test I am interested in running. In there, I made a small change to the Makefile, which I believe has a small bug which is that -m32 is not explicitly specified in the all32 target which causes the result of all32 and all64 to be the same if compiled on a 64-bit system. Next:
I ran make (builds everything okay)
Now, my understanding of what is supposed to happen is that there is a target host.c which is compiled to hijackme32 and hijackme64. These are 32 and 64 bit binaries to which rel.32.o and rel.64.o are injected to respectively.
This injection can be performed in two ways in the test - through the ELFsh script (relinject32.esh and relinject64.sh) and through the C API (relinject32 and relinject64).
Running relinject32 results in:
[E] Unable to load object
Running relinject64 results in:
[E] Unable to copy PLT
To get finer grained information about where the problem lies, I loaded up ELFsh interactively and went through the steps of relinject32/64.esh one by one. Both scripts fail on loading of the target:
(elfsh-0.82-b2-dev#local) load hijackme32
[E] Cannot load object
(elfsh-0.82-b2-dev#local) load hijackme64
[*] Sun Mar 18 02:49:04 2012 - New object loaded : hijackme64
Architecture EM_X86_64 : AMDx86-64 architecture not supported. No flowjack available.
[E] Libmjollnir unsupported architecture
Oddly, attempting to load the 32-bit target with its full path results in a different error:
(elfsh-0.82-b2-dev#local) load /home/mike/Desktop/eresi/testsuite/elf/etrel_inject/etrel_original/hijackme32
Architecture EM_X86_64 : AMDx86-64 architecture not supported. No flowjack available.
[E] Cannot load object
This is surprising because the OS produces:
mike#mike-linux:file hijackme32
hijackme32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
mike#mike-linux:file hijackme64
hijackme64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
The current system I am testing on is x86-64 Ubuntu.
My question is how do I get this test to run? Am I setting up the environment or building incorrectly?
I tried going on the IRC (preferred method of communication), but the project (and channel) seem pretty much dead now.
Related
【1】, I have a linux os environment, which is based on arm32(qemu similute).
【2】, There are two file in / directory. One is "init", and one is "nesoft", but i can only run "init", and i can not run "nesoft" :
/ # ./init
This is initramfs - init !!!
/ # ./nesoft
-/bin/sh: ./nesoft: not found
【3】, The two file have dirrerence below:
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file init
init: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=08c7f187d91207660caa2db0101980a1f4b12716, notd
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file nesoft
nesoft: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 4.4.0, stripped
【4】, I have search ,so i think "LSB shared object" should run as executable file (I learn form https://unix.stackexchange.com/questions/472449/what-is-the-difference-between-lsb-executable-et-exec-and-lsb-shared-object )
BUT, why it still does not run ?
【END】
Has anyone meet this before, and know why ?
The main difference I see that second file is dynamically linked which means it requires library .so files to execute. I suppose it just that can't load the dependency.
Try running ldd (or export LD_TRACE_LOADED_OBJECTS=1 before running your binary since ldd may not be on busybox) to see which library is missing.
I have two ELF binaries on my Linux machine. When I run file on them I receive the following:
File#1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.0, not stripped
File#2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
Now as far as I understand it, the for GNU/Linux 2.2.X part stems from the .note.ABI-tag section of the binary and is added by the linker. The resulting value of 2.2.X depends on the version of the C library that is linked to the binary and describes the lowest ABI version that this C library version supports - meaning that File #1 will be supported on machines with a Linux kernel >= 2.2.0 and File #2 on machines with a Linux kernel >= 2.2.5. (Is that correct, or am I already wrong here?)
I would suppose that the differences in the ABI tag would stem from two different C library versions contained in the two binaries. But when I examine the strings of the binaries, both of them contain the string glibc 2.3.2.
How is this possible? It seems unreasonable to me, that a patch of some sort to the GNU C Library which didn't result in a version number change would change the supported ABI version...
The glibc ABI is supposed to be independent of the kernel version it is built for, and the test suite attempts to verify that a newly built glibc conforms to the official ABI.
The minimum kernel version required by a glibc release can be specified at glibc configure time, and this is what ends up in the .note.ABI-tag section. No patching of the glibc sources is needed. I'm not entirely sure whether it is correct that the configured minimum kernel version ends up in dynamically linked binaries (because it should be possible to run the binaries on older kernels with a differently built glibc).
However, for statically linked binaries, this is certainly correct because configuring a higher minimum kernel version will make the program fail to run on older kernels.
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
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.
After migrating a Debian 7.6 system from i368 to amd64 I encountered the problem to use some older ELF 32-bit LSB executables. Of course, there is the possibility to setup a secondary 32-bit system (in fact I could use my old one) and to apply chroot(8) or schroot(1). But I do not like the additional admin effort, the performance loss by a wrapper program and a different command sequence.
I am wondering whether there is really no way to run a 32-bit application directly on the x86_64 architecture (as possible, e.g., for HP-UX 11.0)? Both
$ /home/alf/prog32
and
$ /usr/bin/linux32 /home/alf/prog32
just lead to the failure message /home/alf/prog32: file or directory not found. This behavior is observed for all ELF 32-bit LSB executables (Debian i386, downloaded, self-written and compiled C-programs).