Last fixes

inc/2.dynamorio.tex

@@ -10,13 +10,13 @@ The explained topics are mainly based on the chapters \textit{``DynamoRIO''}, \t
 \revabbr{Dynamic binary instrumentation}{DBI} is a method to analyze, profile, manipulate and optimize the behavior of a binary application while it is executed.
 This is achieved through the injection of additional instructions into the instruction trace of the target application, which either accumulate statistics or intervene the instruction trace.
 
-In comparison, debuggers use special breakpoint instructions (e.g. INT3 on x86 or BKPT on ARM) that are injected at specific places in the code, raising a debug exception when reaching it.
+In comparison, debuggers use special breakpoint instructions (e.g., INT3 on x86 or BKPT on ARM) that are injected at specific places in the code, raising a debug exception when reaching it.
 At those exceptions a context switch to the operating system kernel will be performed.
 However, those context switches result in a significant performance penalty as the processor state has to be saved and restored afterwards, making it less efficient than DBI.
 
 DBI tools can either invoke the target application by themselfes or are attached to the application's process dynamically.
 The former method allows instrumentation of even the early startup stage of the application whereas the latter method might be used if the application has to be first brought into a certain state or the process cannot be restarted due to reliability reasons.
-Some DBI tools also allow to directly implement the DBI framework into the applications source code.
+Some DBI tools also allow to directly integrate the DBI framework into the applications source code.
 While this eliminates the flexibility of observing applications that are only available in binary form, it enables the control over the DBI tool using its application interface.
 With this method, it is possible to precisely instrument only a specific code region of interest and otherwise disable the tool for performance reasons.
 
@@ -87,7 +87,7 @@ Client code should also not alter the application stack in any way, as some spec
 Alternatively, DynamoRIO provides a separate stack that should be used instead to store temporary data.
 To remain undetected, it is also required for DynamoRIO to protect its own memory from malicious reads or writes from the application.
 Those should, like in the native case, raise an exception as unallocated data is accessed.
-However, as these memory regions are actually allocated, DynamoRIO has to produce those execption itself to remain transparent.
+However, as these memory regions are actually allocated, DynamoRIO has to produce those exceptions itself to remain transparent.
 When the application branches to a dynamically calculated address, DynamoRIO has to translate this address to the corresponding address of the basic block in the code cache.
 But also in the backward case, whenever a code cache address is exposed to the application, it has to be converted back to the corresponding address to the mapped address region of the binary executable.
 
@@ -110,9 +110,9 @@ So the required instructions have to be inserted into the basic block instructio
 Table \ref{tab:dynamorio_api} lists some of the most important hooks that a client can implement.
 
 \begin{table}
-\caption{Client routines that get called by DynamoRIO \cite{Bruening2003}.}
+\caption[Client routines that are called by DynamoRIO.]{Client routines that are called by DynamoRIO \cite{Bruening2003}.}
 \begin{center}
-\begin{tabular}{|p{0.55\linewidth} | p{0.35\linewidth}|}
+\begin{tabular}{|p{0.6\linewidth} | p{0.4\linewidth}|}
  \hline
  Client Routine             & Description\\
  \hline