Officially SLIPFEST is an acronym for "System level intrusion prevention system evaluation suite and toolkit". But the name is really a french joke meaning something like "Panty's party".
It's a tool which can help you to understand how your Windows HIPS (or personal firewall, or advanced anti-virus) works. With it you can list SDT (in kernel) or userland (in library) hooks, caracterize address space layout randomization (ASLR) or non executability, inject shellcodes in a process' address space to try to fool the heuristic or test the MAC mecanism with common flaws.
This tool was created in France Telecom R&D while testing HIPS products.
(This code has been archived on Google code: SLIPFEST)
2006-03-27: - version 1.01, CanSecWest edition, first release to the public 2006-03-27: - added consistency checking of remote/local and stack/nonstack with type of shellcode 2006-03-22: - added support for showing min/max values during ASLR test, and for all thread aggregation 2006-03-14: - added support for PE Exports Forwarding in find_proc (fixes crash on ExitThread on Windows Vista) 2006-02-24: - version 1.0
SLIPFEST -------- Version 1.01 'CanSecWest 2006 edition' SLIPFEST (system level intrusion prevention framework evaluation suite and toolkit) is a toolkit to assist the evaluation of HIPS systems such as CISCO CSA, McAfee Entercept, Ozone, Whentrust.. It is distributed under the conditions of GPL version 2. Additional information can be found on http://slipfest.cr0.org FAQ: ---- Q: How can I compile Slipfest? A: The driver can be compiled with the Windows DDK and the SPLIFEST application can be compiled with Visual C++ 2005. You can get the express edition for free from Microsoft at http://msdn.microsoft.com/vstudio/express/ Q: Why does my target crash ? A: You probably ran a search type shellcode (everything with a ".ret" ) in a remote process, and it did not find the right opcodes. You can try locally : uncheck 'run in remote process', Slipfest will inject the opcodes automatically so that it cannot fail. It could also be a protection (such as SafeSEH or NX) (nb: there is a version of the egghunt that tricks SafeSEH [Doesn't work under Vista for now]) Q: Why is UTRegister hooked (List all hooks) ? A: When trying to ret to kernel32 in local process (run in remote process is unchecked) on the stack, SLIPFEST will patch UTRegister to inject some opcodes (see 'Why does it crash?') Q: Why are there only two editbox ? A: Each editbox has different purposes. For example the second editbox can be a proc name, an address or the number of process and threads to create with ASLR test, the number of bytes to patch, the dump filename, a binary string to patch or the 'target by mouse delay'. I know, it's crazy. Q: How does 'Test NX' work? A: The shellcode will patch the unhandled exeption handler pointer in the TEB of the target process, then zeroes the load_config dir in the PE (to disable safeseh). Then it'll VirtualAlloc and VirtualProtect PAGE_READWRITE some code and run it. Depending on wether the exception handler is called or not it'll print a MessageBox telling that NX is enable or disabled. Q: What is NX? A: NX (AMD's name), called DEP (data execution prevention) by Microsoft and XD (eXecute Disable) by Intel is the support for non executable pages by the processor. If your version of Windows supports DEP and if your processor supports NX, Windows will use the processor in PAE mode and can use the NX flags in the PTEs. This means that a page which is not marked as executable will not be executable. Some HIPS will use PaX' splitted TLB instrumentation to 'emulate' NX. Q: Why is "run in remote process" or "run on stack" unchecked when I select my shellcode? A: Starting from version 1.01, there is an automatic consistency check which is done when you select your shellcode. Invalid combinations are not allowed. However, beeing a research tool, SLIPFEST doesn't want to go in your way and will allow you to force an invalid combination by selecting it after the shellcode selection. HEAP | PE | K32 -------+---------+-------- Local STACK | STACK | STACK N/A | NOSTACK | N/A -------+---------+-------- Remote N/A | STACK | STACK N/A | NOSTACK | NOSTACK N/A: not available STACK: run on stack is checked NOSTACK: run on stack is unchecked The only way to return to the heap is by running from the current process' stack. This is a limitation. In the local (SLIPFEST) process, if not run on stack you cannot return to anything but the PE. This is because in this situation the shellcode will be run from the PE of slipfest.exe and cannot be relocated. This is not really a limitation, feel free to use SLIPFEST as your remote process.