I have taken android linux kernel split it from the gzip header and decompressed it. However when I try to do an objdump from the android ndk to dump the file I am getting a File format not recognized error.
Anyone know how get a symbol table from the binary image.
On my android device I can do the following to get a symbol table:
cat /proc/kallsyms
This is not unique to Android - it happens on most (all?) Linux systems. The bootable image of the Linux kernel (on which Android is based) is not a proper ELF binary:
# file /boot/vmlinuz-2.6.38.7-desktop-1mnb2
/boot/vmlinuz-2.6.38.7-desktop-1mnb2: Linux kernel x86 boot executable bzImage, version 2.6.38.7-desktop-1mnb2 (thomas#celeste.mandriva.com) #1 SMP Sun, RO-rootFS, root_dev 0x902, swap_dev 0x3, Normal VGA
# nm /boot/vmlinuz-2.6.38.7-desktop-1mnb2
nm: /boot/vmlinuz-2.6.38.7-desktop-1mnb2: File format not recognized
The bootable image is created by wrapping the vmlinux kernel ELF binary in a compressed container and adding a set of boot and decompression utilities. If you need a kernel image for debugging. the vmlinux file is what you need - I don't know if/where it exists in the Android NDK though.
Try using nm.
$ nm path/to/someobj
Related
I'm trying to build a C binary for my Oneplus 3T (LogoInjector) which uses a snapdragon 821 so it's a arm64 device.
When I run:
android-ndk-r13b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-gcc -I android-ndk-r13b/platforms/android-24/arch-arm64/usr/include -c LogoInjector.v1.4.c lodepng
and copy the compiled binary to /system/bin on my phone I get this error:
sush: /system/bin/LogoInjector: not executable: 64-bit ELF file
I also tried the 32 bit toolchain but then it gives me:
sush: /system/bin/LogoInjector: not executable: 32-bit ELF file
I set the binary's permission to 755 just like all the others in /system/bin
Can anyone help me fix this?
Thanks!
The -c switch is instructing the compiler to perform the compilation only step, skipping the linkage stage, producing an object file and not executable. Invoke the
aarch64-linux-android-gcc -I android-ndk-r13b/platforms/android-24/arch-arm64/usr/include LogoInjector.v1.4.c -o lodepng
command instead. It is possible that you will need to specify some linker options (like libraries to link with) in addition to these parameters.
I met this issue when trying to run an application.
Try to run command :"file nameapp". Here I get:
ELF executable, 32-bit LSB arm, dynamic (/system/bin/linker), not stripped.
But my board run command:"file system/bin/sh"
ELF shared object, 64-bit LSB x86-64, dynamic(/system/bin/linker64), for Android 27,BuildID=4a49062467e2958e78ce79839f483302, stripped.
It's different so cannot run.
If you want to run it. Get the file with x86-64.
I'm trying to compile a Android Kernel from source and I have downloaded all the right packages to do it but for some reason I get this error:
arm-linux-androideabi-gcc: error: unrecognized command line option '-mgeneral-regs-only'
/home/livlogik/android/kernel/H901BK_L_Kernel/./Kbuild:35: recipe for target 'kernel/bounds.s' failed
make[1]: *** [kernel/bounds.s] Error 1
Makefile:858: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
I have the latest NDK and I'm using Ubuntu 15.10 64bit if this helps.
Here is where I have the NDK and kernel:
NDK ---- /home/livlogik/android/ndk/
Kernel ---- /home/livlogik/android/kernel/H901bk_L_Kernel/
If someone could help me that would be great. Sorry if this was already posted I could find a answer to it.
Thanks,
Zach
As it can be seen from build error message:
drivers/media/platform/msm/camera_v2/sensor/msm_sensor.c:20:27: fatal error: ./mh1/msm_mh1.h: No such file or directory
#include <./mh1/msm_mh1.h>
compiler just can't find msm_mh1.h file. This is because the path specified for #include directive isn't correct. Most probably it's typo: instead ./ there should be ../.
To fix that error, in drivers/media/platform/msm/camera_v2/sensor/msm_sensor.c file change this line:
#include <./mh1/msm_mh1.h>
to this line
#include "../mh1/msm_mh1.h"
After this make command should work fine. Also, kernel image file will be available at arch/arm64/boot, and it's not zImage as stated in documentation, it's actually Image.gz. Uncompressed kernel image is Image file.
Update
Answering your question in comments:
Is there any way to make it compress into a zImage?
From Documentation/arm64/booting.txt:
The AArch64 kernel does not currently provide a decompressor and
therefore requires decompression (gzip etc.) to be performed by the boot
loader if a compressed Image target (e.g. Image.gz) is used. For
bootloaders that do not implement this requirement, the uncompressed
Image target is available instead.
Basically zImage is just gzipped and self-extracted Image. So zImage file consists of program for unpacking gzip archive in the beginning, followed by gzipped Image, and when kernel is run by bootloader its unpacking itself (hense "self-extracted" term) and then start running.
...So I can make it flashable
In case of arm64, you don't have zImage, so most likely you need to use Image file (which acts in the same way, but only its size is bigger). You can create boot.img from Image file and built AFS ramdisk (using mkbootimg tool) and then just do fastboot flash boot boot.img. Refer to this documentation for example. Of course for your platform some things can be different, so try to find instructions for your platform.
You have to install the right toolchain:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
And configure the Makefile appropriately
The wrong toolchain is at
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-android-4.9
I want to create an image for the Arm chip and deploy it on my Samsung Note 3. I have a compiled copy of
the Samsung source. I added another module to this copy for added functionality. I then downloaded a copy
of the stock firmware, which I have used a number of times to flash my phone. I took the boot.img file of
the stock firmware split it open with a tool online, and replaced the zImage with the zImage that I got
from compiling my source. After several attempts, I seem to be able to create a complete tar.md5 file of
everything in the directory of modified stock source. When I flash the phone with this file using Odin,
the file goes in fine, but the phone is stuck in download mode. I am trying to figure out the main cause
of phone going into download mode, and is the root cause one of packing the files incorrectly or did I not
include a file that is required? Here is what I did to create the tar file with md5 authentication:
I created the tar file:
tar -H ustar -c aboot.mbn sbl1.mbn rpm.mbn tz.mbn sdi.mbn NON-HLOS.bin boot.img recovery.img
system.img.ext4 cache.img.ext4 modem.bin > tarfile.tar
cp tarfile.tar tarfile.tar.md5
md5sum tarfile.tar >> tarfile.tar.md5
I then tried to do a sanity check by comparing the file with a tar archive in an image I have used to
flash my phone with using the file command, and here is what I get ( note: I put my results in the
/expermental directory and the unpacked validated tar file in /originalstck/originaltarfile directory ) (
Note also that the file called tarfile below is the result of packing my files vs.
N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5 is what was in the validated stock rom ) :
#ubuntu:~/expermental_stock$ file *
aboot.mbn: Hitachi SH big-endian COFF object, not stripped
boot.img: data
cache.img.ext4: data
info: ASCII text
initramfs.cpio.gz: gzip compressed data, from Unix
modem.bin: x86 boot sector
N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5: POSIX tar archive
N900PVPUCNC5_N900PSPTCNC5_SPR.zip: Zip archive data, at least v2.0 to extract
NON-HLOS.bin: x86 boot sector
recovery.img: data
rpm.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
sbl1.mbn: data
sdi.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
SS_DL.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS
Windows
system.img.ext4: data
tarfile.tar: POSIX tar archive (GNU)
tz.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
zImage: Linux kernel ARM boot executable zImage (little-
endian)
file ~/originalstock/originaltarfile/*
/aboot.mbn: Hitachi SH big-endian COFF object, not stripped
/boot.img: data
/cache.img.ext4: data
/modem.bin: x86 boot sector
/N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5: POSIX tar archive
/NON-HLOS.bin: x86 boot sector
/recovery.img: data
/rpm.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
/sbl1.mbn: data
/sdi.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
/system.img.ext4: data
/tz.mbn: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), statically linked, stripped
( Note: Here tarfile.tar is the file I made, and I am comparing it with the original tar file that came with the stock rom, which is called N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5.) There are two things that concern me with the above output as I am comparing tarfile.tar in /experimentalstock directory with N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5 file in the originalstock/originaltarfile dirctory. 1- tarfile.tar is smaller. I added more modules to the source. But that may be explained by the source I started from. I did compare the boot.img files, and the one I created by adding my zImage to it is larger than the one that came with stock rom. I started from the Samsung source code which may not contain the telecom provider's files. 2- My other concern is the output associated with the file command; for tar.file I get: POSIX tar archive (GNU) and for N900PVPUCNC5_N900PSPTCNC5_N900PVPUCNC5_HOME.tar.md5 I get POSIX tar archive. Is there a difference between the GNU version vs. whatever is the default format?
My other question is how can see what is going on during the boot when I push my image to the phone? Is there some way I can save the logs on a phone that is unrooted?
According to one of the online sources I used to get this far, I also need to or may include kernel modules. As far as I remember these files have a km extension? I did a search in my Kernel's directory, and do not see any files with this extension:
user#ubuntu:~$ locate -r '^/home/user/androidkernel3/.*.km$'
/home/user/androidkernel3/arch/arm/mvp/commkm
/home/user/androidkernel3/arch/arm/mvp/mvpkm
/home/user/androidkernel3/arch/arm/mvp/oektestkm
/home/user/androidkernel3/arch/arm/mvp/pvtcpkm
user#ubuntu:~$
Sean
I'm trying to port Android on VersatilePB using [Android Goldfish 3.10 kernel](https://android.googlesource.com/kernel/goldfish/+/android-goldfish-3.10).
First, I configured kernel for versatile_defconfig and I successfully built it. I got .config file, renamed it as versatile_config and added Android base configuration to that using the following command
ARCH=arm scripts/kconfig/merge_config.sh versatile_config android/configs/android-base.cfg
Again, I built the kernel successfully. After that, I built the Android Google source code and I have taken ramdisk.img from google_src_v4.4/out/target/product/generic. After that, I tested using following command,
qemu-system-arm -M versatilepb -kernel ./arch/arm/boot/zImage -initrd ramdisk.img -append "console=ttyAMA0 root=/dev/ram0 rw" -serial stdio
but I'm getting the following error. Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: init Not tainted 3.10.0 #15
[<c001271c>] (unwind_backtrace+0x0/0xe8) from [<c001129c>] (show_stack+0x10/0x14)
[<c001129c>] (show_stack+0x10/0x14) from [<c0368304>] (panic+0x8c/0x1d4)
[<c0368304>] (panic+0x8c/0x1d4) from [<c001fe94>] (do_exit+0x7f8/0x8d8)
[<c001fe94>] (do_exit+0x7f8/0x8d8) from [<c001ffe0>] (do_group_exit+0x40/0xd4)
[<c001ffe0>] (do_group_exit+0x40/0xd4) from [<c002a75c>] (get_signal_to_deliver+0x178/0x5c4)
[<c002a75c>] (get_signal_to_deliver+0x178/0x5c4) from [<c00109a4>] (do_signal+0xd0/0x434)
[<c00109a4>] (do_signal+0xd0/0x434) from [<c0010ea4>] (do_work_pending+0xa8/0xb8)
[] (do_work_pending+0xa8/0xb8) from [] (work_pending+0xc/0x20)
Somehow related to the "init()" function, where kernel is trying to create the very first process (in userspace) for the first time - this is also where LInux and Android differs. So did you use the QEMU from Android?:
https://github.com/android/platform_external_qemu
And see the discussion here:
https://balau82.wordpress.com/2010/03/22/compiling-linux-kernel-for-qemu-arm-emulator/
there are some hints here:
Run Android app in qemu-arm?
And here has commandline for emulation:
How to compile android goldfish 3.4 kernel and run on emulator
As I could not get mksquashfs tool for android. I compiled it for arm using cross compilation and got it built, toolchain is same for kernel as well mksquashfs.
I pushed mksquashfs to /data/ partition of target.
#: cd /data/
#: mkdir xyz
#: ./mksquashfs xyz xyz.sqsh
Error message is:
/system/bin/sh: ./mksquashfs: not executable: magic 7F45
Please let know how to get a working mksquashfs for android, if I am missing any cross compile toolchain etc.
Magic number 7F45 specifies the Executable and Linkable Format (ELF) file type, a format that is not executable on ARM processors.
Reason could be either improper cross compilation or either using wrong toolchain.
Using correct toolchain should fix this problem