FINAL PROJECT Dean Kay

INVESTIGATING REMOTE AND AUTOMATED ATTACK VECTORS
USING A MICROCOMPUTER FROM INSIDE A KNOWN NETWORK.
By

DEAN KAY

A DISSERTATION

Submitted to

in partial fulfilment of the requirements
for the degree of
BSc Computer Networks and Security
BATCHELOR OF SCIENCE

2015/2016

Abstract

INVESTIGATING REMOTE AND AUTOMATED ATTACK VECTORS
USING A MICROCOMPUTER FROM INSIDE A KNOWN NETWORK.
By

DEAN KAY

As the Internets’ users, devices and volumes of data expand at an ever increasing and
exponential rate, the security, authenticity, confidentiality and integrity of the data being
exchanged worldwide presents the risk of data being stolen, misused or lost. One form of
prevention to this risk of data breach occurring is to have an organisations network security
audited by a penetration tester. Penetration testing is often a high cost service which will
undoubtedly start with a reconnaissance of the network under examination. This report asks
the question; Using off the shelf hardware, is it possible to build an automated network
reconnaissance device and in completion how long can the device remotely operate on
battery power.

DECLARATION
I hereby certify that this dissertation constitutes my own product, that where the language of
others is set forth, quotation marks so indicate, and that appropriate credit is given where I
have used the language, ideas, expressions or writings of another.
I declare that the dissertation describes original work that has not previously been presented
for the award of any other degree of any institution.
DEAN KAY

“This dissertation contains material that is confidential and/or commercially sensitive. It is
included here on the understanding that this will not be revealed to any person not involved in
the assessment process”.

ACKNOWLEDGEMENTS
I would like to take this opportunity to acknowledge and thank my friends and family that have
supported me throughout my studies at the University of Bolton. I would also like thank Dr.
Robert Campbell for his support and advice as my project supervisor during the final year of
study.

Table of Contents
Chapter 1. Introduction ............................................................................................................... 4
1.1 Aim ................................................................................................................................................... 4
1.2 Motivation ........................................................................................................................................ 4
1.3 Objectives ......................................................................................................................................... 5
1.4 Further Project Enhancements Opportunities ................................................................................. 6
1.5 Project Plan ...................................................................................................................................... 7
1.5.1 Original Project Timeline ........................................................................................................... 8
1.6 Milestones ........................................................................................................................................ 9
Chapter 2. Background and Review of Literature ...................................................................... 10
2.1 Related Work .................................................................................................................................. 12
2.2 Literature ........................................................................................................................................ 12
Chapter 3. Methodology ............................................................................................................ 13
3.1 Hardware ........................................................................................................................................ 13
3.1.1 Microcomputer ........................................................................................................................ 14
3.1.2 Screen and keypad input ......................................................................................................... 15
3.1.3 Wireless network interface ...................................................................................................... 15
3.1.4 Secondary Ethernet interface .................................................................................................. 16
3.1.5 Battery pack ............................................................................................................................. 16
3.1.6 Project financial cost ............................................................................................................... 17
3.2.1 Operating system .................................................................................................................... 17
3.2.2 Programming languages ......................................................................................................... 18
3.2.3 Nmap ....................................................................................................................................... 19
3.2.4 Reverse AES HTTP Shell ............................................................................................................ 19

Chapter 4. Design and Implementation ..................................................................................... 20
4.1 Hardware construction ................................................................................................................... 20
4.2 Software Implementation .............................................................................................................. 21
4.2.1 LCD Menu system .................................................................................................................... 22
4.2.2 Reverse shell ............................................................................................................................ 22
4.2.3 Port Scan and Report ............................................................................................................... 23
4.2.4 Anonymous Inline Ethernet packet capture ............................................................................. 24
4.2.5 Battery Timer script ................................................................................................................. 26
4.3 Problems faced ............................................................................................................................... 27
4.3.1 Port Security ............................................................................................................................ 27
4.3.2 Stateful Firewalls ..................................................................................................................... 28
4.3.3 IDS/IPS Systems ....................................................................................................................... 28
4.4 Inline Ethernet packet capture Investigation ................................................................................. 29
4.4.1 Battery life testing ................................................................................................................... 29
4.4.1 Hardware testing ..................................................................................................................... 30
Chapter 5. Results and Discussion .............................................................................................. 32
5.1 Complete battery depletion test results ........................................................................................ 32
5.2 Hardware utilisation test results .................................................................................................... 33
5.3 Additional findings ......................................................................................................................... 35
5.3.1 Ease of development ............................................................................................................... 35
5.3.2 Development time ................................................................................................................... 36
5.3.3 The level of skills required to do the project ............................................................................ 36
5.3.4 Risk factors for organisations .................................................................................................. 36
5.3.5 How easy was it to find information on this? .......................................................................... 37
5.3.6 How technically in depth is the programming code ................................................................ 37

Chapter 6. Conclusion ................................................................................................................. 38
6.1 Lessons Learned ............................................................................................................................. 38
6.2 Future Activity ................................................................................................................................ 39
Bibliography and References ...................................................................................................... 40
Appendices ................................................................................................................................. 43

1

LIST OF TABLES
Table 1. Battery life results ..................................................................................................... 32

LIST OF FIGURES
Figure 1. Original Project Timeline ........................................................................................... 8
Figure 2. Project Financial Costs ............................................................................................. 17
Figure 3. Diagram of reverse shell topology (source: Infosecinstitute.com, 2016 ) ............... 19
Figure 4.Hardware construction start .................................................................................... 20
Figure 5. Hardware construction Finish ................................................................................. 21
Figure 6. Nmap command breakdown ................................................................................... 23
Figure 7. Port scan function code ........................................................................................... 23
Figure 8. Inline Ethernet packet capture conceptual design .................................................. 24
Figure 9. Inline Ethernet packet capture physical design ....................................................... 24
Figure 10. Inline Ethernet packet capture script .................................................................... 25
Figure 11. Battery timer script ............................................................................................... 26
Figure 12. Logical diagram of battery life test ........................................................................ 30
Figure 13. Hardware utilisation test diagram ......................................................................... 31

2

Figure 14. Bar chart of battery life results .............................................................................. 33
Figure 15. Memory cache utilisation ...................................................................................... 34
Figure 16. System interrupt information ................................................................................ 35

LIST OF ACRONYMS

AES - Advanced Encryption Standard
ACL – Access Control Lists
BASH - Bourne Again Shell
CPU – Centralised Processing Unit
FTP – File Transfer Protocol
GPIO – General purpose Input Output
GSM – Global System for Mobile communications
HTTP – HyperText Transfer Protocol
I/O – Input / Output
IMAP – Internet Message Access Protocol
MAC – Media Access Control

3

Mbps – Megabit per second
NNTP – Network News Transfer Protocol
RAM –Random Access Memory
SMTP – Simple Mail Transfer Protocol
WEP – Wired Equivalent Privacy

4

Chapter 1.
Introduction

1.1 Aim
The aim of the project is to build a device using off the shelf miniaturised single board
computing hardware, for the purpose of exploring possible automated reconnaissance
attacks. The Device must be modular allowing it to be configured and utilised dynamically,
depending on the environment it is to be used within and also be mobile powered via a
battery power pack. It will also utilise a physical keypad input and on board display allowing
pre-programmed automation to be triggered.
The aim is to discover whether or not the project is possible with the use off the shelf
hardware and also the length of time it can be being deployed remotely using only a battery
pack.

1.2 Motivation
Due to the multiple redundant miniaturised single computing devices that were already in
personal possession, plus the keen interest in the study of network security alike. The project
of this category seemed to automatically come to light, when the process of deciding on a
project was in order. Upon review of literature, it became apparent that there had not been

5

much academic research done in the particular area of study. The only area which had any
substance, was that of the niche market selling commercially branded products, though these
where typically non physically modular devices allowing no physical alteration to the device,
and of a high financial cost. As a result of the the findings, the project was subsequently
aimed towards the possibility of designing a low cost alternative to the few existing
commercial products. Which would allow features similar to that of the commercial products,
potentially using higher performance hardware and the open possibility of modularity.

1.3 Objectives
The projects main objectives were as follows:
• Design and build a miniaturised single board computing device for the purpose of
network reconnaissance, integrating an on-board keypad and display unit.
• Compile code which will interact with the on-board keypad and display unit for the
purpose of automating reconnaissance attacks.
• Test the successfully compiled automated attacks against factors such as battery life.
Target requirements that where discussed and agreed upon with project supervisor are as
follows:
• Research all the various network attack vector that are possible, given the authors
level of knowledge surrounding the network security field.

6

• Run several tests on the battery, while the device performs a network reconnaissance
under various network loads. Once tests are complete, run further tests on the
hardware utilisation on the device under several more network loads.
• Draw a correlation between the network load and hardware utilisation when
undergoing a reconnaissance attack, allowing a forward projection of battery life on
a given load.

1.4 Further Project Enhancements Opportunities
Further project enhancements opportunities are as follows:
i. Implement an encrypted reverse http shell for back door into target network, using
the on-board physical keypad input.
ii. implement an automated port scan for a target network producing a report for later
analysis, using the on-board physical keypad input.
iii. Implement an automated anonymous inline Ethernet packet capture that will write
the information to a local file for later analysis, using the on-board physical keypad
input.
iv. Implement an automated wireless tool to crack the WEP security algorithm and
deposit the encryption key to a local file for later use, using the on-board physical
keypad input.
v. Overcome the network defence of switch port security, with an automated pre
programmable MAC spoofing script.

7

1.5 Project Plan
This project began with a considerable amount of time focusing on the background research
and review of literature surrounding the area of microcomputers and remote automations.
Although the literature was scarce, some of the concepts that where being studied followed
the same principles, helping provide a fundamental knowledge around the subject.
Given the LCD screen and keypad input relied on Python libraries for their interaction with
the Raspberry Pi, a basic course on the ‘Introduction to Python’ was completed giving the
author the basic knowledge in the programming language, allowing the coding of
automations in the project.
Additional research was directed at software which could test the hardware utilisation and
battery life of the device under test network loads.

