forked from vustac/dse
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
81 lines (64 loc) · 4.66 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
The DSE consists of 5 seperate builds contained in separate subdirectories:
- **danalyzer**: consists of a Java program that performs the instrumentation of the
bytecode of a Java program, and provides the executed methods that are added to
the bytecode. Executing the instrumented code will provide the user with a GUI
interface for defining the parameters in the code that the user wishes to
symbolize and allows enabling messages to be output for debugging and monitoring
the process.
- **danhelper**: consists of a native agent (written in C++) that monitors running
processes to allow running callbacks (in danalyzer) when methods from the
instrumented program are entered and exited. This simplifies the danalyzer code
and is run in conjunction with it.
- **dandebug**: a Java program that runs as a server for monitoring the debug output
from an instrumented test (using either UDP or TCP) and allows viewing and saving
the call graph of the captured data (as long as CALL/RETURN debug messages are enabled).
- **dansolver**: a Java program that runs as a server for receiving the symbolic
constraints output by danalyzer on a TCP port and generating solutions for them.
The results are then saved to a database (mongodb).
- **danlauncher**: a Java program for consolidating the execution and monitoring of
the above programs. It provides the user with a GUI interface for selecting a Java
application to test, instruments it for danalyzer, then monitors its debug output
similarly to dandebug. It also provides an interface for examining the bytecode of
the application and allows the user to specify the parameters he wishes to declare
as symbolic, and monitors the solutions that are placed in the database by dansolver.
There are 3 additional directories for testing:
- **test**: contains several tests for verifying danalyzer.
- **SymbolicExplorer** - this attempts to "close the loop" on a simple test case to
use the DSE to find a worst case input solution to the application.
The following scripts provide an easier process for running the STAC Challenge
problems and Canonicals.
- **setup.sh**: will create the DSETests folder that will contain the tests that
you wish to instrument and run. This command is specified with a single
argument to define which test(s) to copy from the engagement repos.
It is assumed that the engagement repo (and public-el-information-mirror repo
for the Canonicals) have been setup and the path locations are defined in
setpaths.sh. The tests can be copied over individually or the entire list
from the specified engagement (e1, e2, e4, e5), or the Canonicals (canon),
or all tests (all). Running without an argument will display the usage info.
- **make.sh**: will perform the instrumentation of the specified test that is
contained in the DSETests directory. The format is simply "make.sh <Testname>"
It will build danalyzer (to make sure the latest version is being used), then
instruments the specified test file using it, and strips out all debug content
so that danhelper can interpret the input correctly.
Adding the -t option will cause no commands to actually run, but will output
the commands that would be used otherwise.
- **run.sh**: will run the specified test, assuming it has previously been instrumented
using make.sh. It also takes as an argument the test to run. If you want to
force a build of danhelper prior to running, add the -f option.
Adding the -t option will cause no commands to actually run, but will output
the commands that would be used otherwise.
- **runorig.sh**: will run the original (un-instrumented) version of the specified test.
This can be helpful for comparing results to the instrumented version.
Adding the -t option will cause no commands to actually run, but will output
the commands that would be used otherwise.
The following scripts are not meant to be executed by the user - they are called by
the above scripts. You may, however need to adapt them.
- **setpaths.sh**: sets up the paths for your directory structure. Modify this file to
conform to your needs, or setup your paths to conform to its defined paths.
Your choice.
- **projinfo.sh**: defines the name of the application jar file and the mainclass name
for it, as well as which engagement it is connected with. Any test project name
that is not found in here assumes that the jar file name and the mainclass name
will be the same as the project name.
- **projargs.sh**: defines the default arguments for each test. These can be overridden
by adding them to the end of the run.sh command.