Didier Stevens

Tuesday 25 September 2007

Update: Disabling UserAssist Logging for Windows Vista

Filed under: Forensics — Didier Stevens @ 8:02

In my usual posting routine, most posts have a life-cycle of a couple of weeks before they get published. This allows me to think about it and conduct further testing when necessary.

Unfortunately, I didn’t do this for the UserAssist Vista post. I wanted to get this post out before my holiday, but should I have postponed it, I would have found out that toggling the privacy toggle in Windows Vista is effective immediately. It’s only when you change the setting via the registry that you have to restart Windows Explorer to make the change effective.

And another important difference is that disabling it through the start menu properties dialog will also erase all UserAssist entries!

Sunday 16 September 2007

Reversing ROL-1 Malware

Filed under: Malware,Reverse Engineering — Didier Stevens @ 7:15

Today I want to explain how I deal with a piece of malware that obfuscates its strings.

After dealing with the packing, we end up with an unpacked PE file. BinText reveals some strings, but not URLs. Searching for HTTP with XORSearch (version 1.1) doesn’t reveal any XOR encoding.

So let’s take a look with IDA Pro:

rol1-01a.png

This is interesting! The strings are somehow obfuscated. Let’s go to this .data segment:

rol1-04a.png

OK, so in this segment, all strings are obfuscated. This malware must have a routine to deobfuscate these strings before they get passed to functions like RegOpenKey…

Now let’s take a look at the code that references the start of this .data segment.

rol1-02a.png

See the LOOP and the ROR instructions? They form a very good candidate for our deobfuscation routine. The loop goes through each byte of the .data segment (0x2600 is the size of the .data segment), and performs a ROR 7 on it.

We want to decode the strings, but unfortunately, the free XVI32 binary editor doesn’t support rotate operations, only shift operations. So we will use the 010 Editor, another binary editor (not free). This editor also supports binary templates. Let’s take a look at our malware file with the PE2 binary template. We select the .data segment like this:

rol1-12a.png

And then we rotate all bytes in this segment 7 bits to the right:

rol1-08.png

Bingo:

rol1-14a.png

Let’s save this deobfuscated piece of malware and analyze it with IDA Pro:

rol1-10a.png

Now the reversing becomes more easy, because we can read the strings.

This obfuscated malware prompted me to update my XORSearch tool and to write a Python script to manipulate bits.

Saturday 8 September 2007

Disabling UserAssist Logging for Windows Vista

Filed under: Forensics,Reverse Engineering — Didier Stevens @ 20:14

For Windows XP, there is a secret trick to disable the creation of entries under the UserAssist registry keys:

under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist, create a key named Settings and under this new key create a DWORD value named NoLog with value 1. My UserAssist tool has a menu toggle (Logging disabled) to do this easily.

I call this a secret, because there is no official Microsoft documentation about this key, but of course, there are many pages on the Web about this switch.

This switch doesn’t work with Windows Vista. For Vista, you have to set the following key to 0 to disable logging:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Start_TrackProgs

But now, it’s not a secret anymore. Open the properties of the Start Menu:

userassist-privacy.png

The Store and display a list of recently opened programs checkbox allows you to toggle this Start_TrackProgs registry value.

Like for Windows XP, changing this switch only has effect after restarting Windows Explorer.

Monday 3 September 2007

The New Windows Vista, Now With Less Spying! ;-)

Filed under: Forensics,Reverse Engineering — Didier Stevens @ 5:56

I’m conducting research into the different types of values the UserAssist registry keys can adopt and what user actions cause a particular value to be created/updated. You know, I mean values like UEME_RUNPATH, UEME_RUNPIDL, UEME_UITOOLBAR, …

But this is for an upcoming blogpost. Today, I want to talk about something surprising I found with the UserAssist keys in Windows Vista.

When trying to understand a system, you often acquire valuable insights by comparing the system under scrutiny with slightly different systems. I’ve reported in the past that the UserAssist keys also exist on Windows Vista and that there is an extra Count key. Now, I wanted to find out which new types of values have been added to Windows Vista. I had quite a surprise looking for UEME strings in the browserui.dll of Vista (version 6.0.6000.16386). Contrary to what I expected to find, Microsoft didn’t add new types but removed many existing types. Here are the only UEME strings I found in the Vista DLL:

UEME_RUNPATH
UEME_CTLCUACount:ctor
UEME_CTLSESSION
UEME_RUNPIDL
UEME_RUN

Compare this to all the UEME strings present in the XP DLL (version 6.00.2900.3157):

UEME_CTLCUACount:ctor
UEME_CTLSESSION
UEME_DBSLEEP
UEME_DBTRACE
UEME_DBTRACEA
UEME_DBTRACEW
UEME_DONECANCEL
UEME_DONEFAIL
UEME_DONEOK
UEME_ERROR
UEME_ERRORA
UEME_ERRORW
UEME_INSTRBROWSER
UEME_RUN
UEME_RUNCPLA
UEME_RUNCPLW
UEME_RUNINVOKE
UEME_RUNOLECMD
UEME_RUNPATHA
UEME_RUNPATHW
UEME_RUNPIDL
UEME_RUNWMCMD
UEME_UIHOTKEY
UEME_UIMENU
UEME_UIQCUT
UEME_UISCUT
UEME_UITOOLBAR
UEME_USER

Why do I find this surprising? It’s not often that the functionality of a feature decreases when a new version is released, the opposite is often true. But I assume that some of the values didn’t make sense anymore in the redesigned Start Menu of Windows Vista. Hence the Microsoft programmers cleaned-up their code.

Here’s a little experiment you can try to confirm the removal of the UEME_UITOOLBAR value:

Open an Explorer window on Windows XP SP2 and click on the Search button on the Toolbar. With my UserAssist tool, you can check that an UEME_UITOOLBAR:0x1,123 entry has been added (or updated). 123 is the ID (hexadecimal) of the Search button.

Now on Windows Vista, the ability to customize the layout and buttons on the toolbars has been removed. But try the new search function anyway. No UEME_UITOOLBAR entry will be created. It’s only logical that if you cannot customize the toolbar anymore, the need to collect data about frequently used programs on that same toolbar disappears.

Another experiment you can try is starting a Control Panel Applet, like Power Options. Launch the Power Options control panel. On XP, you’ll see an UEME_RUNCPL entry referencing powercfg.cpl. While on Vista, you’ll see an UEME_RUNPATH entry referencing control.exe. So on Vista, you can still tell the user started a Control Panel Applet, but you’ve lost the ability to tell which one.

Important conclusion for forensic investigators: be aware that less data is collected in the UserAssist keys on Windows Vista than on Windows XP/2003.

Now if you still find other keys on Windows Vista than the 5 I mentioned, I’m interested in hearing from you. But first, check that you’re not dealing with a workstation that has been upgraded from XP to Vista or with a user data migration scheme. Because in such cases, these entries stem from Windows XP and not from Windows Vista.

I’m also working on a new feature for my UserAssist tool. It allows you to select an UserAssist entry and get an explanation, like this:

userassist_explain_1.png

BTW, there are many of the UEME strings I listed for Windows XP, that I’ve never seen in actual UserAssist registry keys. It wouldn’t surprise me that they serve another internal, unknown purpose.

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 228 other followers