Overall Information

This document explains the required steps to check for a requirement against a DTLS implementation. We provided the implementation of our proposed approach using a virtual machine (Artifacts-VM). An instance of this document exists on the Desktop of this virtual machine. The virtual machine can be run using Oracle VirtualBox and the credentials for it is as the following:

Username: user
Password: user

On high level, Artifacts-VM contains :

KLEE symbolic execution engine
Tested DTLS implementations
The raw data for executed experiments
Scripts to facilitate compiling and executing different experiments

Tested DTLS implementations are located in:

/media/user/Artifacts/SUTs

The Raw Data for Executed Experiments

For each tested DTLS implementation, we have the raw results for all executed experiments stored in the following directories:

Implementation              | Path To Raw Results For Executed Experiments
--------------------------  | -----------------------------------------
OpenSSL 3.0.0-alpha12       | /media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic/Experiments
TinyDTLS^E (commit:7068882) | /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests/Experiments
TinyDTLS^E (commit:94205ff) | /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests/Experiments
TinyDTLS^C                  | /media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/tests/Experiments
OpenSSL 1.0.1f              | /media/user/Artifacts/SUTs/sym-openssl-1.0.1f/apps/applicationSymbolic/Experiments
MbedTLS                     | /media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl/Experiments

Checking a Requirement

In the following, we describe the required steps to check a requirement on each DTLS implementation. Generally, it consists of the following steps:

Compiling the library and the test harness
Run an experiment to check for a requirement
Checking for the results once the experiment is done

Note: All the libraries and test harnesses are already compiled with wllvm and are ready to be executed by KLEE. Thus, step 1 is optional.

OpenSSL 3.0.0-alpha12

The library is located at:

/media/user/Artifacts/SUTs/sym-openssl-alpha/

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-openssl-alpha/ssl/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-openssl-alpha/ssl/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic

1- Compiling the library and the test harness (Optional)

In order to re-compile the whole library, one need to execute ./compile.sh in the parent directory. This will compile the whole OpenSSL library along with the test harness using wllvm.

This step produces dtls-fuzz.bc which later will be executed using KLEE.

2- Running an Experiment

In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
			Record-level requirements 	
----------------------  | ----------------------
ctypevalidity-server    | Content Type Validity for the server side
ctypevalidity-client    | Content Type Validity for the client side
recversion-server       | Record Version Validity for the server side
recversion-client       | Record Version Validity for the client side
epoch-server            | Epoch Validity for the server side
epoch-client            | Epoch Validity for the client side
rsequniqueness-server   | Record Sequence Uniqueness for the server side
rsequniqueness-client   | Record Sequence Uniqueness for the client side
rlenvalidity-server     | Record Length Validity for the server side
rlenvalidity-client     | Record Length Validity for the client side
----------------------  | ----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
htypevalidity-server    | Handshake Type Validity for the server side
htypevalidity-client    | Handshake Type Validity for the client side
mlenvalidity-server     | Message Length Validity for the server side
mlenvalidity-client     | Message Length Validity for the client side
mseqvalidity-server     | Message Sequence Validity for the server side
mseqvalidity-client     | Message Sequence Validity for the client side
flenvalidity-server     | Fragment Length Validity for the server side
flenvalidity-client     | Fragment Length Validity for the client side
fragoffset-server       | Fragment Offset Validity for the server side
fragoffset-client       | Fragment Offset Validity for the client side
flenmleneq-server       | Equality of Fragment Length and Message Length for the server side
flenmleneq-client       | Equality of Fragment Length and Message Length for the client side
bytecontain-server      | Fragment Reassembly for the server side
bytecontain-client      | Fragment Reassembly for the client side
mseqeq-server           | Message Sequence Equality in all Fragments of the same message for the server side
mseqeq-client           | Message Sequence Equality in all Fragments of the same message for the client side
mleneq-server           | Message Length Equality in all Fragments of the same message for the server side
mleneq-client           | Message Length Equality in all Fragments of the same message for the client side
----------------------  | ----------------------
		   Message-level requirements 	
