Skip to content

Commit

Permalink
Proofreading fixes part 7 0x05c (OWASP#2349)
Browse files Browse the repository at this point in the history
Link, formatting, we instead of I
  • Loading branch information
Laancelot authored Jan 24, 2023
1 parent 1d7fb90 commit aec82a1
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions Document/0x05c-Reverse-Engineering-and-Tampering.md
Original file line number Diff line number Diff line change
Expand Up @@ -2262,11 +2262,11 @@ find . | cpio --create --format='newc' | gzip > ../myinitd.img
The Android kernel is a powerful ally to the reverse engineer. Although regular Android apps are hopelessly restricted and sandboxed, you, the reverser, can customize and alter the behavior of the operating system and kernel any way you wish. This gives you an advantage because most integrity checks and anti-tampering features ultimately rely on services performed by the kernel. Deploying a kernel that abuses this trust and unabashedly lies about itself and the environment, goes a long way in defeating most reversing defenses that malware authors (or normal developers) can throw at you.
Android apps have several ways to interact with the OS. Interacting through the Android Application Framework's APIs is standard. At the lowest level, however, many important functions (such as allocating memory and accessing files) are translated into old-school Linux system calls. On ARM Linux, system calls are invoked via the SVC instruction, which triggers a software interrupt. This interrupt calls the `vector_swi` kernel function, which then uses the system call number as an offset into a table (known as sys_call_table on Android) of function pointers.
Android apps have several ways to interact with the OS. Interacting through the Android Application Framework's APIs is standard. At the lowest level, however, many important functions (such as allocating memory and accessing files) are translated into old-school Linux system calls. On ARM Linux, system calls are invoked via the SVC instruction, which triggers a software interrupt. This interrupt calls the `vector_swi` kernel function, which then uses the system call number as an offset into a table (known as `sys_call_table` on Android) of function pointers.
The most straightforward way to intercept system calls is to inject your own code into kernel memory, then overwrite the original function in the system call table to redirect execution. Unfortunately, among many other [kernel hardening measures](https://source.android.com/docs/core/architecture/kernel/hardening#implementation), stock Android kernels starting with Lollipop are built with the `CONFIG_STRICT_MEMORY_RWX` option enabled. This prevents writing to kernel memory regions marked as read-only, so any attempt to patch kernel code or the system call table result in a segmentation fault and reboot. To get around this, build your own kernel. You can then deactivate this protection and make many other useful customizations that simplify reverse engineering. If you reverse Android apps on a regular basis, building your own reverse engineering sandbox is a no-brainer.
For hacking, the recommendation is to use an AOSP-supported device. Google's Pixel smartphones are the most logical candidates because kernels and system components built from the AOSP run on them without issues. Sony's Xperia series is also known for its openness. To build the AOSP kernel, you need a toolchain (a set of programs for cross-compiling the sources) and the appropriate version of the kernel sources. Follow [Google's instructions](https://source.android.com/source/building-kernels.html#id-version "Google's instructions") to identify the correct git repo and branch for a given device and Android version.
For hacking, the recommendation is to use an AOSP-supported device. Google's Pixel smartphones are the most logical candidates because kernels and system components built from the AOSP run on them without issues. Sony's Xperia series is also known for its openness. To build the AOSP kernel, you need a toolchain (a set of programs for cross-compiling the sources) and the appropriate version of the kernel sources. Follow [Google's instructions](https://source.android.com/docs/setup/build/building-kernels#id-version "Google's instructions") to identify the correct git repo and branch for a given device and Android version.
For example, to get kernel sources for Lollipop that are compatible with the Nexus 5, you need to clone the `msm` repository and check out one of the `android-msm-hammerhead` branches (hammerhead is the codename of the Nexus 5, and finding the right branch is confusing). Once you have downloaded the sources, create the default kernel config with the command `make hammerhead_defconfig` (replacing "hammerhead" with your target device).
Expand All @@ -2280,7 +2280,7 @@ make hammerhead_defconfig
vim .config
```
I recommend using the following settings to add loadable module support, enable the most important tracing facilities, and open kernel memory for patching.
We recommend using the following settings to add loadable module support, enable the most important tracing facilities, and open kernel memory for patching.
```bash
CONFIG_MODULES=Y
Expand Down

0 comments on commit aec82a1

Please sign in to comment.