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
Related
I cannot understand how to build Botan for android, according on the instruction here:
$ export CXX=/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android28-clang++
$ ./configure.py --os=android --cc=clang --cpu=arm64
i cannot understand how to use this commands on Windows, also reading previous issues did not help me, can you tell me how did you build this library on windows step-by-step, just your command examples?
I used --cc-bin option of configure.py to specify the path to the compiler, it is considered a solution for windows, but what i have is:
D:\Programming\Libraries\botanAndroid\botan-master>python configure.py --cc-bin=D:\Android\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++ --os=android --cc=clang --cpu=armv7
INFO: configure.py invoked with options "--cc-bin=D:\Android\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++ --os=android --cc=clang --cpu=armv7"
INFO: Configuring to build Botan 2.14.0 (revision unknown)
INFO: Running under 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 22:20:52) [MSC v.1916 32 bit (Intel)]
INFO: Autodetected platform information: OS="Windows" machine="AMD64" proc="Intel64 Family 6 Model 142 Stepping 10, GenuineIntel"
INFO: Canonicalized CPU target armv7 to arm32
WARNING: Could not execute ['D:\Android\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++', '-E', 'src\build-data\detect_version.cpp']: [WinError 193] %1 is not an application of Win32
WARNING: Tried to get clang version, but output '0.0' does not match expected version format
WARNING: Could not execute ['D:\Android\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++', '-E', '-fstack-protector', '-pthread', 'src\build-data\detect_arch.cpp']: [WinError 193] %1 is not an application of Win32
WARNING: Unable to detect target architecture via compiler macro checks
INFO: Target is clang:0.0-android-arm32
INFO: Assuming target arm32 is little endian
INFO: Skipping (dependency failure): asio certstor_sqlite3 rdrand sessions_sqlite3
INFO: Skipping (incompatible CPU): aes_armv8 aes_ni aes_power8 chacha_avx2 clmul_cpu clmul_ssse3 idea_sse2 p9_darn rdrand_rng rdseed serpent_avx2 sha1_armv8 sha1_sse2 sha1_x86 sha2_32_armv8 sha2_32_bmi2 sha2_32_x86 sha2_64_bmi2 sha3_bmi2 shacal2_avx2 shacal2_x86 simd_avx2 sm4_armv8 threefish_512_avx2
INFO: Skipping (incompatible OS): certstor_system_macos certstor_system_windows commoncrypto getentropy proc_walk win32_stats
INFO: Skipping (no enabled compression schemes): compression
INFO: Skipping (requires external dependency): boost bzip2 lzma openssl sqlite3 tpm zlib
INFO: Loading modules: adler32 aead aes aes_vperm aont argon2 aria asn1 auto_rng base base32 base58 base64 bcrypt bcrypt_pbkdf bigint blake2 block blowfish camellia cascade cast128 cast256 cbc cbc_mac ccm cecpq1 certstor_flatfile certstor_sql certstor_system cfb chacha chacha20poly1305 chacha_rng chacha_simd32 checksum cmac comb4p cpuid crc24 crc32 cryptobox ctr curve25519 des dev_random dh dl_algo dl_group dlies dsa dyn_load eax ec_group ecc_key ecdh ecdsa ecgdsa ecies eckcdsa ed25519 elgamal eme_oaep eme_pkcs1 eme_raw emsa1 emsa_pkcs1 emsa_pssr emsa_raw emsa_x931 entropy fd_unix ffi filters fpe_fe1 gcm gmac gost_28147 gost_3410 gost_3411 hash hash_id hex hkdf hmac hmac_drbg hotp http_util idea iso9796 kasumi kdf kdf1 kdf1_iso18033 kdf2 keccak keypair lion locking_allocator mac mce mceies md4 md5 mdx_hash mem_pool mgf1 misty1 mode_pad modes mp newhope nist_keywrap noekeon noekeon_simd numbertheory ocb ofb par_hash passhash9 pbes2 pbkdf pbkdf1 pbkdf2 pem pgp_s2k pk_pad pkcs11 poly1305 poly_dbl prf_tls prf_x942 psk_db pubkey rc4 rfc3394 rfc6979 rmd160 rng roughtime rsa salsa20 scrypt seed serpent serpent_simd sessions_sql sha1 sha2_32 sha2_64 sha3 shacal2 shacal2_simd shake shake_cipher simd siphash siv skein sm2 sm3 sm4 socket sodium sp800_108 sp800_56a sp800_56c srp6 stateful_rng stream streebog system_rng thread_utils threefish_512 tiger tls tls_10 tls_cbc tss twofish utils uuid whirlpool x509 x919_mac xmss xtea xts
INFO: Using hardlink to link files into build dir (use --link-method to change)
INFO: Botan 2.14.0 (revision unknown) (unreleased undated) build setup is complete
Now i'm currently using VisualStudio 2017 native tool command prompt, or calling vcvarsall.bat, to set up the environment.
It seems Botan support for building Android binaries on Windows hosts is limited. You will have to use dark magic to make this work.
The build process consists of two phases, the configuration phase and the make phase.
The Android-specific instructions in the documentation you linked do not cover the whole build process, only the configuration phase. For the make phase, you then have to follow the Windows-specific instructions (link).
Configuration phase:
You will need the following binaries, adjust the paths to your machine:
clang++ (note the .cmd at the end): C:\Development\android-ndk-r19c-windows-x86_64\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++.cmd
ar: C:\Development\android-ndk-r19c-windows-x86_64\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\arm-linux-androideabi-ar.exe
In the Botan folder, run the configure command:
python.exe .\configure.py --cc-bin=C:\Development\android-ndk-r19c-windows-x86_64\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\armv7a-linux-androideabi28-clang++.cmd --ar-command=C:\Development\android-ndk-r19c-windows-x86_64\android-ndk-r19c\toolchains\llvm\prebuilt\windows-x86_64\bin\arm-linux-androideabi-ar.exe --os=android --cpu=armv7 --verbose
Make phase
The configuration phase generates a Makefile in the Botan folder. You will have to make some adjustments to this file:
In the line all: libs cli tests docs remove docs
Reason: Additional tools are needed for building the documentation files. If you really need the documentation, you could also try to install these tools, but I have not tested this.
Replace the occurrences of ln -fs with copy.
Reason: On Linux ln -fs would create a symbolic link from the second file in the parameter list to the first. This command is not available, so changing it to copying the first file to the second seems like a pragmatic work-around to me. You could also change it to the appropriate command for creating a link on Windows, but then you might have to adjust it again when deploying to your Android target.
In the lines starting with LIBOBJS =, CLIOBJS = and TESTOBJS =, replace all occurrences of \ with /. In the whole file, replace occurrences of .\ with ./. Reason: Using the Windows-style path separator \ seems to cause problems in some places.
Find the block with # Executable targets and # Library targets. Insert #<< ... << around the parameter lists (known as the nmake inline file feature, based on this answer), to make it look like this:
# Executable targets
$(CLI): $(LIBRARIES) $(CLIOBJS)
$(EXE_LINK_CMD) #<<
$(ABI_FLAGS) $(CLIOBJS) $(EXE_LINKS_TO) $(LDFLAGS) -o $#
<<
$(TEST): $(LIBRARIES) $(TESTOBJS)
$(EXE_LINK_CMD) #<<
$(ABI_FLAGS) $(TESTOBJS) $(EXE_LINKS_TO) $(LDFLAGS) -o $#
<<
# Library targets
./libbotan-2.a: $(LIBOBJS)
$(AR) #<<
$(AR_OPTIONS) $# $(LIBOBJS)
<<
./libbotan-2.so.13: $(LIBOBJS)
$(CXX) #<<
-shared -fPIC -Wl,-soname,libbotan-2.so.13 $(ABI_FLAGS) $(LDFLAGS) $(LIBOBJS) $(LIB_LINKS_TO) -o $#
<<
Reason: Without this change, I got an error about the parameter list being too long.
You will need nmake (part of Visual Studio). On my machine it is installed in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\Hostx64\x64\nmake.exe
In the Botan folder, run nmake.exe. Afterwards, your Botan folder should contain the binaries botan, botan-test and libraries libbotan-2....
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'm trying to get the assembler code executed for an APK. It can be extracted dynamically like gdb dissas or statically like objdump.
I tried with gdb without any exit.
APKs are actually just archives, similar to a JAR.
Within an APK you will find a number of files with application metadata (such as a manifest and certificate information), along with resource files and source files. The source code within an APK are also not Assembly files; they are DEX files for the Dalvik VM.
You will not find Assembly in an APK.
Solved using GDB.
Emulator:
gdbserver :5039 --attach pid
PC:
adb forward tcp:5039 tcp:5039
gdb
=> target remote 127.0.0.1:5039
Now in gdb we can see asm with "layout asm" or EIB ass using "x/i 0xEIB"
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