----------------------  | ----------------------
handversion-server      | Handshake Version Validity for the server side
handversion-client      | Handshake Version Validity for the client side
cookielenvalidity-server| Cookie Length Validity for the server side
cookielenvalidity-client| Cookie Length Validity for the client side
sessionidlenvalidity-server| Session ID Length Validity for the server side
sessionidlenvalidity-client| Session ID Length Validity for the client side
extlenvalidity-server   | Extension Length Validity for the server side
extlenvalidity-client   | Extension Length Validity for the client side
----------------------  | ----------------------
            Input-output requirements
----------------------  | ----------------------
hvrmseqoutput-server    | ClientHello/HeloVerifyRequest Message Sequence Output Validity for the server side
shmseqoutput-server     | ClientHello2/ServerHello Message Sequence Output Validity for the server side

We can choose one of the requirements in the table above to check. For example if we want to check for the validity of the handshake type for the server side, after executing ./run.sh one will provide the name of the requirement and press Enter as the following:

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic$ ./run.sh 
Requirement to check: htypevalidity-server

This will start symbolic execution for that specific requirement (validity of the handshake type for the server side).

Note: Starting the symbolic execution in the case of OpenSSL might take up to one minute.

3- Checking the results

When the symbolic execution is finished, KLEE reports the number of instructions executed during the experiment, the number of completed paths and the number of generated test cases. For our example, one gets the following output:

KLEE: done: total instructions = 87647012
KLEE: done: completed paths = 6
KLEE: done: generated tests = 5

One can find the generated test cases in a directory with the name of the requirement (e.g. htypevalidity-server).

/media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic/htypevalidity-server

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

Note: In this example, you should get a test case flagged in the form test<N>.ptr.err. This indicates that a memory bug is found.

In order to see the produced concrete values for symbolic variables in each test case, one can use ktest-tool with the name of the test case. For example in the experiment for Handshake type validity:

ktest-tool test000001.ktest

This will show the produced concrete values for handshake type in the DTLS records sent to the server as the following:

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-openssl-alpha/apps/applicationSymbolic/htypevalidity-server$ ktest-tool test000001.ktest 
ktest file : 'test000001.ktest'
args       : ['./dtls-fuzz.bc', '-i', 'handshakes/nofrag', '-r', 'htypevalidity-server', '-c', 'psk']
num objects: 4
object 0: name: 'model_version'
object 0: size: 4
object 0: data: b'\x01\x00\x00\x00'
object 0: hex : 0x01000000
object 0: int : 1
object 0: uint: 1
object 0: text: ....
object 1: name: 'CH0-handshaketype'
object 1: size: 1
object 1: data: b'\x14'
object 1: hex : 0x14
object 1: int : 20
object 1: uint: 20
object 1: text: .
object 2: name: 'CH2-handshaketype'
object 2: size: 1
object 2: data: b'\x00'
object 2: hex : 0x00
object 2: int : 0
object 2: uint: 0
object 2: text: .
object 3: name: 'CKE-handshaketype'
object 3: size: 1
object 3: data: b'\x00'
object 3: hex : 0x00
object 3: int : 0

TinyDTLS^E (commit:7068882)

The library is located at:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests

1- Compiling the library and the test harness (Optional)

In order to re-compile the whole library, one need to execute ./compile.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests

This will compile the whole TinyDTLS library along with the test harness (produces dtls-fuzz.bc) using wllvm.

2- Running an Experiment

In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
			Record-level requirements 	
----------------------  | ----------------------
ctypevalidity-server    | Content Type Validity for the server side
ctypevalidity-client    | Content Type Validity for the client side
recversion-server       | Record Version Validity for the server side
recversion-client       | Record Version Validity for the client side
epoch-server            | Epoch Validity for the server side
epoch-client            | Epoch Validity for the client side
rsequniqueness-server   | Record Sequence Uniqueness for the server side
rsequniqueness-client   | Record Sequence Uniqueness for the client side
rlenvalidity-server     | Record Length Validity for the server side
rlenvalidity-client     | Record Length Validity for the client side
----------------------  | ----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
htypevalidity-server    | Handshake Type Validity for the server side
htypevalidity-client    | Handshake Type Validity for the client side
mlenvalidity-server     | Message Length Validity for the server side
mlenvalidity-client     | Message Length Validity for the client side
mseqvalidity-server     | Message Sequence Validity for the server side
mseqvalidity-client     | Message Sequence Validity for the client side
flenvalidity-server     | Fragment Length Validity for the server side
flenvalidity-client     | Fragment Length Validity for the client side
fragoffset-server       | Fragment Offset Validity for the server side
fragoffset-client       | Fragment Offset Validity for the client side
flenmleneq-server       | Equality of Fragment Length and Message Length for the server side
flenmleneq-client       | Equality of Fragment Length and Message Length for the client side
----------------------  | ----------------------
		   Message-level requirements 	