8

1.5.1 Original Project Timeline
FIGURE 1. ORIGINAL PROJECT TIMELINE
DATE: 21
ST

SEPTEMBER
24
TH

NOVEMBER
21
ST

JANUARY
3
RD

FEBRUARY
12
TH

APRIL
20
TH

APRIL
28
TH

APRIL
6
TH

MAY
BACKGROUND
RESEARCH

LITERATURE
REVIEW

SOURCING
HARDWARE

SOURCING
SOFTWARE

POSSIBLE ATTACK
VECTORS

DESIGN AND
IMPLEMENTATION

TESTING
DATA ANALYSIS
FINAL REPORT

The original project timeline that was planned was very ambitious and in retrospect not
realistic, focus on the length and complexity of procedures was not taken seriously when
determining the project timeline. Also, various parts of the project where vastly
underestimated in terms of timescale, therefore delaying the parts that where based on the
successful completion of the previous tasks.
Additionally, the lack of technical knowledge and experience in various technologies
throughout the project, partnered with several issues concerning the python-modules that
where a fundamental and integral part of the hardware interaction. Delayed the projects
timeline even further in key areas of the build.
Due these influences, a revised project timeline was not prepared.

9

1.6 Milestones

When the project was initiated there was various milestones set, these where set by
the author, and as the project took course and supervisory meetings where made to discuss
the projects progression. The project was given additional milestones that would run in
conjunction with the original existing set.
The milestones that where set where as follows:
• Complete free introduction to Python course online.
• Source low cost hardware for device.
• Source free and open-source software for device.
• Decide upon the test environment to be used.
• Attend regular supervisory meetings

10

Chapter 2.
Background and
Review of Literature

As the Internets’ users, devices and volumes of data expand at an ever increasing and
exponential rate, the security, authenticity, confidentiality and integrity of the data being
exchanged worldwide is taken for granted as a civil expectation, similar to that of a physical
asset such as a person's passport or driving license. However, recurring news headlines and
official public disclosures of personal data security breaches and network hacking across the
world have proven this expectation to be of a false nature. This new and fast-moving era of
technology and communication, as brought the demand for multiple new professions in order
to safely secure the digital data of users, groups and corporations alike. One profession that
has arisen from this evolution in the exchange of digital resources across society, is that of
the network penetration tester. The responsibility of the modern day network penetration
tester is to embrace the immense challenge of assessing the existing cyber security placed
upon one's local or wide-area network by network and systems administrators. Focusing both
from the defence of internally orchestrated attacks (incidents originating from within the
local network of which is under security audit) and externally coordinated attacks (incidents
initiated from outside the local network with the intention to gain access to the local
network). In order for a networks’ security to be extensively tested, it has become accustom

11

for a penetration-tester to act in the manner of a rogue party. Allowing the penetration-tester
to think and operate like an attacker would, therefore granting them the necessary
knowledge in the prevention of potential attacks. Penetration-testers will try a plethora of
techniques in order to break the security of a computers network. These are referred to as
‘attack vectors’ and as the creative minds of a rogue parties devise various new methods of
exploiting known and unknown vulnerabilities within a networks security, so does the that of
the penetration-testers. Performing this type of network security assessment is a necessary
step toward the defence of the public and private data stored within the associated network.
In addition to this evolution in technological communications and security there has also
been substantial developments in the miniaturization and processing power of computer
hardware on the computer platform itself. Computers were once thought as big, bulky
systems and with the sale of a so called 'portable computer' in 1975, the IBM 5100 weighing
in at around 50 pounds, offering 16Kilobyte of storage for a price tag upward of $8,975 (IBM,
2016). It is clear to see the technological advancements made within the industry, as one can
now buy an inexpensive $25 Raspberry Pi 2 miniature computer the size of a credit card with
a multiple core processor, a gigabyte of RAM and expandable storage upwards of 100GB+
(Raspberry Pi, 2016). These relatively inexpensive computing systems allow people of all ages
and backgrounds to explore computing, specifically targeting educational facilities. It has
also prompted many hobbyists to build a multitude of projects ranging from home
automation systems collaborating a Raspberry Pi with a collection of sensors, to major
projects such as the Astro-Pi, a Raspberry Pi fitted with various sensors and that was set into
space in order to conduct numerous experiments (Astro-Pi, 2016).

12

Taking the previous information into account, this prompted the question; using
inexpensive miniaturised computing hardware, would it be possible to facilitate a network
reconnaissance on a given network in order to further advance the security placed upon it
presently?
2.1 Related Work
As this is a new and seemingly niche area of research, related work is somewhat scarce
though there has been some research conducted. Jun Zheng of the New Mexico Institute
of Mining and Technology ran a similar project where he discovered the possible attacks
available using a single-board microcomputer and the detrimental effects these attacks would
have on battery life of a connected power source. Zheng used older and lower powered
hardware to perform his tests and came to the conclusion that a small single-board computer
such as the Raspberry Pi is a seriously viable threat towards the defense of an internal
network, Zheng, J. (2013).
2.2 Literature
All the original literature reviewed for this project can be found in Appendix A as this was
completed in the earlier stages of the project timeline. Also a supervisory meeting Log can
be found in appendix F.

13

Chapter 3.
Methodology

The primary question of this project was, could the construction of a mobile and networked
microcomputer device fitted with a LCD screen, keypad input and automation software, for
the purpose of allowing an ordinary person to conduct network penetration tests using off
the shelf IT equipment be possible?
This question followed with, should the construction of a mobile and networked
microcomputer penetration testing device be possible, what is the length of time a mobile
attack can be run without the need for a power supply?
The following sections will show the necessary steps taken in order to perform such a task
like this.

3.1 Hardware
The following section will take a look at the hardware purchased for the project, it will look
at each individual component comparing them to their market competitors and provide the
reasoning as to the the final choice which was made.

14

3.1.1 Microcomputer
Research suggested that the hardware required would be a miniaturised single-board
computer with an adequate amount of processing power and lots of I/O for additional
peripherals and connectivity tailoring to the intended modular design. A previous study
which was similar to that of which was being conducted used a Raspberry Pi version 1 model
B, this offered everything required for the project build but was an older model of the
Raspberry Pi range, luckily the company had recently just brought a new Raspberry Pi version2
model B to market which offered considerable improvements to the technical specifications
of the device. Improvements such as moving from a 700Mhz single core CPU to a 900Mhz
quad core, 512MB to 1 GB of RAM, from 2x USB 2.0 ports to 4x USB ports and both models
kept the 40 pin GPIO headers for expansion. The Raspberry Pi vesion2 hardware is also very
inexpensive in price and costs the same as the prior version, it also offers large online
community that run a plethora of heterogeneous projects leaving vast amounts of
information online to take study from should there be any problems in the development.
There are alternatives to the Raspberry Pi such as the Beaglebone Black, ODROID-C1+ and
BananaPi, they are also around the same hardware specifications and price range but their
online community is miniscule in comparison to that of the Raspberry Pi’s. It was this key
factor which clarified the decision to use a Raspberry Pi single-board computer for the project,
as should any issues occur along the timeline a large online community of help would be
available.

15

3.1.2 Screen and keypad input
Though technically not required in some cases, a physical screen and keypad input was
necessary for the remote installation of the devices on a target network. Adding a screen and
keypad input allows a penetration tester to trigger automated attacks directly from the device
itself as opposed to using additional hardware/software to log into it. There were two main
types of screen and input, these where the basic RGB display with physical buttons that can
be programmed to interact with software with the use of existing Python libraries or a touch
screen unit allowing a desktop environment to be loaded and potentially use on screen
keyboard. Both technologies physically interact with the Raspberry Pi through a section of
the GPIO headers that are on the board.
Due to the nature of the project requiring automation the RGB display and keypad input
where the more useful and discrete hardware choice allowing for the pre-programmed
automation to be triggered through the on board keypad.

3.1.3 Wireless network interface
The open design of a Raspberry Pi allows the addition of lots of different hardware
collaborations and with the integration of 4x USB 2.0 ports. This allowed the use of a USB
powered device wireless dongle. The review of literature surrounding network security
suggested that the necessity of a specific chipset and drivers is required when performing
particular network penetration tests. These specific chipsets would allow the tester to
perform on the fly packet injection while monitoring the streams of wireless frequencies in
the air.

16

There were 2 main wireless dongles which used the required chipset, these where by brands
TP-link and Alfa network. The TP-Link brand of wireless dongle offered a smaller design
allowing more discrete design and was chosen for this reason.

3.1.4 Secondary Ethernet interface
To allow certain reconnaissance attacks such as an inline Ethernet packet capture the need
for a second Ethernet networking interface is required, as the device alone only as one on-
board Ethernet connection. An inline Ethernet packet capture would require the device to
sit on the link between two communicating networked devices. Fortunately, additional
Ethernet interfaces can be added to a Raspberry PI via the USB ports using an Ethernet RJ45
USB Network Adapter.
As the existing onboard Ethernet port as a maximum throughput of 100Mbps, there was no
need to choose a higher throughput USB Ethernet network adapter as network traffic will
scale to the lowest speed link, This narrowed sourcing the hardware to just 100Mbps.

3.1.5 Battery pack
As the penetration testing device is to be mobile, it will require a source of power in the form
of a mobile battery pack. After Study of the previous research completed on exploring attack
vectors which used a 5,000mAh USB power bank, Zheng (2013). It was deciding that a
20,000mAh USB power bank would be more beneficial as there studies found the max a
5,000mAh battery could last running various attack vectors was 6 hours, which gives little
time to conduct a thorough reconnaissance.

17

3.1.6 Project financial cost
The following table is the parts required for the project with a source of purchase and price
at the time of sale.
FIGURE 2. PROJECT FINANCIAL COSTS

