powershell -Command “Add-Type -TypeDefinition \”public class Demo {public int a;}\””
This command just adds the definition of a class (Demo) with one member (a).
When this Add-Type cmdlet is executed, the C# compiler is invoked by PowerShell to compile this class definition (a C# program) into an assembly (DLL) with the .NET type to be used by the PowerShell script.
A temporary file (oj5zlfcy.cmdline in this example) is created inside folder %appdata%\local\temp with extension .cmdline. This is passed as argument to the invoked C# compiler csc.exe, and contains directions to compile a C# program (oj5zlfcy.0.cs):
Interactive Sieve is a program I developed to help you analyze log files and other data in tabular form. It’s designed to help you when you don’t know exactly what you’re looking for. You sift through the data by hiding or coloring events (or data) that are not relevant.
I started writing this program in 2007 and use it often. But there is a problem I’ve not been able to fix: when you hide a lot of rows, it takes a long time, probably because of the redraw operation that takes place for each hidden row. Maybe someone will find a solution. Update: big thanks to @woanware for fixing the redraw performance problem!
For more details on how to use the program, select Help / About.
I’ve been playing with a .NET Micro Framework micro-controller: the USBizi. A few of its interesting characteristics are that you program it in C# with Visual Studio and that in-circuit debugging (including single-stepping) is supported.
The .NET Micro Framework has no assemblies to support USB in host mode (only guest mode), but the USBizi comes with assemblies for host mode providing support for removable drives like USB sticks. To illustrate this feature, I wrote a program to scan the files on a USB stick for the EICAR test file and replace the content with a message appropriate for the time of the year.
Some ideas I’ve for this device: program it as a hardware keylogger, a hardware password vault, …
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).
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.
Example:
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! 😉
Didier Stevens 