Add flash-stuff

FFI/ForensInf2_Zusammenfassung.tex

@@ -59,6 +59,61 @@
 		des Beweises $0.66$. Offensichtlicherweise, wenn nun $Prob_1 >> Prob_2$ ist der Beweis sehr
 		stark. Mit der gleichen Logik gilt f\"ur das Nichtvorhandensein von Beweisen das Gegenteil, also
 		das wenn $Prob_3 >> Prob_4$ der Beweis sehr schwach ist.
+    \section{Flash-Speichertechnologie}
+    \subsection{NAND-Flash-Speicherzelle}
+    \noindent \includegraphics[width=\textwidth]{pics/nand-speicherzelle.png}
+    \begin{itemize}
+        \item NAND-Speicher bestehen aus Transistoren
+        \item Durch Oxid-Schicht elektrisch isoliertes Gate, dessen Ladung durch den Quanten-mechanischen Tunneleffekt Auswirkungen hat auf die Source-Drain-Strecke
+        \item Ladung des Gates bewirkt eine Änderung (Erhöhung) der Schwellspannung, bei der der Transistor auf der Source-Drain-Strecke leitend wird.
+        \item Schreiben (Programmieren) der Speicherzelle: das Einbringen von Elektronen auf das Floating Gate (Zustand: logische \enquote{0})
+        \item Löschen der Speicherzelle: das Entfernen von Elektronen von dem Floating Gate (Zustand: logische \enquote{1})
+        \item Lesen einer logische \enquote{0}: die Source-Drain-Strecke ist nicht leitend beim Anlegen einer Spannung oberhalb der \enquote{normalen} Schwellspannung
+        \item Lesen einer logische \enquote{1}: die Source-Drain-Strecke ist leitend beim Anlegen einer Spannung oberhalb der \enquote{normalen} Schwellspannung
+        \item Bei einem Löschzyklus durchtunneln die Elektronen die Oxidschicht. Dafür sind hohe Spannungen erforderlich.
+        \item Dadurch wird bei jedem Löschvorgang die Oxidschicht, die das Floating-Gate umgibt, ein klein wenig beschädigt (Degeneration, \enquote{wear out}).
+        \item nach einer endlichen Anzahl von Schreib- und Löschvorgängen nimmt die Zahl der Elektronen, die die Isolierungsschicht durchqueren können, ab
+        \item Resultat: Schwellspannung beim Lesevorgang zeigt keinen ausreichenden Unterschied, um zwischen 0 und 1 zu unterscheiden.
+        \item Unterscheidung Page vs. Block
+            \begin{itemize}
+                \item Page: kleinste Einheit, die geschrieben werden kann (\"ublich 2-16 KiB)
+                \item Block: kleinste Einheit, die gel\"oscht werden kann (üblich 4-8 MiB)
+                \item Grund: Der Löschvorgang erfordert das Anlegen einer hohen Spannung in mehreren Schritten, die Abschirmung benachbarter Bereiche von Zellen vor ungewollter Beeinflussung sowie das Überprüfen (Lesen) aller Zellen, ob der Löschvorgang erfolgreich war.
+            \end{itemize}
+    \end{itemize}
+
+    \subsection{Flash-Speicherformate}
+    \begin{itemize}
+        \item Solid State Drives (SSDs)
+        \item USB-Sticks
+        \item Speicherkarten
+        \item Wichtige Standards
+            \begin{itemize}
+                \item Multimedia Card (MMC)
+                \item Secure Digital (SD)
+                \item Universal Flash Storage (UFS)
+            \end{itemize}
+    \end{itemize}
+
+    \subsubsection{embedded MMC (eMMC)}
+    \begin{itemize}
+        \item Speichermedium als interner Datenspeicher in mobilen Ger\"aten
+        \item Speicherkarte als Chip, werden in Smartphones verbaut, oft auch als Chip in USB-Speichersticks
+        \item Standardisiert von JEDEC (2015: v.5.1 (JESD84-B51))
+        \item 64 Befehle mit 32 Bit Parameter
+        \item Beispiel TRIM/Secure TRIM seit v.4.4
+            \begin{itemize}
+                \item While it is similar to ATA TRIM, the manufacturer can define what is returned after a read (kein DRAT oder DZAT)
+                \item Secure TRIM muss zus\"atzlich sofort ausgef\"uhrt werden und kann nich delayed werden
+                \item More similar to ATA TRIM is \enquote{discard} (since v.4.5) (Habe nichts gefunden was diese Behauptung st\"utzt)
+            \end{itemize}
+        \item eMMC Chips werden of recycelt, z.B. Handy-Speicher wiederverwendet in USB-Sticks
+        \item Je nach Standard ist sicheres L\"oschen der Daten vorher m\"oglich
+        \item Nicht alle Hersteller f\"uhren sicheres L\\"oschen auch durch
+        \item $->$ Daten k\"onnen wiederhergestellt werden
+    \end{itemize}
+
+
 	\section{Live-Analyse}
 		\subsubsection*{Fl\"uchtige Spuren}
 			\begin{itemize}
@@ -97,11 +152,24 @@
 				\item Aktivit\"aten m\"ussen dokumentiert werden (z.B. Videoaufzeichnungen)
 				\item System kann sich wehren (bei Nutzung des Betriebssystemes sowieso, aber im
 				schlimmesten Fall auch die Hardware)
-				\item einige, z.B. Rootkits, k\"onnen im laufenden Betrieb nicht zuverl\"assig erkannt werden
-
+				\item Einige, z.B. Rootkits, k\"onnen im laufenden Betrieb nicht zuverl\"assig erkannt werden
+                \item Nur ein Versuch, keine Wiederholung, deshalb evtl. Videoaufzeichung oder Vier Augen-Prinzip
 			\end{itemize}
 		\subsubsection*{Sniffing}
 		Mitlesen des Netzwerkverkehrs, nur schwer bis gar nicht durch Maleware manipulierbar, allerdings Verschl\"usselung m\"oglich, was wiederum bedeutet, dass nur Metadaten gesammelt werden k\"onnen.
+        \begin{itemize}
+            \item LAN-Sniffing
+                \begin{itemize}
+                    \item Mirror/Monitorport am Switch/Router
+                    \item LAN/Ethernet Tabs
+                    \item Switch-Jamming oder ARP-Spoofing
+                \end{itemize}
+            \item WLAN-Sniffing
+                \begin{itemize}
+                    \item Aufsp\"uren von Netzen: Aktiv (Probe-Request), Passiv (Monitor-Mode)
+                    \item Sniffing von Traffic in verbundenem (evtl. verschl\"usseltem) Netz: Promiscuous Mode
+                \end{itemize}
+        \end{itemize}
 		\subsection{Hauptspeichersicherung}
 		\begin{itemize}
 			\item eingesetzte Werkzeuge sollen System nicht ver\"andern (Integrit\"at)
@@ -118,12 +186,21 @@
 		\subsubsection*{Technische M\"oglichkeiten}
 		\noindent \includegraphics{pics/RAM-Sicherung.png}
 		\begin{itemize}
-			\item Crashdumps unter Windows
-			\item Modul Hijacking unter Linux
-			\item Linux-sysfs (/dev/mem)
-			\item Fireware/DMA/Hardware allgemein
-			\item Snapshot bei VM
-			\item Linux /dev/mem ist etwas broken kriegt man aber mit kernel-modules gebacken
+            \item Hardware (DMA)
+                \begin{itemize}
+                    \item Vorteil: Keine Interaktion mit dem OS, Int\"agrit\"at des RAMs wird gewahrt
+                    \item Nachteil: Braucht Hardware-Zugriff
+                    \item Meist Zugriff auf DMA-f\"ahigen Bus
+                    \item z.B. Tribble (PCI card) oder FireWire bus
+                \end{itemize}
+            \item Software
+                \begin{itemize}
+                    \item Linux-sysfs (/dev/mem) + Data Dumper (dd)
+                    \item Linux /dev/mem ist etwas broken kriegt man aber mit kernel-modules gebacken
+                    \item Crashdumps unter Windows
+                    \item Modul Hijacking unter Linux
+                    \item Snapshot bei VM (Nur bei VMs)
+                \end{itemize}
 		\end{itemize}
 		Aus dem Hauptspeicher-Abbild kann der Systemzustand nachvollziehbar rekonstruiert werden oder
 		einfach nach \textit{strings} oder \textit{magic-bytes} gesucht werden.
@@ -137,15 +214,11 @@
 			aber vielleicht trotzdem noch interessanten) Speicherseiten
 		\end{itemize}
 		\subsubsection*{Dotplot}
-		Die meisten Fehler in forensischen Tools sind systematischer Natur, die Leute die dieses Paper
-		oben geschrieben haben, haben effektiv jede Speicherseite gehasht und dann, die Hashes der
-		Speicherseiten an X/Y-Achse aufgetragen und alle identischen \textit{('\"ahnlichen')} Felder
-		schwarz markiert.\\\\
-		Dass zwei Seiten im Speicher die gleiche SHA-Sum haben, kann eigentlich (0er und 1er-Seiten
-		weggefiltert) nicht sein/ist sehr
-		unwahrscheinlich. Das bedeutet, wenn zwei Seiten den gleichen Hash haben aka, schwarz sind,
-		muss das Tool in irgendeiner Weise daf\"ur verantwortlich sein - z.B. weil das \textit{dd}, die
-		Daten die es aus /dev/mem liest, cached, und dann gleich nochmal aus dem Hauptspeicher liest.
+		Die meisten Fehler in forensischen Tools sind systematischer Natur.
+        Die Autoren des Papers haben effektiv jede Speicherseite gehasht und die resultierenden Hashes an X/Y-Achse aufgetragen und alle identischen \textit{('\"ahnlichen')} Felder schwarz markiert.\\\\
+		Der Fall dass zwei Seiten im Speicher die gleiche SHA-Sum haben kann eigentlich (0er und 1er-Seiten weggefiltert) nicht sein bzw. ist sehr unwahrscheinlich.
+        Das bedeutet, wenn zwei Seiten den gleichen Hash haben aka schwarz sind, muss das Tool in irgendeiner Weise daf\"ur verantwortlich sein.
+        Das Tool \textit{dd} zum Beispiel cached die aus dem Hauptspeicher gelesenen Daten und schreibt diese somit ein zweites mal in den Hauptspeicher.
 		\textbf{Long story short: Nutzlose, aber ganz lustige Spielerrei um Probleme mit forensischen
 		Tools die das System beeinflussen zu zeigen. Pr\"adikat 'nicht lesenswert'.}
 		\subsubsection*{Evalution von Live-Analyse Techniken}
@@ -153,7 +226,7 @@
 			\item zwei identische VMs aufsetzen und Speicher in festen Abschnitten dumpen
 			\item m\"ogliche Unterschiede beider VMs ohne Interaktion \"uberpr\"ufen (vorhanden aber
 			gering)
-			\item auf der einen Live-Analyse starten auf der anderen nicht -> Unterschied = Impact der
+			\item auf der einen Live-Analyse starten auf der anderen nicht $->$ Unterschied = Impact der
 			Untersuchung
 			\item suprise, Unterschiedliche Tools, unterschiedlich viel Impact
 		\end{itemize}