search

pi-2r / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

overlays failing when an after is specified #410

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. python --plugins=example.py -f IMAGE pslist -d

What is the expected output? What do you see instead?
A process listing is expected for IMAGE. Instead we get:

DEBUG   : volatility.utils    : Voting round
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.macho.MachOAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.lime.LimeAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.vmware.VMWareSnapshotFile'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.intel.JKIA32PagedMemoryPae'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.intel.JKIA32PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemoryPae'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.standard.FileAddressSpace'> 
DEBUG   : volatility.obj      : Applying modification from BasicObjectClasses
DEBUG   : volatility.utils    : Failed instantiating (exception): No concrete 
ProfileModification found for E
DEBUG   : volatility.utils    : Trying <class 
'volatility.plugins.addrspaces.arm.ArmAddressSpace'> 
No suitable address space mapping found
Tried to open image as:
 MachOAddressSpace: mac: need base
 LimeAddressSpace: lime: need base
 WindowsHiberFileSpace32: No base Address Space
 WindowsCrashDumpSpace64: No base Address Space
 HPAKAddressSpace: No base Address Space
 VirtualBoxCoreDumpElf64: No base Address Space
 VMWareSnapshotFile: No base Address Space
 WindowsCrashDumpSpace32: No base Address Space
 JKIA32PagedMemoryPae: No base Address Space
 AMD64PagedMemory: No base Address Space
 JKIA32PagedMemory: No base Address Space
 IA32PagedMemoryPae: Module disabled
 IA32PagedMemory: Module disabled
 FileAddressSpace - EXCEPTION: No concrete ProfileModification found for E
 ArmAddressSpace: No base Address Space

What version of the product are you using? On what operating system?
r3375

Please provide any additional information below.
If before and after are merged into a composite before, then things work as 
expected. The reason for an after here is that (in my actual application) the 
intent is to modify MalwareEPROCESS by adding in extra methods. As I wish to 
perform such modifications in multiple plugins, I want to make sure that this 
is done prior to the MalwareEPROCESS vtype being compiled, merged, etc.

If I'm understanding things correctly, I guess that the issue is located 
somewhere in obj.Profile (perhaps _resolve_mod_dependencies - the single "E" 
being printed could be accounted for at line 1117 if we assumed that s was 
bound to the string "ExampleModification")?

Original issue reported on code.google.com by carl.pulley on 17 Apr 2013 at 10:23

Attachments:

GoogleCodeExporter commented 9 years ago 
Hiya Carl, it's been a long time since I worked with the overlay stacking, but 
I don't think before and after is for when compilation happens, it's for which 
order the classes are accessed.  You can recompile everything by calling 
something like profile.recompile at any time (so you can change the object 
class an object uses whenever you'd like, then just recompile the profile).

You only need to use after if you have to ensure you're underneath another 
overlay (ie, you know the other overlay depends on something you define).  It's 
extremely rare that it's necessary, and I'm pretty sure it doesn't apply to 
your situation.  Please try only using before to define which 
ProfileModifications have to be in place before yours, and then use recompile 
if you make any changes to any of it...

Original comment by mike.auty@gmail.com on 17 Apr 2013 at 11:42

GoogleCodeExporter commented 9 years ago 
OK, the problem here is line 1085 - this line should read:

  data[a] = data.get(a, set([])).union(set([mod.__class__.__name__]))

Wrt my specific application issue, thanks for the advice/pointers - I'll carry 
on looking here as things here are not working as I'm expecting (so either my 
understanding here is lacking (very possible!) or there's something else a 
foot?).

Original comment by carl.pulley on 18 Apr 2013 at 1:44

GoogleCodeExporter commented 9 years ago 
Clarity: my application specific issue is caused by myself being slow to 
realise that profile.object_classes.update overwrites the previous object 
mapping - duh!

Original comment by carl.pulley on 18 Apr 2013 at 1:57

GoogleCodeExporter commented 9 years ago 
No problem, marking as invalid.

Original comment by mike.auty@gmail.com on 18 Apr 2013 at 6:51

GoogleCodeExporter commented 9 years ago 
Surely line 1085 of obj.Profile still needs fixing (see comment #2 above)?

Original comment by carl.pulley on 18 Apr 2013 at 7:00

GoogleCodeExporter commented 9 years ago 
Thanks, it's fixed in r3387.

Original comment by mike.auty@gmail.com on 18 Apr 2013 at 7:05