If phone is rooted you can then just insmod the compiled LiME module into it. If the phone is not rooted then the best case is temporarily rooting the phone (using an exploit that does not require a reboot), and then using the temp root access to load the module. Thanks, Andrew (@attrc) On 5/17/2014 8:10 AM, masdif wrote: _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

Thank you both, Andrew and Joe! My fault: of course it sometimes is possible to get root access without rebooting. So my initial question is answered: Yes, you can use LiME with an initially un-rooted device. --- tl;dr --- But this is not always the case, is it? Is it imaginable to somehow quantify how often we can overcome the challenges of rooting, get kernel source, unlock screen, …? Is it a waltz in general for average law enforcement forensics section? Or do they have an address book of specialists for each device/ROM/version combination? --- full length --- I’m writing about Android volatile memory dump forensics. Even if this will be a thesis for a scientific degree, my goal is to include work on real world stuff. So the use case Joe asked for is that an examiner gets a running Android device with locked screen and is asked to forensically acquire the volatile memory ASAP. That is without changing the memory too much; neither by him nor by keeping the device in a safe for a few weeks while finding out how to handle his mission. At least I want to try to quantify stochastically how often this is possible and how often this is an unfeasible task respectively. To my mind there are quite a few factors making examiner's live hard: a) The device’s manufacturer and model should be determinable from the device’s body. Ok, easy in general if the device is not too exotic. b) Next to find out is the operating system and version. You can guess that the manufacturer’s up-to-date standard ROM is on the device and no e. g. CyanogenMod or any other custom ROM. But how can you be sure? c-a) For device and guessed ROM the examiner finds an exploit to root without reboot. How likely is that? c-b) The rooting solutions I found up to now require interaction via touch screen. But in our case the screen is locked. c-c) How about rooting really new devices like an “OnePluse One”? On the other side I myself got a low-cost retro “HTC Magic” to play with; and all sources I found on the internet about exploiting/rooting end in dead links or do not work anymore (Androot, Framaroot). d) For device and guessed ROM the examiner finds the kernel sources to compile the LiME module against. This should not be a problem due to the open source license if we do not have to deal with a very exotic device. e) How to switch on debugging with the screen locked? In papers I found so far these questions were not really examined but circumvented by just using prepared devices. Examples: Thing et al. [1] just mention: “The mobile phone used in our investigation was an Android mobile phone, the Google development set”. No further modifications are discussed. Sylve [2] mentions “[…] an investigator should only use rooting techniques that have been verified to work reliably on a particular device and furthermore, verified not to have undesirable consequences, such as introduction of malicious code. The chosen rooting technique should also not require the device to be reset, which will likely wipe volatile memory.” But the paper’s focus is not on “rooting toolkit quality management”. This aspect Sylve skipped in [3]. Ali-Gombe [4] gets root access without rebooting on two Motorola devices with Androot. (But “Universal Androot v1.6.1” did not work for my own retro “HTC Magic”.) Macht [5] writes: “What method works depends heavily on the device and the Android version it is powered by. […] Because of this, this thesis assumes that an unlocked, rooted device is already available […]” Xenakis et al. [6] work with DDMS on emulator and phones without mentioning how they were prepared. Later in [7] they described using LiME but mentioned some of the limitations I see: “1. It requires rooted devices […] 2. […] The source code of kernel is not always available […]3. It requires the config.gz file […].” [1] Thing et al. (2010-08) - Live memory forensics of mobile phones http://dfrws.org/2010/proceedings/2010-309.pdf [2] Sylve (2011-12) - Android Memory Capture and Applications for Security and Privacy http://scholarworks.uno.edu/cgi/viewcontent.cgi?article= 2348&context=td [3] Sylve (2012-02) - Acquisition and analysis of volatile memory from android devices http://www.504ensics.com/uploads/publications/android- memory-analysis-DI.pdf [4] Ali-Gombe (2012-01) - Volatile Memory Message Carving - A per process basis Approach http://scholarworks.uno.edu/cgi/viewcontent.cgi?article= 2614&context=td [5] Macht (2013-01) - Live Memory Forensics on Android with Volatility https://www1.informatik.uni-erlangen.de/filepool/ publications/Live_Memory_Forensics_on_Android_with_Volatility.pdf [6] Xenakis et al. (2013-04) - Discovering Authentication Credentials in Volatile Memory of Android Mobile Devices http://cgi.di.uoa.gr/~xenakis/Published/49-I3E-2013/2013-I3E-AMNX.pdf [7] Xenakis et al. (2013-12) - Acquisition and Analysis of Android Memory http://www.ucd.ie/cci/cync/Acquisition%20and%20Analysis% 20of%20Android%20Memory.pdf Thanks a lot and have a great weekend, Philipp ________________________________________________________________ From: Joe Sylve Sent: Friday, May 30, 2014 3:41AM To: Andrew Case Cc: Vol-users, Masdif Subject: Re: [Vol-users] LiME in real world Android forensics What andrew said us completely accurate. What is your specific use case _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users