Item Source Cost
Raspberry Pi 2 Model B+ . Uk.rs-
online.com
£25
Adafruit RGB Negative 16×2 LCD+Keypad Kit for Raspberry Pi. Amazon.co.uk £25
TP-LINK TL-WN722N Wireless N150 High Gain USB Adapter, 150Mbps,
4dBi External Antenna, WPS Button.
Amazon.co.uk £8
Anker Astro E6 Power bank - 20800 mAh. Amazon.co.uk £30
TP-LINK TD-W8968 300Mbps Wireless N USB ADSL2+ Modem Router. Amazon.co.uk £29
0.5M CAT.5 UTP Patch Cable. Amazon.co.uk £3
SanDisk Mobile Ultra micro SDHC 16 GB UHS-I Class 10 Memory Card 30
MB/s.
Amazon.co.uk £8
USB to 10/100 Ethernet RJ45 Network Adapter Converter PC Laptops
Wired Connection USB Male to RJ45 Female.
Amazon.co.uk £1.75

Adafruit Raspberry Pi B+ / Pi 2 / Pi 3 Case - Smoke Base

Adafruit.com £5
Total: £134.75
3.2 Software
The following section will take a look at the software used within the project, it will look at
each individual piece, comparing it with any alternate software’s that are available and
provide the reasoning as to the the final choice which was made.
3.2.1 Operating system
There are a number of open-source Linux based penetration testing distributions, that are
specifically configured for the Raspberry Pi as it uses an ARM based CPU architecture, these
are available to download online and free. Distribution such as Kali Linux, Pwn Pi and

18

Raspberry Pwn all offer a number of penetration testing tools free to install and use.
However, this project was designed to be a modular device, so it was decided that the best
operating system for the project would be Raspbian; an unofficial port of the Debian wheezy
ARMhf distribution that is available download on the Raspberry Pi website. Raspbian is
completely compatible with the Raspberry Pi and is updated frequently, so there will be no
issues regarding compatibility. Raspbian also comes with the Python programming language
pre-installed and with Python installed a program known as ‘Katoolin’ can be downloaded
and run. Katoolin offers a quick and easy way to download repositories and tools from the
Kali Linux penetration testing distribution, in order to then select and install penetration
testing tools from its suite. The tools can be installed individually as and when needed making
this a better approach to having a bloated system full of tools that are not in use.

3.2.2 Programming languages
Has there have been over 2500 computer languages created (Kinnersley B, 2016) the choice
of which language to use in the project was cumbersome. However, with the decision to use
the Adafruit RGB screen and keypad input, also came the need to use the pre-written Python
libraries for the interaction between the module and operating system. This made Python
the only viable programming language available but a valuable part of the python
programming language is the ability to run BASH commands within the code. This would be
very beneficial as the author had previously completed an academic module on UNIX and
familiar with the commands available.

19

3.2.3 Nmap
Nmap is a free and open source network discovery tool that can scan a target network finding
information in hosts such as open/closed ports, operating system versions and firewall filters.
It is a commonly used tool for the reconnaissance of a network when performing a network
penetration test as the tester can build a logical picture of what the network consists off.
Nmap offers the ability to write information that has been discovered to file allowing a report
to be built and analysed at a later date.

3.2.4 Reverse AES HTTP Shell
A reverse shell is form of shell whereby the target system of which is required use of,
communicates back to a remote attacking system. The remote system is configured to listen
on a specific port whereby it receives the connection this is achieved by using command or
code execution (InfosecInstitute, 2016).
The diagram below shows the state of a reverse shell connection.
FIGURE 3. DIAGRAM OF REVERSE SHELL TOPOLOGY (SOURCE: INFOSECINSTITUTE.COM, 2016 )

Reverse shell tools are available from the Kali Linux repositories an can be downloaded
through katoolin.

20

Chapter 4. Design and
Implementation

The following section will show the physical construction of the miniaturised penetration
testing computer followed by a look at the software that was implemented on it.
4.1 Hardware construction
The first step of the build was to solder the RGB display and keypad kit together following the
online instruction set provided on the Adafruit website. The following figures show the start
and finish of the build.
FIGURE 4.HARDWARE CONSTRUCTION START

21

FIGURE 5. HARDWARE CONSTRUCTION FINISH

The build required a soldering iron as the the RGB display and keypad there in kit form, a
more detailed view of the construction can be seen in Appendix B

4.2 Software Implementation
The following section will explain how the software was implemented on the device
presenting extracts of code implementations.
To implement the software, the Raspbian Image was pre-installed on the Micro SD cards and
inserted in the Raspberry Pi as this was the operating system of choice. Following this, the
necessary Python libraries where downloaded from the Adafruit website to utilise the
interaction between pi and screen/keypad

22

4.2.1 LCD Menu system
As there are many hobbyists who take on the Raspberry Pi for various projects,
sources such as GitHub host free open-source repositories of programming code for
individuals to upload and download from, allowing communities to collaborate and share
code. It was this source which allowed the author to discover a pre-written menu system that
had been wrote in the python computing language for the interaction between the Raspberry
Pi and Adafruit RGB display and keypad input. On parsing the code, it was revealed there was
a lot of unnecessary functions that originally where tailored for the use of its creator. These
where deemed unnecessary and the code was adapted to that of a basic menu system with
no functions. This base code would be where all later functions would be called from and
would be placed in as a script to be ran in the ‘.bashrc’ file; a file which initiates the commands
within it on the boot of the device. The Adapted menu system code for the project can be
found in Appendix C.

4.2.2 Reverse shell
The reverse shell code was taken from the penetration testing tools that are supplied with
the Kali Linux distribution. It was installed using the katoolin application referred to earlier,
the code was mildly adapted as the AES private key was changed this was done as the default
is set for everyone who wishes to use the tool and therefore it is well known making it a
security risk.

23

4.2.3 Port Scan and Report
The port scan feature of the project was implemented using the well-known Nmap software
previously mentioned. Given specific flags the author was able to scan a specified a dress
range for all open ports and operating system versions of hosts within a define network a
breakdown an extract of the implemented function is shown below.
FIGURE 6. NMAP COMMAND BREAKDOWN

This network port scanning feature can be triggered from the keypad LCD menu system
allowing the tester to produce a report swiftly without the need of peripherals such as
keyboard mouse and monitor adhering to intentionally discrete and mobile nature. Figure 7
below shows the port scan function extracted from the LCD menu script it should be noted
that the interaction on the keypad requires the user to press the left switch in order to break
loop the function is placed in leaving the area of the LCD menu they were once placed in.
FIGURE 7. PORT SCAN FUNCTION CODE

A sample network port scan report output has been provided in Appendix D of the
appendices.

24

4.2.4 Anonymous Inline Ethernet packet capture
The inline Ethernet packet capture was implemented with the use of the USB RJ45 Ethernet
adapter, the device works by sitting in the middle of the communicating and taking a copy of
all the traffic that passively runs through the device. The diagram below shows the
conceptual design followed by the physical design.
FIGURE 8. INLINE ETHERNET PACKET CAPTURE CONCEPTUAL DESIGN

FIGURE 9. INLINE ETHERNET PACKET CAPTURE PHYSICAL DESIGN

25

To allow the device to be anonymised, a configurations had to be set on the device these are
as follows:
1. Disable DHCP daemon from running denying the devices interfaces being given an IP
address.
2. Create bridge and add interfaces both interfaces to the bridge.
3. Remove the IP addresses of the interfaces on the bridge.
4. Initiate the Bridge.
5. Initiate the capture of the the traffic passing through the bridge interface.
The script for the inline Ethernet packet capture can be seen below.
FIGURE 10. INLINE ETHERNET PACKET CAPTURE SCRIPT

26

4.2.5 Battery Timer script
The battery timer was a simple script wrote in BASH to record the time at which the device
powered off. This was written for the testing phase of the project as the USB battery pack as
no indication of when the batteries power is about to deplete, meaning a script would have
to be run as a background process constantly rewriting the current time into a file. Once a
test had been performed the and battery and fully depleted the device would be powered on
and the time would be read from the file in order to calculate how long the battery life had
lasted during the test. This was performed by deducting the start time of the test by the finish
time, showing the number of hours and minutes the battery had lasted. Figure 11 below
show the basic battery timer script.
FIGURE 11. BATTERY TIMER SCRIPT

27

4.3 Problems faced
After completion of the build, to run the pen testing device in a target environment research
showed it had the potential to face various issues surrounding general network security
techniques
4.3.1 Port Security
Organisations such as banks and who wish to be certified to the ISO27002 information
security standards must follow strict regulations on the access control they place on their
network and systems (ISO/IEC 27002:2013, 2013). They will apply security configurations to
their networking equipment such as port security as a physical defence against unauthorised
access to the local network. Port security is a technique of access control that consists of
MAC filtering on the physical ports of a switch, it is secured by allowing or denying a physical
connection to the network based on the MAC address of the connecting device. This can be
a problem for the reconnaissance device, has should it want to initiate a reverse shell
connection, it would require a valid MAC address from the filter list implemented to the
switch.
This problem could be overcome with a technique known as MAC spoofing (D Cardenas, E,
2003), it would require the user of the device to manually configure the device using a valid
MAC address to connect to the network.

28

4.3.2 Stateful Firewalls
The use of Stateful Firewall technologies will allow or deny various types of traffic across a
network. Software such as IPtables rules or Cisco IOS’s ACL lists can perform IP filter rules on
the state of a connection, these are known as reflexive ACL’s or Stateful rules (Cisco, 2014).
A common configuration of the reflexive ACL is to allow outbound connections that where
started within a network through the firewall, but deny any connections inbound that where
not started from within the network. This maybe filtered by the port in which is in use for
example HTTP traffic over port 80 is allowed out and return, but not allowed in. Another
function of a Stateful firewall is the ability to perform deep packet inspection; this is the
capturing of packets in transit for analysis (Solarwinds, 2014). Deep packet inspection can
detect fraudulent packets that are entering the network under a valid port number but
contain different protocols to which that port number is associated.
This was overcome with the use of the reverse AES HTTP shell which can run across port 80
out of the network (a common configuration). It is also Encrypted with AES encryption
denying any packet inspection to be performed.

