Skip to content

Commit c4bef2b

Browse files
jweaderjweader
committed
VMF 3.0.0 release
1 parent 46fe027 commit c4bef2b

File tree

1,178 files changed

+228564
-62
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,178 files changed

+228564
-62
lines changed

‎.dockerignore

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
build/

‎.gitignore

+17
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
.vs/
2+
.vs/*
3+
*/.vs/*
4+
*.class
5+
*.obj
6+
*.*~
7+
*.exe
8+
*/VaderWin/.vs/*
9+
out/
10+
output/
11+
output_test/
12+
x64/
13+
classes/
14+
*/classes/
15+
build/
16+
targets/
17+
.vscode/

‎.gitmodules

+18
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
[submodule "LibAFL-legacy"]
2+
path = vmf/submodules/LibAFL-legacy
3+
url = https://github.com/AFLplusplus/LibAFL-legacy
4+
[submodule "external/projects/AFLplusplus"]
5+
path = vmf/submodules/AFLplusplus
6+
url = https://github.com/AFLplusplus/AFLplusplus
7+
[submodule "external/projects/googletest"]
8+
path = vmf/submodules/googletest
9+
url = https://github.com/google/googletest.git
10+
[submodule "submodules/yaml-cpp"]
11+
path = vmf/submodules/yaml-cpp
12+
url = https://github.com/jbeder/yaml-cpp
13+
[submodule "submodules/klee"]
14+
path = submodules/klee
15+
url = https://github.com/klee/klee
16+
[submodule "submodules/plog"]
17+
path = vmf/submodules/plog
18+
url = https://github.com/SergiusTheBest/plog.git

‎CMakeLists.txt

