Didier Stevens

Thursday 28 February 2008

Introducing the Basic Process Manipulation Tool Kit

Filed under: Forensics,Hacking,My Software,Reverse Engineering — Didier Stevens @ 10:01

For about a month or two now, I’ve been working on a toolkit to manipulate processes (running programs) on Windows. I’ve been using it mainly to research security mechanisms implemented in user processes, like Microsoft .NET Code Access Security.

Here are some of the design goals of the toolkit:

  • the toolkit must support limited accounts (accounts that are not local administrators) as much as possible
  • flexibility: provide a set of commands that can be assembled in a configuration file to execute a given task
  • the toolkit must be able to operate as a single EXE, without requiring the installation of supporting environments like Python
  • it must be a command-line tool

The toolkit has commands to search and replace data inside the memory of processes, dump memory or strings, inject DLLs, patch import address tables, … I’ll be posting examples in the coming weeks, illustrating how these commands can be used.

I’m releasing a beta version of the toolkit now, you can download it here.

This is an example of a configuration file (disable-cas.txt) to disable CAS for a given program (exactly like CASToggle does):

process-name CASToggleDemoTargetApp.exe
write version:2.0.50727.42 hex:7A3822B0 hex:01000000
write version:2.0.50727.832 hex:7A38716C hex:01000000
write version:2.0.50727.1433 hex:7A3AD438 hex:01000000

It looks for processes with the name CASToggleDemoTargetApp.exe, and will then write to the memory of these processes to set a variable to 1 (hex:01000000). The address to write to depends upon the version of the DLL containing the variable. If the DLL has version 2.0.50727.42, we will write to address 7A3822B0. For version 2.0.50727.832, we will write to 7A38716C, … So in this configuration file, at most one write command will be successful and write to memory.

Launch the toolkit with the configuration file like this:

bpmtk disable-cas.txt

You can also use the toolkit to audit programs, for example to check if they protect secrets correctly. Let’s investigate how Firefox keeps passwords (I tested this with Firefox English on Windows XP SP2):

I created a new Firefox profile, defined a master password and stored two passwords: one for Google (BigSecretGoogle) and one for WordPress (BigSecretWordpress).

This is the config file:

process-name firefox.exe
strings address:on memory:writable regex:BigSecret

This config file will search inside the memory (only the writable virtual memory) of Firefox for strings containing the string BigSecret, and dump them to the screen, together with the address where they were found.

Let’s start Firefox and search inside the memory (bpmtk demo-firefox-passwords.txt):


No BigSecrets here. Now let’s navigate to Google mail. We are prompted for the master password, so that Firefox can complete our credentials on the login screen:



Let’s take another peek inside the memory of the Firefox process:


It should be no surprise that we find our Google password in memory (at 2 different addresses, the U indicates that we found a Unicode string).

Now let’s go to Firefox’s options and display the passwords:



The password manager displays the stored URLs and the usernames, but not the passwords. Let’s take another peek inside the memory of the Firefox process:


This time, Firefox has also decrypted our WordPress password (BigSecretWordpress), although it’s not displayed. It’s only displayed if we provide the master password a second time:



So although Firefox prompts you a second time for the master password to display all the passwords, the passwords have already been decrypted in memory before you provided the master password a second time.

Now I don’t have issues with this behavior of the password manager of Firefox, I don’t think it’s a security issue (I’ve an idea why it was programmed like this). But if Firefox was a perfect program, all passwords would only be decrypted when a user explicitly asks to display all passwords.

Do you make online payments with your credit card? Now that I’ve showed you how you can look for specific strings inside a running program with my toolkit, you should know how to use it to check how long your browser keeps your credit card number inside its memory. And can you find out how to use bpmtk to erase that number from your browser’s memory?

Let me finish with an appetizer: I’ve also developed a DLL that, once injected inside a process, will instantiate a scripting engine inside said process, and start executing a script inside the process. This allows you to inject a script inside a process, which can be handy for rapid prototyping or when you’re operating in a limited environment where you don’t have a C compiler to develop a custom DLL to inject. Of course, a script is not as powerful as a compiled C program, but I’m adding some objects to provide some missing functionality.

This script injector will be released with an upcoming version of the bpmtk.

Wednesday 20 February 2008

CASToggle and The Polymorphic Podcast

Filed under: .NET — Didier Stevens @ 10:15

