Open GoogleCodeExporter opened 9 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
Original comment by jamie.l...@gmail.com
on 27 Mar 2013 at 7:20
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
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
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
[deleted comment]
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
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
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
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
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
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:
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
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
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
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
Original issue reported on code.google.com by
nojan1...@gmail.com
on 27 Mar 2013 at 6:30Attachments: