I'm currently testing an application that my company wrote. One of the scenarios was to see what happens to the system state if that application was to crash. Is there an application out there that could force crash my application? I'd rather not write a crash into the code itself (ie. null pointer dereference). Using the task manager to kill the process doesn't yield the same results.
- Using DLL Injection might be a viable route to achive this, I don't know of any app that already would handle this however.Martin Ba– Martin Ba2010-11-26 11:41:16 +00:00Commented Nov 26, 2010 at 11:41
- Can't you put a simple exit() in the middle of your cod ? Or isn't that considered as "crashing" ?Raveline– Raveline2010-11-26 11:42:07 +00:00Commented Nov 26, 2010 at 11:42
- What do you mean by system state? Generally when a process crashes, the system will clean up all the resources used. However this might not extend to things like database handles. How will you examine the system state?Nick– Nick2010-11-26 11:44:36 +00:00Commented Nov 26, 2010 at 11:44
- Crash is a result, you should precise the cause.mbq– mbq2010-11-26 12:48:50 +00:00Commented Nov 26, 2010 at 12:48
11 Answers
On Windows you can attach WinDbg to a process, corrupt some register or memory and detach. For instance you can set instruction pointer to 0 for some active application thread.
windbg -pn notepad.exe Right after attach, current thread is set to debug thread, so you need to change to app thread to make it crash with RIP register update
0:008> ~0s 0:000> rip=0 0:000> qd Comments
Assuming Windows, see Application Verifier.
It can do fault injection (Low Resource Simulation) that makes various API calls fail, at configurable rates. E.g. Heap allocations, Virtual Alloc, WaitForXxx, Registry APIs, Filesystem APIs, and more.
You can even specify a grace period (in milliseconds) when no faults will be injected during startup.
1 Comment
The best way is to call RaiseException API from windows.h
RaiseException(0x0000DEAD,0,0,0); Or you can do a runtime linking to KeBugCheckEx() from ntoskrnl.exe and call it in your code.
Example:
#include <windows.h> #include <iostream> using namespace std; int main() { HINSTANCE h = LoadLibrary("ntoskrnl.exe"); cout<<h<<endl; void* a; a = (void*) GetProcAddress(h,"KeBugCheckEx"); int(*KeBugCheckEx)(ULONG,ULONG_PTR,ULONG_PTR,ULONG_PTR,ULONG_PTR); KeBugCheckEx = (int(*)(ULONG,ULONG_PTR,ULONG_PTR,ULONG_PTR,ULONG_PTR))a; cout << a; KeBugCheckEx(0,0,0,0,0); //crash in module ntoskrnl.exe means that call success! } 2 Comments
EXCEPTION_NONCONTINUABLE rather than 0. KeBugCheckEx crashes the operating system, which is overkill unless you're calling it from kernel mode and crashing the system is necessary to prevent corruption.STATUS_FAIL_FAST_EXCEPTION (0xC0000409). If you want to use your own custom exception codes, make sure you set bit 29 (indicated a user-defined code) and leave bit 28 clear (because it's reserved by the system). In other words, your exception codes should probably start with 0xE in the high nybble, as in 0xE000DEAD.You haven't stated which OS you're running on but, if it's Linux (or another UNIX-like system), you can just kill -9 your process. This signal can't be caught and will result in the rug being pulled out from under your process pretty quickly.
If you're not on a UNIX-like system, I can't help you, sorry, but you may find some useful information here (look for "taskkill").
Comments
If the system runs on UNIX/Linux you can send it a signal: SIGQUIT should produce a core-dump, you can also send it SIGSEGV if you want to test it getting a "segmentation fault". Those are signal 3 and 11 respectively.
If the system is Windows I do not know a way to raise a signal in a different application but if you can modify the application to handle a specific Windows message number that will call raise() you can emulate that. raise() causes the signal to be raised without actually having to write code that performs an illegal action. You can then post a message to the application which will have the handler that raises this signal.
1 Comment
Where is this "system state" defined? If this were unix, you could send a signal 9 to the process...
If you really needed to, you could share all the application memory with another process (or thread), and have that thread randomly write random data some unfortunate memory location - I think NASA did this for some of their space projects, but I really couldn't give a reference.
The real question is why you want to do this - what are you /really/ testing?
If this is, for example, some program that controls some medical service that prescribes drugs... Unit test that service instead, analyse the API, and look for flaws.
Comments
Make a bufferoverflow yourself.
#include <string.h> void doSomething(char *Overflow) { char Buffer[1]; strcpy(Buffer, Overflow); } int main() { doSomething("Muhaha"); } And your program will crash
1 Comment
An alternative would be to run the application in a good debugger, set a breakpoint to a particular line of code, and viola, your application has "crashed". Now, this might not cause all your threads to stop running, depending on the debugger being used. Alternatively, you could run the application in the debugger, and simply "stop" the application after a time.
This doesn't neccessarily result in a crash with the kernel killing the application (and possibly dumping core) but it would probably do what you want regardless.
Comments
Call abort() function from your code. Other programs can't reliably "crash" your program - they have their own process context which is isolated from your program's context. You could use something like TerminateProcess() in Windows API or another platform-specific function but that would be more or less the same as using Task Manager.