This is in relation to this XDA thread and my thread on xda. This is a cross post from XDA, trying my luck on here.
Device specs, just in case someone asks
Device Specifications:
Current Android Version: Android Lollipop 5.1.1
Chipset: Marvell Armada PXA1908 (Note: Due to this being a rarely used chip, the CF-Auto root won't work)
Custom Recovery Status: TWRP 3.0.2-0 (Not working with lollipop)
Root Status (This is technically why I am here): Android KitKat 4.4.4 (Root), Android Lollipop 5.1.1 (NO ROOT Yet)
ARMv8 64-bit
Now let's get into my steps up to the point and then my problem.
Note: In the kernel readme it states to use the toolchain 4.8 but when I use it, it complains of not being able to find gcc. Also in the read me it states "get Toolchain download and install arm-eabi-4.8 toolchain for ARM EABI.(64bit)" and when reading up on it, it says to use aarch64 for ARM 64 Bit devices.
Device Source Code can be found at Here
cd ~/android
export CROSS_COMPILE=~/android/ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-
cd ~/android/kernel
make ARCH=arm64 pxa1908_xcover3lte_eur_defconfig
make ARCH=arm64
This outputs: Image, Image.gz, .dts and .dtb files.
Where's the kernel readme (I believe this hasn't been update since kitkat) says the output will be,
- Kernel : Kernel/arch/arm/boot/zImage
- module : Kernel/drivers//.ko
Note: when trying to compile with the 32- bit ARM toolchain it fails, as the config is found in arm64, wheres other configs are found in arm.
So know I have a kernel (Image or Image.gz), and some .dts and .dtb files. Now to unpack boot.img, this is where problems occur. When trying to use tools like abootimg or the various different versions of unmkbootimg, they complain about non-standard boot.img.
or
While also try saving it as a zImage when its meant to be a Image.gz, or they extract it without throwing any errors, but when looking at the extracted files with a hex editor, it is all 00 throughout the files, therefore a useless file.
So therefor I tried manually unpacking with a hex editor and managed to get the kernel. Left is my Compiled and Right is the hex version.
Notice the difference in size, is this because the kernel in boot.img is stripped of its debugging items while mine isn't? If so I should look up on how to fix that.
But I am having troubles trying to extract the ramdisk via hex.
So is anyone able to Teach/Help me extract the boot.img properly (with tools like unmkbootimg or with a hex editor)
I have attached necessary files if you want to have a look at them yourself.
Files: Samsung xCover3 Files
Any help is appreciated.
After Numerous trial and error, I finally managed to output ramdisk.cpio.gz.
The start of a Gzip file in hex is, 1F 8B 08, therefor when using the search function in you had editor application you can narrow down your results to 1 or 2 files (2 Files for me as my kernel and ramdisk are both gzipped). You then follow it all the way down till you find a big bunch of zeros(seems like they are passing between files). When you reach the bunch of zeros include the first "00" at the end of the other hexidecial. E.G. End of one of my gzip files is "CE 24 00 00 00....00 (ZERO PADDING BETWEEN FILES), Threaded the end of my file is "CE 24 00".
Knowing this I was able to successfully extract and verify both my kernel and ramdisk files are correct.
Related
Hy Guys ..
I'm making a custom kernel project for my device, the project is almost done, but I'm having constraints about the camera, and in the kernel source there are no suitable drivers for my phone,
my last choice is just to unpack zimage stock .. can it be unpacked or not?
My Devices:
Smartfren Andromax Ec C46B2H
Qualcomm Snapdragon 410 Msm8916
Yes, but not much.
Similar to what Chris pointed out, the zImage is a binary blob which is self extracting when run by the cpu on system bootup.
So you can manually look into the initial uncompression code and do it yourself to get an uncompressed kernel binary also known as: uImage
Thats it. You cannot unpack it any further without counting disassembly.
I have an Android app that uses some JNI code. Long story short (pun intended), it is nearly impossible to convert the JNI libraries to 64-bit as it would require a lot of changes. The code (both Java and JNI) works nicely on armeabi-v7a architecture.
The libraries are being loaded using loadLibrary. When I attempt to run my app on a Nexus 6, the app loads fine. As soon as loadLibrary is executed, the app crashes with the error described here.
The problem, as I understand it, is that when executing on Nexus 6, the app builds as arm64-8a. But the libraries are not built for arm64-8a (as the 64-bit version has issues I mentioned at start of the question).
My question is, can I force arm64-8a devices to also run armeabi-v7a code? How do I force my app apk to be armeabi-v7a so it is only 32-bit regardless of device?
Yes, arm64-v8a devices can also run armeabi-v7a code.
When the APK is installed, the installer checks if the package contains libraries in the official directories, and marks the activity as 32 or 64 bit depending on the outcome.
If it finds libraries in lib/arm64-v8a within the APK (normally taken from the directory libs/arm64-v8a in the build directory), it will be marked as 64 bit, and will ignore all other directories. If it finds libraries in lib/armeabi-v7a or lib/armeabi in the APK, the process is marked as 32 bit. If there's no native libraries in any of these, the installer assumes that the application doesn't use native code at all and is free to run it in either mode, in practice in 64 bit mode.
Now if you do ship some, but not all, libraries in 64 bit mode, the process will be launched in 64 bit mode and will be unable to load the 32 bit libraries (which won't even be installed). In this case, you must avoid bundling any 64 bit libraries unless all of them are available.
Or you don't use the official libs directory but install your libraries some other way (e.g. by downloading them at runtime or keeping them in e.g. assets), the system has no idea that your process wants to run libraries in 32 bit mode (at which point it is too late to switch to the other mode). In these cases, make sure to include at least some dummy library in the normal/official way, in order to flag the application as 32 bit.
See https://stackoverflow.com/a/33919454/3115956, https://stackoverflow.com/a/27713998/3115956 and https://stackoverflow.com/a/35450911/3115956 for answers to similar issues.
I have written a .c source code (in Eclipse) which is using libcap library to get information related to network traffic. Now i have created an executable binary by using ndk-build in Eclipse. I have pushed the created binary in libs/armeabi folder to /data/local/ folder of my android (rooted nexus 5, Lollipop) and tried to execute the binary. but android is throwing this error
Error: only position independent executables (PIE) are supported
I don't know anything about PIE, Please tell me how to create a position independent executable.
I don't know anything about PIE, Please tell me how to create a position independent executable.
Position Independent Executable or PIE allows a program to be relocated, just like a shared object. At each run of the program, the program can be loaded at different addresses to make it harder for an attacker to guess certain program state.
You can compile and link a PIE executable in one of two ways. First, compile everything with -fPIE and link with -pie. The second is to compile everything with -fPIC and link with -pie.
If you are building both a shared object and a program, then compile everything with -fPIC. Link the shared object with -shared, and link the program with -pie.
You cannot do it the other way. That is, you cannot compile everything with -fPIE and build both a shared object and a program. For the details, see Code Generation Options in the GCC manual.
One thing to watch out for on Android: building with PIE prior to 4.1 will cause a segmentation fault in /system/bin/linker. PIE was added at Android 4.1, and it crashes lesser versions.
Someone told me to supply a custom link/loader to avoid the problem, but I can't find the reference at the moment.
Also see Security Enhancements in Android 1.5 through 4.1.
Error: only position independent executables (PIE) are supported
Yes, that's a Lollipop feature. See Security Enhancements in Android 5.0.
You can check if a program is built with PIE using readelf:
$ readelf -l my-prog | grep -i "file type"
Elf filetype is DYN (shared object file)
The important part is readelf is reporting DYN, and not reporting EXE. EXE means it lacks PIE, and that should trigger a security related defect.
Related, see Is PIE (Position-independent executable) for main executables supported in Android 4.0 (ICS)?
i know this is an old topic but this hacky way may save some people's time
with a Hex-Editor , find the 17th byte, change the value 02 to 03, and that’s it!
Good day for you. I just started to learn and work with android kernel development or internals. I purchased a development board on-line that uses AM3359 - TI Processor. Works fine with factory Images and I booted from SD_CARD.
Later I read the documentation and I tried to compile the kernel. Everything went well as expected. I do have a little questions that I would like to clear it regarding the files that were created.
I had a section in documentation in which I was asked to Create a Root FileSystem which gave me a file called ubi.img - What is this file ?
Later I was asked to create a tarball file providing the roots path which created me an other file rootfs.tar.bz2 - What is this file ?
My question is... both the files used the files from rootfs directory to create these files. What are these files for? What exactly ubi.img does and what is it used for? Is it used for flashing it to nand and rootfs.tar.bz2 is to boot if I am booting from SD_CARD ???
Thanks & Regards
I don't know much about AM3359 - TI Processor, but on most smartphones and also in the linux kernel requires a ramdisk which is usually compressed mostly it's a .gz file.
According to my experience when the file is decompressed and usually it contains hardware initialization routines which the kernel runs first during startup.
The .img files are where everything is stored.
Most commonly :
BOOT.img - Read Only Contains ramdisk and
the rootfs this are usually zImage + rootfs.tar.bz2
System.img- Also read only although can be remounted as read+write Contains
the operating system files e.g binaries like su, busybox etc.
Userdata.img- This is where all the users data and settings are stored.
The above are all that's necessary to get a system up and running.But we might have others such as Uboot.img Preloader etc, it varies depending on the platform.
I followed the instructions in the cyanogenmod wiki page to build a custom ROM for grouper (Nexus 7 wifi only model). However, the CM-DATE-UNOFFICIAL.zip file is not created. I get this error message --
No private recovery resources for TARGET_DEVICE grouper.
I followed the answer in this link to add below line
TARGET_KERNEL_CONFIG := cyanogenmod_grouper_defconfig
to ~/android/system/device/asus/grouper/BoardConfig.mk and did "make modules" and "make grouper_defconfig", "make grouper" to no avail.
From further research, I found that I might be missing the kernel. I followed the android documentation on building the kernel. However, this also did not solve the issue (I might have not placed the kernel at the right location). Can someone tell me what I am missing?
I was able to generate the zip file. The main issue was that Ubuntu by default uses OpenJDK while Cyanogenmod needs Oracle JDK. Downloading and using Oracle JDK and following rest of the steps mention in this xda-developers forum thread generated the zip file. Also make sure that you have plenty of swap space (atleast as much as your ram or twice of that if possible)
Another thing that is not mentioned in the wiki for building Cyanogenmod is that the kernel has to be built first. I followed this link to build the Android kernel.