Forced application crash

Question

I am currently testing an application that my company wrote. One of the scenarios was to see what would happen to the state of the system if this application should have crashed. Is there an app out there that could cause my app to crash? I would prefer not to write the accident in the code itself (i.e., dereference a null pointer). Using a task manager to kill a process does not produce the same results.

Answer 1

Assuming Windows, see Application Verifier .

It can perform injection (Low Resource Simulation), which leads to the failure of various API calls at custom rates. For example. Heap Allocation, Virtual Alloc, WaitForXxx, Registry APIs, File System APIs, etc.

You can even specify a grace period (in milliseconds) when no errors will be entered during startup.

Answer 2

On Windows, you can attach WinDbg to a process, corrupt any register or memory, and disconnect. For example, you can set the instruction pointer to 0 for some active application thread.

windbg -pn notepad.exe 

Immediately after attaching, the current thread is configured to debug the thread, so you need to switch to the application thread so that it crashes with updating the RIP register

 0:008> ~0s 0:000> rrip=0 0:000> qd 

Answer 3

The best way is to call RaiseException API from windows.h

 RaiseException(0x0000DEAD,0,0,0); 

Or you can bind the runtime 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! } 

Answer 4

You did not indicate which OS you are running on, but if it is Linux (or another UNIX-like system), you can simply kill -9 execute your process. This signal can not be caught and will lead to the fact that the mat will be pulled out from under your process pretty quickly.

If you are not using a UNIX-like system, I cannot help you, sorry, but you can find useful information here (look for "taskkill").

Answer 5

You can override the global new operator. Then you can use a counter and, at a certain value, you dereference the null pointer to make your application crash. Just changing the value when you can easily change the time of failure to perform dereferencing.

Answer 6

Where is this “system state" defined? If it was unix, you could send signal 9 to the process ...

If you really need to, you can share all the application memory with another process (or stream), and this stream accidentally writes random data to some unsuccessful memory location - I think NASA did this for some of its space projects, but I really could not give a link.

The real question is - why do you want to do this - what are you / really / testing?

If this, for example, is some kind of program that monitors some medical service that prescribes medicines ... Unit test, this service instead analyzes the API and looks for flaws.

Answer 7

Make your buffer stream yourself.

 #include <string.h> void doSomething(char *Overflow) { char Buffer[1]; strcpy(Buffer, Overflow); } int main() { doSomething("Muhaha"); } 

And your program will crash

Answer 8

If the system is running UNIX / Linux, you can send it a signal: SIGQUIT should create a core dump, you can also send it SIGSEGV if you want to check its receipt of a “segmentation error”. These are signals 3 and 11, respectively.

If the system is Windows, I don’t know a way to raise a signal in another application, but if you can change the application to process a specific Windows message number that will raise (), you can emulate this. raise () causes the signal to rise without having to write code that performs an illegal action. Then you can send a message to the application, in which there will be a handler that raises this signal.

Answer 9

An alternative would be to run the application in a good debugger, set a breakpoint on a specific line of code and alt, your application will “crash”. Now this may not cause all your threads to stop working, depending on the debugger you are using. In addition, you can run the application in the debugger and just “stop” the application after a while.

This does not necessarily crash with the kernel killing the application (and possibly dropping the kernel), but it will probably do what you want independently.

Answer 10

Call abort() function from your code. Other programs cannot crash your program — they have their own process context that is isolated from your program context. You can use something like TerminateProcess() in the Windows API or another platform-specific function, but it will be more or less the same as when using the task manager.