Target Application

The target application is a catch-all term that denotes the sum of all code added by a user to a Customer VM to enable a Security Risk Detection job:

  • The Entry-Point Executable (or EPE, required)

  • Optional Windows roles or features

  • Dependent platforms, frameworks, or libraries

  • Additional process executable(s)

Of these components, only the EPE is required. Whether your particular fuzzing job includes others depends on the configuration and characteristics of the code you intend to test.

We explore each of these components, including limitations and best practices, in the following sections.

Entry-Point Executable (EPE)

The EPE is the program that the Security Risk Detection fuzzer suite will call repeatedly while the job it running. It should (1) take a file name as argument, (2) exercise the data parser with the content of the file specified in its file-name argument, and then (3) stop immediately after the parsing is finished without making any changes to the VM.

Ideally, this executable should be simple, fast, and can be executed repeatedly, successively and concurrently.

Supported Code and Data Types

Any type of code is supported – native, managed, script, etc., so long as it accepts external input data.

The external input data encoding, however, must either be binary (e.g., a media file like a JPG or AVI) or a low-level text format -- that is, one whose underlying bytes represent characters but whose characters do not include protocol syntax like XML tags or JSON braces. The reasoning behind the latter restriction is simple: any modification of the protocol syntax would result in malformed input data the target data parser would reject, resulting in multiple iterations with near zero code coverage.


Your application must be both installable and runnable on Windows 7 SP1 or Windows Server 2008 R2 with the latest framework and/or Windows SDK installed (see Platforms/Frameworks below).


We are currently working on full support for Microsoft’s latest released operating systems, Windows 10 and Windows Server 2016. Support for Redhat Linux is currently in preview.


Security Risk Detection supports both 32-bit and 64-bit binaries. It is currently, however, slightly more effective against 32-bit applications, so if you have both, choose the 32-bit version.

There are several ways to determine whether my app is 32-bit or 64-bit:

  • Run your test driver (or app) under 32-bit windbg, which is pre-installed the Customer VM (see the shortcut on the Desktop)

  • Install and use the (free) DUMPBIN utility

  • Install and use the (free) Process Explorer tool from the Sysinternals suite

Dependent Libraries

This includes anything from dynamic link libraries (DLLs) to external services and applications such as a relational database system.

Optional Windows Roles or Features

If your application requires optional Windows roles or features, such as IIS or WCF, you may install them from Server Manager on the Customer VM.


The VM on which you’ll install your application is Windows Server 2008 R2 with the Windows 10 RTM SDK (version 10.0.26624) installed. If your application is native code built with Visual Studio 2013, 2015, or 2017 (using platform toolkits v120, v140, or v141), you’ll need to install the appropriate redistributable:

For managed applications, the Customer VM has the .NET Framework 4.5.2 preinstalled.

Additional Process Executable(s)

Security Risk Detection can fuzz client/server applications. Security Risk Detection provides a virtual machine to install software. Security Risk Detection can either fuzz the client or server in isolation, or a combination of both provided that both the client and server can run on the same virtual machine. In fact, Security Risk Detection can fuzz applications requiring any number of dependent servers provided all those servers can run on the same virtual machine.

If your test driver is a client process and there is another (e.g., server) process continually running in the background, only the client process will be monitored. Note that, if the server process were to crash on a VM, no further fuzzing would be possible on that VM.

Note that if your entry-point application creates multiple child processes, Application Verifier will be attached to each by default.