----------------------  | ----------------------
handversion-server      | Handshake Version Validity for the server side
handversion-client      | Handshake Version Validity for the client side
cookielenvalidity-server| Cookie Length Validity for the server side
cookielenvalidity-client| Cookie Length Validity for the client side
sessionidlenvalidity-server| Session ID Length Validity for the server side
sessionidlenvalidity-client| Session ID Length Validity for the client side
extlenvalidity-server   | Extension Length Validity for the server side
extlenvalidity-client   | Extension Length Validity for the client side
----------------------  | ----------------------
            Input-output requirements
----------------------  | ----------------------
hvrmseqoutput-server    | ClientHello/HeloVerifyRequest Message Sequence Output Validity for the server side
shmseqoutput-server     | ClientHello2/ServerHello Message Sequence Output Validity for the server side

We can choose one of the requirements in the table above to check. For example if we want to check for the validity of the epoch for the server side, after executing ./run.sh one will provide the name of the requirement and press Enter as the following:

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests$ ./run.sh 
Requirement to check: epoch-server

This will start symbolic execution for that specific requirement (validity of the epoch for the server side).

3- Checking the results

KLEE: done: total instructions = 1319208
KLEE: done: completed paths = 11
KLEE: done: generated tests = 4

One can find the generated test cases in a directory with the name of the requirement (e.g. epoch-server).

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests/epoch-server

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

Note: In this example, you should get a test case flagged in the form test<N>.assert.err. This indicates that a non-conformance bug is found.

One can see the produced concrete values for each symbolic variable in a similar way as it is explained for OpenSSL 3.0.0-alpha12.

TinyDTLS^E (commit:94205ff)

The library is located at:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation

This commit of Eclipse TinyDTLS is equivalent to commit 7068882. The only difference is that it supports fragmentation. Thus, we only check fragmentation requirements on this.

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests

1- Compiling the library and the test harness (Optional)

In order to re-compile the whole library, one need to execute ./compile.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests

This will compile the whole TinyDTLS library along with the test harness (produces dtls-fuzz.bc) using wllvm.

2- Running an Experiment

In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
bytecontain-server      | Fragment Reassembly for the server side
bytecontain-client      | Fragment Reassembly for the client side
mseqeq-server           | Message Sequence Equality in all Fragments of the same message for the server side
mseqeq-client           | Message Sequence Equality in all Fragments of the same message for the client side
mleneq-server           | Message Length Equality in all Fragments of the same message for the server side
mleneq-client           | Message Length Equality in all Fragments of the same message for the client side

We can choose one of the requirements in the table above to check. For example if we want to check for the validity of the fragment reassembly for the server side, after executing ./run.sh one will provide the name of the requirement and press Enter as the following:

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests$ ./run.sh 
Requirement to check: bytecontain-server

This will start symbolic execution for that specific requirement ( validity of the fragment reassembly for the server side).

3- Checking the results

KLEE: done: total instructions = 48589844
KLEE: done: completed paths = 300
KLEE: done: generated tests = 14

One can find the generated test cases in a directory with the name of the requirement (e.g. bytecontain-server).

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-fragmentation/tests/bytecontain-server

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

Note: In this example, you should get a test case flagged in the form test<N>.ptr.err. This indicates that a memory bug is found.

One can see the produced concrete values for each symbolic variable in a similar way as it is explained for OpenSSL 3.0.0-alpha12.

TinyDTLS^C

The library is located at:

/media/user/Artifacts/SUTs/sym-tinydtls-contiki-master

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/tests

1- Compiling the library and the test harness (Optional)

In order to re-compile the whole library, one need to execute ./compile.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/tests

This will compile the whole TinyDTLS library along with the test harness (produces dtls-fuzz.bc) using wllvm.

2- Running an Experiment

In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-tinydtls-eclipse-develop/tests

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
			Record-level requirements 	