4.3.3 IDS/IPS Systems
There is a possibility an organisation will use an IDS/IPS system to monitor and detect freak
activity on the network, such as extremely high bandwidth use or hosts being repeatedly
pinged. An IDS/IPS is configured with the use of factors such as network traffic flows,
signature based inspection and baseline network activity. Once these rules are violated the

29

IPS can dynamically prevent suspicious activity from occurring by altering firewall rules and
logging activity.
To prevent detection from any IDS/IPS systems, the network port scanning software Nmap,
was given command flags set to avoid detection by fragmentation of packets. However, this
would not prevent detection in every scenario.

4.4 Inline Ethernet packet capture Investigation
The following section is the second part of the implementation where by the penetration
testing device that was constructed, was tested to see how long the device could monitor
traffic using the Inline Ethernet packet capturing software previously implemented

4.4.1 Battery life testing
To test the network reconnaissance attack against battery life, a piece of software was
required to generate specific levels of traffic across a physically connected Ethernet link.
Initial research referred the author to a software known as iperf; a program that is used for
testing the throughput of a connection by sending a defined amount of bandwidth to saturate
a physical link. This software was used in the project in conjunction with software known as
tcpdump; a packet analysing application which is run from the Linux command line. tcpdump
itself was used to capture the packets that were in transit across the Ethernet link which is
being anonymously monitored.

30

The initial testing was performed in 3 stages these as follows;
1. Battery consumption monitoring 10Mbps throughput
Each test was conducted using all of the same equipment, with the only variant being the bit
rate transmitted. A logical diagram of the battery life test is shown below.
FIGURE 12. LOGICAL DIAGRAM OF BATTERY LIFE TEST

4.4.1 Hardware testing
The final piece of software that was used is known as vmstat, it is also a command line tool
similar to tcpdump, but for the monitoring of a computers statistical information such as CPU,
memory, I/O, and swap, this information can be printed to screen or written to a file for
further analysis. vmstat was run on the penetration testing device alongside tcpdump, to
identify the effect on hardware as the the iperf software transmitted packets at incrementing
bandwidths of 10Mbps till it reached 100Mbps, a Logical diagram of the test is shown below

31

FIGURE 13. HARDWARE UTILISATION TEST DIAGRAM

32

Chapter 5. Results
and Discussion

The following section cover the results collected from tests ran in the previous chapter,
discussing the expected results and then analysing the data for further discussion. To view
the full a transcript of all the results collected refer to appendix E.

5.1 Complete battery depletion test results
The theorised expectation of the tests would be that, the higher the throughput which was
being transmitted from the iperf client software to the iperf server software and anonymously
monitored with the packet capturing application. This would theoretically be running more
processes and utilising the hardware of the penetration testing device meaning the the
battery would deplete more rapidly as the device took more energy from the battery cells.
The following Table and Figure show the results of the battery life tests.
TABLE 1. BATTERY LIFE RESULTS
Reconnaissance Attack Bit Rate (Mbps) Battery life (Hrs)
Inline Ethernet packet capture Average traffic 39.2
Inline Ethernet packet capture 100 28.9

33

FIGURE 14. BAR CHART OF BATTERY LIFE RESULTS

This theory proved to be true as the results below show, the rate at which throughput of
traffic is sent directly affects the speed of drain on the battery life.

5.2 Hardware utilisation test results
The Theorised expectation of this test was similar to that of the battery depletion test, the
author assumed that the higher throughput of data across the monitored link, then this would
directly affect the hardware utilisation on the monitoring device.
This theory however was not fully correct, the tests where rather inconclusive towards the
theory of a direct link between link throughput and hardware utilisation. Although there were
evident patterns in statistics when the highest values of each statistic from the 30 data
outputs where collated. One evident pattern was that of the memory cache utilisation this
can be seen in figure 15 below.
39.2
28.9
34.5
37.9
Wired Inline Ethernet Wire
TAP general use
TAP at 100Mbps
TAP at 50Mbps
TAP at 10Mbps
Time Till Complete Battery Depletion
Time Till Battery Depletion (Hours)

34

As the throughput of the link was is increased by 10Mbps, the size of the memory cache
increases at an exponential rate (seen in red).
FIGURE 15. MEMORY CACHE UTILISATION

35

One other area of interest surrounds the correlation between the link throughput and and
the number of system interrupts per second. Figure 16 below shows after a freak data point
in the 20Mbps test there is a stable increase in the number of interrupts per second in relation
to the link throughput.
FIGURE 16. SYSTEM INTERRUPT INFORMATION

5.3 Additional findings
Throughout the course of the project, there where various other findings that where
discovered that may often be overlooked.

5.3.1 Ease of development
The ease of development on the project was relatively easy, as the author had most of the
technical knowledge that was needed available to them through previous experiences using
902
30
1022 1052 1063 1073 1086 1094 1098 1108
20 0 29 28 29 30 30 31 31 310
200
400
600
800
1000
1200
0 2 4 6 8 10 12
Bandwidth (Mbps)
Min value taken from 30x 1 second interval
(System)
system in system cs

36

the technologies. This was aided by the understanding the author had on subjects at a
fundamental level, meaning any new concepts where built on the pre-existing knowledge.

5.3.2 Development time
The time to develop the project was reasonable and should more time be available to the
individual the project may have been completed earlier then proposed. This is also down to
the discipline of the individual for example the ability deny themselves from procrastinating.

5.3.3 The level of skills required to do the project
The level of skill required to complete the project is that of a first year university student and
low level, it does however require a lot of determination and a keen interest in the field of
network security. Areas such as UNIX and python are the most essential part of the build,
knowing their fundamentals is the basis to furthering the project.

5.3.4 Risk factors for organisations
The projects device presents a lot of risks for an organisation as the device is mobile and
proven to be capable of performing reconnaissance attacks. With the ability to remain hidden
and powered by a battery for up to 39.2 house under average users traffic, the device can
present a serious risk towards the security of an organisations network.

37

5.3.5 How easy was it to find information on this?
Information on the subject was somewhat scarce, however sourcing information on network
security practices and browsing community developed Raspberry Pi projects can provide the
necessary information towards implementing such a project.

5.3.6 How technically in depth is the programming code
The most technical code in the project was that of the LCD menu system, though this was not
written by the author, only adapted and used as a framework. Most of the python code used
in the project refers back to UNIX commands and shell scripts meaning it does not require an
individual at the level of a completed computer science degree in order to write the code in
use.

38

Chapter 6. Conclusion

The initial concept of this project changed quite vastly at an early stage of the process, due to
what was theoretically possible with over ambitious time line. This change however allowed
the project to be refined giving the project two clear and concise questions;
1. Can a device be built using off the shelf IT hardware for the purpose of exploring
possible automated network reconnaissance attacks?
2. If such a device was built, how long can the device be deployed remotely before the
battery life is depleted?
Both of these questions were successfully answered with the build of the device running code
for the automation of network attacks reconnaissance and the testing of battery life depletion
against the device running such code. There were no major surprises to the findings which
were made throughout projects testing, but overall the project gave clarification on the
questions it answered.
Overall the project was a success and a pleasure to complete.

6.1 Lessons Learned
The lessons learned throughout the course of this project were, it does not take an individual
with the knowledge of computer science graduate to achieve the projects goals. Basic

39

understanding of the fundamental technologies partnered with further study in the projects
technical areas will provide the necessary information required to complete such a project.
6.2 Future Activity
Possible future activity furthering the project would consist of the following:
• Implement a GSM shield on the device to allow out of band communication through
the 3G or 4G cellular network. Once connected to to a target network the device
would theoretically be able to upload the extracted recon data to the attacker’s
remote system. Avoiding detection across the target network.
• Test the battery life depletion time when running wireless network reconnaissance
attacks while also observing the effect on hardware utilisation.
• Automate a password cracking application onboard the RGB display and input

40

Bibliography and
References

Adafruit. 2016. Adafruit RGB Negative 16x2 LCD+Keypad Kit for Raspberry Pi. [ONLINE] Available at:
https://www.adafruit.com/products/1110. [Accessed 07 January 16].
Adafruit. 2016. Adafruit Raspberry Pi B+ / Pi 2 / Pi 3 Case - Smoke Base - w/ Clear Top. [ONLINE]
Available at: https://www.adafruit.com/products/2258. [Accessed 1 May 2016].
ALFA. 2016. AWUS036NH. [ONLINE] Available
at: http://www.alfa.com.tw/products_show.php?pc=34&ps=21. [Accessed 1 May 2016].
Amazon. 2016. USB to 10/100 Ethernet RJ45 Network Adapter Converter PC Laptops Wired
Connection USB Male to RJ45 Female. [ONLINE] Available
at:https://www.amazon.co.uk/gp/product/B003Q85EEA/ref=oh_aui_detailpage_o01_s00?ie=UTF8&p
sc=1. [Accessed 1 May 2016].
Ankita Gupta#1, Kavita2, Kirandeep Kaur 2013, "Vulnerability Assessment and Penetration Testing",
International Journal of Engineering Trends and Technology, vol. 4, no. 3, pp. 328-333.
Astro-Pi. 2016. Astro-Pi. [ONLINE] Available at: https://astro-pi.org/about/. [Accessed 04 March 16].
Aufderheide, A. 2013. RaspberryPiLcdMenu. [ONLINE] Available at:
https://github.com/aufder/RaspberryPiLcdMenu. [Accessed 21 February 16].
BananaPi. 2016. BananaPi. [ONLINE] Available at: http://www.bananapi.org/p/product.html.
[Accessed 1 May 2016].
BeagleBoard. 2016. BeagleBone Black. [ONLINE] Available at: https://beagleboard.org/black.
Cunningham, C. 2015. Configure Auto-start. [ONLINE] Available at:
https://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/configure-auto-start. [Accessed 21
February 16].
Cisco. 2014. Configuring IP Session Filtering (Reflexive Access Lists). [ONLINE] Available
at:http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfreflx.ht
ml. [Accessed 4 May 2016].

41

