quentinleher / volatility

Automatically exported from code.google.com/p/volatility
0 stars 0 forks source link

Crashes when analysing android memory dumps #394

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
The crash happens when analysing a memory dump from a Samsung 10.1 inch tablet. 
It seems to have the model number GT-7510. 

Profile was created by compiling the kernel source obtained from Samsung for 
this model. The resulting System.map was used in the profile according to the 
Wiki.

What steps will reproduce the problem?
1. Dumping memory on the tablet using lime (lime address space)
2. Attempting to run the linux_pslist module on the image.

What is the expected output? What do you see instead?
I get a crash dump from python when running;

vol.py --profile LinuxAndroid-GT7510x86 -f AndroidDump.lime linux_pslist
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj      : Overlay structure cpuinfo_x86 not present in 
vtypes
Offset     Name                 Pid             Uid             Gid    DTB      
  Start Time
---------- -------------------- --------------- --------------- ------ 
---------- ----------
Traceback (most recent call last):
  File "/usr/bin/vol.py", line 186, in <module>
    main()
  File "/usr/bin/vol.py", line 177, in main
    command.execute()
  File "/usr/lib/python2.7/site-packages/volatility/plugins/linux/common.py", line 55, in execute
    commands.Command.execute(self, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/volatility/commands.py", line 111, in execute
    func(outfd, data)
  File "/usr/lib/python2.7/site-packages/volatility/plugins/linux/pslist.py", line 73, in render_text
    task.get_task_start_time())
  File "/usr/lib/python2.7/site-packages/volatility/plugins/overlays/linux/linux.py", line 745, in get_task_start_time
    data = struct.pack("<I", sec)
struct.error: integer out of range for 'I' format code

Using another plugin alters the error message slightly;
 vol.py --profile LinuxAndroid-GT7510x86 -f AndroidDump.lime linux_pstree
Volatile Systems Volatility Framework 2.3_alpha
Name                 Pid             Uid            
WARNING : volatility.obj      : Overlay structure cpuinfo_x86 not present in 
vtypes
[0??0??@???0]     -390250480                     
.[t]                 6                              
                     -16777216       0              
WARNING : volatility.obj      : NoneObject as string: Invalid Address 
0xFEFFFDF4, instantiating task_struct
--------------------                                
Traceback (most recent call last):
  File "/usr/bin/vol.py", line 186, in <module>
    main()
  File "/usr/bin/vol.py", line 177, in main
    command.execute()
  File "/usr/lib/python2.7/site-packages/volatility/plugins/linux/common.py", line 55, in execute
    commands.Command.execute(self, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/volatility/commands.py", line 111, in execute
    func(outfd, data)
  File "/usr/lib/python2.7/site-packages/volatility/plugins/linux/pstree.py", line 37, in render_text
    self.recurse_task(outfd, task, 0)
  File "/usr/lib/python2.7/site-packages/volatility/plugins/linux/pstree.py", line 53, in recurse_task
    for child in task.children.list_of_type("task_struct", "sibling"):
  File "/usr/lib/python2.7/site-packages/volatility/plugins/overlays/linux/linux.py", line 484, in list_of_type
    nxt = item.m(member).next.dereference()
AttributeError: 'function' object has no attribute 'dereference'

What version of the product are you using? On what operating system?
Arch linux 3.7.10 - Python 2.7.3

If anyone want to download the memory image it is available on;
http://nyclon.crabdance.com/mem/AndroidDump.lime

Size is 1GB

Original issue reported on code.google.com by nojan1...@gmail.com on 27 Mar 2013 at 6:30

Attachments:

GoogleCodeExporter commented 8 years ago
And the version of volatility is 2.3_alpha. Both the android and main branch 
gives the same output.

Original comment by nojan1...@gmail.com on 27 Mar 2013 at 6:32

GoogleCodeExporter commented 8 years ago

Original comment by jamie.l...@gmail.com on 27 Mar 2013 at 7:20

GoogleCodeExporter commented 8 years ago
None of the plugins are working against the profile & memory image you sent. 
How did you get the System map file for the profile? It seems like that would 
be the first place to check since none of the symbols seem to make sense

Original comment by atc...@gmail.com on 29 Mar 2013 at 7:55

GoogleCodeExporter commented 8 years ago
I downloaded the source code for the Samsung branded kernel from this site;
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValu
e=p7510
I then used the Android-NDK and the prebuilt ARM toolchain (v 4.4.3) to cross 
compile the kernel. The resulting System.map file is the one I used.
Come to think of it I had to add "-fno-pic" to the C-compiler for it to build 
however as I understand that it this only has a impact when using x64.

Original comment by nojan1...@gmail.com on 29 Mar 2013 at 9:48

GoogleCodeExporter commented 8 years ago
Did you then put that kernel on your device or kept the stock one? I ask 
because you need to cross compile our tools/linux/Makefile against that source 
and then use System.map from the phone. The system.map that you produced will 
likely not match anything on the device unfortunately. 

You can check to see if the zip distributed by them has the system.map 
(unlikely) but otherwise it must come from the device.

Original comment by atc...@gmail.com on 29 Mar 2013 at 10:02

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
No I didn't do that, I just used the System.map file from the compiled kernel 
source and built the tools/linux/module.c against the same source.
However as you said the memory dump was taken from the original kernel and not 
the one I compiled. I just sort of assumed it would work since they both are 
the same version.

Do you know if one can generate a new System.map from the zImage kernel image 
file of the device and if I can use that one?

Original comment by nojan1...@gmail.com on 29 Mar 2013 at 10:20

GoogleCodeExporter commented 8 years ago
You can try a few things:

1) Is there a system.map distributed with the kernel source code you downloaded?
2) If not, does your phone have a /proc/kallsyms? If so, you can copy this as 
System.map, but it may be missing some of the variables needed by plugin.

