Solution for virtualization of an Android device???

I am not sure to understand the question.

There is a thing called Genymotion
http//www.webupd8.org/2013/07/genymotion-fast-easy-to-use-android-x86.html
http//www.webupd8.org/2013/11/android-x86-emulator-genymotion-20.html

which comes with Virtual machines attempting to emulate some "common" physical devices and that uses - if I recall correctly - VirtualBox as "backbone".

jaclaz

Thank you for your answer, but I think you got my question wrong.

I dont want to run pre-configured virtual images. Like I wrote in my first post, I know that there are solutions like genymotion to virtualize a fresh installation of a x86 android image.

But I want to virtualize an android evidence device, which I took a physical memory dump (raw image) from. So I am looking for any solution to virtualize an ARM architecture.

So I am looking for any solution to virtualize an ARM architecture.

Which then will probably be Qemu
http//wiki.qemu.org/Main_Page
Example
https://lists.cs.columbia.edu/pipermail/kvmarm/2013-April/005557.html
but the point is that while Qemu can emulate an ARM architecture alright, it is to be seen if virtual hardware (apart the processor/architecture) is available which is the same as the "real machine" of which you have an image.

To make a parallel example on Qemu emulating a "normal" X86 Windows PC, set aside the processor, Qemu uses a number of "standard" devices (IDE/ATA hard disk channels, Cirrus Logic or Standard Vga or VMware video card, etc.) and if you try to run on such a VM an image of (say) a laptop, with SATA disk and - say - Nvidia GeForce video card) won't ever boot, because the drivers in the OS are those for hardware which is not emulated, until you - one way or the other - install the appropriate drivers for the virtual hardware that it is actually provided.

jaclaz

So if I got you right I have to find out which devices (graphic card etc.) are emulated from qemu and find fitting drivers for the android image? I think some linux drivers should work if they are compiled for the same linux kernel like its used with the evidence device.

Sounds like it will be hard stuff to get it work.

So if I got you right I have to find out which devices (graphic card etc.) are emulated from qemu and find fitting drivers for the android image? I think some linux drivers should work if they are compiled for the same linux kernel like its used with the evidence device.

Yes and no, meaning that you need to either find such drivers AND "install" them on the image you have (which is "wrong" from a forensic point of view as you will be altering the image) or find (or write your own) emulated devices - similar to the ones used in the "real hardware" from which the image came from (which is "right", but you wouldn't be here asking these questions if you knew how to do that, which I presume is extremely difficult/very error prone).

Sounds like it will be hard stuff to get it work.

Definitely. (

From the little I know/understand with Genymotion, it comes with a number of "common" hardware emulated, and maybe one of them is the same (or similar enough) to the device from which you took the image.
But you are right, Genymotion is x86 based, so it is not suitable for your use.

Of you prefer, from which make/model comes the image you have?

Maybe there is a specific emulator for the specific hardware (most probably only if it is "common enough") or actually such an emuated hardware existes for Qemu or similar.

jaclaz

Ok. Thank you very much for your explanations.

It was more a generally question to virtualize android evidence devices. We have a lot of different models, so I can't talk about one special model.

I just thought it would be nice to do some forensic work on a virtualized Android device or even to view the virtual device in a court case.

One way around this might be to do a logical copy of the app and the user-data to the virtual device. That way you could at least show how this app behaves with the specific user data

The problem with using physical dumps is that there are numerous ways of filesystems, SpareAreas, partitions, offsets etc. for each device. It would require a lot of configuration to build up the memory drivers, mounting points etc. inside the VBox to work with the memorydump

An image taken with an ext4,yaffs… filesystem will be very different from an UBIFS image which needs the Flash-translation layer partition (or parts of it) to get actual filetables etc. On the device itself data from the translation layer will be loaded into ram while the phone is booting. Rebuilding this process in a vm would require a ton load of work, i suppose -)

So my suggest is the above mentioned way of actuall copying the data and install the app on the Vbox (with similar android version) and work with that.

EDIT

one thing - > the process would be

- get the actual app-apk from the system/app location on the device (or app-secure for some paid apps) and install it via adb.
- run it once to let it create all the folder structure
- close it via application manager (use the force-close option)
- copy the data from the /data/data/###Ap### onto the VM
- run it -)

it is important that the app is closed proper in order to use the "new" data. Otherwise it might only access user-data from the phone ram

For court why not show visual representations of the device by using the manual examination photographs showing the actual phone display? For instance photographs of the Application and residing data such as messages or images. I understand if you no longer have the device after the extraction process that this is not a valid solution. None the less one that should be considered during any exam of this nature.

Regards,

Chris Currier