D Cardenas, E, 2003. MAC Spoofing--An Introduction. Global Information Assurance Certification
Paper, [Online]. Available at: http://www.giac.org/paper/gsec/3199/mac-spoofing-an-
introduction/105315 [Accessed 30 April 2016].
Github. 2016. Katoolin. [ONLINE] Available at: https://github.com/LionSec/katoolin. [Accessed 2 May
2016].
Hardkernel. 2016. ODROID-C1+. [ONLINE] Available
at:http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143703355573. [Accessed 1
May 2016].
Holm, H. ; Sommestad, T. ; Almroth, J. ; Persson, M. (2011). A quantitative evaluation of vulnerability
scanning. InformationManagement&Computer Security. Vol 19 (No. 4), p231-247.
Hunt, A. 2014. Media over Coaxial Alliance (MoCA): Operation and Security Posture. [Online] Available
at: https://www.defcon.org/images/defcon-22/dc-22-presentations/Hunt/DEFCON-22-Andrew-Hunt-
MoCA-Overview-and-Security-Posture-WP.pdf. [Accessed 01 January 16].
IBM. 2016. IBM 5100 Portable Computer. [ONLINE] Available at: http://www-
03.ibm.com/ibm/history/exhibits/pc/pc_2.html. [Accessed 22 February 16].
InfosecInstitute. 2016. What are shells?. [ONLINE] Available
at:http://resources.infosecinstitute.com/icmp-reverse-shell/. [Accessed 2 May 2016].
iperf. 2016. iPerf - The network bandwidth measurement tool. [ONLINE] Available at: https://iperf.fr/.
[Accessed 30 April 2016].
ISO. 2013. ISO/IEC 27002:2013(en) Information technology — Security techniques — Code of practice
for information security controls. [ONLINE] Available at: https://www.iso.org/obp/ui/#iso:std:iso-
iec:27002:ed-2:v1:en. [Accessed 4 May 2016].
Kali. 2016. Kali on Raspberry Pi. [ONLINE] Available at: http://docs.kali.org/kali-on-arm/install-kali-
linux-arm-raspberry-pi. [Accessed 2 May 2016].
Kinnersley B. 2016. The Language List. [ONLINE] Available
at:http://people.ku.edu/~nkinners/LangList/Extras/langlist.htm. [Accessed 2 May 2016].
Mortensen, C. ; Winkelmaier, R. ; Zheng, J. (2013). Exploring Attack Vectors Facilitated by Miniaturized
Computers. Proceedings of the 6th International Conference on Security of Information and Networks.
( ), p203-209.
Pwnpi.sourceforge. 2016. PwnPi. [ONLINE] Available at: http://pwnpi.sourceforge.net/index.html.
Ponnusamy P. 2016. Understanding VMSTAT Output - Explained. [ONLINE] Available
at:http://www.lazysystemadmin.com/2011/04/understanding-vmstat-output-explained.html.

42

PwnieExpress. 2016. PWNPLUG R3. [Online] Available at:
https://www.pwnieexpress.com/product/pwn-plug-r3penetration-testing-device/. [Accessed 07
January 16].
Raspberrypi. 2016. RASPBERRY PI 2 MODEL B. [ONLINE] Available
at:https://www.raspberrypi.org/products/raspberry-pi-2-model-b/. [Accessed 22 February 16].
Raspbian. 2016. Raspbian. [ONLINE] Available at: https://www.raspbian.org/RaspbianAbout.
RS Components Ltd. 2016. Raspberry Pi 2 Model B. [Online] Available at: http://uk.rs-
online.com/web/p/processor-microcontroller-development-kits/832-6274/. [Accessed 07 January
16].6.
SANS. 2004. Understanding IPS and IDS: Using IPS and IDS together for Defense in Depth. [ONLINE]
Available at: https://www.sans.org/reading-room/whitepapers/detection/understanding-ips-ids-ips-
ids-defense-in-depth-1381. [Accessed 5 May 2016].
Shravan, K., Neha, B. & Pawan, B. 2014, "Penetration Testing: A Review", Compusoft, vol. 3, no. 4, pp.
752-757.
Solarwinds. (2014). SolarWinds Deep Packet Inspection & Analysis for Quality of Experience
Monitoring. [Online Video]. 29 July 2014. Available
from: https://www.youtube.com/watch?v=aDnpS0LhUC8#t=27. [Accessed: 5 May 2016].
TP-Link. 2016. 150Mbps High Gain Wireless USB Adapter TL-WN722N. [ONLINE] Available
at:http://www.tp-link.com/en/products/details/TL-WN722N.html. [Accessed 1 May 2016].
Tcpdump. 2016. TCPDump&LibPcap. [ONLINE] Available at: http://www.tcpdump.org/. [Accessed 2
May 2016].
Venkateswaran, D. ; Alex, C. ; Jose, K.M. ; Sahasranamam, S. . (2014). Mobile Phone Controlled Farm
Management Aider. Humanitarian Technology Conference (R10-HTC), 2014 IEEE Region 10 . p117-
120.
Violent Python; a cookbook for hackers, forensic analysts, penetration testers and security engineers.
2013. Reference and Research Book News, 28(4),.

43

Appendices

Appendix A – Literature review
Appendix B – Penetration testing device build
Appendix C – LCD menu system code
Appendix D – Port Scan Report
Appendix E – Full transcript of results collected
Appendix F - Supervisory Meeting Log

LITERATURE
REVIEW
Investigating Remote and Automated attack vectors using
a microcomputer from inside a known network.
DEAN KAY ID: 1208626
Prepared for Amanda Dewhurst & Louise Ashby |8th January 2016

APPENDIX A
Appendix - A 2
Table of Contents
ABBREVIATIONS 3
LIST OF FIGURES 3
1. INTRODUCTION 3
2. APPROACH AND METHODS 4
3. FINDINGS 5
4. EVALUATION AND REFLECTION 7
5. BIBLIOGRAPHY 8
6. APPENDICES 8

APPENDIX A
Appendix - A 3
Abbreviations

GSM - Global System for Mobile Communication
OSS - Open Source Software

List of Figures

Figure 1 PwnPlug R3 - source: pwnieexpress.com .................................................................. 6
Figure 2 RGB LCD plate with keypad – source: Adafruit.com .................................................. 6
Figure 3. Bar chart of battery lifetime - source: Exploring attack vectors facilitated by
miniaturized computers ................................................................................................... 7

1. Introduction
Due to an ever increasing number of cyber attacks against computer systems and
networks being committed across the world, companies and nations alike are taking cyber
security as a primary defence against existing and fore coming attacks.
One technique towards building stronger cyber security systems is the hiring of penetration
testers, in order to find security holes in the current computer and networks security
infrastructure of an organisation. Penetration testers are known to use a plethora of
techniques known as ‘attack vectors’, in order to break into their target systems. One rather
new technique is known as a penetration testing drop box. Whereby a computing device with
penetration testing tools pre-installed, is hidden away within a targets physical location with
potential physical access to the target network via a nearby Ethernet port or in wireless range
of an access point.
The purpose of the project is to investigate the viability of using a microcomputer combined
with keypad input and display in order to run automated attacks against a computer network.
Due to its uniqueness there is very little study been made in this area of cyber security, only
finding one main literature containing specific research conducted in the field. Broader
research was made around the subject but it was felt necessary to use the main research
already conducted and build from it.

The overall goal of performing this research carries two segments, firstly to establish whether
or not the device is at all creatable using consumer grade hardware.
This will encompass three parts.

• How the device is to be administered
This is of interest to how the device will efficiently make use of its target
environment, the main focus being the various implementations towards
interaction between the user and device.

• The fashion in which the device will interact in its environment
This represents how the device will interact with its target network. Variants
of attack vector will be considered, such as wired or wireless attacks.

APPENDIX A
Appendix - A 4

• Potential physical forms the device may take
This considers the various physical forms in which the device may take, earlier
research from interactions between users and environments will shape the
path in which this research is conducted.

Using part one’s research as a reference towards physical design of the artefact, the second
segment of the research will take a look at the complexity involved towards handling of the
project, largely being the time constraints placed upon the project deadline and costs to build
the device.
For this very reason, a clear and concise number of attack vectors are to be researched as
there simply is not enough time to study all variant’s. Defining a set amount of attack vectors
will narrow the the scope of the research and allow time for testing and data analysis toward
the end of the project.
2. Approach and Methods
As stated earlier research for this project was broken into 3 parts as follows:

• How the device is to be administered
• The fashion in which the device will interact in its environment
• Potential physical forms the device may take

Research performed on this project would be fundamentally of a technical nature, thus it was
segmented in order to give a clear outlook on key areas of importance within the project.

Part one was to discover how the device would be administered by a user and in order to
carry out specified attacks, a literature search was conducted, via the use of a university
search engine for online academic journals and publications. It is believed this method of
research would provide trustworthy and valid information on the given subject, as the
content is of a scholarly nature and often peer reviewed by professionals in the field.
Following this initial research, it was considered useful to determine if any products offering
penetration testing tools on a microcomputer or of a similar sort, already pre exist on the
consumer market. To no surprise there was few products currently on the market these can
be seen in Appendix A.
Lastly, research was looked upon to see if automating vulnerability scans was a viable option.
A study by academics on the automation of 7 popular vulnerability scanners all being run on
the same computer network consisting of 28 hosts, with a variety of operating systems,
services and potential vulnerabilities. Was performed in 2011 and drew conclusion that the
accuracy of such tests proved invalid (Holm, H; Sommestad, T; Almroth, J; Persson, M, 2011).
This method of automation would not be used because of the validity issues.

Part two of the research took into account the way in which the device would interact in its
environments.
Research that had previously been conducted showed the possibility of both interacting with
a target network physically or wirelessly (Mortensen, C; Winkelmaier, R; Zheng, J, 2013). This
allowed the idea to facilitate both wired and wireless for attacks, opening a wider range of
attack vectors to choose from. On carrying out this research towards the idea of wireless

