Didier Stevens

One year ago, to the day, I posted YACoSTO. I explained how I reversed a program that “protects” data. This is one of my favorite posts, but it hardly gets any hits. I encourage you to read it, because this time, I focus on reversing the protected data rather than the program itself. You might learn a couple of new and simple techniques.

The binary tools I used for the YACoSTO post can be found here, I published them afterwards.

Contrary to what some of you might think, this is not a “I’m on holiday” post 😦 . We took a short cruise in June. My sister-in-law, a professional wedding film producer, shot this movie (YouTube) during our holiday, hires version here. Absolutely no malware, hacking, revering, … in the movie, just holidaying.

Oh, and BTW, until now, nobody ever asked me what YACoSTO means…

Coming Soon: Reverse Engineering Khallenge

Give it a shot, last year, the first stage was very easy, you could even crack it just using Windows Notepad!

Yes, I’ve the feeling it will be late in Brussels again…

The Firefox add-on BlockSite by Erik van Kempen allows you to maintain a blacklist of sites you want to block for surfing. I extended his add-on with a whitelist: in stead of specifying the sites you want to block, you can decide to specify the sites you want to allow, and all other sites will be blocked. Erik has integrated my code in his add-on:

Version 0.5 — December 30, 2006 — 34 KB

[+] Whitelist/Blacklist feature (by Didier Stevens): Choose if the list is a blacklist or a whitelist.
[~] Password protection still pending (unfortunately), most probably in next major release

Reverse engineering a Firefox add-on is really simple. The file format for add-ons, XPI, is in fact a ZIP file. After unzipping the XPI file, you’ll find a JAR file (again, this is also based on ZIP). Unzip the JAR file and then you can analyze the JavaScript and XUL files.

You can also load an unpacked Firefox add-on in Firefox to test and debug it, how is explained here.

I was a speaker at the local ISSA chapter last Monday. My talk explained how to use my UserAssist tool for forensic analysis. The audience had great questions for me at the Q&A, some of which I want to share here.

Does switching to the “Classic Start Menu” prevent the logging of data in the UserAssist registry keys?
No, it doesn’t. When you use the classic start menu (the start menu from Windows NT & 2000, without a frequently used programs pane), Windows explorer still continues to monitor and log the programs you execute. When you switch back to the “modern” start menu, you’ll see several of the programs you recently used in the frequently used programs pane.

Does disabling the Active Desktop prevent the logging of data in the UserAssist registry keys?
No, it doesn’t. In fact, I use the following litmus test to know if starting a program is recorded in the UserAssist keys: did a user perform the action through Windows explorer? If a user did, then the action is logged.
The only trick I know to permanently disable the UserAssist keys is this one:

• add a new subkey “Settings” under the “UserAssist” key
• add a new DWORD value “NoLog” and set it to one.

My UserAssist tool allows you to toggle this setting via a simple menu command.

One audience member asked me if I was really sure that using a mandatory user profile (NTUSER.MAN) implied that the UserAssist registry keys where not persisted.

I promised him that I would test it, and I must admit that I was wrong.
A mandatory user profile is a profile that the user can change, but the changes are not saved when the user logs out.
This is how I tested the UserAssist tool with a mandatory user profile:

1. a domain controller
2. a member workstation
3. a domain user with the profile path set to a share on the DC
4. renaming NTUSER.DAT to NTUSER.MAN
5. log on to the workstation with the domain user account
6. start some programs
7. analyse the profiles

I discovered that the NTUSER.MAN file in the local copy of the profile (file NTUSER.MAN in c:\document and settings\user on the workstation) had been modified, and that the UserAssist keys listed the program I had executed. As expected, the NTUSER.MAN file on the DC in the roaming user profile was not modified. And when I logged on to the workstation a second time, the local profile was overwritten with the mandatory profile, as expected.

So you can use the NTUSER.MAN file in a forensic investigation, but some restrictions apply:

1. use the local copy, not the file hosted on the DC (in fact, you should compare the UserAssist entries from both files, because some entries in the UserAssist keys might come from the original NTUSER.MAN file)
2. make sure to grab a copy before the user logs on again, otherwise the file will be overwritten (you could try to recover it)
3. entries in the UserAssist keys will pertain to the last session of the user, it is not a complete history of all the sessions (and remember restriction 1, comparing the profiles)

Raymond Chen has started a series of blog posts about the Start Menu’s frequently used programs. Keep in mind that he discusses the rules that govern the display and ranking of programs on the start menu, and not actually the rules for collecting the data (i.e. UserAssist keys). What he calls points is not the same as the counter in a UserAssist entry.