----------------------  | ----------------------
ctypevalidity-server    | Content Type Validity for the server side
ctypevalidity-client    | Content Type Validity for the client side
recversion-server       | Record Version Validity for the server side
recversion-client       | Record Version Validity for the client side
epoch-server            | Epoch Validity for the server side
epoch-client            | Epoch Validity for the client side
rsequniqueness-server   | Record Sequence Uniqueness for the server side
rsequniqueness-client   | Record Sequence Uniqueness for the client side
rlenvalidity-server     | Record Length Validity for the server side
rlenvalidity-client     | Record Length Validity for the client side
----------------------  | ----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
htypevalidity-server    | Handshake Type Validity for the server side
htypevalidity-client    | Handshake Type Validity for the client side
mlenvalidity-server     | Message Length Validity for the server side
mlenvalidity-client     | Message Length Validity for the client side
mseqvalidity-server     | Message Sequence Validity for the server side
mseqvalidity-client     | Message Sequence Validity for the client side
flenvalidity-server     | Fragment Length Validity for the server side
flenvalidity-client     | Fragment Length Validity for the client side
fragoffset-server       | Fragment Offset Validity for the server side
fragoffset-client       | Fragment Offset Validity for the client side
flenmleneq-server       | Equality of Fragment Length and Message Length for the server side
flenmleneq-client       | Equality of Fragment Length and Message Length for the client side
----------------------  | ----------------------
		   Message-level requirements 	
----------------------  | ----------------------
handversion-server      | Handshake Version Validity for the server side
handversion-client      | Handshake Version Validity for the client side
cookielenvalidity-server| Cookie Length Validity for the server side
cookielenvalidity-client| Cookie Length Validity for the client side
sessionidlenvalidity-server| Session ID Length Validity for the server side
sessionidlenvalidity-client| Session ID Length Validity for the client side
extlenvalidity-server   | Extension Length Validity for the server side
extlenvalidity-client   | Extension Length Validity for the client side
----------------------  | ----------------------
            Input-output requirements
----------------------  | ----------------------
hvrmseqoutput-server    | ClientHello/HeloVerifyRequest Message Sequence Output Validity for the server side
shmseqoutput-server     | ClientHello2/ServerHello Message Sequence Output Validity for the server side

We can choose one of the requirements in the table above to check. For example if we want to check for the validity of the cookie length for the client side, after executing ./run.sh one will provide the name of the requirement and press Enter as the following:

ser@user-VirtualBox:/media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/tests$ ./run.sh 
Requirement to check: cookielenvalidity-client

This will start symbolic execution for that specific requirement (validity of the cookie length for the client side).

3- Checking the results

KLEE: done: total instructions = 10747900
KLEE: done: completed paths = 18
KLEE: done: generated tests = 3

One can find the generated test cases in a directory with the name of the requirement (e.g. cookielenvalidity-client).

/media/user/Artifacts/SUTs/sym-tinydtls-contiki-master/tests/cookielenvalidity-client

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

Note: In this example, you should get a test case flagged in the form test<N>.ptr.err. This indicates that a memory bug is found.

One can see the produced concrete values for each symbolic variable in a similar way as it is explained for OpenSSL 3.0.0-alpha12.

OpenSSL 1.0.1f

The library is located at:

/media/user/Artifacts/SUTs/sym-openssl-1.0.1f

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-openssl-1.0.1f/ssl/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-openssl-1.0.1f/ssl/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-openssl-1.0.1f/apps/applicationSymbolic

1- Compiling the library and the test harness (Optional)

In order to re-compile the whole library, one need to execute ./compile.sh in the parent directory. This will compile the whole OpenSSL library along with the test harness using wllvm.

2- Running an Experiment

3- In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-openssl-1.0.1f/apps/applicationSymbolic

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
			Record-level requirements 	
