Design Overview

Fault Monitoring

Fault monitoring, a step that's often grossly overlooked, is a crucial part of fault testing. The majority of fault injection projects developed by the academic community detect failures in an application only if it crashes or dumps its core . Enterprise applications are almost always built with a strong fault tolerance using exception handling, signal handling, or any other fault handling available from the overlying operating system. By monitoring our faults using the operating system's debugging subsystem, we can detect man faults that were previously overlooked.

Using a Debugger

If you are interactively fault testing, then a debugger will suit your needs. Choose your debugger and attach the process of the software product you are auditing. Many debuggers are configured by default to catch only exceptions that are not handled by the process; for example, unhandled exceptions. Other debuggers allow you to catch only unhandled exceptions. If your debugger is capable of catching exceptions before they are passed to the application "first chance," we recommend you enable this feature for every type of exception that you want to monitor. The most important exceptions to monitor are access-violation exceptions. Access violations are generated when a thread in the process attempts to access an address that isn't valid in the address space of the process. These violations are often seen when data structures designated to reference memory are corrupted during the operation of the program.

FaultMon

Unfortunately, very few debuggers out there will allow you to log exceptions and automatically continue operation. For this reason, we've provided FaultMon, a utility written by Derek Soeder, a member of the eEye research group , on the Shellcoder's Handbook Web site ( www. wiley .com/compbooks/koziol ). To use FaultMon, simply open a command prompt and issue the process ID for the application for which you want to monitor exceptions. Each time an exception is generated, FaultMon will display information about the exception to the console.

 21:29:44.985  pid=0590 tid=0714  EXCEPTION (first-chance)      ----------------------------------------------------------------             Exception C0000005 (ACCESS_VIOLATION writing [0FF02C4D])      ----------------------------------------------------------------        EAX=00EFEB48: 48 00 00 00 00 00 F0 00-00 D0 EF 00 00 00 00 00        EBX=00EFF094: 41 00 41 00 41 00 41 00-02 00 41 00 41 00 41 00        ECX=00410041: 00 00 00 A8 05 41 00 0F-00 00 00 F8 FF FF FF 50        EDX=77F8A896: 8B 4C 24 04 F7 41 04 06-00 00 00 B8 01 00 00 00        ESP=00EFEAB0: 38 25 F9 77 70 EB EF 00-94 F0 EF 00 8C EB EF 00        EBP=00EFEAD0: 58 EB EF 00 89 AF F8 77-70 EB EF 00 94 F0 EF 00        ESI=00EFEB70: 05 00 00 C0 00 00 00 00-00 00 00 00 B4 69 CC 68        EDI=00000001: ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??        EIP=00410043: 00 A8 05 41 00 0F 00 00-00 F8 FF FF FF 50 00 41          --> ADD [EAX+0F004105],CH       ----------------------------------------------------------------     Continue? y/n: 

Here we see a sample exception that was captured by FaultMon during a RIOT test. The interactive option was set to -i . By having the interactive option set, we can pause between exceptions and examine the state of the program.