+144
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,144 @@
1+
#===============================================================================
2+
# Vader Modular Fuzzer (VMF)
3+
# Copyright (c) 2021-2023 The Charles Stark Draper Laboratory, Inc.
4+
# <vader@draper.com>
5+
#
6+
# Effort sponsored by the U.S. Government under Other Transaction number
7+
# W9124P-19-9-0001 between AMTC and the Government. The U.S. Government
8+
# Is authorized to reproduce and distribute reprints for Governmental purposes
9+
# notwithstanding any copyright notation thereon.
10+
#
11+
# The views and conclusions contained herein are those of the authors and
12+
# should not be interpreted as necessarily representing the official policies
13+
# or endorsements, either expressed or implied, of the U.S. Government.
14+
#
15+
# This program is free software: you can redistribute it and/or modify
16+
# it under the terms of the GNU General Public License version 2 (only) as
17+
# published by the Free Software Foundation.
18+
#
19+
# This program is distributed in the hope that it will be useful,
20+
# but WITHOUT ANY WARRANTY; without even the implied warranty of
21+
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
22+
# GNU General Public License for more details.
23+
#
24+
# You should have received a copy of the GNU General Public License
25+
# along with this program. If not, see <http://www.gnu.org/licenses/>.
26+
#
27+
# @license GPL-2.0-only <https://spdx.org/licenses/GPL-2.0-only.html>
28+
#===============================================================================
29+
cmake_minimum_required(VERSION 3.10.2)
30+
31+
set(CMAKE_VERBOSE_MAKEFILE ON)
32+
33+
# Specify project related variables.
34+
set(CMAKE_CXX_STANDARD 11)
35+
set(CMAKE_CXX_STANDARD_REQUIRED True)
36+
set(CMAKE_CXX_COMPILER g++)
37+
38+
# This is not an option that we want to enable. Think twice about re-enabling it.
39+
# Three times, maybe. And then don't do it. If some legacy code needs it, put it there
40+
# somehow, not globally.
41+
#add_compile_options(-fpermissive)
42+
43+
# Use address sanitizer?
44+
#add_compile_options(-fsanitize=address)
45+
#add_link_options(-fsanitize=address)
46+
47+
#Added to prevent issues like this:
48+
#https://stackoverflow.com/questions/61278099/using-stdthread-in-shared-library-causes-sigsegv
49+
set(CMAKE_CXX_FLAGS -Wl,--no-as-needed)
50+
51+
project(Vader VERSION 2.0
52+
LANGUAGES CXX)
53+
54+
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/vmf/cmake)
55+
56+
# Bring in VMF project wide variables and utility functions
57+
include(vmf/cmake/vmf.cmake)
58+
include(vmf/cmake/external_libs.cmake)
59+
60+
# Add in project directories
61+
add_subdirectory(${PROJECT_SOURCE_DIR}/vmf/src)
62+
63+
# Create VADER Executable and link in dependencies.
64+
# These dependencies are for the the VMF Framework
65+
# not for specific modules
66+
add_executable(vader ${PROJECT_SOURCE_DIR}/vmf/src/framework/main.cpp)
67+
target_link_libraries(vader
68+
PRIVATE
69+
yaml
70+
VMFFramework
71+
stdc++fs
72+
)
73+
target_include_directories(vader PRIVATE
74+
${PROJECT_SOURCE_DIR}/vmf/src/framework/baseclasses
75+
${PROJECT_SOURCE_DIR}/vmf/src/framework/app
76+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/common/formatter
77+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/common/initilization
78+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/common/inputgeneration
79+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/common/mutator
80+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/common/output
81+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/linux/executor
82+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/linux/feedback
83+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/linux/initialization
84+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/linux/mutator
85+
${PROJECT_SOURCE_DIR}/vmf/src/coremodules/linux/output
86+
)
87+
set_vmf_compile_options(vader)
88+
install(TARGETS vader
89+
RUNTIME DESTINATION ${VMF_INSTALL_BINDIR})
90+
91+
include(GoogleTest)
92+
enable_testing()
93+
94+
add_subdirectory(${PROJECT_SOURCE_DIR}/test)
95+
96+
install(FILES "vmf/cmake/vmf.cmake" "vmf/cmake/vmf_imports.cmake"
97+
DESTINATION ${CMAKE_INSTALL_PREFIX}/cmake)
98+
99+
install(DIRECTORY ${EXTERNAL_LIBDIR}
100+
DESTINATION ${CMAKE_INSTALL_PREFIX}
101+
PATTERN "*.a" EXCLUDE
102+
)
103+
104+
#Install samples project
105+
install(DIRECTORY ${EXTERNAL_BINDIR}
106+
DESTINATION ${CMAKE_INSTALL_PREFIX}
107+
USE_SOURCE_PERMISSIONS
108+
)
109+
110+
#Copy pre-built python klee script into vmf_install
111+
install(DIRECTORY vmf/src/scripts/bin/
112+
DESTINATION ${VMF_INSTALL_BINDIR}
113+
USE_SOURCE_PERMISSIONS)
114+
115+
#Copy pre-built python klee script into local directory (for developers running directly from build)
116+
add_custom_command(TARGET vader POST_BUILD
117+
COMMAND ${CMAKE_COMMAND} -E copy ${PROJECT_SOURCE_DIR}/vmf/src/scripts/bin/* ${PROJECT_BINARY_DIR}/
118+
)
119+
120+
#Header files are needed for plog library
121+
install(DIRECTORY ${EXTERNAL_INCLUDEDIR}/plog
122+
DESTINATION ${CMAKE_INSTALL_PREFIX}/include/
123+
)
124+
125+
126+
install(DIRECTORY vmf/src/samples
127+
DESTINATION ${CMAKE_INSTALL_PREFIX}
128+
PATTERN "build" EXCLUDE)
129+
130+
#install sample configuration files and haystack example
131+
INSTALL(DIRECTORY test DESTINATION
132+
DESTINATION ${CMAKE_INSTALL_PREFIX}
133+
PATTERN "*.cpp" EXCLUDE
134+
PATTERN "*.txt" EXCLUDE
135+
PATTERN "haystack" EXCLUDE
136+
PATTERN "test_only" EXCLUDE
137+
PATTERN "test_only/*" EXCLUDE
138+
PATTERN "unittest" EXCLUDE
139+
)
140+
141+
#install haystack example executable
142+
file (COPY test/haystackSUT/haystack
143+
DESTINATION ${CMAKE_INSTALL_PREFIX}/test/haystackSUT
144+
USE_SOURCE_PERMISSIONS)

‎CODE_OF_CONDUCT.md

+127
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
2+
# Code of Conduct
3+
4+
## Our Pledge
5+
6+
We as members, contributors, and leaders pledge to make participation in our
7+
community a harassment-free experience for everyone, regardless of age, body
8+
size, visible or invisible disability, ethnicity, sex characteristics, gender
9+
identity and expression, level of experience, education, socio-economic status,
10+
nationality, personal appearance, race, caste, color, religion, or sexual
11+
identity and orientation.
12+
13+
We pledge to act and interact in ways that contribute to an open, welcoming,
14+
diverse, inclusive, and healthy community.
15+
16+
## Our Standards
17+
18+
Examples of behavior that contributes to a positive environment for our
19+
community include:
20+
21+
* Demonstrating empathy and kindness toward other people
22+
* Being respectful of differing opinions, viewpoints, and experiences
23+
* Giving and gracefully accepting constructive feedback
24+
* Accepting responsibility and apologizing to those affected by our mistakes,
25+
and learning from the experience
26+
* Focusing on what is best not just for us as individuals, but for the overall
27+
community
28+
29+
Examples of unacceptable behavior include:
30+
31+
* The use of sexualized language or imagery, and sexual attention or advances of
32+
any kind
33+
* Trolling, insulting or derogatory comments, and personal or political attacks
34+
* Public or private harassment
35+
* Publishing others' private information, such as a physical or email address,
36+
without their explicit permission
37+
* Other conduct which could reasonably be considered inappropriate in a
38+
professional setting
39+
40+
## Enforcement Responsibilities
41+
42+
Community leaders are responsible for clarifying and enforcing our standards of
43+
acceptable behavior and will take appropriate and fair corrective action in
44+
response to any behavior that they deem inappropriate, threatening, offensive,
45+
or harmful.
46+
47+
Community leaders have the right and responsibility to remove, edit, or reject
48+
comments, commits, code, wiki edits, issues, and other contributions that are
49+
not aligned to this Code of Conduct, and will communicate reasons for moderation
50+
decisions when appropriate.
51+
52+
## Scope
53+
54+
This Code of Conduct applies within all community spaces, and also applies when
55+
an individual is officially representing the community in public spaces.
56+
Examples of representing our community include using an official e-mail address,
57+
posting via an official social media account, or acting as an appointed
58+
representative at an online or offline event.
59+
60+
## Enforcement
61+
62+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
63+
reported to the community leaders responsible for enforcement at
64+
[INSERT CONTACT METHOD].
65+
All complaints will be reviewed and investigated promptly and fairly.
66+
67+
All community leaders are obligated to respect the privacy and security of the
68+
reporter of any incident.
69+
70+
## Enforcement Guidelines
71+
72+
Community leaders will follow these Community Impact Guidelines in determining
73+
the consequences for any action they deem in violation of this Code of Conduct:
74+
75+
### 1. Correction
76+
77+
**Community Impact**: Use of inappropriate language or other behavior deemed
78+
unprofessional or unwelcome in the community.
79+
80+
**Consequence**: A private, written warning from community leaders, providing
81+
clarity around the nature of the violation and an explanation of why the
82+
behavior was inappropriate. A public apology may be requested.
83+
84+
### 2. Warning
85+
86+
**Community Impact**: A violation through a single incident or series of
87+
actions.
88+
89+
**Consequence**: A warning with consequences for continued behavior. No
90+
interaction with the people involved, including unsolicited interaction with
91+
those enforcing the Code of Conduct, for a specified period of time. This
92+
includes avoiding interactions in community spaces as well as external channels
93+
like social media. Violating these terms may lead to a temporary or permanent
94+
ban.
95+
96+
### 3. Temporary Ban
97+
98+
**Community Impact**: A serious violation of community standards, including
99+
sustained inappropriate behavior.
100+
101+
**Consequence**: A temporary ban from any sort of interaction or public
102+
communication with the community for a specified period of time. No public or
103+
private interaction with the people involved, including unsolicited interaction
104+
with those enforcing the Code of Conduct, is allowed during this period.
105+
Violating these terms may lead to a permanent ban.
106+
107+
### 4. Permanent Ban
108+
109+
**Community Impact**: Demonstrating a pattern of violation of community
110+
standards, including sustained inappropriate behavior, harassment of an
111+
individual, or aggression toward or disparagement of classes of individuals.
112+
113+
**Consequence**: A permanent ban from any sort of public interaction within the
114+
community.
115+
116+
## Attribution
117+
118+
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org),
119+
version 2.1, available at
120+
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).
121+
122+
Community Impact Guidelines were inspired by
123+
[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity "Mozilla Diversity & Inclusion in Open Source").
124+
125+
For answers to common questions about this code of conduct, see the FAQ at
126+
[https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available at
127+
[https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).

‎CONTRIBUTING.md

+67
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
# Contributing to VMF
2+
3+
Thank you for your interest in contributing to VMF! The following is a set of guidelines for contributing to VMF and its associated modules, which are hosted on this site.
4+
5+
## Legal Requirements
6+
7+
In order to become a contributor, you first need to sign the appropriate [Contributor License Agreement](vmf_contributor_license_agreement.pdf).
8+
9+
## Code of Conduct
10+
11+
This project and everyone participating in it is governed by the [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [vmf@draper.com](mailto:vmf@draper.com).
12+
13+
14+
## Overview
15+
16+
VMF is an open-source project. If you are interested in making it better, there are many ways you can contribute. For example, you can:
17+
18+
- Submit a bug report
19+
- Propose a bug fix by submitting a pull request
20+
- Suggest new module or feature
21+
- Propose a new module by submitting a pull request
22+
- Suggest or submit documentation improvements
23+
- Answer questions from other users
24+
- Share the software with other users who are interested
25+
- Teach others to use the software
26+
27+
## Submitting Bugs and Feature Requests
28+
29+
If you believe that you have found a bug or wish to propose a new feature, please first search the existing [issues] to see if it has already been reported. If you are unable to find an existing issue, consider using one of the provided templates to create a new issue and provide as many details as you can to assist in reproducing the bug or explaining your proposed feature.
30+
31+
## Contribution Submission Guidelines
32+
33+
Generally, any issue that doesn't have an Assignee is free for anyone to work on. Assign the issue to yourself to indicate you intend to start working on it shortly. Please unassign yourself if you no longer have time work on it so that someone else may pick it up.
34+
35+
Treat the issue as a place to document decisions about the issue, hold discussions in the comments, create to-do lists, paste diagrams, or whatever you think would be helpful for you during development. Try to keep the description up to date as development progresses.
36+
37+
Contributions should be submitted in the form of Pull Requests to the VMF [repository] on GitHub.
38+
39+
### Repo Structure and Hygiene
40+
Our code repo follows the "OneFlow" pattern described [here]( https://www.endoflineblog.com/implementing-oneflow-on-github-bitbucket-and-gitlab). As the name suggests, there is a single persistent "main" branch. Other branches are all temporary and are deleted once the changes have been merged back into main. Releases are marked (and created) via git tags.
41+
42+
#### Release Readiness
43+
Our current criteria for release readiness is that all unit tests pass, and sign-off obtained from a majority of the official maintainers.
44+
45+
#### Mergeability
46+
When making a PR, it helps to try to keep it mergeable into the official repo. In practice, this usually means periodically rebasing on main when there are changes upstream after your PR was created.
47+
48+
### Code Standards
49+
For a smooth code review, it helps to make sure your code adheres to standards, conventions, and design goals for VMF. A best-effort attempt to understand and meet these standards before requesting code review can go a long way towards making the review process as fast and painless as possible.
50+
51+
### Other Information and Tips
52+
53+
Please consider the following tips to ensure a smooth process when submitting:
54+
55+
- Ensure that the code compiles and does not break any build-time tests.
56+
- Be understanding, patient, and friendly; the VMF team needs time to review your submission before they can act or respond. This does not mean your contribution is not valued. If your contribution has not received a response in a reasonable time, consider commenting with a polite inquiry for an update.
57+
- Limit individual changes to the smallest reasonable change to achieve your intended goal. For example, do not make unnecessary indentation changes; but don't go out of your way to make the patch so minimal that it isn't easy to read, either. Consider the reviewer's perspective.
58+
- Isolate multiple patches from each other. If you wish to make several independent patches, do so in separate, smaller pull requests that can be reviewed more easily.
59+
- Before submission, please squash your commits and use a message that starts with the issue number and a description of the changes. We suggest following the “[seven rules of a great Git commit message]( https://cbea.ms/git-commit/).”
60+
- Be prepared to answer questions from reviewers. They may have further questions before accepting your patch and may even propose changes. Please accept this feedback constructively, and not as a rejection of your proposed change.
61+
- Unless previously authorized by the VMF team, repackaging, renaming, and other refactoring should not be part of any pull request. These types of changes are difficult to review, pollute the git history making it harder to do git forensics on regressions, and will likely conflict with other changes that the VMF team is making internally.
62+
- Avoid "find and replace" changes in your pull request. While it may be tempting to globally replace calls to deprecated methods or change the style of the code to fit your personal preference, these types of seemingly trivial changes have likely not already been performed by the VMF team for good reason.
63+
- Please do not submit pull requests that update 3rd party dependencies. It is preferred that these changes are made internally by the team. If you have a need for an updated tool or library, please submit an issue with your request instead of a pull request.
64+
65+
## Legal
66+
67+
Consistent with Section D.6. of the GitHub Terms of Service as of 2022, the project maintainer for this project accepts contributions using the inbound=outbound model. When you submit a pull request to this repository (inbound), you are agreeing to license your contribution under the same terms as specified in [LICENSE] (outbound).

0 commit comments

Comments
 (0)