----------------------  | ----------------------
ctypevalidity-server    | Content Type Validity for the server side
ctypevalidity-client    | Content Type Validity for the client side
recversion-server       | Record Version Validity for the server side
recversion-client       | Record Version Validity for the client side
epoch-server            | Epoch Validity for the server side
epoch-client            | Epoch Validity for the client side
rsequniqueness-server   | Record Sequence Uniqueness for the server side
rsequniqueness-client   | Record Sequence Uniqueness for the client side
rlenvalidity-server     | Record Length Validity for the server side
rlenvalidity-client     | Record Length Validity for the client side
----------------------  | ----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
htypevalidity-server    | Handshake Type Validity for the server side
htypevalidity-client    | Handshake Type Validity for the client side
mlenvalidity-server     | Message Length Validity for the server side
mlenvalidity-client     | Message Length Validity for the client side
mseqvalidity-server     | Message Sequence Validity for the server side
mseqvalidity-client     | Message Sequence Validity for the client side
flenvalidity-server     | Fragment Length Validity for the server side
flenvalidity-client     | Fragment Length Validity for the client side
fragoffset-server       | Fragment Offset Validity for the server side
fragoffset-client       | Fragment Offset Validity for the client side
flenmleneq-server       | Equality of Fragment Length and Message Length for the server side
flenmleneq-client       | Equality of Fragment Length and Message Length for the client side
bytecontain-server      | Fragment Reassembly for the server side
bytecontain-client      | Fragment Reassembly for the client side
mseqeq-server           | Message Sequence Equality in all Fragments of the same message for the server side
mseqeq-client           | Message Sequence Equality in all Fragments of the same message for the client side
mleneq-server           | Message Length Equality in all Fragments of the same message for the server side
mleneq-client           | Message Length Equality in all Fragments of the same message for the client side
----------------------  | ----------------------
		   Message-level requirements 	
----------------------  | ----------------------
handversion-server      | Handshake Version Validity for the server side
handversion-client      | Handshake Version Validity for the client side
cookielenvalidity-server| Cookie Length Validity for the server side
cookielenvalidity-client| Cookie Length Validity for the client side
sessionidlenvalidity-server| Session ID Length Validity for the server side
sessionidlenvalidity-client| Session ID Length Validity for the client side
extlenvalidity-server   | Extension Length Validity for the server side
extlenvalidity-client   | Extension Length Validity for the client side
----------------------  | ----------------------
            Input-output requirements
----------------------  | ----------------------
hvrmseqoutput-server    | ClientHello/HeloVerifyRequest Message Sequence Output Validity for the server side
shmseqoutput-server     | ClientHello2/ServerHello Message Sequence Output Validity for the server side

We can choose one of the requirements in the table above to check. For example if we want to uncover the vulnerability that occurs in the process of fragmentation (CVE-2014-0195), after executing ./run.sh we can type mleneq-server and press Enter as the following:

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-openssl-1.0.1f/apps/applicationSymbolic$ ./run.sh 
Requirement to check: mleneq-server

This will start symbolic execution for that specific requirement (Message Length Equality in all Fragments of the same message for the server side).

Note: Starting the symbolic execution in the case of OpenSSL might take up to one minute.

3- Checking the results

KLEE: done: total instructions = 12898696
KLEE: done: completed paths = 8
KLEE: done: generated tests = 7

One can find the generated test cases in a directory with the name of the requirement (e.g. mleneq-server).

/media/user/Artifacts/SUTs/sym-openssl-1.0.1f/apps/applicationSymbolic/mleneq-server

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

Note: The test case that uncovers the vulnerability is flagged in the form: test<N>.ptr.err

One can see the produced concrete values for each symbolic variable in a similar way as it is explained for OpenSSL 3.0.0-alpha12.

MbedTLS

The library is located at:

/media/user/Artifacts/SUTs/sym-mbedtls-master

For this library, DTLS requirements are defined in:
> /media/user/Artifacts/SUTs/sym-mbedtls-master/library/symbolic.c

Moreover, the data structures to store DTLS records and other helper functions are defined in:
> /media/user/Artifacts/SUTs/sym-mbedtls-master/library/records.c

The test harness (```dtls-fuzz.c```)that allows us to check each requirement is located in:
> /media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl

1- Compiling the library and the test harness

In order to re-compile the whole library, one need to execute ./compile.sh in:

/media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl

This will compile the whole MbedTLS library along with the test harness (produces dtls-fuzz.bc) using wllvm.

2- Running an Experiment

In order to check for a requirement against the library, one can execute run.sh in:

/media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl

After executing run.sh, the script asks for the requirement we intend to check. The list of requirements is as the following:

Requirement             | Description
----------------------- | -----------------------
			Record-level requirements 	
