Is that nerdy enough?
All blog posts to date
Introduction
It may come as a surprise to you that I am an enormous Star Wars fan.Yes, that may be surprising. I mean, I only run a blog on Android forensics (nerdy), I hack around in my spare time (nerdy), I track football stats like it is my job (nerdy), and I collect watches (nerdy). So you may be quite surprised to know that I am a Star Wars fan.
And you may have heard that a certain movie came out last week. Of course my wife and I saw Star Wars: The Last Jedi on opening night. No spoilers: I loved it. It is a complex movie that addresses some themes not previously explored in Star Wars. Normally Star Wars is black and white, good and evil. This one is more subtle. It is awesome.
And of course there is some outstanding action. I won't give anything away but I'll say there is a close-quartered battle in the movie that might be the series' best action scene. There is good emotion and character development going on in that scene, and of course the visuals of the fighting. Excellent scene.
There are so many things in the movie that I just haven't seen before in a Star Wars movie. And with that, I love that they brought back some weirdness. Star Wars needs to be weird. When the original came out in 1977, everybody probably thought Chewbacca and that entire cantina scene was weird. Now that Star Wars is such a staple of pop culture, it's not weird; it is just accepted. So this one brought some weird back and it was a perfect fit.
Overall, I haven't enjoyed a movie in the theater this much since Mad Max: Fury Road.
I could keep going on and on but I'm afraid I'll get into spoiler territory, which I will not do.
So why, you may ask, do I open with a Star Wars commentary in a post on unpacking kernels? Honestly, I've got nothing. Just wanted to talk some Star Wars.
On we go.
What is a kernel?
The kernel is the core of an operating system. Check out this Wikipedia article if you would like to know more. The kernel has the core services of an operating system. It has the programs that allow a device to even run in a usable state.
In Android, the kernel is not part of the system partition. It is a separate part of the device and you can retrieve it using forensic tools such as FTK Imager. There additionally is a recovery kernel.
The boot kernel is what boots up when you run normal Android. The recovery kernel is what runs when you are in recovery mode.
I previously said the kernel is the core operating system. It does not contain default apps, like the phone app, web browser, and other core apps. Those are in the system partition. The kernel instead has much more low level utilities.
What does unpacking a kernel even mean?
Unpacking the kernel means extracting files from within it. Pretty straightforward. And surprisingly easy, which leads me to the next section.
How to do it?
Head on over to this XDA site. All credit goes to user dsixda for developing this awesome tool, the Android Kitchen. This is a very useful tool for making custom Android ROMs with the ability to automatically do many of the functions needed to make your own Android build. We're using it for forensics, but if you are developer, definitely check this tool out. The tool's development has been done for quite a while, but the Android Kitchen remains an immensely useful tool.
Now before anything, make a physical image of your device. Follow the instructions on any of my posts on imaging a device and image the device's /dev/block/mmcblk0. Then open the image in FTK Imager and extract out the boot and/or recovery images. The following screenshot of FTK Imager shows what I mean.
Alternatively, if you have downloaded a factory image to flash to the device, you can extract the boot and recovery images out and analyze them. Depending upon the device type, you might need to run some process on the image before proceeding to the next step. You can reach out to me if you're in this type of situation.
Download the kitchen in a Linux or Mac environment (it says it also works in Windows with cygwin but I've never personally tried), and just unpack the zip. That's it. (You need to install Java but chances are you already have it set up).
Now open a terminal window and cd to the directory where you unpacked the Kitchen zip and enter the following:
./menuThis launches the Kitchen menu. Then type "0" for "ADVANCED OPTIONS", and then "12" for "Tools for boot image (unpack/re-pack/etc.)". And then "a" for "Extract kernel+ramdisk from boot.img/recovery.img in any folder".
At this point you see the following message:
Creating folder /<path to kitchen>/Android-Kitchen-0.224/bootimg_<timestamp> ...
---> Place boot.img/recovery.img into the folder mentioned above <--
Press Enter to continue
Assuming you have already extracted your boot or recovery from your image using FTK Imager or from a factory flash image, rename the extracted partition boot.img or recovery.img (whichever is appropriate for what you extracted) and copy the file to the location specified by the Kitchen. Then in the terminal screen, hit enter.
The Kitchen then does all the unpacking, and it does it fast. When done, navigate to the directory. You'll likely see two entries: a directory called boot.img-ramdisk, and a file called zImage. The file is the actual kernel program. This is the core program of the operating system. It is a native executable, so it can be analyzed but that is a topic outside the scope of this blog.
The directory is the RAM disk. The kernel mounts all the contents of this directory in RAM, and there are all kinds of findings there. There are various scripts with filenames that start with init. These are scripts that run on boot. If you've ever wanted to know what happens when you start your device and you have some basic command line knowledge, check these out. For example, I have a Nexus 7 boot image and I see the following early in the init.rc script:
mkdir /system
mkdir /data 0771 system system
mkdir /cache 0770 system cache
mkdir /config 0500 root root
These lines create important root directories. Browse around these scripts. You might gain some insight into your device.
Check out the directory sbin, if you have one. This directory stores command line programs, or native executables, that are part of the operating system. For example, mine has the file adbd, which is the ADB daemon, which activates when you interact with your device via ADB. Without this file, just about nothing on this blog would be possible. This file is stored in the kernel and lives in RAM during device operation.
I also unpacked my recovery kernel. It is laid out much the same way, which may raise an obvious question: why? When booted into Android, you have a full user experience rich with time-wasting apps (my wife is currently addicted to a mobile game and no comment on my gaming habits), but in recovery mode, you have a basic user interface. Why is the kernel so similar? The reason is this is a kernel: the core of the operating system, the functionality that allows the device to actually do something useful. So the functionality required to power the device on, use the screen, use the buttons, and capture input is the same, whether we are talking about a modern mobile operating system or a basic recovery mode.
Anyways, that recovery kernel is pretty similar, but there are some other interesting findings. My recovery mode is TWRP, so it is advanced. There is a directory called twres, and within that images. I suppose twres stands for TW resources. The images directory stores a bunch of images used in navigating TWRP. For anyone that uses TWRP, the following images might look a bit familiar.
 |
 |
 |
|---|
All found right there. Now when booting to normal Android, you will not see images packed into the boot kernel. User interface images will be stored in the system partition. Images are packed into recovery mode kernel for a few reasons:
- the images are small
- other partitions may not be mounted, so images stored there may be inaccessible
- updating recovery mode would also require updating other partitions if it is dependent upon files stored in other partitions
I mentioned the sbin directory previously. The TWRP recovery mode kernel also has an sbin directory ... and it is packed with files, notably busybox. If you've read my post on live imaging devices, you know that busybox is an insanely useful tool that gives all kinds of extra Linux-style functionality to Android. This also explains why you are able to image your device in custom recovery mode, because custom recovery mode can include busybox and a full Android shell. This sbin directory is full because TWRP includes loads of extra functionality.
Honestly, I could do a full post on breaking down the TWRP kernel. But I'd put most of my readers to sleep (those that weren't already asleep after reading my geeky writing).
Why?
This is all fun and dandy, but why would you ever want to unpack your boot or recovery kernel? I'll give you a few quick reasons:
- A sense of curiosity. You're on this blog, so you naturally have that already.
- To understand the core Android OS. If you're an advanced type, this might be up your alley.
- To see what your custom recovery mode or custom kernel is actually doing. You never know - you might want to see if there's anything fishy going on.
- If this is a forensic investigation and the owner of the device is a highly advanced user, there's a slight possibility there's some funny business in the kernel worth checking out. Faint possibility but worth considering.
Summary
- At the core of your Android usage is a kernel, and it is possible to split open the kernel and see what is inside.
- Every Android kernel has a RAM disk. You can see the init scripts and some native executables, along with possibly other resource files.
- Maybe this will be useful for an investigation. Or maybe it is just fun to do.
