forked from dslab-epfl/s2e2-gui
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRapport.txt
87 lines (42 loc) · 4.84 KB
/
Rapport.txt
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
S2E GUI
Davide Di Dio
------------------------
Context :
S2E is a platform for writing tools that analyze the properties and behavior of software systems. S2E is a virtual machine augmented with symbolic execution and modular path analyzers. S2E runs unmodified x86, x86-64, or ARM software stacks, including programs, libraries, the kernel, and drivers. Symbolic execution then automatically explores hundreds of thousands of paths through the system, while analyzers check that the desired properties hold on these paths and selectors focus path exploration on components of interest.
Currently S2E is executed by command line and configuration files, the goals of this project are to ease the use of S2E making it more approachable to beginners, to provide a easy way to manage and access analysis and to display the results of the analysis in a more readable way.
Project Stages:
1. Decide on the development stack to use.
I choose to use a stack with : python, django, Linux and javascript.
When I started to work on the project, S2E was only supported on Linux choosing it was inevitable.
2. Automate the generation of configuration files.
Currently, on S2E, if a user wants to use a plugin, it as to through the source code of the plugin and understand the way it works. Then the user has to write a configuration file in LUA to be able to use that plugin. With the interface, the user can just select which plugin to enable.
The plugin's developer must include a small annotation in his code for each attributes of the plugin. The comment looks like this:
// attribute_name:
// type: int
// description: "attribute description."
The developer must supply the name of the attribute, the type and optionally a description for the attribute. These comment should respect the YAML format. Currently the project supports multiple types: "int", "bool", "string", "stringList", "intList" and "list". An attribute of type list describes a list of attributes, it must contain a variable named "content" assigned with every attributes included in the list.
Here is an example of a list attribute:
// list_prefix:
// type: list
// description: "this is the description of the list"
// content:
// checked:
// type: bool
// description: "this is the description of checked"
When the annotation has been written inside the plugin source, a script will generate a json file with the information inside the source files.
This as the added benefit to encourage the developer to comment their plugins code, otherwise it will not work inside the GUI.
3. Configure and run S2E.
The json file constructed in stage 2 is used by the GUI to create a customized interface to generate the plugin configuration. The user can use the interface to configure the analysis
When the user has configured the plugins with the interface, he has to supply a binary to execute and then he can run the analysis. The interface sends everything to the server, generates a config.lua file and runs S2E on the binary with the generated config.lua file.
4. Extend the web interface to displays plugin-specific output in an easy-to-understand way
In a normal execution, S2E outputs three log files (info.txt, debug.txt, warning.txt) and files generated by plugins (e.g., ExecutionTracer.dat). The user has then to read and understand those files to debug or profile his binary file.
With the GUI, the analysis log files are broken down into the S2E states, which the user can then read individually. The user can also look at the analysis overview, it displays all the states that have run in the analysis as well as their termination status and message. If the user decides to enable the InstructionCounter plugin, he can go to a tab containing the total instruction count on every states of the analysis.
The GUI offers a view on the line coverage and on the function's graphs, for that, the TranslationBlockCoverage plugin must be enabled.
The function's graph is a set of images that describe the flow of the program, an image is generated for each function involved in the submitted binary.
The line coverage just displays if a line has been executed and how many states ran it under the line data.
5. Implement a mechanism for storing S2E analysis results and allow the user to browse a history of S2E analysis.
In the current S2E environment, when the user creates a project, by default the project name is the same as the binary name.
The GUI uses this disposition to maintain a consistence with s2e-env. Everything related to an analysis is stored inside the S2E output folder. A database keeps track of the project name, s2e-number and binary checksum for later accessibility.
Thanking:
I thank everyone who helped me in the elaboration of this project and report. I also want to "remercier particulierement" a special thank to M. Herrara who followed this project really closely.
I also want to thank Dr. Candea