Didier Stevens

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.

I started mentoring someone on Reverse Engineering. We use a Wiki to communicate, feel free to join as a mentor or mentee.

Have you read NJ Verenini post on Websense’s Blog were he explains how to use SpiderMonkey to deobfuscate Javascript? As SpiderMonkey has no document object, Verenini shows a way to define your own document object to support document.write().

I’ve adapted the SpiderMonkey source code to include the document object. Not that my method is better than Verenini’s, I just wanted to play with SpiderMonkey.
An upcoming “Virus Lab” post will explain how I use this adapted SpiderMonkey, but for now I want to explain how I proceeded to modify SpiderMonkey.

If you’re not familiar with the SpiderMonkey source-code (like me), were do you start? I want to implement a document object with a write method. Is there something similar in JavsScript? Take a look at the Math object.

js
js>Math
[object Math]

The Math object has several methods, like sin:
js> Math.sin(3.1415926/2)
0.9999999999999997

document does not exist:
js> document
2: ReferenceError: document is not defined

The trick is to add a document object that has the same behaviour as the Math object (i.e. same members), and if this works, we adapt the document object by removing all Math members and adding a write method.

Greping for Math in the source code reveals that the object is defined in jsmath.c and jsmath.h. This is good, the Math object is defined in it’s own source files. So we will make our own source files for document based on Math: copy jsmath.[ch] to jsdocument.[ch]. Then edit jsdocument.[ch] and replace Math with document (there are some execeptions, like math.h).

Then we add jsdocument.[ch] to the makefile.
Greping for jsmath.h reveals that it’s included in jsapi.c. A quick search for
Math in jsapi.c reveals this code:
js_InitMathClass(cx, obj) &&
{js_InitMathClass, ATOM_OFFSET(Math)},

We add our own code:

js_InitDocumentClass(cx, obj) &&
{js_InitDocumentClass, ATOM_OFFSET(Document)},

Now when we build, we’ll get an error because we use a Document ATOM that we didn’t define. A bit of searching in the source code shows that atoms are defined in jsatom.[ch]. We search for Math and add extra code for Document.
And now the build succeeds!

js
js> document
[object document]
js> document.sin(3.1415926/2)
0.9999999999999997

Now we have to remove all members and add our own write method, but this is for another post, where I’ll publish my modified spidermonkey (it’s GPLed).

Reversing with the commented source code is not so difficult as reversing binaries, especially the patching process. If you want to add a new feature, look for an existing similar feature and do an “intelligent” copy-paste of the source code.

Once upon a time, long ago, I read the Dragon Book, and this also explains how I was able to quickly understand how to modify SpiderMonkey.

I’ve released a new version of my OllyDbg plugin called OllyStepNSearch.

The new features are:

• an options dialog
• Disable After Break option
• Search in Information Pane
• a new help function

And this time, there is also a demo movie here on YouTube, a hires (XviD) version can be found here.

Unipeak is a free anonymous proxy, it encodes the URLs like this:

http://www.unipeak.com/gethtml.php?_u_r_l_=aHR0cDovL3d3dy5nb29nbGUuY29t (this is http://www.google.com).

Suppose you had to reverse engineer the encoding scheme, how could you proceed? You are in a comfortable position, because you can execute a Chosen Plaintext Attack.

First we need to find out if the encoding scheme is reversible, because it could also be a hash or another key used to access the cache of the proxy (if it’s a caching proxy).

So we add a letter ‘a’ to the encoded URL and see what Unipeak replies:

http://www.unipeak.com/gethtml.php?_u_r_l_=aHR0cDovL3d3dy5nb29nbGUuY29ta

and we see the Google website.

So it’s not a hash, it’s reversible.

We add another ‘a’:

http://www.unipeak.com/gethtml.php?_u_r_l_=aHR0cDovL3d3dy5nb29nbGUuY29taa

and now we get an error message:

unable to connect to http://www.google.comi:80/

It’s definitely reversible.

