fix typos up to ch 3

3_rasta/1_intro.typ

@@ -33,4 +33,4 @@ The chapter is structured as follows.
 @sec:rasta-failure-analysis investigates the reasons behind the observed failures of some of the tools. 
 We then compare in @sec:rasta-soa-comp our results with the contributions presented in @sec:bg.
 In @sec:rasta-reco, we give recommendations for tool development that we drew from our experience running our experiment.
-Finally, @sec:rasta-limit lists the limit of our approach, @sec:rasta-futur presents further avenues that did not have time to pursue and @sec:rasta-conclusion concludes the chapter.
+Finally, @sec:rasta-limit lists the limit of our approach, @sec:rasta-future presents further avenues that did not have time to pursue and @sec:rasta-conclusion concludes the chapter.

3_rasta/2_methodology.typ

@@ -204,7 +204,7 @@ To guarantee reproducibility, we published the results, datasets, Dockerfiles an
 - https://zenodo.org/records/10144014 . 
 - https://zenodo.org/records/10980349 .
 - on Docker Hub as `histausse/rasta-<toolname>:icsr2024`.
-]
+].
 
 #figure(
   raw-render(```

3_rasta/4_failures_analysis.typ

@@ -263,7 +263,7 @@ dad: SError
 
 #paragraph([Mallodroid and Apparecium])[
 Mallodroid and Apparecium stand out as the tools that raised the most errors in one run. 
-They can raise more than #num(10000) error by analysis. 
+They can raise more than #num(10000) errors by analysis. 
 However, it happened only for a few dozen #APKs, and conspicuously, the same #APKs raised the same high number of errors for both tools. 
 The recurring error is a `KeyError` raised by Androguard when trying to find a string by its identifier. 
 Although this error is logged, it seems successfully handled, and during a manual analysis of the execution, both tools seemingly perform their analysis without issue. 
@@ -286,7 +286,7 @@ Instruction10x%
 */
 
 #paragraph([Blueseal])[
-Because Blueseal rarely log more than one error when crashing, it is easy to identify the relevant error. 
+Because Blueseal rarely logs more than one error when crashing, it is easy to identify the relevant error. 
 The majority of crashes come from unsupported Android versions (due to the magic number of the DEX files not being supported by the version of back smali used by Blueseal) and methods whose implementation is not found (like native methods).
 ]
 

3_rasta/6_recommendations.typ

@@ -40,7 +40,7 @@ Good error reporting can allow future users to solve issues encountered using th
 This issue could easily be fixed by changing the filenames used to store the results.
 In contrast, the errors generated by Flowdroid are so opaque that we have no idea how we could solve them.
 
-And at last, an important remark concerns the libraries used by a tool. 
+At last, an important remark concerns the libraries used by a tool. 
 We have seen two types of libraries:
 - internal libraries manipulating internal data of the tool.
 - external libraries that are used to manipulate the input data (APKs, bytecode, resources).

3_rasta/7_limitations.typ

@@ -2,7 +2,7 @@
 
 Some limitations of our approach should be kept in mind.
 
-Our application dataset is biased in favour of Androguard, because Androzoo have already used Androguard internally when collecting applications and discarded any application that cannot be processed with this tool.
+Our application dataset is biased in favour of Androguard, because Androzoo has already used Androguard internally when collecting applications and discarded any application that cannot be processed with this tool.
 
 Despite our best efforts, it is possible that we made mistakes when building or using the tools. 
 It is also possible that we wrongly classified a result as a failure. 

3_rasta/8_future_works.typ

@@ -2,7 +2,7 @@
 #import "X_var.typ": tool_info
 #import "X_lib.typ": ok
 
-== Futur Works <sec:rasta-futur>
+== Future Works <sec:rasta-future>
 
 A first extension to this work would obviously be to study more tools.
 We restricted ourselves to the tools listed by Li #etal, but it would be interesting to compare our result to the finishing rate of recently released tools.
@@ -17,7 +17,7 @@ Such datasets would need to be updated regularly: we saw that there is a trend f
 
 In addition to the finishing rate, it would be both interesting and useful to have reference values.
 @tab:rasta-rec-deps list common Android-related dependencies we encountered when packaging the tools.
-We can see that each tools use at least one of those dependencies.
+We can see that each tool uses at least one of those dependencies.
 It would be reasonable to consider the best finishing ratio a tool can have to be the finishing ratio of a tool that would perform an "empty analysis" using the same dependencies.
 Considering the prevalence of those dependencies, having those theoretical minimums could also guide future tool developers when choosing their dependencies.
 

3_rasta/9_conclusion.typ

@@ -29,5 +29,5 @@ This will allow the research community to use the tools directly without the bui
   In some cases, it was due to our inability to set up the tool correctly.
   Mostly, it was due to the high failure rate when analysing real-world applications.
   Results show that large applications cause more crashes, as do applications with a higher min #SDK target.
-  Goodware also appear to generate more analysis failures than malware.
+  Goodware also appears to generate more analysis failures than malware.
 ])))

3_rasta/main.typ

@@ -21,7 +21,7 @@
   This chapter intends to explore the robustness of past software dedicated to static analysis of Android applications.
   We pursue the community effort that identified software supporting publications that perform static analysis of mobile applications, and we propose a method for evaluating the reliability of this software.
   We extensively evaluate static analysis tools on a recent dataset of Android applications, including goodware and malware, that we designed to measure the influence of parameters such as the date and size of applications.
-  Our results show that #resultunusable of the evaluated tools are no longer usable and that the size of the bytecode and the min #SDK version have the greatest influence on the reliability of tested the tools.
+  Our results show that #resultunusable of the evaluated tools are no longer usable and that the size of the bytecode and the min #SDK version have the greatest influence on the reliability of the tested tools.
 ])))
 
 
@@ -32,5 +32,5 @@
 #include("5_soa_comp.typ")
 #include("6_recommendations.typ")
 #include("7_limitations.typ")
-#include("8_futur_works.typ")
+#include("8_future_works.typ")
 #include("9_conclusion.typ")