Craig Shoemaker, a good friend, Microsoft MVP and host of The Polymorphic Podcast, sweetened my little CASToggle quiz by trowing in a license for a Microsoft .NET development tool. Check out hist post. Thanks Craig!

BTW, The Polymorphic Podcast is about object oriented development, not about polymorphic malware. Polymorphism is also a programming language concept.

When you look at the comments of my previous blogpost, you’ll read that we have a winner. Let me fill you in on the details.

Caspol requires administrative credentials to disable CAS enforcement:


The reason is that the setting for disabled CAS enforcement is implemented with a mutex owned by the BUILTIN\Administrators group. As a non-admin user, you can also create this mutex, but it will be owned by your account, not by the administrator group. And the CLR checks the ownership of the mutex and will only acknowledge it when it is owned by BUILTIN\Administrators.

But my CASToggle tool does not use a mutex. CASToggle allows you to directly manipulate the variable in the CLR where the status of the mutex is stored. This variable can have 3 values:

  • 0: uninitialized, this means that the CLR has not yet looked for the presence of the mutex. This is the case when your .NET program starts to run.
  • 1: CAS enforcement disabled, this means that the CLR has found the mutex.
  • 2: CAS enforcement enabled, this means that the CLR has not found the mutex.

The CLR will only perform a single check for the presence of the mutex. That’s why changing the CAS enforcement policy with caspol has no effect on running .NET programs.

Did you know that the CLR runs in your own process memory? And did you know that in Windows, you have full control over your own processes, even as a limited user? To manipulate the process of another user (e.g. reading and writing to the virtual memory owned by the target process), you need the debug privilege (local admins have this privilege by default). But you don’t need this privilege for your own processes.

That’s what differentiates CASToggle from caspol. If you’re a local admin (or you have the debug privilege, to be more precise), you can use CASToggle on any process. But as a limited user, you can still use it to disable CAS enforcement for your own processes.

I’ve been doing some research on security mechanisms implemented in the user’s own process space. The design of these security mechanisms is fundamentally flawed, because a limited user has full control over his own processes and can thus bypass the security mechanism. He just needs internal knowledge about the mechanisms (or a tool), and then he can bypass it because he has the rights to do so.

Robust security mechanisms are implemented in process space that is off-limit to normal users. This can be inside the kernel (like the reference monitor) or inside user-land space of a protected account (like services that run under the local system account).

Tuesday 12 February 2008

Fine-Grained Control over Code Access Security

Filed under: .NET — Didier Stevens @ 7:12

With Code Access Security (CAS) in the .NET Framework, Microsoft introduced a whole new security layer on top of Windows security.

If you need to temporarily disable CAS, for example during a debugging session, you can use the caspol utility. The command caspol -security off will disable CAS enforcement as long as the caspol tool is running (this is true for .NET 2.0 and later). If you are interested in the implementation details: it’s done via a mutex.

One issue with caspol -security is that its effect is system-wide. If you need to unit test .NET assemblies by repeatedly toggling CAS enforcement, the caspol utility lacks some control. Not only your assembly will be affected by the toggle, but every other assembly on the machine. And the setting only takes effect for assemblies started after the caspol command was issued. When you re-enable CAS enforcement, it will only affect new processes. Running programs continue to ignore CAS, they have to be restarted for the new setting to take effect.

My new utility, CASToggle, gives you more control over CAS enforcement. First of all, it operates on a per-process basis. You have to specify the process ID of the program for which you want to switch CAS enforcement. Second: the effect is immediate, you don’t have to restart the program.


  • castoggle 123 1 – this will immediately disable CAS enforcement for process 123
  • castoggle 123 2 – this will immediately enable CAS enforcement for process 123

CASToggle controls CAS enforcement by directly manipulating the appropriate variable in the process memory of the targeted program. So it’s best to use CASToggle only for testing purposes. When you look at the source code of CASToggle, you’ll notice that most of the code is there to ensure that it manipulates the correct memory location. For example, it will check the version of mscorwks.dll before it attempts to access the process memory. But if the DLL is not loaded at its base address (e.g. because of ASLR on Vista or Windows 2008), the program could manipulate the wrong memory location and cause the program to crash. Unknown DLL versions cause the tool to break-off without accessing the process memory. I’ve tested CASToggle on Windows XP SP2, Windows 2003 and Vista with different versions of .NET (2.0 and up).

To see CASToggle at work, take a look here on YouTube, hires (XviD) version here.

Oh, and there is one more thing that differentiates CASToggle from caspol, but I’m not going to tell you right now. Can you figure it out? Post a comment! First one to figure it out gets the honors! 😉