Searching with Google via Unipeak gives another URL:

http://www.unipeak.com/gethtml.php?_u_r_l_=aHR0cDovL3d3dy5nb29nbGUuY29tOjgwL3NlYXJjaA%3D%3D&hl=en&q=unipeak&btnG=Google+Search

This URL starts with the same sequence as our first URL, so it’s probably a simple encoding scheme where the characters are processed from left to right.

So let’s start another experiment, we enter this URL: aaaaaaaaaa

The encoded URL is:

http://www.unipeak.com/gethtml.php?_u_r_l_=YWFhYWFhYWFhYQ==

Very interesting, we also get a repeating pattern, but the cycle is 4 characters long (YWFh).

Ok, now let’s use a trick: we enter a series of characters Us. The character U is special, its ASCII encoding written in binary is 01010101. Thus UU is 0101010101010101, UUU is 010101010101010101010101, …

Entering UUUUUUUUUU gives us:

http://www.unipeak.com/gethtml.php?_u_r_l_=VVVVVVVVVVVVVQ==

Another nice sequence!

This is a strong indication that the encoding is done at the bit level: the input is seen as a stream of bits, the bits are grouped in groups of X bits (where X is unknown). Each group is transformed to another sequence of bits by a function F, and the same function F is used for each group. We can also assume that X is even, otherwise we wouldn’t get a sequence of identical characters, but a sequence of identical pairs.

We perform some extra tests to prove (or disprove) our hypothesis.

We encode sequences of different lengths and compare the length of the cleartext and the cyphertext: the ratio is about 3 to 4, 3 input characters generate 4 output characters (BTW, the fact that we get a cycle of 4 characters for aaaaa… is also a strong indication for this ratio).

So X can be 3, 6, 9, 12, … . Except we assume X is even: 6, 12, …

Let’s test X = 6.

