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 
I think it’s the xml file embedded in the exe file, am i right?
Comment by Klau — Tuesday 19 February 2008 @ 9:07
The XML file is a manifest I added for Vista UAC. But you don’t have to disassemble CASToggle.exe to find the answer.
Hint: It’s in the security requirements. Who can use caspol -security off and who can use castoggle 123 1?
Comment by Didier Stevens — Tuesday 19 February 2008 @ 9:47
Only a user running as an Administrator (or with Admin rights) can use caspol -security off; the user who started the process “123” (as your example mentions) can use castoggle 123.
Comment by Chris Symons — Wednesday 20 February 2008 @ 3:57
Congratulations Chris, you answered correctly. I’m sending you an e-mail for the .NET development tool license offered by The Polymorphic Podast. Details are in my latest blogpost.
Pingback by CASToggle and The Polymorphic Podcast « Didier Stevens — Wednesday 20 February 2008 @ 10:16