Try these two and let me know.

Original comment by atc...@gmail.com on 2 Apr 2013 at 6:41

GoogleCodeExporter commented 8 years ago
1) There is no system.map distributed with the kernel source.

2) Yes it has, however if I use that as the system.map then volatility says it 
can't identify the address layout. Interestingly not even the LimeAddressSpace 
works, it says "Invalid lime header" I have verified it (using a hex-editor) 
though and the header is correct.
I had to remove a few lines in the end to make volatility accept it as well, 
these lines ended with [dhd] so it was to many value for it to unpack otherwise.

Original comment by nojan1...@gmail.com on 2 Apr 2013 at 6:53

GoogleCodeExporter commented 8 years ago
Could you paste the output of "vol.py --profile LinuxAndroid-GT7510x86 -f 
AndroidDump.lime linux_pslist -d" please? (Note the -d on the end)

The debug output will contain some information to help see what's going on with 
the lime address space. Thank you!

Original comment by michael.hale@gmail.com on 8 Apr 2013 at 2:11

GoogleCodeExporter commented 8 years ago
Sure, the output it right here; http://pastebin.com/2exwt7F6
I also uncommented a print statement in the file "lime.py" to make it "say" a 
bit more.

Original comment by nojan1...@gmail.com on 8 Apr 2013 at 2:35

GoogleCodeExporter commented 8 years ago
Some more information. I have now done some further testing on a ZTE Blade 
running Cyagenmod 10.1, on this one I have compiled the rom myself so I have 
full access to the system map.

However I still can't get it to run. I have done to dumps using the lime kernel 
module on of the dumps was done using the lime format and the other in a raw 
ARM format dump.
Using the lime dump results in the same error as before;
vol.py --profile LinuxAndroid-Blade-CM10_1-2_6_35ARM -f cm10.1-blade-dump.lime 
linux_pslist -d =>  http://pastebin.com/eK5TSDkF

Using the raw dump give a just as bad result;
vol.py --profile LinuxAndroid-Blade-CM10_1-2_6_35ARM -f cm10.1-blade-dump.dd 
linux_pslist -d =>  http://pastebin.com/1VEqPN45

I'm attaching the profile to this comment and the memory dumps are on 
http://nyclon.crabdance.com/blade-memdumps/.

Original comment by nojan1...@gmail.com on 22 Apr 2013 at 8:17

Attachments:

GoogleCodeExporter commented 8 years ago
Hello,

I have been working on this issue using your files, but am still not sure if 
there is a bug in our code or if the profile is wrong. To clarify, you:

1) built a custom kernel
2) copied the custom kernel into the custom rom
3) booted the phone into the custom rom and dumped memory
4) built your profile from the same custom kernel without recompiling or 
otherwise changing anything from when you moved it to the rom

Are these steps correct? If not, what is different?

Original comment by atc...@gmail.com on 29 Apr 2013 at 5:24

GoogleCodeExporter commented 8 years ago
Hi,

All of the points are correct. I built both the kernel and the rest of the 
system according to the instructions on this forum post; 
http://www.modaco.com/topic/359832-devrom194-cyanogenmod-101-android-422/ 
(third post from the top). 

Original comment by nojan1...@gmail.com on 29 Apr 2013 at 6:38

GoogleCodeExporter commented 8 years ago
Hi nojan1989, are you still having issues with this? Andrew, are there any 
debug statements nojan1989 can put in the code to figure out what/where things 
are going wrong? 

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 9:16

GoogleCodeExporter commented 8 years ago
closing this out due to lack of activity.  reopen on github as needed: 
https://github.com/volatilityfoundation/volatility/issues

Original comment by jamie.l...@gmail.com on 20 Nov 2014 at 8:36