diff --git a/paper.pdf b/paper.pdf
index 1047350..6e4d505 100644
Binary files a/paper.pdf and b/paper.pdf differ
diff --git a/paper.tex b/paper.tex
index bfdc8f1..892a4aa 100644
--- a/paper.tex
+++ b/paper.tex
@@ -42,7 +42,7 @@
 \begin{document}
 \title{Overview of IoT Fuzzing Techniques}
 \author{\IEEEauthorblockN{Tuan-Dat
-    Tran\\\small(3012345)}\\\IEEEauthorblockA{University of
+    Tran\\\small(3030462)}\\\IEEEauthorblockA{University of
     Duisburg-Essen\\tuan-dat.tran@stud.uni-due.de}}
 
 \maketitle
@@ -179,10 +179,10 @@ In this section, we are going to create an overview of different IoT fuzzers, li
       Firm-AFL\cite{firmafl}      & Greybox   & Firmware         & Mutation \newline Augmented Process Emulation* & Emulation\\\midrule
       Snipuzz\cite{snipuzz}       & Blackbox  & API & Snippet-based mutation*\newline & Network Monitor  \\\midrule
       Firmcorn\cite{firmcorn}     & Greybox   & Firmware & Optimal virtual execution*\newline Vulnerability-oriented fuzzing*& Instrumentation \\\midrule%Memory corruption check \& Exception detection
-%      FirmFuzz\cite{firmfuzz}     & Greybox   & Web Interface & Generational\newline & \\ \midrule
+      % FirmFuzz\cite{firmfuzz}     & Greybox   & Web Interface & Generational\newline & \\ \midrule
       Diane\cite{diane}           & Blackbox  & Companion App  & Mutation &  Active probing\\\midrule
       HFuzz\cite{hfuzz}           & Greybox   & Network protocol & Message Structure Tree*& Instrumentation \\\midrule
-%      IoTHunter\cite{iothunter}   & Greybox   & Network protocol & Multi-level message generation* &                 \\
+      % IoTHunter\cite{iothunter}   & Greybox   & Network protocol & Multi-level message generation* &                 \\
       WMIFuzzer\cite{wmifuzzer}   & Blackbox  & Web Interface & Mutation & Network Monitor\\
       \bottomrule
     \end{tabularx}  
@@ -202,7 +202,7 @@ Message Structure Tree is a mutational fuzzing technique where the valid input i
 Binary rewriting can be used to add instrumentation to firmware\cite{crash}. Instrumentation can be used to e.g.\ add hooks to specific functions. This is interesting for fuzzing once instrumentation is added to internal exceptions to check for crashes or otherwise unexpected behavior\cite{firmcorn}. To perform binary rewriting disassembly of the firmware is necessary, which requires partial decompilation. An additional challenge is the missing room for additional instrumentation due to embedded devices being optimized for their memory usage\cite{crash}.
 \subsection{Full Emulation}
 Emulation tackles the problems of throughput and scalability in IoT fuzzing. This is done by improving the performance, success rate and hardware-indipendance of fuzzers\cite{snipuzz}. Full emulation of the firmware with the help of heuristics mitigates the lack of fault detection and increases accuracy of found vulnerabilities to a level of desktop system application fuzzers. Additionally emulation based fuzzing provides the possibility to repeat test cases and their executions to further analyze specific test runs\cite{panda}.
-%
+% 
 Often third party developers lack details of the device to implement good emulator. This makes building emulator requiring huge amounts of manual effort\cite{crash}. This is due to IoT devices being heavily dependent on their hardware\cite{firmafl}.
 \subsection{Partial Emulation}
 Partial emulation can lead to accurate vulnerability detection with decreased performance in comparison to full emulation, but possibly better performance than fuzzing the physical device, since it makes the fuzzing process more scalable\cite{crash}. Partial emulation is done by only emulating parts of the firmware or its peripheral devices.
@@ -214,13 +214,13 @@ This technique used by Firmcorn\cite{firmcorn} executes firmware instructions in
 A technique used to increase code coverage by using symbols as input and tracking manipulations and comparisons of them during runtime\cite{avatar}. The usage of the input is then backtracked to solve the constraints of specific code branches if a desired state is reached. Symbolic execution has the problem of path explosions and constraint solving, which poses as an obstacle to scalability\cite{angora}. Path explosions is the exponential increase of code branches the larger the program is. A part of this problem are possible infinite loops. Constraint solving can pose another challenge, since depending on ``how deep'' the programs tracking goes, the calculation of the constraints of a specific branch can be complex.%\textbf{citation needed}.
 \subsection{Liveness Check}
 By checking for liveness a fuzzer can determine the state of an IoT device. This is done actively by sending regular heartbeat messages to the device or passively by checking for expected responses of the IoT device.
-%
+% 
 Liveness checks may cause timeouts to be detected as crashes, which slows down fuzzing. Omitting active liveness check improves performance, since probing packages aren't sent, which make up a certain percentage of traffic that do not contribute to the detection of vulnerabilities during the fuzzing process.
 \subsection{Taint analysis}
 Taint analysis is used to track data of interest during execution. The data that is being tracked is called taint source. IoTFuzzer\cite{iotfuzzer} uses taint analysis to track e.g.\ user input to find out which input influences network messages sent to the analyzed IoT device.
 \subsection{Stateful Message Generation}
 This technique was introduced by SIoTFuzzer\cite{siotfuzzer} which fuzzes web interfaces of IoT devices. Stateful Message Generation (SMG) is divided into three parts: front-end analysis, state analysis and seed generation. 
-%
+% 
 SMG considers that communication depends on certain states and therefore groups together messages as a test case to fuzz the target system. So far SMG is only used to fuzz web interfaces in SIoTFuzzer\cite{siotfuzzer}.
 \subsection{Vulnerability-oriented fuzzing}
 Vulnerability-oriented fuzzing is used in Firmcorn\cite{firmcorn}. For this method, static analysis is used to find vulnerable code. Vulnerable code is determined by multiple factors like, complexity, number of memory operations and call to sensitive functions. 
@@ -232,7 +232,7 @@ Since only a fraction of firmware code has vulnerabilities the graybox approach
 
 \section{Conclusion}
 In this paper we created an overview of the different IoT fuzzing techniques used by state of the art IoT fuzzing tools and compared their approaches in regards to input generation, crash detection heuristics and their device scopes.
-%
+% 
 The IoT fuzzer we looked at, utilized many techniques to make use of many attack surfaces and even used software outside the IoT devices themselves to gain information about the device, like IoTFuzzer\cite{iotfuzzer} which used the devices companion app to send fuzzing messages to the tested device.
 \printbibliography{}