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