... | @@ -92,7 +92,7 @@ bool verify_pin(uint8_t* user_pin, uint8_t* card_pin); |
... | @@ -92,7 +92,7 @@ bool verify_pin(uint8_t* user_pin, uint8_t* card_pin); |
|
|
|
|
|
# Instrumenting the code
|
|
# Instrumenting the code
|
|
|
|
|
|
The first step will consist in instrumenting the code to have a program exploitable by **Lazart**. For more information, please consult the [attack model](Attack-Model#description-with-instrumentation) and [attack objective](Core/Attack-objective) sections.
|
|
The first step will consist in instrumenting the code to have a program exploitable by **Lazart**. For more information, please consult the [attack model](Attack-Model) and [attack objective](Core/Attack-objective) pages.
|
|
|
|
|
|
Create a _main.c_ file corresponding to the entry point of the analysis, and put all source files (_verify_pin.c_, _verify_pin.h_ and _main.c_) in a _src_ subfolder.
|
|
Create a _main.c_ file corresponding to the entry point of the analysis, and put all source files (_verify_pin.c_, _verify_pin.h_ and _main.c_) in a _src_ subfolder.
|
|
|
|
|
... | @@ -186,7 +186,7 @@ Two arguments are required: the input files of the program and the attack model. |
... | @@ -186,7 +186,7 @@ Two arguments are required: the input files of the program and the attack model. |
|
|
|
|
|
The second argument is the attack model, it contains a specification of the fault that can be applied by the attacker. In this case, the [`functions_list(fcts, models)`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.attack_model.html#lazart.core.attack_model.functions_list) function creates an attack model in which a list of models is applied on each specified function. More complex attack models can be defined, see the [tutorial 3](Overview/Tutorial-3:-Data-Load-and-model-combination-on-memcmps) and [attack model section](Attack-Model).
|
|
The second argument is the attack model, it contains a specification of the fault that can be applied by the attacker. In this case, the [`functions_list(fcts, models)`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.attack_model.html#lazart.core.attack_model.functions_list) function creates an attack model in which a list of models is applied on each specified function. More complex attack models can be defined, see the [tutorial 3](Overview/Tutorial-3:-Data-Load-and-model-combination-on-memcmps) and [attack model section](Attack-Model).
|
|
|
|
|
|
Several optional parameters can be specified. The `max_order` argument specifies the fault limit of the analysis (default to 2). The `params` parameter accepts the [`install_script`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.script.html#lazart.script.install_script) argument namespace overriding some argument depending on the CLI, for instance `max_order` will be set by `params` if the option `--order` (`-o`) is specified.
|
|
Several optional parameters can be specified. The `max_order` argument specifies the faults limit of the analysis (default to 2). The `params` parameter accepts the [`install_script`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.script.html#lazart.script.install_script) argument namespace overriding some argument depending on the CLI, for instance `max_order` will be set by `params` if the option `--order` (`-o`) is specified.
|
|
The `path` argument specifies in which folder the analysis files will be generated. It's often better to have your analysis files in a subfolder to separate the analysis script. If not specified, an auto-generated fresh folder name is used. Additionally, `compiler_args` allows to specify additional arguments to the compiler and `klee_args`allows to give parameters to KLEE.
|
|
The `path` argument specifies in which folder the analysis files will be generated. It's often better to have your analysis files in a subfolder to separate the analysis script. If not specified, an auto-generated fresh folder name is used. Additionally, `compiler_args` allows to specify additional arguments to the compiler and `klee_args`allows to give parameters to KLEE.
|
|
|
|
|
|
The analysis `flags` determines which analyses are possible. Use [`AttackAnalysis`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.analysis.html#lazart.core.analysis.AnalysisFlag.AttackAnalysis) (default) for attack analysis. [`execute`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.util.exec.html#lazart.util.exec.execute) function performs all the operations required for the analysis. This function behaves differently depending on the analysis's flags. For attack analysis, the call to [`execute`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.util.exec.html#lazart.util.exec.execute) will be roughly equivalent to the following code:
|
|
The analysis `flags` determines which analyses are possible. Use [`AttackAnalysis`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.analysis.html#lazart.core.analysis.AnalysisFlag.AttackAnalysis) (default) for attack analysis. [`execute`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.util.exec.html#lazart.util.exec.execute) function performs all the operations required for the analysis. This function behaves differently depending on the analysis's flags. For attack analysis, the call to [`execute`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.util.exec.html#lazart.util.exec.execute) will be roughly equivalent to the following code:
|
... | @@ -247,9 +247,11 @@ verify: attacks tests passed |
... | @@ -247,9 +247,11 @@ verify: attacks tests passed |
|
verify: traces tests passed
|
|
verify: traces tests passed
|
|
root@lazart:/opt/lazart/use-cases/examples/get-started/#
|
|
root@lazart:/opt/lazart/use-cases/examples/get-started/#
|
|
```
|
|
```
|
|
In this example, the analysis was run with quiet verbosity mode (`-V=quiet`), forcing the re-computation of each step despite the cache (-r). The fault limit was set to 4 in the CLI (`-o=4`), which was forwarded with the (`params` argument of [`read_or_make`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.io.html#lazart.io.read_or_make)).
|
|
In this example, the analysis was run with quiet verbosity mode (`-V=quiet`), forcing the re-computation of each step despite any cached results (`-r`).
|
|
|
|
|
|
All results are stored inside the analysis folder, named `results` (specified in the `path` field in `read_or_make`). Lazart produces several results tables:
|
|
The faults limit was set to 4 in the CLI (`-o=4`), which was forwarded with the (`params` argument of [`read_or_make`](https://securitytools.gricad-pages.univ-grenoble-alpes.fr/lazart/python-api/lazart.core.io.html#lazart.io.read_or_make)).
|
|
|
|
|
|
|
|
Here, Lazart produces several results tables:
|
|
- Program: static information about the program: total LLVM instructions (*Instr.*), total branches (*BRs*), total injection points (*IPs*) and detectors count (*Dets*, only used in countermeasures analysis).
|
|
- Program: static information about the program: total LLVM instructions (*Instr.*), total branches (*BRs*), total injection points (*IPs*) and detectors count (*Dets*, only used in countermeasures analysis).
|
|
- Attack Analysis: the number of attacks for each order (up to 4 here) and the total number of attacks.
|
|
- Attack Analysis: the number of attacks for each order (up to 4 here) and the total number of attacks.
|
|
- Full attacks results: extended table of attack analysis for redundancy and equivalence analysis (see [tutorial 2](Overview/Tutorial-2:-Symbolic-Inputs,-Equivalence-and-Redundancy)).
|
|
- Full attacks results: extended table of attack analysis for redundancy and equivalence analysis (see [tutorial 2](Overview/Tutorial-2:-Symbolic-Inputs,-Equivalence-and-Redundancy)).
|
... | @@ -258,6 +260,8 @@ All results are stored inside the analysis folder, named `results` (specified in |
... | @@ -258,6 +260,8 @@ All results are stored inside the analysis folder, named `results` (specified in |
|
- Coverage: instruction and basic blocs coverage (*ICov(%)* and *BCov(%)*), incomplete traces (*ITr*), full branches (*FBr*) and partial branches (*PBr*).
|
|
- Coverage: instruction and basic blocs coverage (*ICov(%)* and *BCov(%)*), incomplete traces (*ITr*), full branches (*FBr*) and partial branches (*PBr*).
|
|
- Hotspots analysis results: providing information about injection points (see the [dedicated section](Analysis/Hotspot-Analysis)).
|
|
- Hotspots analysis results: providing information about injection points (see the [dedicated section](Analysis/Hotspot-Analysis)).
|
|
|
|
|
|
|
|
All results are stored inside the analysis folder, named `results` (specified in the `path` field in `read_or_make`).
|
|
|
|
|
|
**Lazart** will generate an _analysis report_ in the analysis folder. You can find the report of this analysis [here](https://gricad-gitlab.univ-grenoble-alpes.fr/lazart/lazart/-/raw/master/use-cases/examples/get-started/results/report.md).
|
|
**Lazart** will generate an _analysis report_ in the analysis folder. You can find the report of this analysis [here](https://gricad-gitlab.univ-grenoble-alpes.fr/lazart/lazart/-/raw/master/use-cases/examples/get-started/results/report.md).
|
|
|
|
|
|
The complete results CSV file can be found inside the `res.csv` file in the analysis folder, the `results` binary file contains the `Metric` object for the Analysis. The analysis folder structure is presented [here](Analysis#analysis-folder-structure).
|
|
The complete results CSV file can be found inside the `res.csv` file in the analysis folder, the `results` binary file contains the `Metric` object for the Analysis. The analysis folder structure is presented [here](Analysis#analysis-folder-structure).
|
... | | ... | |