We try URL 000, this gives us MDAw (http://www.unipeak.net/gethtml.php?_u_r_l_=MDAw)
Now 000 is 30 30 30 (in hexadecimal ASCII)

or 00110000 00110000 00110000 in binary, grouped in 8 bits (1 byte)
or 001100 000011 000000 110000 in binary, but grouped in 6 bits (X = 6)

Now increment the first group:

001101 000011 000000 110000

or 00110100 00110000 00110000 in binary, grouped in 8 bits (1 byte)

or 34 30 30 (in hexadecimal ASCII)

or 400

So 000 becomes 400 when you increment the first group of 6 bits.

Testing URL 400 gives NDAw: changing the first 6 bits changes only the first character!

We do the same for the remaining groups:

000 -> 0@0 -> MEAw

000 -> 00p -> MDBw

000 -> 001 -> MDAx
So X is indeed 6, because changing a group of 6 bits at a time changes only one encoded character.

And we can also assume that function F is linear, because incrementing the input with 1 increments the output with 1 (M -> N, D -> E, A -> B and w -> x).

Now we could try every possible permutation of 6 bits, and see what the corresponding encoded character is.

We would discover that F maps 0..63 to ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

And this is a very common encoding scheme: base64

I’ve published a BartPE plugin for my UserAssist utility, you can download it here (https, MD5 D43E519B7BCE90F31EB54884E7AA75C1 DE9D576C0F5FF8D33E039A5064BD8AFF). And I’m posting another movie.
Windows Live CDs are a popular troubleshooting and forensic investigation tool, they allow you to boot a (Windows) PC from a CD. Bart Lagerweij developed BartPE, a tool to create a Windows Live CD (a Windows “pre-install” environment CD), and several people build their own tools based on his work. The Ultimate Boot CD for Windows is based on BartPE.

Bart’s PE has an open architecture, you can integrate your own tools by making a dedicated plugin. My UserAssist utility uses the Microsoft .NET Framework 2.0, which is not supported by BartPE. You need to add Colin Finck’s Microsoft .NET Framework 2.0 plugin to the Ultimate Boot CD for Windows plugins to use my plugin.

You add plugins to the Ultimate Boot CD for Windows with the Plugins dialog:

Afterwards you create your own Ultimate Boot CD for Windows (you have to provide your own licensed Windows XP SP2 CD).

The UserAssist utility is located in the Programs/Forensics menu (when you boot from the CD):

The UserAssist utility displays the activity of the current user at startup. This is of course not useful for a Live CD, because the profile of the current user of a Live CD is not persisted.

You will have to load the NTUSER.DAT registry hive of the user you want to investigate in RegEdit and export it to a reg file, before you can import it in UserAssist (I plan to add a feature to UserAssist to automate this task).

I’ve tested my plugin with the Ultimate Boot CD for Windows, not with BartPE.
There’s a movie here on YouTube, or hires (XviD) here showing you how to do this for user Employee.

Where and how do you store credentials used by applications? There is no easy solution in Windows. We all agree that storing cleartext passwords in the source code or a configuration file is a bad idea. We should encrypt these passwords. But what do we do with the decryption key? Is the decryption algorithm easy to break?

I wondered how difficult it would be to extract the password from McAfee’s EPO agent installation program. It turns out to be rather easy, it took me about 3 hours of debugging with OllyDbg. And then I developed a OllyDbg plugin to automate the task.

McAfee’s EPO provides centralized anti-virus management. It connects to EPO agents installed on each managed machine. One can install the EPO agent centrally via the EPO manager or locally by copying the EPO agent installation program to the machine and executing it with local admin credentials. McAfee provides a solution when the install has to be done by a user without administrative privileges. The necessary credentials are stored in the EPO agent installation program.

Here’s how I proceeded to extract the password from the EPO agent installation program.

First I create 2 EPO agent installation programs with different passwords (password and P@ssw0rd) and I compare the files with JojoDiff.

jdiff-w32 -lr FramePkg-1.exe FramePkg-2.exe:

1        1 EQL 25792
25793    25793 MOD 64
25856    25856 EQL 1487303

The files are identical, except for 64 bytes.

I extract the 64 bytes from FramePkg-1.exe with my binary tools:

middle FramePkg-1.exe 25792 64 password.bin

I examine password.bin with XVI32 and discover it’s ASCII:

jXoAADpNAADvOY9WkCYp0xOk6ON8lFjm4af+X4+8IVL6vuLPafhTAuyfdv52BG4e

This must be the encrypted password (P@ssw0rd).

I debug FramePkg-1.exe with OllyDbg, looking for the password (encrypted and cleartext). It takes an hour to discover that FramePkg-1.exe extracts several files to a temporary folder and starts another program it extracted: FrmInst.exe
This program takes several arguments, one of which is the encrypted password:

/CreateService="C:mydirsEPOAgentEPOAgentFramePkg-1.exe"
/LOGDIR=C:DOCUME~1ADMINI~1LOCALS~1TempNAILogs
/Cleanup2="C:DOCUME~1ADMINI~1LOCALS~1Tempunz6.tmp"
/EmbeddedUsername="administrator"
/EmbeddedDomain="."
/EmbeddedPassword="jXoAADpNAADvOY9WkCYp0xOk6ON8lFjm4af+X4+8IVL6vuLPafhTAuyfdv52BG4e"
/Install=Agent

I debug FrmInst.exe with these arguments, and after 2 hours I find register EBP pointing to ASCII string P@ssw0rd. This is at address 0x004101BD.

This confirms my suspicion: the password is safe from a normal user, but someone with assembly debugging skills can recover the password within a few hours. No big surprise, but you know, there are people who can only be convinced when you deliver a proof to backup your claim.

This dreary debugging process inspired me to develop a OllyDbg plugin called OllyStepNSearch to automated the debugging process. It will automatically step through the debugged program until a register points to the string you specified. You can download it, but it’s still beta.

I used it to debug the EPO agent to look for P@ssw0rd. It’s slow (about 45 minutes), but it runs unattended.