|
1 | 1 | # `Lich` |
2 | 2 |
|
3 | | -*Defying IoT firmware defects through magical instruments* |
| 3 | +*Defying OS-based firmware defects through forbidden magical instruments* |
4 | 4 |
|
5 | 5 | ## Description |
6 | 6 |
|
7 | | -Lich is an IoT firmware analyzer to detect vulnerabilities and extract energy |
8 | | -consumption data. |
| 7 | +**Lich** is an OS-based firmware analyzer designed to detect vulnerabilities and |
| 8 | +extract energy consumption data. |
9 | 9 |
|
10 | | -The main idea behind this software consists of aggregating the results produced |
11 | | -by different tools into a single final report. To create this report, all |
12 | | -selected tools must be executed one after the other. |
13 | | -A tool can be disabled from being executed through a configuration file option. |
14 | | -This offers more flexibility in case of unmaintained tools. |
| 10 | +The core idea behind this software is to aggregate results from various tools |
| 11 | +into a single final report. To generate this report, all selected tools are |
| 12 | +executed sequentially. |
| 13 | +A tool can be excluded from execution via a configuration file option, offering |
| 14 | +flexibility, especially when dealing with unmaintained tools. |
15 | 15 |
|
16 | | -It does not matter the programming language adopted for firmware development, |
17 | | -only the final binary instance, and its variants, are taken into consideration |
18 | | -during the analysis. |
| 16 | +The programming language used to develop the firmware doesn't matter, as only |
| 17 | +the final binary and its variants are considered during the analysis. |
19 | 18 |
|
20 | | -Lich differs from other tools because developers do not need to install |
21 | | -none of the tools on their own computers since all tests are performed within |
22 | | -a single and independent environment created with Docker. |
| 19 | +Unlike other tools, **Lich** eliminates the need for developers to install any |
| 20 | +dependencies on their local machines. All tests are run within a self-contained |
| 21 | +environment created by Docker. |
23 | 22 |
|
24 | | -The final results are presented as a single markdown where at each test is |
25 | | -assigned a different file section. |
| 23 | +The final results are presented in a single markdown document, with each test |
| 24 | +output assigned to a separate section. |
26 | 25 |
|
27 | | -Lich has been written in Rust because it allows to manage in a safe way a tool |
28 | | -invocation. Indeed, the Rust `Command` API defines a process builder which |
29 | | -provides a fine-grained control over how a new process should be spawned. |
30 | | -Furthermore, a tool written in Rust reduces the possibility of introducing new |
31 | | -vulnerabilities within the tool itself. |
| 26 | +**Lich** is written in Rust, which ensures safe management of tool invocations. |
| 27 | +The Rust `Command` API provides a fine-grained process builder for precise |
| 28 | +control over how processes are spawned. Additionally, using Rust reduces the |
| 29 | +risk of introducing vulnerabilities into the tool itself. |
32 | 30 |
|
33 | 31 | ## Usability |
34 | 32 |
|
35 | | -Lich can also be used for Continuous Integration purposes. It can be run either |
36 | | -at each commit or before an IoT firmware release to verify the presence of |
37 | | -some internal vulnerabilities, but even for estimating firmware energy |
38 | | -consumptions. |
39 | | -Final results can be provides as Continuous Integration artifacts or shown as |
40 | | -a pull request comment in the form of a link pointing to a temporary |
41 | | -`html` file. |
| 33 | +**Lich** can also be used for Continuous Integration (CI) purposes. It can be |
| 34 | +run either on every commit or before a firmware release to check for internal |
| 35 | +vulnerabilities, or even to estimate firmware energy consumption. |
| 36 | +The final results can be provided as CI artifacts or displayed as a pull request |
| 37 | +comment with a link to a temporary `html` file. |
42 | 38 |
|
43 | | -This tool might also be adopted within a certification process to evaluate |
44 | | -whether some properties are satisfied or not. When a property is not correct, |
45 | | -the relative test **should** fail. |
| 39 | +This tool can also be integrated into a certification process to verify whether |
| 40 | +specific properties are met. If a property is violated, the corresponding test |
| 41 | +**should** fail. |
46 | 42 |
|
47 | | -Energy costs nowadays. Having the possibility to estimate how much an IoT |
48 | | -firmware consumes during its execution helps to reduce the monthly billing, |
49 | | -especially if the firmware must be used day and night without interruptions. |
| 43 | +Energy costs are a growing concern. Estimating firmware energy consumption |
| 44 | +during execution can help lower monthly billing, particularly for firmware that |
| 45 | +runs continuously, day and night. |
50 | 46 |
|
51 | 47 | ## Limitations |
52 | 48 |
|
53 | | -- Lich **must** have the same IoT firmware hardware architecture. Since most of |
54 | | -the tests are performed at runtime, it is needed to run the input binary. |
55 | | -An emulator architecture might not always be the right solution due to the |
56 | | -flaws which usually affect these kinds of software. |
57 | | -- Some of the tools used by Lich might support only the most famous hardware |
58 | | -architectures. Therefore, some peculiar and independent platforms will be |
59 | | -excluded from the analysis. |
| 49 | +- **Lich** **must** be run on the same hardware architecture as the OS-based |
| 50 | +firmware, since the firmware needs to be executed at runtime to perform most of |
| 51 | +the tests. |
| 52 | +An emulator may not always be a viable solution due to common limitations in |
| 53 | +such software. |
| 54 | +- Some tools used by **Lich** may only support popular hardware architectures, |
| 55 | +excluding niche or independent platforms from the analysis. |
0 commit comments