ppd6016 / volatility

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

Volatility types and hash tables #323

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
So I came across this while working on a Linux plugin and made a simplified 
case for the issue. Basically, volatility types do not evaluate as I would 
expect when using the "in" operator with a hash table...

Example code:

        hash = {
                1 : "A",
                2 : "B",
                3 : "C"
               }

        bufferas = addrspace.BufferAddressSpace(self._config, data = "\x01\x00\x00\x00")

        val = obj.Object("int", offset=0, vm=bufferas)

        print "val: %d" % val

        print "val == 1 ->", val == 1

        print "hash[1] = ", hash[1]

        print "val in hash => ", val in hash

        print "hash[val.v()] = ", hash[val.v()]

The output:

val: 1
val == 1 -> True
hash[1] =  A
val in hash =>  False
hash[val.v()] =  A

-----------

so the confusing things are:

1) hash[1] == "A" , as you would expect

2) accessing "hash[val]" gives a key error of:

  "KeyError:  [int]: 1"

3) So you have to do "val.v()" to get the correct value out of the hash table 
and for the "in" operator to work

----------

Is there a reason it needs to be this way? It would seem like the "in" operator 
should cause the .v() in the background

Original issue reported on code.google.com by atc...@gmail.com on 8 Aug 2012 at 3:19

GoogleCodeExporter commented 9 years ago

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:27

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

Original comment by mike.auty@gmail.com on 18 Feb 2015 at 6:53