APPENDIX A
Appendix - A 5
and wired attacks. Further unintended research into remote interaction via 3G cellular
networks arose. A study into system of cellular controlled farming management was being
used with a GSM shield attached to a Raspberry Pi microcomputer (Venkateswaran, D; Alex,
C; Jose, K.M; Sahasranamam, S, 2014). This gave the idea to possible out of band connectivity
to the device being used in the project, thus hiding the identity of commands being
communicated to and from the device, adding another layer of anonymity.
Lastly, the option of using a mains power supply or battery powered supply as an
implementation was also discovered. This allowed obscurity as the device would not need to
rely on a mains power supply to function and could be well hidden (Mortensen, C;
Winkelmaier, R; Zheng, J, 2013).

The final part of the research relates to the physical form of the device, showing the
requirements intended to meet below:

• To be compatible with all connected hardware on device.

• Mobile for instalment in target locations.

• Able to run basic network connectivity test from the device itself locally.

• Perform attacks locally and remotely.

Decisions towards the physical design will take into account, the project costs and case study
findings in order to achieve a suitable medium.
Research showed that the Raspberry Pi microcomputer was a worthy candidate in terms of
the cost of hardware and the capabilities of the hardware. Using hardware such as the
Raspberry Pi would allow the instalment of non proprietary software (Raspberry Pi, 2016).
Such as a specialised operating system known as Kali Linux, which provides a penetration
testing security suite of 250+ tools (Kali, 2016). It was evident from the research conducted
into exploring attack vectors that their device was automatically given connectivity when
placed in the network, as there was know hardware to configure the device on placement.
This gave the idea of fitting a Raspberry Pi with a LCD screen and keypad input module in
order to test basic network connectivity from the device while being placed on location.

3. Findings

Maintaining to the segmentation of the project research into three separate areas,
the following represent the findings found within each area.

Currently there already exists commercial products that include microcomputers installed
with penetration testing suites. It was found that there are various ways to interact with pen
testing hardware, with commercial products such as the PwnPlug R3 seen below.

APPENDIX A
Appendix - A 6

Figure 1 PwnPlug R3 - source: pwnieexpress.com

Pen-testers can utilise over 100+ OSS-based penetration testing tools, from a web based UI
supplied by the vendor. With a price tag of $1000 this was deemed as an expensive approach
to penetration testing. A more cost effective approach would be via the use of a raspberry pi
micro computer partnered with the free security software suite Kali Linux.
Using this approach also allows the additions of modules to the raspberry pi device, allowing
new forms of interaction between user and device. Such as the RGB LCD screen and keypad
module made by Adafruit that can be seen below.

Figure 2 RGB LCD plate with keypad – source: Adafruit.com

This would allow the programming of a basic menu system to be written and a user could run
basic network connectivity checks. Before leaving the device in its target location for later
remote attacks once connectivity as been made.
The use of a 3G cellular hardware is a possible approach for out of band access to the remote
device, thus hiding the identity of commands being communicated to and from the device.
Though this would be another incremental cost to the project but would be taken into
account for any future projects in this area.

Another consideration to be made when implementing the hardware is whether or not to use
a power supply from the target organisation or use an external battery power supply. The
advantages to the battery powered implementation would be that the device would be able
to be hidden out of site, taking the idea that if it was deployed by a cyber criminal they would
not want you knowing it is there. The disadvantage to using a battery powered approach is
the the battery life itself. As it is put under strain through carrying out different attack vectors
battery life can deplete overtime. Previous research found in the case studies found battery

APPENDIX A
Appendix - A 7
life to be an issue causing some attack vectors to simply not be used. This was also due to
the older and less performance microcomputer hardware. The Bar chart below shows the
battery lifetime of a 5,000mah battery, under the use of different attack vectors.

Figure 3. Bar chart of battery lifetime - source: Exploring attack vectors facilitated by miniaturized computers

It can also be depicted from the bar chart above that wireless attacks are more consuming on
battery life as opposed to attacks using a wired connection. This is because of the high
powered antenna always running.

The project approach will be of a similar foundation to the research of ‘Exploring Attack
Vectors Facilitated by Miniaturized Computers’. Though as the study is 3 years old and
technological hardware as progressed. Tests will be carried out on an updated model of the
Raspberry Pi hardware allowing processing speeds of up to 6 times faster then that of the
previously tested. This paired with a 20,000mah external battery supply over the original
5,000mah will allow attack vectors to be trialled that where thought previously not of been
able to run because of the slower older generation hardware.

4. Evaluation and Reflection

The nature of this project produces significant academic and technical challenges
relating to the understanding and grasp of the topic, the implementation cost and hardware
to test the different attack vectors.

Using the unique yet sparse research found on the topic as given a clearer understanding to
possibilities that are viable. This as allowed pre conceptual ideas to be approved or disproved
before any technical implementation as been started. Ultimately saving time, but also
allowing new avenues to be looked upon instead.

APPENDIX A
Appendix - A 8

The methods in which research as been conducted have proved to be of a high standard,
allowing the information required to be taken where needed. Even unintended research that
occurred proved useful in the process of eliminating potential routes to take with the project.

The research has narrowed the project idea down to a more manageable one, eradicating the
broad spectrum of ideas into just a few. Allowing precise information to be extracted from
the project.

5. Bibliography

Adafruit. 2016. Adafruit RGB Negative 16x2 LCD+Keypad Kit for Raspberry Pi. [ONLINE] Available at:
https://www.adafruit.com/products/1110. [Accessed 07 January 16].

Venkateswaran, D. ; Alex, C. ; Jose, K.M. ; Sahasranamam, S. . (2014). Mobile Phone Controlled Farm
Management Aider. Humanitarian Technology Conference (R10-HTC), 2014 IEEE Region 10 . p117-120.

Hunt, A. 2014. Media over Coaxial Alliance (MoCA): Operation and Security Posture. [Online] Available at:
https://www.defcon.org/images/defcon-22/dc-22-presentations/Hunt/DEFCON-22-Andrew-Hunt-MoCA-
Overview-and-Security-Posture-WP.pdf. [Accessed 01 January 16].

Holm, H. ; Sommestad, T. ; Almroth, J. ; Persson, M. (2011). A quantitative evaluation of vulnerability scanning.
InformationManagement&Computer Security. Vol 19 (No. 4), p231-247.

Kali. 2016. About Kali Linux. [Online] Available at: https://www.kali.org/downloads/. [Accessed 07 January 16].

Mortensen, C. ; Winkelmaier, R. ; Zheng, J. (2013). Exploring Attack Vectors Facilitated by Miniaturized
Computers. Proceedings of the 6th International Conference on Security of Information and Networks. ( ), p203-
209.

PwnieExpress. 2016. PWNPLUG R3. [Online] Available at: https://www.pwnieexpress.com/product/pwn-plug-
r3penetration-testing-device/. [Accessed 07 January 16].

RS Components Ltd. 2016. Raspberry Pi 2 Model B. [Online] Available at: http://uk.rs-
online.com/web/p/processor-microcontroller-development-kits/832-6274/. [Accessed 07 January 16].6.
6. Appendices

Appendix A

APPENDIX A
Appendix - A 9
BeagleBone
MiniPwner

Raspberry Pi