----------------------  | ----------------------
ctypevalidity-server    | Content Type Validity for the server side
ctypevalidity-client    | Content Type Validity for the client side
recversion-server       | Record Version Validity for the server side
recversion-client       | Record Version Validity for the client side
epoch-server            | Epoch Validity for the server side
epoch-client            | Epoch Validity for the client side
rsequniqueness-server   | Record Sequence Uniqueness for the server side
rsequniqueness-client   | Record Sequence Uniqueness for the client side
rlenvalidity-server     | Record Length Validity for the server side
rlenvalidity-client     | Record Length Validity for the client side
----------------------  | ----------------------
		  Fragment-level requirements 	
----------------------  | ----------------------
htypevalidity-server    | Handshake Type Validity for the server side
htypevalidity-client    | Handshake Type Validity for the client side
mlenvalidity-server     | Message Length Validity for the server side
mlenvalidity-client     | Message Length Validity for the client side
mseqvalidity-server     | Message Sequence Validity for the server side
mseqvalidity-client     | Message Sequence Validity for the client side
flenvalidity-server     | Fragment Length Validity for the server side
flenvalidity-client     | Fragment Length Validity for the client side
fragoffset-server       | Fragment Offset Validity for the server side
fragoffset-client       | Fragment Offset Validity for the client side
flenmleneq-server       | Equality of Fragment Length and Message Length for the server side
flenmleneq-client       | Equality of Fragment Length and Message Length for the client side
bytecontain-server      | Fragment Reassembly for the server side
bytecontain-client      | Fragment Reassembly for the client side
mseqeq-server           | Message Sequence Equality in all Fragments of the same message for the server side
mseqeq-client           | Message Sequence Equality in all Fragments of the same message for the client side
mleneq-server           | Message Length Equality in all Fragments of the same message for the server side
mleneq-client           | Message Length Equality in all Fragments of the same message for the client side
----------------------  | ----------------------
		   Message-level requirements 	
----------------------  | ----------------------
handversion-server      | Handshake Version Validity for the server side
handversion-client      | Handshake Version Validity for the client side
cookielenvalidity-server| Cookie Length Validity for the server side
cookielenvalidity-client| Cookie Length Validity for the client side
sessionidlenvalidity-server| Session ID Length Validity for the server side
sessionidlenvalidity-client| Session ID Length Validity for the client side
extlenvalidity-server   | Extension Length Validity for the server side
extlenvalidity-client   | Extension Length Validity for the client side

user@user-VirtualBox:/media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl$ ./run.sh 
Requirement to check: htypevalidity-server

This will start symbolic execution for that specific requirement (validity of the handshake type for the server side).

3- Checking the results

KLEE: done: total instructions = 2533150
KLEE: done: completed paths = 3
KLEE: done: generated tests = 3

One can find the generated test cases in a directory with the name of the requirement (e.g. htypevalidity-server).

/media/user/Artifacts/SUTs/sym-mbedtls-master/programs/ssl/htypevalidity-server

Normal generated test cases have the name in the form: test<N>.ktest
Test cases that reveal a memory bug are flagged in the form: test<N>.ptr.err
Test cases that reveal a non-conformance bug are flagged in the form: test<N>.assert.err

One can see the produced concrete values for each symbolic variable in a similar way as it is explained for OpenSSL 3.0.0-alpha12.

Overall Information

The Raw Data for Executed Experiments

Checking a Requirement

OpenSSL 3.0.0-alpha12

1- Compiling the library and the test harness (Optional)

2- Running an Experiment

3- Checking the results

TinyDTLSE (commit:7068882)

1- Compiling the library and the test harness (Optional)

2- Running an Experiment

3- Checking the results

TinyDTLSE (commit:94205ff)

1- Compiling the library and the test harness (Optional)

2- Running an Experiment

3- Checking the results

TinyDTLSC

1- Compiling the library and the test harness (Optional)

2- Running an Experiment

3- Checking the results

OpenSSL 1.0.1f

1- Compiling the library and the test harness (Optional)

2- Running an Experiment

3- Checking the results

MbedTLS

1- Compiling the library and the test harness

2- Running an Experiment

3- Checking the results

TinyDTLS^E (commit:7068882)

TinyDTLS^E (commit:94205ff)

TinyDTLS^C