backtrace w/ldrmodules

[volatilityfoundation]

backtrace w/ldrmodules

[gleeda]

also get the same backtrace on malfind (not surprising)

[gleeda]

As I'm looking at the code where it breaks, I'm puzzled about why we are adding the obj_offset for the current VAD node within the for loop.... it seems like it should be added beforehand, so that all children will have it in the visited set... for some reason this doesn't make sense to me. if you apply the patch below, we are able to get the rest of the VAD nodes for the process that was causing the crash:

diff --git a/volatility/plugins/overlays/windows/vad_vtypes.py b/volatility/plugins/overlays/windows/vad_vtypes.py
index e685c6e..889f95b 100644
--- a/volatility/plugins/overlays/windows/vad_vtypes.py
+++ b/volatility/plugins/overlays/windows/vad_vtypes.py
@@ -64,12 +64,13 @@ class VadTraverser(obj.CType):
         elif depth and str(self.Tag) != "":
             return

+        visited.add(self.obj_offset)
         for c in self.LeftChild.traverse(visited = visited, depth = depth + 1):
-            visited.add(self.obj_offset)
+            #visited.add(self.obj_offset)
             yield c

         for c in self.RightChild.traverse(visited = visited, depth = depth + 1):
-            visited.add(self.obj_offset)
+            #visited.add(self.obj_offset)
             yield c

 class VadFlags(obj.CType):

i'm going to see if this change effects other working samples.

[gleeda]

committed to c11111e

I didn't see any changes between a handful of samples

[gleeda]

in case you want to verify, you can do:

$ python vol.py -f SampleRepository/crash/VistaSP2x86/VistaSP2x86.dmp --profile=VistaSP2x86 vadinfo -p 3620