fix 'typos' (yesss, they are definitely typos)

2_background/3_problem_statements.typ

@@ -3,36 +3,36 @@
 
 == Problems of the Reverse Engineer <sec:bg-probl>
 
-In this section, we will develop some issues encontered by reverse engineer, and link them to our problem statements.
+In this section, we will develop on some issues encountered by reverse engineers, and link them to our problem statements.
 
 In the previous section, we listed some limitations to static analysis.
-Some limitations have been known for some time now, and many contributions have been made to been made to overcome them.
-Those contribution often introduce new tools that implements solutions to those different issues.
-Depending on the situation, a reverse engineer might want to use those tools, or build another tool on top of one.
+Some limitations have been known for some time now, and many contributions have been made to overcome them.
+Those contributions often introduce new tools that implement solutions to those different issues.
+Depending on the situation, a reverse engineer might want to use those tools or build another tool on top of one.
 Unfortunately, they can be hard to use.
 And like we said previously, the fast evolution of Android can be a significant obstacle.
-The combinaison of those two point can lead a reverse engineer to spend a lot of time trying to use a tool without realising that tools does not work anymore.
+The combination of those two points can lead a reverse engineer to spend a lot of time trying to use a tool without realising that the tool does not work anymore.
 Our first problem statement #pb1 focuses on this issue: #pb1-text
-Determining which tools are still usable today is a first step, but finding out what reasons make a tool stop working might help writing more resilient tools in the futur.
+Determining which tools are still usable today is a first step, but finding out what reasons make a tool stop working might help write more resilient tools in the future.
 
-We also presented dynamic code loading an obstacle for static analysis.
+We also presented dynamic code loading as an obstacle for static analysis.
 Code loading is achieved using class loader objects, causing class loaders to be generally associated with dynamic code loading.
 However, class loading plays a much more important role in the #ART.
-Class loading originate from the Java ecosystem, and was ported to Android so that developers could keep writting application in Java.
-Despit that, Android made a lot of change to the original Java classes, and did not document those changes.
-Between static analysis general oversight of class loading, relegating it to dynamic analysis, and the lake of documentation of the actual behaviour of the #ART, the question of the impact of the class loading algorithm on static analysis can be ask.
+Class loading originates from the Java ecosystem and was ported to Android so that developers could keep writing applications in Java.
+Despite that, Android made a lot of changes to the original Java classes and did not document those changes.
+Between static analysis, general oversight of class loading, relegating it to dynamic analysis, and the lake of documentation of the actual behaviour of the #ART, the question of the impact of the class loading algorithm on static analysis can be asked.
 Our second problem statement #pb2 aims to anwser this question: #pb2-text
 
 Circling back to known limitations of static analysis, dynamic code loading and reflection are often used to obfuscate applications.
-Dynamic code loading allows to hide bytecode from static analysis with relativelly low effort.
-The bytecode can downloaded at runtime, stored in the application encrypted, hidden inside other files, generated at runtime, etc.
-In a way, reflection allows to do the same thing, but for specific method calls: instead of the actual call, static analysis will see a call to the generic `Method.invoke()` method.
-By contrast, it is relatively easy to find those the name of the method called or to intercept dynamically loaded bytecode using dynamic tools like Frida.
-The issue that arrise then is what to do with the collected data.
+Dynamic code loading allows hiding bytecode from static analysis with relatively low effort.
+The bytecode can be downloaded at runtime, stored in the application encrypted, hidden inside other files, generated at runtime, etc.
+In a way, reflection can do the same thing, but for specific method calls: instead of the actual call, static analysis will see a call to the generic `Method.invoke()` method.
+By contrast, it is relatively easy to find the name of the method called or to intercept dynamically loaded bytecode using dynamic tools like Frida.
+The issue that arises then is what to do with the collected data.
 Simply having it greatly helps a manual analysis, but it cannot be used directly by tools that perform static analyses.
 There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls for most tools.
-This means that in most cases, when a reverse engineer wants to improve static analysis with dynamic analysis, they need to modify the static tools to receive the additionnal runtime data.
+This means that in most cases, when a reverse engineer wants to improve static analysis with dynamic analysis, they need to modify the static tools to receive the additional runtime data.
 Doing so requires both time and knowledge of the internals of the tools used.
-Our third problem statement, #pb3, explore an alternative aproach that modify the application instead of the tool: #pb3-text
+Our third problem statement, #pb3, explores an alternative approach that modifies the application instead of the tool: #pb3-text
 
-We will now explore the current state of the art for relevent contributions related to our problem statements.
+We will now explore the current state of the art for relevant contributions related to our problem statements.