diff --git a/relatorio/relatorio.pdf b/relatorio/relatorio.pdf
index 6ddfa02..8ac9745 100644
Binary files a/relatorio/relatorio.pdf and b/relatorio/relatorio.pdf differ
diff --git a/relatorio/relatorio.synctex.gz b/relatorio/relatorio.synctex.gz
index 9aa67a8..9c805f2 100644
Binary files a/relatorio/relatorio.synctex.gz and b/relatorio/relatorio.synctex.gz differ
diff --git a/relatorio/relatorio.tex b/relatorio/relatorio.tex
index 93154f1..3f07f40 100644
--- a/relatorio/relatorio.tex
+++ b/relatorio/relatorio.tex
@@ -21,10 +21,13 @@
 \newpage
 
 \section{Introduction}
-% FAZER EM ENGLISH??? 
+% FAZER EM ENGLISH???  O prof é BR temos que fazer em Brazileiro
 Este trabalho tem como objetivo realizar testes de penetração numa aplicação
 cobaia (o \textit{Juicebox}) desenhada para aprendizagem. 
 
+Este trabalho tem como objetivo utilizar o \textbf{WSTG} (Web security testing guide) e configurar um ModSecurity reverse proxy como uma \textbf{WAF}.
+Para esse fim temos uma aplicação cobaia (o \textit{Juicebox}) desenhada para aprendizagem que vamos utilizar num ambiente controlado para aprender como descobrir vulnerabilidades (aplicando o \textbf{WSTG} e recorrendo ao \textbf{OWASP ZAP}) e prevenir antes do serviço estar online (elaborando uma \textbf{WAF}).
+
 \section{Architecture Considered for Both Stages}
 
 Utilizámos somente duas máquinas virtuais: um servidor a correr \textit{CentOS 9}
@@ -36,11 +39,21 @@ Vão ser realizadas duas etapas de testes: primeiro, sem WAF (\textit{Web Applic
 e com foco em explorar vulnerabilidades na aplicação; e, posteriormente, com uma WAF configurada para 
 mitigar as várias vulnerabilidades que foram encontradas na etapa anterior.
 
+Para simular utilizámos \textit{Virtual Box}, como nos outros projetos, para criar as maquinas virtuais. O cenario que foi criado tem duas máquinas virtuais (servidor e cliente), e ambas as maquinas estão ligadas há mesma rede interna. O servidor vai ser executado numa das maquinas e vai ter o sistema operativo \textit{CentOS 9}, edereço 20.60.0.1, alojar um servidor \textit{Node.js} com o \textit{Juicebox} (a aplicação cobaia) na port 3000 e contém o seviço \textit{Apache} que através do módulo \textit{ModSecurity} funcionará como \textbf{WAF}. O cliente vai ser processado na maquina com o sistema operativo \textit{Kali Linux} e vai ter o edereço 20.60.0.2.
+
+Com o ambiente criado foram realizadas duas etapas de testes:
+\begin{itemize}
+	\item \texttt{Primeira etapa}: Explorar vulnerabilidades na aplicação que existem sem a \textbf{WAF}
+	\item \texttt{Segunda etapa}:Verificar que vulnerabilidades foram mitigadas da primeira etapa com o uso de uma \textbf{WAF} configurada.
+\end{itemize}
+Realisticamente estas etapas podiam continuar a repetir-se, até que estivessemos satisfeitos com o resultado, mas para o fim deste projeto estas etapas serão suficientes.
+
 
 \subsection{Network structure}
 % 10.60.0.0 - rede externa
 % 20.60.0.0 - rede interna
 
+
 \subsection{Servers}
 % 10.60.0.1 - router
 % 20.60.0.2 - client 
@@ -57,6 +70,14 @@ Juicebox no port 3000
 
 Utilizámos a política por omissão (\textit{default policy}) para a realização do \textit{Active Scan} através do OWASP ZAP. Com esta abordagem, obtivemos múltiplos alertas automáticos. De forma a priorizar a análise, selecionámos os cinco alertas principais com base no maior nível de risco e grau de confiança reportados pela ferramenta.
 
+Para conseguir informação inicial realizamos um \textit{Active Scan} através do \textit{OWASP ZAP}, o policy utilizado para esse scan foi \textit{Default Policy}. Foi obtido vários aletas automáticos devido a esse scan e decidimos selecionar os cinco alertas principais com base no nível de risco e grau de confiança reportado pela ferramenta.
+\begin{itemize}
+	\item \textbf{Sql Injection Vulnerability in product search}
+	\item \textbf{}
+	\item \textbf{}
+	\item \textbf{}
+	\item \textbf{}
+\end{itemize}
 Adicionalmente, realizámos testes de infraestrutura e mapeamento de vetores utilizando ferramentas especializadas:
 
 \begin{codeblock}{bash}
@@ -72,6 +93,7 @@ Paralelamente, realizámos uma descoberta de ficheiros e diretórios através de
     \item \texttt{/api-docs}: Documentação e esquemas estruturais da API.
 \end{itemize}
 
+
 \subsection{Configuration and Deployment Management Testing}
 
 \subsubsection*{Enumerate Infrastructure and Application Admin Interfaces}
@@ -188,6 +210,9 @@ sqlmap -u "http://10.60.0.1:3000/rest/products/search?q=apple" -p q --dbms=sqlit
 | sqlite_sequence       |
 +-----------------------+
 \end{codeblock}
+\subsubsection{Testing for SQL Injection}
+
+Apesar de não ter sido detetado pelo active scan foi feito fuzzing nos detalhes de login para saber se estava vulneravel a esse tipo de ataques visto que existia essa vulnerabilidade noutros paremetros. Verificamos que de facto também estava vulneravel a SQL Injection, e que a resposta era a tabela com o
 
 \subsection{Testing for Error Handling}