APPENDIX C
1. #!/usr/bin/python
2.
3. # Created by Alan Aufderheide, February 2013
4. # Modified by Dean Kay, February 2016
5. # This provides a menu driven application using the LCD Plates
6. # from Adafruit Electronics.
7.
8. import commands
9. import subprocess
10. import os
11. import urllib
12. from string import split
13. from time import sleep, strftime, localtime
14. from datetime import datetime, timedelta
15. from xml.dom.minidom import *
16. from Adafruit_I2C import Adafruit_I2C
17. from Adafruit_MCP230xx import Adafruit_MCP230XX
18. from Adafruit_CharLCDPlate import Adafruit_CharLCDPlate
19. from ListSelector import ListSelector
20.
21. import smbus
22.
23. configfile = 'lcdmenu.xml'
24. # set DEBUG=1 for print debug statements
25. DEBUG = 0
26. DISPLAY_ROWS = 2
27. DISPLAY_COLS = 16
28.
29. # set to 0 if you want the LCD to stay on, 1 to turn off and on auto
30. AUTO_OFF_LCD = 0
31.
32. # set busnum param to the correct value for your pi
33. lcd = Adafruit_CharLCDPlate(busnum = 1)
34. # in case you add custom logic to lcd to check if it is connected (useful)
35. #if lcd.connected == 0:
36. # quit()
37.
38. lcd.begin(DISPLAY_COLS, DISPLAY_ROWS)
39. lcd.backlight(lcd.OFF)
40.
41. # commands
42. def rePortscan():
43. if DEBUG:
44. print('in rePortscan')
45. lcd.clear()
46. subprocess.call("sudo nmap -O -sV -v --reason --open -
oX /home/pi/portScans/testmap.xml 192.168.0.0/24 --stylesheet=nmap.xsl &",shell=True)
47. while 1:
48. if lcd.buttonPressed(lcd.LEFT):
49. break
50. sleep(0.25)
51. def ShowPubIP():
52. if DEBUG:
53. print('in ShowPublicIP')
54. publicIPUrl = urllib.urlopen("http://my-ip.heroku.com/")
55. pubIP = publicIPUrl.read().split()[2].translate(None, '"')
56. lcd.clear()
57. lcd.message(pubIP)
58. while 1:
60. break
61. sleep(0.25)
62.
63. def ShowDG():
64. if DEBUG:
65. print('in ShowIPGate')
66. lcd.clear()
67. lcd.message(commands.getoutput("sudo python /home/pi/getDG.py"))
68. while 1:
70. break

APPENDIX C
71. sleep(0.25)
72.
73. def revShell():
74. if DEBUG:
75. print('in Reverse Shell')
76. lcd.clear()
77. subprocess.call("sudo python /home/pi/testmenu/reVSHELL/shell.py 192.168.1.101 80 &",shell=Tru
e)
78. while 1:
80. break
81. sleep(0.25)
82.
83. def reWireTAP():
84. if DEBUG:
85. print('in reWireTAP')
86. lcd.clear()
87. subprocess.call("sudo /home/pi/reTools/reWireTAP/reWireTAP.sh",shell=True)
88. while 1:
90. break
91. sleep(0.25)
92.
93. def DoQuit():
94. lcd.clear()
95. lcd.message('Are you sure?nPress Sel for Y')
96. while 1:
98. break
99. if lcd.buttonPressed(lcd.SELECT):
100. lcd.clear()
102. quit()
103. sleep(0.25)
104.
105. def DoShutdown():
106. lcd.clear()
108. while 1:
110. break
112. lcd.clear()
114. commands.getoutput("sudo shutdown -h now")
115. quit()
116. sleep(0.25)
117.
118. def DoReboot():
119. lcd.clear()
121. while 1:
123. break
125. lcd.clear()
127. commands.getoutput("sudo reboot")
128. quit()
129. sleep(0.25)
130.
131. def LcdOff():
132. global currentLcd
133. currentLcd = lcd.OFF
134. lcd.backlight(currentLcd)
135.
136. def LcdOn():
138. currentLcd = lcd.ON
140.

APPENDIX C
141. def LcdRed():
143. currentLcd = lcd.RED
145.
146. def LcdGreen():
148. currentLcd = lcd.GREEN
150.
151. def LcdBlue():
153. currentLcd = lcd.BLUE
155.
156. def LcdYellow():
158. currentLcd = lcd.YELLOW
160.
161. def LcdTeal():
163. currentLcd = lcd.TEAL
165.
166. def LcdViolet():
168. currentLcd = lcd.VIOLET
170.
171. def ShowDateTime():
172. if DEBUG:
173. print('in ShowDateTime')
174. lcd.clear()
175. while not(lcd.buttonPressed(lcd.LEFT)):
176. sleep(0.25)
177. lcd.home()
178. lcd.message(strftime('%a %b %d %Yn%I:%M:%S %p', localtime()))
179.
180. def ValidateDateDigit(current, curval):
181. # do validation/wrapping
182. if current == 0: # Mm
183. if curval < 1:
184. curval = 12
185. elif curval > 12:
186. curval = 1
187. elif current == 1: #Dd
188. if curval < 1:
189. curval = 31
191. curval = 1
192. elif current == 2: #Yy
193. if curval < 1950:
194. curval = 2050
196. curval = 1950
197. elif current == 3: #Hh
198. if curval < 0:
199. curval = 23
201. curval = 0
202. elif current == 4: #Mm
203. if curval < 0:
204. curval = 59
206. curval = 0
207. elif current == 5: #Ss
208. if curval < 0:
209. curval = 59
211. curval = 0

APPENDIX C
212. return curval
213.
214. def SetDateTime():
215. if DEBUG:
216. print('in SetDateTime')
217. # M D Y H:M:S AM/PM
218. curtime = localtime()
219. month = curtime.tm_mon
220. day = curtime.tm_mday
221. year = curtime.tm_year
222. hour = curtime.tm_hour
223. minute = curtime.tm_min
224. second = curtime.tm_sec
225. ampm = 0
226. if hour > 11:
227. hour -= 12
228. ampm = 1
229. curr = [0,0,0,1,1,1]
230. curc = [2,5,11,1,4,7]
231. curvalues = [month, day, year, hour, minute, second]
232. current = 0 # start with month, 0..14
233.
234. lcd.clear()
235. lcd.message(strftime("%b %d, %Y n%I:%M:%S %p ", curtime))
236. lcd.blink()
237. lcd.setCursor(curc[current], curr[current])
238. sleep(0.5)
239. while 1:
240. curval = curvalues[current]
241. if lcd.buttonPressed(lcd.UP):
242. curval += 1
243. curvalues[current] = ValidateDateDigit(current, curval)
244. curtime = (curvalues[2], curvalues[0], curvalues[1], curvalues[3], curvalues[4]
, curvalues[5], 0, 0, 0)
245. lcd.home()
248. if lcd.buttonPressed(lcd.DOWN):
249. curval -= 1
250. curvalues[current] = ValidateDateDigit(current, curval)
251. curtime = (curvalues[2], curvalues[0], curvalues[1], curvalues[3], curvalues[4]
, curvalues[5], 0, 0, 0)
252. lcd.home()
255. if lcd.buttonPressed(lcd.RIGHT):
256. current += 1
257. if current > 5:
258. current = 5
261. current -= 1
262. if current < 0:
263. lcd.noBlink()
264. return
267. # set the date time in the system
268. lcd.noBlink()
269. os.system(strftime('sudo date --set="%d %b %Y %H:%M:%S"', curtime))
270. break
271. sleep(0.25)
272.
273. lcd.noBlink()
274.
275. def ShowIPAddress():
276. if DEBUG:
277. print('in ShowIPAddress')
278. lcd.clear()
279. lcd.message(commands.getoutput("/sbin/ifconfig").split("n")[1].split()[1][5:])
280. while 1:

APPENDIX C
282. break
283. sleep(0.25)
284.
285. # Get a word from the UI, a character at a time.
286. # Click select to complete input, or back out to the left to quit.
287. # Return the entered word, or None if they back out.
288. def GetWord():
289. lcd.clear()
290. lcd.blink()
291. sleep(0.75)
292. curword = list("A")
293. curposition = 0
294. while 1:
295. if lcd.buttonPressed(lcd.UP):
296. if (ord(curword[curposition]) < 127):
297. curword[curposition] = chr(ord(curword[curposition])+1)
298. else:
299. curword[curposition] = chr(32)
301. if (ord(curword[curposition]) > 32):
302. curword[curposition] = chr(ord(curword[curposition])-1)
303. else:
304. curword[curposition] = chr(127)
305. if lcd.buttonPressed(lcd.RIGHT):
306. if curposition < DISPLAY_COLS - 1:
307. curword.append('A')
308. curposition += 1
309. lcd.setCursor(curposition, 0)
310. sleep(0.75)
312. curposition -= 1
313. if curposition < 0:
314. lcd.noBlink()
315. return
318. # return the word
319. sleep(0.75)
320. return ''.join(curword)
321. lcd.home()
322. lcd.message(''.join(curword))
324. sleep(0.25)
325.
326. lcd.noBlink()
327.
328. # An example of how to get a word input from the UI, and then
329. # do something with it
330. def EnterWord():
331. if DEBUG:
332. print('in EnterWord')
333. word = GetWord()
334. lcd.clear()
335. lcd.home()
336. if word is not None:
337. lcd.message('>'+word+'<')
338. sleep(5)
339.
340. class CommandToRun:
341. def __init__(self, myName, theCommand):
342. self.text = myName
343. self.commandToRun = theCommand
344. def Run(self):
345. self.clist = split(commands.getoutput(self.commandToRun), 'n')
346. if len(self.clist) > 0:
347. lcd.clear()
348. lcd.message(self.clist[0])
349. for i in range(1, len(self.clist)):
350. while 1:

APPENDIX C
352. break
353. sleep(0.25)
354. lcd.clear()
355. lcd.message(self.clist[i-1]+'n'+self.clist[i])
356. sleep(0.5)
357. while 1:
359. break
360.
361. class Widget:
362. def __init__(self, myName, myFunction):
364. self.function = myFunction
365.
366. class Folder:
367. def __init__(self, myName, myParent):
369. self.items = []
370. self.parent = myParent
371.
372. def HandleSettings(node):
373. global lcd
374. if node.getAttribute('lcdColor').lower() == 'red':
375. LcdRed()
376. elif node.getAttribute('lcdColor').lower() == 'green':
377. LcdGreen()
378. elif node.getAttribute('lcdColor').lower() == 'blue':
379. LcdBlue()
380. elif node.getAttribute('lcdColor').lower() == 'yellow':
381. LcdYellow()
382. elif node.getAttribute('lcdColor').lower() == 'teal':
383. LcdTeal()
384. elif node.getAttribute('lcdColor').lower() == 'violet':
385. LcdViolet()
386. elif node.getAttribute('lcdColor').lower() == 'white':
387. LcdOn()
388. if node.getAttribute('lcdBacklight').lower() == 'on':
389. LcdOn()
390. elif node.getAttribute('lcdBacklight').lower() == 'off':
391. LcdOff()
392.
393. def ProcessNode(currentNode, currentItem):
394. children = currentNode.childNodes
395.
396. for child in children:
397. if isinstance(child, xml.dom.minidom.Element):
398. if child.tagName == 'settings':
399. HandleSettings(child)
400. elif child.tagName == 'folder':
401. thisFolder = Folder(child.getAttribute('text'), currentItem)
402. currentItem.items.append(thisFolder)
403. ProcessNode(child, thisFolder)
404. elif child.tagName == 'widget':
405. thisWidget = Widget(child.getAttribute('text'), child.getAttribute('functio
n'))
406. currentItem.items.append(thisWidget)
407. elif child.tagName == 'run':
408. thisCommand = CommandToRun(child.getAttribute('text'), child.firstChild.dat
a)
409. currentItem.items.append(thisCommand)
410.
411. class Display:
412. def __init__(self, folder):
413. self.curFolder = folder
414. self.curTopItem = 0
415. self.curSelectedItem = 0
416. def display(self):
417. if self.curTopItem > len(self.curFolder.items) - DISPLAY_ROWS:
418. self.curTopItem = len(self.curFolder.items) - DISPLAY_ROWS
419. if self.curTopItem < 0:

APPENDIX C
421. if DEBUG:
422. print('------------------')
423. str = ''
424. for row in range(self.curTopItem, self.curTopItem+DISPLAY_ROWS):
425. if row > self.curTopItem:
426. str += 'n'
427. if row < len(self.curFolder.items):
428. if row == self.curSelectedItem:
429. cmd = '-'+self.curFolder.items[row].text
430. if len(cmd) < 16:
431. for row in range(len(cmd), 16):
432. cmd += ' '
433. if DEBUG:
434. print('|'+cmd+'|')
435. str += cmd
436. else:
437. cmd = ' '+self.curFolder.items[row].text
438. if len(cmd) < 16:
439. for row in range(len(cmd), 16):
440. cmd += ' '
441. if DEBUG:
442. print('|'+cmd+'|')
443. str += cmd
444. if DEBUG:
445. print('------------------')
446. lcd.home()
447. lcd.message(str)
448.
449. def update(self, command):
451. global lcdstart
453. lcdstart = datetime.now()
454. if DEBUG:
455. print('do',command)
456. if command == 'u':
457. self.up()
458. elif command == 'd':
459. self.down()
460. elif command == 'r':
461. self.right()
462. elif command == 'l':
463. self.left()
464. elif command == 's':
465. self.select()
466. def up(self):
467. if self.curSelectedItem == 0:
468. return
469. elif self.curSelectedItem > self.curTopItem:
470. self.curSelectedItem -= 1
471. else:
472. self.curTopItem -= 1
473. self.curSelectedItem -= 1
474. def down(self):
475. if self.curSelectedItem+1 == len(self.curFolder.items):
476. return
477. elif self.curSelectedItem < self.curTopItem+DISPLAY_ROWS-1:
478. self.curSelectedItem += 1
479. else:
480. self.curTopItem += 1
481. self.curSelectedItem += 1
482. def left(self):
483. if isinstance(self.curFolder.parent, Folder):
484. # find the current in the parent
485. itemno = 0
486. index = 0
487. for item in self.curFolder.parent.items:
488. if self.curFolder == item:
489. if DEBUG:
490. print('foundit')
491. index = itemno

APPENDIX C
492. else:
493. itemno += 1
494. if index < len(self.curFolder.parent.items):
495. self.curFolder = self.curFolder.parent
496. self.curTopItem = index
497. self.curSelectedItem = index
498. else:
499. self.curFolder = self.curFolder.parent
502. def right(self):
503. if isinstance(self.curFolder.items[self.curSelectedItem], Folder):
504. self.curFolder = self.curFolder.items[self.curSelectedItem]
507. elif isinstance(self.curFolder.items[self.curSelectedItem], Widget):
508. if DEBUG:
509. print('eval', self.curFolder.items[self.curSelectedItem].function)
510. eval(self.curFolder.items[self.curSelectedItem].function+'()')
511. elif isinstance(self.curFolder.items[self.curSelectedItem], CommandToRun):
512. self.curFolder.items[self.curSelectedItem].Run()
513.
514. def select(self):
515. if DEBUG:
516. print('check widget')
517. if isinstance(self.curFolder.items[self.curSelectedItem], Widget):
518. if DEBUG:
519. print('eval', self.curFolder.items[self.curSelectedItem].function)
520. eval(self.curFolder.items[self.curSelectedItem].function+'()')
521.
522. # now start things up
523. uiItems = Folder('root','')
524.
525. dom = parse(configfile) # parse an XML file by name
526.
527. top = dom.documentElement
528.
529. currentLcd = lcd.OFF
530. LcdOff()
531. ProcessNode(top, uiItems)
532.
533. display = Display(uiItems)
534. display.display()
535.
536. if DEBUG:
537. print('start while')
538.
539. lcdstart = datetime.now()
540. while 1:
541. if (lcd.buttonPressed(lcd.LEFT)):
542. display.update('l')
544. sleep(0.25)
545.
546. if (lcd.buttonPressed(lcd.UP)):
547. display.update('u')
549. sleep(0.25)
550.
551. if (lcd.buttonPressed(lcd.DOWN)):
552. display.update('d')
554. sleep(0.25)
555.
556. if (lcd.buttonPressed(lcd.RIGHT)):
557. display.update('r')
559. sleep(0.25)
560.
561. if (lcd.buttonPressed(lcd.SELECT)):
562. display.update('s')

APPENDIX C
564. sleep(0.25)
565.
566. if AUTO_OFF_LCD:
567. lcdtmp = lcdstart + timedelta(seconds=5)
568. if (datetime.now() > lcdtmp):

APPENDIX E
Full Battery Depletion Test

Reconnaissance Attack Bit Rate (Mbps) Battery life (Hrs)
Inline Ethernet packet capture Average traffic 39.2
31.15
39.2
28.9
34.5
37.9
Wireless Multichannel
Access Point Packet
Capture
Wired Inline Ethernet
Wire TAP general use
Wire TAP at 100Mbps
Wire TAP at 50Mbps
Wire TAP at 10Mbps

APPENDIX E
Vmstat Output Values for 30 seconds at Bandwidth of 10Mbps
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 812808 46348 55508 0 0 15 2 902 20 0 0 99 0 0
0 0 0 812732 46348 55648 0 0 0 0 5062 324 0 2 98 0 0
0 0 0 812516 46348 55784 0 0 0 0 5029 318 0 1 99 0 0
0 0 0 812360 46348 55920 0 0 0 0 5024 311 0 1 99 0 0
1 0 0 812236 46356 56044 0 0 0 36 5058 329 1 1 99 0 0
0 0 0 812144 46356 56192 0 0 0 0 5030 317 0 1 99 0 0
0 0 0 811988 46356 56324 0 0 0 0 5012 336 0 3 97 0 0
0 0 0 811864 46356 56460 0 0 0 0 5011 300 0 1 99 0 0
0 0 0 811740 46356 56592 0 0 0 0 5038 311 0 0 100 0 0
0 0 0 811680 46364 56724 0 0 0 16 5027 342 0 1 99 0 0
0 0 0 811548 46364 56872 0 0 0 0 5026 311 0 1 99 0 0
0 0 0 811392 46364 57008 0 0 0 0 5066 322 0 1 99 0 0
0 0 0 811364 46364 57144 0 0 0 0 5048 322 0 1 99 0 0
0 0 0 811208 46364 57284 0 0 0 0 5023 303 0 0 100 0 0
0 0 0 811084 46372 57408 0 0 0 16 5058 329 0 1 98 0 0
0 0 0 810772 46372 57552 0 0 0 0 5029 317 0 1 99 0 0
0 0 0 810680 46372 57692 0 0 0 0 5035 308 0 1 99 0 0
0 0 0 810556 46372 57824 0 0 0 0 5028 308 0 1 99 0 0
0 0 0 810308 46372 57960 0 0 0 0 5038 317 0 1 99 0 0
0 0 0 810152 46380 58084 0 0 0 16 5042 325 0 1 99 0 0
0 0 0 810060 46380 58232 0 0 0 0 5078 327 0 1 99 0 0
0 0 0 809968 46380 58364 0 0 0 0 5053 329 0 1 99 0 0
1 0 0 809844 46380 58504 0 0 0 0 5025 353 0 1 98 0 0
0 0 0 809704 46380 58636 0 0 0 0 5065 337 1 1 98 0 0
0 0 0 809548 46388 58764 0 0 0 4032 5076 387 0 1 98 0 0
0 0 0 809424 46388 58908 0 0 0 0 5021 315 0 1 99 0 0
0 0 0 809472 46388 59180 0 0 0 0 5151 256 0 1 99 0 0
0 0 0 809320 46388 59176 0 0 0 0 5202 274 0 1 99 0 0
0 0 0 809196 46388 59316 0 0 0 0 5124 256 0 1 99 0 0
0 2 0 809040 46392 59448 0 0 0 52 5063 345 0 1 98 1 0

APPENDIX E
Vmstat Output Values for 30 seconds at Bandwidth of 20Mbps
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 767356 46968 100096 0 0 11 7 988 30 0 0 99 0 0
0 0 0 767264 46968 100240 0 0 0 0 5050 326 0 1 99 0 0
2 0 0 767156 46968 100376 0 0 0 0 5037 317 0 1 99 0 0
0 0 0 767064 46968 100516 0 0 0 0 5095 331 0 1 99 0 0
0 0 0 766940 46976 100648 0 0 0 36 5027 329 0 1 99 0 0
0 0 0 766816 46976 100784 0 0 0 0 5028 310 0 1 99 0 0
0 0 0 766692 46976 100920 0 0 0 0 5051 317 0 0 100 0 0
0 0 0 766568 46976 101056 0 0 0 0 5021 315 0 1 99 0 0
0 0 0 766288 46976 101188 0 0 0 0 5016 309 0 0 99 0 0
0 0 0 766196 46984 101324 0 0 0 16 5050 335 0 1 99 0 0
0 0 0 766040 46984 101460 0 0 0 0 5036 312 0 1 99 0 0
0 0 0 765948 46984 101596 0 0 0 0 5037 308 0 1 99 0 0
0 0 0 765700 46984 101728 0 0 0 0 5071 309 0 1 99 0 0
0 0 0 765576 46984 101856 0 0 0 0 5096 235 0 1 99 0 0
0 0 0 765452 46992 101996 0 0 0 4056 5131 285 0 2 98 0 0
0 0 0 765328 46992 102128 0 0 0 0 5144 257 0 1 99 0 0
0 0 0 765204 46992 102272 0 0 0 0 5027 290 0 1 99 0 0
0 0 0 765048 46992 102408 0 0 0 0 5029 311 0 0 99 0 0
0 0 0 764956 46992 102544 0 0 0 0 5058 320 0 1 99 0 0
0 0 0 764800 47000 102676 0 0 0 44 5044 329 0 1 99 0 0
0 0 0 764708 47000 102816 0 0 0 0 5032 315 0 1 99 0 0
0 0 0 764576 47000 102956 0 0 0 0 5058 341 0 1 99 0 0
0 0 0 764484 47000 103092 0 0 0 0 5071 344 0 1 99 0 0
0 0 0 764296 47000 103228 0 0 0 0 5042 318 0 1 99 0 0
0 0 0 764172 47008 103368 0 0 0 20 5046 339 0 1 99 0 0
0 0 0 764048 47008 103504 0 0 0 0 5032 313 0 1 99 0 0
0 0 0 763924 47008 103636 0 0 0 0 5022 305 0 1 99 0 0
0 0 0 763768 47008 103772 0 0 0 0 5048 318 0 0 100 0 0
0 0 0 763520 47008 103908 0 0 0 0 5036 312 0 1 99 0 0
0 0 0 763428 47016 104036 0 0 0 20 5002 340 0 2 98 0 0

FINAL PROJECT Dean Kay

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to FINAL PROJECT Dean Kay

Similar to FINAL PROJECT Dean Kay (20)

FINAL PROJECT Dean Kay