# HG changeset patch
# User Christian Urban <christian dot urban at kcl dot ac dot uk>
# Date 1416616649 0
# Node ID 6e4e9bdedf7b436ad2a3583629b39c07a5b6ea31
# Parent  48c6751f2173f9517c5494342640ee7599ba8203
updated

diff -r 48c6751f2173 -r 6e4e9bdedf7b handouts/ho03.pdf
Binary file handouts/ho03.pdf has changed
diff -r 48c6751f2173 -r 6e4e9bdedf7b handouts/ho03.tex
--- a/handouts/ho03.tex	Fri Nov 21 22:21:30 2014 +0000
+++ b/handouts/ho03.tex	Sat Nov 22 00:37:29 2014 +0000
@@ -301,7 +301,7 @@
 would just not work. Had the designers of C had just been able
 to foresee what headaches their way of arranging the stack
 caused in the time where computers are accessible from
-everywhere. 
+everywhere?
 
 What the outcome of such an attack is can be illustrated with
 the code shown in Figure~\ref{C2}. Under ``normal operation''
@@ -666,7 +666,7 @@
 under an Ubuntu version ``Maverick Meerkat'' from October 
 2010 and the gcc 4.4.5. I have not tried whether newer versions
 would work as well. I tested all examples inside a virtual 
-box\footnote{https://www.virtualbox.org} insulating my main 
+box\footnote{\url{https://www.virtualbox.org}} insulating my main 
 system from any harm. When compiling the programs I called 
 the compiler with the following options:
 
@@ -688,16 +688,15 @@
 stack executable, thus the the example in Figure~\ref{C3}
 works as intended. While this might be considered
 cheating....since I explicitly switched off all defences, I
-hope I was able convey that this is actually not too far
-from realistic scenarios. I have shown you the classic version
-of the buffer overflow attacks. Updated variants do exist.
-Also one might argue buffer-overflow attacks have been
-solved on computers (desktops or servers) but the computing
-landscape of nowadays is wider than ever. The main problem
-nowadays are embedded systems against which attacker can 
-equally cause a lot of harm and which are much less defended
-against. Anthony Bonkoski makes a similar argument in his 
-security blog:
+hope I was able convey that this is actually not too far from
+realistic scenarios. I have shown you the classic version of
+the buffer overflow attacks. Updated variants do exist. Also
+one might argue buffer-overflow attacks have been solved on
+computers (desktops or servers) but the computing landscape of
+nowadays is wider than ever. The main problem nowadays are
+embedded systems against which attacker can equally cause a
+lot of harm and which are much less defended. Anthony Bonkoski
+makes a similar argument in his security blog:
 
 \begin{center}
 \url{http://jabsoft.io/2013/09/25/are-buffer-overflows-solved-yet-a-historical-tale/}