There are two modes when the Android device starts: the first is to start normally and use the boot partition; the second is to start the recovery process and use the recovery partition. The structure of these two partitions is the same, which will be introduced later. The difference between the two, as the name implies, is not much to say here. The image files of these two partitions correspond to boot.img and recovery.img, which we can obtain from many sources, which contain very important things of the system.
The boot.img image file contains the kernel image file (usually named zImage) and the memory disk (initrd) image file (usually named ramdisk.img or initrd.img). For the definition of its structure, please refer to AOSP system / core / mkbootimg / bootimg.h:
1. zImage contains the bootloader, decompression program, and compressed kernel code and data. The Android kernel is based on the Linux kernel. After a lot of modifications and improvements, many people who are engaged in Android offense and defense will definitely need to obtain equipment. The kernel image file, which contains various configuration information at compile time, including global functions and data symbols; in addition to the image file, you can use tools like IDA to analyze the kernel code to find vulnerabilities; the image file can also be used to verify The existence of known vulnerabilities, etc., in short, there are many benefits.
2. The ramdisk.img mainly contains the three system partitions /, / system, and / data. These three directories contain almost all important things of the system, especially the init.rc file under the root directory /, by modifying this file You can even gain root permission permanently by changing many attributes of the system. ramdis.img mainly contains the following content:
./init.trout.rc
./default.prop saves some debugging parameters, which is very important for developers
./proc
./dev
./init.rc some startup parameters
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system system.img mount point
./data userdata.img mount point
The basic principle of brushing the kernel is to obtain boot.img, modify the content of the zImage or ramdisk.img file, such as init.rc, and then repackage it into a new boot.img, and finally burn it into the device with a flash tool That's it. Of course, many devices have locks.
Before you start, say a few words, introduce a few more important image files, in addition to the above boot.img, there are the following:
The general flash machine is generally these: uboot.img, boot.img, recovery.img, userdata.img, system.img. uboot.img should be something like BIOS, used to initialize the hardware.1. userdata.img, save user and application information, in fact, each application in android is an independent user, its structure is as follows:
/ data / app All installed apps will be moved here, the apk is split into dex and apk, dex is the target file, and apk is the resource package
/ data / data The application stores information internally, sharepreference, database, etc2. system.img, contains the entire android system, structure:
The system / app android factory built-in application is here, and at the same time, the app here can get some special permissions.
The system / framework android framework is here, it should not be disordered, developers can use adb push + pull the battery switch to quickly verify the problem. (The premise is the eng version)
Special App：
The SystemUI.apk status bar is hidden inside.
framework-res.apk contains the entire system res folder including system UI, some configuration parameters, theme, style, animation
Today, I will mainly introduce the Android kernel extraction. The extraction process is very simple. I originally wanted to write it myself. Later, I saw a very good article on the snow. Share it directly 
. This is the case for lazy people. .
Two points are added:
1. Another tool that breaks down the boot.img file is another useful one is abootimg based on mkbootimg. This tool can not only separate the kernel image from boot.img, but also build the boot.img file. github address: https://github.com/majonez/abootimg. In addition, there is a tool called mkbootimg in AOSP that can also build boot.img, but it cannot extract images. There are many useful tools in AOSP, such as mkbootfs can be used to make ramdisk.img, mkuserimg.sh can be used Make userdata.img. These tools are in the host / darwin-x86 / bin / directory of the AOSP source code.
2. The structure of the zImage file in the following article should be the binwalk tool used. This is a firmware analysis tool, which is used to analyze, extract, and reverse the firmware. It is simple and easy to use.
Original link: http://bbs.pediy.com/showthread.php?t=194803
Technical background:
Android phones get root permissions, which can allow the / system and / data partitions to obtain read and write permissions. The permissions configuration of these two partitions is generally in the init.rc file of the root partition. Modify this file to obtain root permissions permanently .
as we all know, the market most of the Android phone file system has three partitions, namely, /, / system, / data. root partition (/) after packaged as ramdisk.img, then packaged as boot.img and zImage kernel of .boot.img exists in the form of RAW DATA in EMMC / NAND, and it cannot be read or written except for programming tools. Because of this, the root partition (/) is loaded from the memory into RAM every time it is turned on. So the root partition (/) is difficult to crack without flashing.
So how to crack?
Obtain boot.img, decompress boot.img to get ramdisk.img, and then decompress ramdisk.img to get root directory (/), modify the init.rc file in it, then package, and finally get a new boot.img. Finally use flash programming The tool can burn boot.img to the mobile phone. (For details, please refer to AOSP / mkbootimg)
Analysis of the specific structure of the boot partition : 1. Extract the kernel file (1) Where is the boot? By downloading the official rom package, after decompression You can see the boot.img file inside and then decompose the rom package, briefly introduce the files inside: boot.img Linux kernel and the basic file system kernel package system.img system / system directory recovery.img system recovery program used Mirror the / data directory / data / app user application of the userdata.img system
/ system / app system application
/ system / fonts font
/ system / media switch machine animation
/ system / media / audio other audio, alarm, alert tones, and other
META-INF Brush Script information and signature
/ system / etc System configuration folder, after restoring the original settings are configured from here and build.prop call to override the error configuration, which can be placed in a folder init.d script, a script is prefixed with figures indicating the priority
build.prop phone information
where (2.1) boot in? Extracted from the real machine (here Samsung Galaxy S4 as an example)
adb shell enters the real machine, ls -l /dev/block/platform/msm_sdcc.1/by-name
msm represents Qualcomm's chip.
Msm_sdcc.1 is an external SD card The mounted directory, by-name refers to the name of this sd card partition can now be extracted by dd command boot.img dd if = / dev / block / mmcblk0p20 of = / sdcard / boot.img (2.2) boot in Where? Extracted from the real machine (Lenovo A300t as an example here) Another method to find boot.img First introduce the mobile partition information: there are mainly mtd partition and emmc partition . The brush script in the brush folder signature folder of the general brush package contains an updater. -script file. For example:
format ("ext4", "EMMC", "/ dev / block / platform / xxxx", "0", "/ system") is the EMMC partition,
format ("yaffs2", "MTD", "/ dev / block / platform / xxxx "," 0 "," / system ") is the MTD partition
MTD is a Linux subsystem used to access memory devices (ROM, flash). The main purpose of MTD is to drive new memory devices The simpler
EMMC structure consists of an embedded storage solution with MMC (multimedia card) interface, flash memory device and host controller-all in a small BGA package. The interface speed is up to 52MB per second, EMMC has The fast and scalable performance
cat / proc / mtd can use the dd command to extract the boot.img file in the same way. Then we can use the adb pull method to extract the boot.img file extracted from the real machine to Local. After that, split_boogimg.pl is used to decompose the extracted boot.img to obtain boot.img-kernel . 2. Reverse analysis of the kernel file: Generally speaking, this kernel file is a gzip compression format, and occasionally there will be other compression algorithms, such as Samsung S5 kernel file compression algorithm is lzop why ? This is the case say it briefly below: After the Kernel is loaded into memory in a compressed state is stored on the disk, the head of his section of the code is to initialize and decompression code to a code of its own compression. Part of the code is decompressed and put in the location of the real kernel.
In this way, we can decompress the real kernel file through a decompressed script. A binary file zImage.
#! / Bin / bash
pos = `grep -P -a -b -m 1 --only-matching '\ x1F \ x8B \ x08 'zImage | cut -f 1 -d: `
echo" Extracting gzip'd kernel image from file: zImage (start = $ pos) "
if [! -z $ pos]; then
echo" Dumping compressed image "
dd if = zImage of = zImage_unpacked.gz bs = 1 skip = $ pos 2> / dev / null> / dev / null
echo "Unzipping compressed image"
gunzip -qf zImage_unpacked.gz
fi
can now import it into IDA for analysis, but After importing IDA, the effect is very unsatisfactory.
This is because we need a symbol table. However, the Android Linux kernel is a flat structure, and it has no symbol table. If you have compiled the Linux kernel, you can find that the compiled zImage is packaged into the boot.img file. Go, there is a huge vmlinux below, it is put into gdb to debug and you can see the complete symbol table and debugging information. The version of the phone is not available.
But in / proc / kallsyms can provide all kernel symbol
cat / proc / kallsyms will find that the addresses are all 0 and
why the addresses are all What about 0?
Because there is a patch in / proc / sys / kernel / kptr_restrict which defaults to 1, the symbol is hidden.
As long as we set it to 0, we can print normally. If we put a su authorization file in the process of flashing, then we can echo 0> / proc / sys / kernel / kptr_restrict cat / proc / kallsyms> /data/local/tmp/syms.txt But our purpose is for root, if there is no su file here? We have other methods. You can print the symbol, then the symbol must be in the kernel. It is in __ksymtab. We can definitely know some common kernel functions, such as kallsyms_lookup_name. We can find its string in the binary file of this kernel. After its relative position, and then use its address to search, we can find a structure that starts from 0xC0008000 and brute forcing a number of consecutive memories with the above characteristics, you can find the exported symbol table of the kernel.With the symbol address, manually in the ida added
