Skip to main content

Setting my Yocto qemu environment for reverse engineering experimental purpose

In this post I have discussed about, how I set my ARM reverse engineering platform in Yocto Qemu. Generally when we are talking about reverse engineering then we need a target platform where we could exercise our experiments. We Can choose Raspberry pi, Beagle Bone etc. for these kind of experimentation. But what we can do in these platforms, can also be performed in some virtual environments. Only for experimenting on some kind of side channel attacks, we would need the actual hardware.

For making the setup, you would need some PC with very good configuration likely atleast 4 GB of RAM, 100 GB of free space, and with atleast Quad Core Processor. I have installed VMWare (non-commercial version) which is running Ubuntu 18.04. If you have ubuntu installed in your PC itself then it is well and good.

I have followed this link to install Ubuntu. The following steps would help:

1. First clone the source code of Yocto. You might also require some dependencies to get it installed:
$ cd $HOME/yocto
$ git clone git://git.yoctoproject.org/poky -b zeus

2. Add gdb package as part of core-image-minimal reciepe:

diff --git a/meta/recipes-core/images/core-image-minimal-dev.bb b/meta/recipes-core/images/core-image-minimal-dev.bb



index 93ead20553..8ecfd4c1f9 100644



--- a/meta/recipes-core/images/core-image-minimal-dev.bb



+++ b/meta/recipes-core/images/core-image-minimal-dev.bb



@@ -5,3 +5,4 @@ is suitable for development work."







 IMAGE_FEATURES += "dev-pkgs"







+IMAGE_INSTALL += "gdb vim"

3. Edit the file $HOME/yocto/poky/build/conf/local.conf and check the following variables and build the complete set of images:
MACHINE ?= "qemuarm64"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_ipk"
INHERIT += "rm_work"
$ bitbake core-image-minimal

4. Make a script to run the build images in qemu (check the path):
/home/sourabh/yocto/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64 -device virtio-net-device,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive id=disk0,file=/home/sourabh/yocto/testbins/core-image-minimal-qemuarm64.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -show-cursor -device VGA,edid=on -device qemu-xhci -device usb-tablet -device usb-kbd -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0  -machine virt -cpu cortex-a57 -m 256 -serial mon:vc -serial null -kernel /home/sourabh/yocto/poky/build/tmp/deploy/images/qemuarm64/Image -append 'root=/dev/vda rw  mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 console=ttyAMA0 '
NOTE: I have copied the rootfs in some separate directory. All these above suffs has been copied in run.sh

5. While you run the script run.sh, which would open a new qemu pop-up window, something like this:

Now you will be wondering how to cross compile and send image to qemu. So there is two solutions: 1. You can add all development related stuffs like gcc, as, ld, xxd, objdump etc in Yocto reciepe.
2. To cross-compile all the codes outside qemu, while you mount and store the binaries and other stuffs inside the rootfs and start the qemu machine again and again.
For doing this:
 
$ mkdir mnt
$ sudo mount /home/sourabh/yocto/testbins/core-image-minimal-qemuarm64.ext4 mnt/
$ sudo cp <target_testable_binaries> mnt/home/root/
$ sudo umount mnt/
$ sudo ./run.sh

Comments

Post a Comment

Popular posts from this blog

ARM Trustzone - An overview on how SMC calls are handled by the EL3 Monitor

In this write up, we will focus mainly on the ARMv8-A exceptions, the role of ARM Trusted Firmware (that provides Secure Monitor functionality) and how the World Switch happens between Secure and Normal. If we look on the the architectural diagram of ARM Trustzone w.r.t ARMv8-A, the Execution Level is divided into four levels namely: EL0 (Secure & Non-Secure) - User Application EL1 (Secure & Non-Secure) - Kernel EL2 - Hypervisor for running different OS's simuntaneously EL3 - Security Monitor Now, whenever a normal world User Application calls for some Secure Operation, the calls goes via IOCTL call to the Linux Driver, which ultimately calls the smc instruction. To understand what the smc instruction, we have to look on the Exceptions in ARMv8 ARMv8 Exceptions In ARMv8 the exceptions are divided into two categories: Synchronous & Asynchronous.  An exception is described as synchronous if it is generated as a result of execution or attempted executi...
1 comment
Read more

An overview of ARM Memory Management Unit

The scope of this documentation is to understand the Memory Management Unit for ARMv8 Based processor. Memory management Unit converts the virtual Address (in CPU's logical space) into Physical Address. For an example let us suppose in the following program: int variable; printf("Addrss of variable = 0x%x\n", &variable); The address could be anything (Let's assume  0x40000200 ). Now 0x40000200 may or may not the actual memory address in the Physical Memory (RAM). It could be anything thing (lets assume  0xA0000200 ). Thus the CPU produce the logical address 0x40000200 which is converted into the physical address 0xA0000200 by the Memory Management Unit. Now the question remains Why we require an Address Translation, or in other word in the above program why we don't operate on actual physical memory 0xA0000200? Let us suppose a program that requires a huge amount of contagious memory in the RAM. Now our external memory would have that much memory requ...
1 comment
Read more

Reverse Engineering an ARM binary

In continuation to my previous experiment , this experiment is all about hacking into an ELF binary file. Means we will change the characteristics of and ELF file by reverse engineering its assembly instructions. For this experiment I have choose AARCH64 binary which is suppose to run in an 64 bit ARM machine. Here I have used these utilities: readelf / aarch64-linux-gnu-readelf aarch64-linux-gnu-objdump - Used to dump all the assembly instructions in a binary xxd (which I feel one of most power free weapon of reverse engineering). NOTE that the toolchain I have installed while building the raspberry secure images . To understand the reverse engineering, one should atleast know the forward engineering that means the basis conditional statements (if, else) and loop statements (for / while). I've demonstrate a program which takes input string (key), compare it with some hard-coded one and accordingly execute the access condition. This is something like an decade ol...
Post a Comment
Read more