Tuesday 5 February 2008

Hiding Inside a Rainbow, Part 3

Filed under: Hacking — Didier Stevens @ 9:37

(IN)SECURE Magazine has published my research on steganography with rainbow tables. As promised, I publish my last algorithm now (my previous posts: part 1, part 2).

This steganographic technique is based on the fact that a rainbow table contains chains with the same hash index but with a different start index.

A rainbow table is just a sequence of records. Each record has 2 fields of 8 bytes each, this makes a record 16 bytes wide. Therefore the size of a rainbow table is a multiple of 16. A record represents a chain. The first field is the password that started the chain. Actually, the first field is an index into the keyspace of all possible passwords for the given rainbow table set. It is a random number between 0 and the size of the keyspace – 1. The second field is the hash of the last password in the chain (actually, this is also an index and not the real hash). The rainbow table is sorted on the second field: the record with the lowest hash is first in the table and the one with the highest hash is last.


This is the hex dump of a rainbow table (the first 16 chains). The green box highlights the random data, notice that the 3 most significant bytes are 0. The blue box highlights the hash, notice that this column is sorted.
My steganographic technique is based on the fact that a rainbow table contains chains with the same hash index but with a different start index.

Take the rainbow table I’ve used in my tests. It’s 1 GB large and has 67.108.864 chains. It contains 9.513.435 pairs of chains with the same hash index but with a different start index. For 4.756.561 of these pairs, the first chain has a higher start index than the second chain. And for 4.756.874 of these pairs, the opposite is true: the first chain has a lower start index than the second chain. This even distribution should be no surprise, as the rainbow table is only sorted on the hash index and not on the start index.

We can change the order of these pairs without breaking the chain and without disrupting the order of the rainbow table. This will allow us to encode 1 bit per chain. I define the following encoding convention:

  • a pair of chains with the same hash index and with the start index of the first chain smaller than the second chain represents a bit equal to zero
  • a pair of chains with the same hash index and with the start index of the first chain greater than the second chain represents a bit equal to one


In our test table, the pair in the green box represents a 0 (0x1C7F02C85E < 0x2D1AB4B674) and the pair in the red box represents a 1 (0x94BD2F41F2 > 0x65616DC547).

Use this algorithm to hide a file in a sorted rainbow table:

  • start a sequential search of chain pairs with equal hash indexes and different start indexes
  • for each bit of the file to hide
    • if the bit is 0 and the chain pair has a first start index higher than the second, swap the order of the chains
    • if the bit is 1 and the chain pair has a first start index lower than the second, swap the order of the chains

To extract the hidden file, use this algorithm:

  • start a sequential search of chain pairs with equal hash indexes and different start indexes
  • if a chain pair has a first start index lower than the second, write a bit equal to 0
  • if a chain pair has a first start index higher than the second, write a bit equal to 1

PoC code to store and retrieve data in rainbow tables using this technique can be found here.

Use rthide2 to hide data in a rainbow table, it takes 3 arguments:

  • the rainbow table (remains unchanged)
  • the file to hide (remains unchanged)
  • the new rainbow table

To hide a file data.zip inside a rainbow table called lm_alpha-numeric-symbol14-space#1-7_0_5400x67108864_0.rt, use this command:

rthide2 lm_alpha-numeric-symbol14-space#1-7_0_5400x67108864_0.rt data.zip lm_alpha-numeric-symbol14-space#1-7_0_5400x67108864_0.rt.stego

This will create a new rainbow table called lm_alpha-numeric-symbol14-space#1-7_0_5400x67108864_0.rt.stego

Use rtreveal2 to extract data from a rainbow table, it takes 3 arguments:

  • the rainbow table
  • the file to create
  • the size of the hidden file

To extract the data, issue this command (you have to know the length of the hidden file, my PoC program doesn’t store this).
rtreveal2 lm_alpha-numeric-symbol14-space#1-7_0_5400x67108864_0.rt.stego data.zip 1620

1620 is the length of file data.zip

The advantages of this technique over the previous techniques I developed is that it creates sorted rainbow tables without broken links, and that it is fast. The disadvantage is that it stores much less hidden data. In my example, a maximum of about 1 MB (9.513.435 bits) can be hidden in a rainbow table of 1 GB. Statistical analysis is the only way to detect the hidden data, but you can foil this by making your data appear random, for example with strong encryption.

Blog at WordPress.com.