Editbox fails to find anything - Windows XP SP3

[vixtor]

I am having an issue with editbox plugin: it does not find any textboxes.

Image is of Windows XP SP3 x86, made from Virtualbox machine using VBoxManage dumpvmcore command.

There is calc.exe, notepad.exe and iexplore.exe running, so output should contain at least one of the textboxes. Specifying PID or activating experimental options did not help.

root@kali:/media/sf_D_DRIVE/Projects/Forensics/Lab3# python volatility-master/vol.py -f lab.dmp editbox -e --profile=WinXPSP3x86
Volatility Foundation Volatility Framework 2.5
24 processes to check.
*******************************************************
root@kali:/media/sf_D_DRIVE/Projects/Forensics/Lab3# 

On Windows 7 image, plugin works as expected.

[iMHLv2]

Hi @vixtor! Silly question, but do you actually have text typed into the notepad application? Also, is there any text entered in the search bar of the browser? You might also go to Start > Run and type something into the text field in the Run dialog (but don't press enter, just leave it there). Does that show up in your output?

[vixtor]

Yes, I have ensured that there is known text in all applications, so that I can try to recover it.

I tried Run dialog as suggested, no results.

Then I tried to increase RAM in Virtual machine from 512 MB to 2 GB. Nothing.

Then I tried another Win XP SP3 machine that I had (this one was set up with VBox additions and 2 GB). No change, here is the output:

D:\Projects\Forensics\LabOtherWin>volatility-2.5.standalone.exe -f labOtherWin.dmp --profile=WinXPSP3x86 editbox
Volatility Foundation Volatility Framework 2.5
29 processes to check.
*******************************************************

D:\Projects\Forensics\LabOtherWin>volatility-2.5.standalone.exe -f labOtherWin.dmp --profile=WinXPSP3x86 notepad
Volatility Foundation Volatility Framework 2.5
Process: 392
Text:
Secret code is Q1W2E3ASDF

Then I tried another machine, this time Windows XP SP2. On this one, editbox plugin worked as expected, so this could be an indicator that there is an issue with SP3 profile. Setting the profile to WinXPSP2x86 did not help.

[iMHLv2]

@bridgeythegeek are you available to help debug this?

[bridgeythegeek]

Hi @vixtor, it does sound like you're doing all the right things. Let me spin up a VM in virtualbox and see if I can reproduce the problem.

[bridgeythegeek]

@vixtor, could you run the windows plugin agains the sample and look for any !Edit classes in the output?

$ python volatility-master/vol.py -f lab.dmp windows --profile=WinXPSP3x86

An output with an !Edit class should look something like this:

Window Handle: #1019a at 0xfffff900c061cd50, Name:
2456 ClassAtom: 0xc14d, Class: 6.0.7601.17514!Edit
2457 SuperClassAtom: 0xc018, SuperClass: UxSubclassInfo
2458 pti: 0xfffff900c268a010, Tid: 2916 at 0xfffffa80042eca10
2459 ppi: 0xfffff900c0112c10, Process: iexplore.exe, Pid: 2912
2460 Visible: Yes
2461 Left: 745, Top: 31, Bottom: 979, Right: 46
2462 Style Flags: WS_CHILD,WS_OVERLAPPED,WS_VISIBLE
2463 ExStyle Flags: WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT
2464 Window procedure: 0x73d0f44c

It's these !Edit classes that editbox actually analyses.

[bridgeythegeek]

Just to confirm:

• WinXPSP3x86 machine created in VirtualBox on a Linux host.
• Acquired the memory using vboxmanage's dumpvmcore.
• git pulled the latest version of volatility.
• editbox worked as expected:

$ python vol.py --profile=WinXPSP3x86 -f winxpsp3x86 editbox
Volatility Foundation Volatility Framework 2.5
21 processes to check.
*******************************************************
Wnd context          : 0\WinSta0\Default
pointer-to tagWND    : 0xbc63c058 [0xcb9d058]
pid                  : 1672
imageFileName        : notepad.exe
atom_class           : 6.0.2600.5512!Edit
address-of cbwndExtra: 0xbc641454 [0x1afcb454]
value-of cbwndExtra  : 4 (0x4)
address-of WndExtra  : 0xbc64146c [0x1afcb46c]
value-of WndExtra    : 0xab008 [0x16250008]
pointer-to hBuf      : 0xaacd8 [0x1620ccd8]
hWnd                 : 0x500d0
parenthWnd           : 0x5f
nChars               : 31 (0x1f)
selStart             : 31 (0x1f)
selEnd               : 31 (0x1f)
text_md5             : 57899ee8b16485a1d0bf443871a2a133
isPwdControl         : No
This is notepad in WinXPSP3x86.
*******************************************************
1 Edit control found.

[iMHLv2]

Thanks Adam.

@vixtor let us know if the windows plugin works for you...

[vixtor]

No, windows plugin does not output anything.

I'm attaching a link to the compressed image that is causing this issue:

Lab3.zip (86 MB)

I tried to update VirtualBox to latest version and recreate the image. Nothing changed.

[bridgeythegeek]

Interesting. editbox is failing for the same reason windows is failing: no window objects are found!

@iMHLv2, MessageHooks.calculate() doesn't find any atom_tables. If I try the atoms plugin nothing is found; windowstations.WndScan(self._config).calculate() finds some candidates, but they fail at atom_table.is_valid(). Does this suggest the memory image is corrupt?

[iMHLv2]

I'll take a look...maybe there's an issue with the atom offsets. Stand by....

[bridgeythegeek]

Hey @iMHLv2, did you get a chance to take a look?

[iMHLv2]

Negative...sorry for the delay. I highly suspect offsets in _RTL_ATOM_TABLE changed but I haven't confirmed it yet. That would explain why _RTL_ATOM_TABLE.is_valid is failing.

[gleeda]

Any update on this?

[gsocgsoc]

Still an issue here.

[jldyer4]

Editbox is failing for me for both Win7SP1x64 and WinXPSP3x86. In both cases, atom_table.is_valid() fails. For Win7SP1x64, atom_table.is_valid() fails only for the "real" Session\Desktop--so 1\WinSta0\Default. For WinXPSP3x86, none of the atom tables are reported as valid. I am using non-virtual machines in both cases.

Memory was dumped with dumpit (Moonsols) on XPSP3 and Memoryze on Win7SP1x64.

[jldyer4]

I also tried a WinXPSP3x86 memory image from a virtual machine, acquired using .pgmphystofile. It is also failing to find any valid atom tables. I also tried to analyze each of the WinXP images on volatility running on a virtualbox Linux host and got the same failure.

@bridgeythegeek , any chance you could post a memory image that does work with editbox?

[bridgeythegeek]

Hi @jldyer4 - I'm sure I can. I've never actually managed to generate a sample where editbox doesn't work! Do you have a preferred version of Windows?

To the best of my understanding, the atom tables problem is not really a criticism of editbox, it's actually more fundamental to Volatility parsing structures. For example, the windows plugin probably fails too.

[jldyer4]

@bridgeythegeek I absolutely understand that the issue doesn't really touch editbox, but I thought it might help me to debug the atom problem if I could see an image that works with atoms, editbox, etc. The version of Windows makes no difference to me. Thanks very much.

[bridgeythegeek]

Ok, sounds good! Would love to hear what you find. I've chucked a couple of samples up for you: https://www.btg.me.uk/memory-samples/

[jldyer4]

@bridgeythegeek Thanks very much. I have been able to make a fix for my problem by comparing your images to mine. Specifically, I found that the offset to the NumberOfBuckets in the RTL_ATOM_TABLE in my XPSP3x86 images is 0x20C (instead of 0xC) and the offset to the bucket table is correspondingly 0x210. I've put an example of the raw memory (as seen by my hex editor) from a big-offset machine below.

Presumably there needs to be a way to distinguish between the relevant flavors of XPSP3x86, but I'm not sure where to go from here. Maybe @iMHLv2 should weigh in again? I'm happy to help if I can.

[bridgeythegeek]

Good stuff @jldyer4! I've actually just come across a WinXPSP2x64 sample where windows (and therefore editbox) returns nothing at all. I agree that we might need the super-devs to chip in with comments as to whether we need to be more granular than SP and architecture.