Unable to load 10.11.3 profile

[tribalchicken]

Hello,

I've run into some issues trying to use the profile for OS X 10.11.3. The same issue seems to appear for the 10.11.1 and 10.11.2 profiles.

Adding the profile causes volatility to crash with TypeError: 'int' object has no attribute '__getitem__'.

I'm sure I'm missing something simple, but haven't figured it out yet. This is using a clean clone of volatility from git on OS X 10.11 (Have also tested on a Linux box).

Additional info (stack trace and volatility debug messages):

$ python volatility/vol.py -v -f/Volumes/VMs/OS\ X\ 10.11.vmwarevm/OS\ X\ 10.11-Snapshot1.vmem imageinfo
Volatility Foundation Volatility Framework 2.5
INFO    : volatility.debug    : Determining profile based on KDBG search...
Traceback (most recent call last):
  File "volatility/vol.py", line 192, in <module>
    main()
  File "volatility/vol.py", line 183, in main
    command.execute()
  File "/Users/tribalchicken/Desktop/volatility/volatility/commands.py", line 147, in execute
    func(outfd, data)
  File "/Users/tribalchicken/Desktop/volatility/volatility/plugins/imageinfo.py", line 45, in render_text
    for k, t, v in data:
  File "/Users/tribalchicken/Desktop/volatility/volatility/plugins/imageinfo.py", line 55, in calculate
    suglist = [ s for s, _ in kdbgscan.KDBGScan.calculate(self)]
  File "/Users/tribalchicken/Desktop/volatility/volatility/plugins/kdbgscan.py", line 116, in calculate
    buf = addrspace.BufferAddressSpace(self._config)
  File "/Users/tribalchicken/Desktop/volatility/volatility/addrspace.py", line 378, in __init__
    BaseAddressSpace.__init__(self, None, config, **kwargs)
  File "/Users/tribalchicken/Desktop/volatility/volatility/addrspace.py", line 73, in __init__
    self.profile = self._set_profile(config.PROFILE)
  File "/Users/tribalchicken/Desktop/volatility/volatility/addrspace.py", line 98, in _set_profile
    ret = profs[profile_name]()
  File "/Users/tribalchicken/Desktop/volatility/volatility/plugins/overlays/mac/mac.py", line 1810, in __init__
    obj.Profile.__init__(self, *args, **kwargs)
  File "/Users/tribalchicken/Desktop/volatility/volatility/obj.py", line 859, in __init__
    self.reset()
  File "/Users/tribalchicken/Desktop/volatility/volatility/plugins/overlays/mac/mac.py", line 1830, in reset
    self.compile()
  File "/Users/tribalchicken/Desktop/volatility/volatility/obj.py", line 960, in compile
    self.types[name] = self._convert_members(name)
  File "/Users/tribalchicken/Desktop/volatility/volatility/obj.py", line 1235, in _convert_members
    members[k] = (v[0], self._list_to_type(k, v[1], self.vtypes))
  File "/Users/tribalchicken/Desktop/volatility/volatility/obj.py", line 1152, in _list_to_type
    if typeList[0] == 'void':
TypeError: 'int' object has no attribute '__getitem__'

Debug:

  ...
  DEBUG   : volatility.debug    : Applying modification from VMwareVTypesModification
  DEBUG   : volatility.debug    : Applying modification from VirtualBoxModification
  DEBUG   : volatility.debug    : Applying modification from MacObjectClasses
  DEBUG   : volatility.debug    : Applying modification from MacObjectClasses2
  DEBUG   : volatility.debug    : Applying modification from MacObjectClasses4
  DEBUG   : volatility.debug    : Applying modification from MacOverlay
  DEBUG   : volatility.debug    : Applying modification from MachoOverlay
  > /Users/tribalchicken/Desktop/volatility/volatility/obj.py(1152)_list_to_type()
  -> if typeList[0] == 'void':
  (Pdb) 

Interestingly enough, attempting to build my own profile on an 10.11.3 VM yields a different error - But that will probably be a different issue (or a user issue - haven't looked at it too much).

Let me know if I can provide any other info.

Cheers,

Thomas

[williamshowalter]

I am receiving the same errors and stack traces as @tribalchicken on the new El Capitan profiles. When I make my own profile using the Mac wiki instructions I also run into a different issue. I'm getting "object of type 'int' has no len()". Given the 'int' object has no attribute 'getitem' in the repo and then len() being run on an int, I'm guessing something in the profile creation process is messing up creating the vtypes and an int is being created in a place a list is expected.

[williamshowalter]

Going off of that hunch I diffed a working Yosemite profile from the repo with the profile I created and I found entries like this all over the file:

<     'soi_so': [0x88, ['unsigned long long']],
<     'soi_pcb': [0x90, ['unsigned long long']],
<     'soi_type': [0x98, ['int']],
<     'soi_protocol': [0x9c, ['int']],
<     'soi_family': [0xa0, ['int']],
<     'soi_options': [0xa4, ['short']],
<     'soi_linger': [0xa6, ['short']],
<     'soi_state': [0xa8, ['short']],
<     'soi_qlen': [0xaa, ['short']],
<     'soi_incqlen': [0xac, ['short']],
<     'soi_qlimit': [0xae, ['short']],
<     'soi_timeo': [0xb0, ['short']],
<     'soi_error': [0xb2, ['unsigned short']],
<     'soi_oobmark': [0xb4, ['unsigned int']],
---
>     'soi_so': [0x88, 0],
>     'soi_pcb': [0x90, 0],
>     'soi_type': [0x98, 0],
>     'soi_protocol': [0x9c, 0],
>     'soi_family': [0xa0, 0],
>     'soi_options': [0xa4, 0],
>     'soi_linger': [0xa6, 0],
>     'soi_state': [0xa8, 0],
>     'soi_qlen': [0xaa, 0],
>     'soi_incqlen': [0xac, 0],
>     'soi_qlimit': [0xae, 0],
>     'soi_timeo': [0xb0, 0],
>     'soi_error': [0xb2, 0],
>     'soi_oobmark': [0xb4, 0],

I found out that the following 3 types had the wrong type declarations in the El Captain repo profiles:

  'IOExternalAsyncMethod': [ 0x30, {
    'object': [0x0, ['pointer', ['IOService_class']]],
    'func': [0x8, 0],
    'flags': [0x18, ['unsigned int']],
    'count0': [0x20, ['unsigned long long']],
    'count1': [0x28, ['unsigned long long']],
}],
  'IOExternalTrap': [ 0x18, {
    'object': [0x0, ['pointer', ['IOService_class']]],
    'func': [0x8, 0],
}],
  'IOExternalMethod': [ 0x30, {
    'object': [0x0, ['pointer', ['IOService_class']]],
    'func': [0x8, 0],
    'flags': [0x18, ['unsigned int']],
    'count0': [0x20, ['unsigned long long']],
    'count1': [0x28, ['unsigned long long']],
}],

By looking at previous declarations for this type I determined that func should have been:

   'func': [0x8, ['BitField', {'end_bit': -18446744073709551488L, 'start_bit': -18446744073709551616L}]],

I've patched them for the 3 El Capitan profiles and will be submitting a pull request shortly.

[tribalchicken]

I can confirm the patched vtypes do indeed seem to resolve the issue. Thanks, @williamshowalter

[iMHLv2]

Thanks guys, nice work. @atcuno will factor this into the profile generation script in the future.