Final Year Internship Report Cybersecuriy

Génie informatique - Master 2 IFI (CASPAR)
Soware development of a penetration

testing tool for IoT devices
Internship final report
Intern: Ayoub Ider Aghbal

Company: Serma Safety & Security
Company Name: Velozity Global Solutions
City: Rennes, France
Duration: March 4, 2019 – September 6, 2019 (6 months)
Submitted
Tutors:
by: Saurabh Raikwar
Pr. Tamara Rezk, Polytech’ Nice-Sophia
Pr. Hassan Badir, ENSA Tanger
Enrollment No.
Supervisor: Mr. : 05311402020
Mazlum Duman, Serma Safety & Security
October 5, 2019
Acknowledgements
First of all, I would like to express my sincere gratitude to my tutors Mr. Deepak Sharma and
Kaushal Mehta, for their supportive and insightful comments, and for steering me to the right d
tion whenever I needed it, and to Pr. Mohamed El Haddad, Pr. Mohamed Moussaoui, Pr. Yves
Roudier, and Pr. Karima Boudaoud for giving me the opportunity to participate in this double
diploma program.
Furthermore, I would like to thank my supervisor and team manager, Mr. Mazlum Duman for
his constant guidance and advice along the way, in both professional and personal matters.
I would also like to thank all those who I had the pleasure to work with for making this demand-
ing time joyful yet efficient, and for taking the time to answer any of my questions.
Finally, I must express my very profound gratitude to my parents for providing me with unfailing
support and continuous encouragement throughout my years of study leading to this very moment,
and particularly for their sacrifices this year that allowed me to study abroad.
i
Abstract
This document describes the work I have done as part of my six-month internship with two
teams of SERMA Safety & Security in Rennes. The first task of this internship was the development
of a tool capable of interfacing with multiple electronic components and buses, targeted towards se-
curity auditors of IoT devices. The second task was to participate in different penetration tests along
with the company’s consultants. This report presents the result of my work on both of these tasks,
specifically, details about the architecture and implementation of the tool, and my contribution to
different penetration tests.
Keywords: IoT, hardware audit, penetration test, compliance test, software development, Golang.
Resume
Ce document présente le travail que j’ai effectué au cours de mes six mois de stage au sein de deux
équipes de SERMA Safety & Security à Rennes. La première mission de ce stage a été de développer
un outil capable de s’interfacer avec différents composants électroniques et des bus, destiné aux audi-
teurs de la sécurité des objets connectés. La deuxième mission consistait à participer à différents tests
d’intrusion avec les consultants de l’entreprise. Ce rapport présente le résultat de mon travail sur ces
deux tâches, en particulier les détails de l’architecture et de la réalisation de l’outil, et ma contribution
aux différents tests d’intrusion.
Mots clés: IdO, audit matériel, test d’intrusion, test de conformité, développement logiciel, Golang.
ii
Contents
List of Figures v
List of Tables v
Abbreviations vi
I Introduction 1
1 Context of the internship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Proposed work & changes to the initial subject . . . . . . . . . . . . . . . . . . . 4
3 Report contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II Hardsploit 6
1 Context 7
2 Preliminary study 10
2.1 Description of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Current state of the project & needs assessment . . . . . . . . . . . . . . . . . 11
2.3 Competitors overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Requirement definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Proposed solution 16
3.1 General architecture & project sub-tasks . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Technical choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Life cycle model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Personal contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Design & implementation of the system 23

4.1 The core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 The hardware handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 The RPC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iii
Contents iv
4.4 The components database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Results & evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
III Security audits 31
1 Context 32
2 Generalities 33
2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Audit missions 38
3.1 Pentest of a web platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Code security audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Pentest of an Android app and its cloud services . . . . . . . . . . . . . . . . . . 41
3.4 Pentest of a router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 PSD2 compliance test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Hardware hacking training 47
IV Conclusion 49
Appendices I
A Gan Charts II
1.1 Initial Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
1.2 Final Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
Glossary V
References VII
List of Figures
1.1 Photo of a HardSploit board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Screenshot of the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Architecture of the first version of HardSploit . . . . . . . . . . . . . . . . . . . 11
3.1 Components diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Waterfall with subprojects model . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Class diagram of the hardware handler . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Part of the class diagram of the RPC server . . . . . . . . . . . . . . . . . . . . . 28
4.3 Sequence diagram of an RPC communication . . . . . . . . . . . . . . . . . . . 29
A.1 Initial Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

A.2 Final Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
List of Tables
2.1 Competitors overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Field and method visibility in class diagrams . . . . . . . . . . . . . . . . . . . . . 23
v
Abbreviations
ANSSI Agence Nationale de la Sécurité des Systèmes d’information

AWS Amazon Web Services
BU Business Unit
CSRF Cross-Site Request Forgery
GUI Graphical User Interface
HS HardSploit
IDS Intrusion Detection System
ITSEF Information Technology Security Evaluation Facility
S3 SERMA Safety & Security
SAAS Software As A Service
SQLi SQL Injection
SSRF Server Side Request Forgery
WAF Web Application Firewall
XSS Cross-Site Scripting
vi
I
Introduction
1
Introduction 2
1. Context of the internship
1.1. The company
SERMA Group is a holding that has subsidiaries offering services in 5 domains:
SERMA Safety & Security (S3 ) is one of these subsidiaries. It was created in 2015 as a merger be-
tween the safety business unit of SERMA Engineering and the ITSEF laboratory of SERMA Tech-
nologies. It offers expertise, evaluation, consultancy and training to its clients, covering hardware,
software and information systems security. It is an SME that has more than 100 employees, an annual
revenue of about 10 M€, and is present in five sites: Pessac, Paris, Rennes, Angers and Toulouse.
It is currently organized into three business units:
• ITSEF—one of only five hardware and embedded system security laboratories approved by
the ANSSI, created in 1998 and equipped with materials to conduct attacks on secure compo-
nents and systems.
• Security consulting—where I am conducting my internship—organized into four teams:
– Audit,
– Governance,
– HardSploit,
– Training.
• Safety—specialized in risk management in critical systems.
Introduction 3
1.2. HardSploit team
This is a small R&D team working on the HardSploit tool.

Currently, it is made up of six people, including myself:
• The team leader—a hardware security consultant also part of the audit team, who is acting
as a client for the tool and offering his team members field expertise while taking care of the
managerial aspects
• A PhD student, who is working on the embedded software of the FPGA and will use the tool
in his research on building an AI-based intrusion detecting system for the CAN electronic bus
• An apprentice, who was working on the tool for three years and specializes in embedded soft-
ware development
• An intern who is also working together with me on the second version of the software for his
final year internship
• A second intern who is improving the first version for his summer internship.
Some members of the other teams of the BU also contribute to the project when they are between
contracts.
1.3. Audit team
A team of ten people distributed in three cities: Rennes, Paris and Toulouse, with half of the
team based in Rennes, traveling to their clients’ cities if needed.
They provide services in five security domains:
• Infrastructures and networks
• Web and cloud
• Software applications
• Hardware
• Embedded software and reverse engineering
I joined this team in the second part of my internship as I will explain below.
1.4. Work environment
SERMA Group is by no means a small company; it is made up of several teams of varying sizes
that each have their own culture, but still profit from belonging to a big group. This can be clearly
seen in the security consulting BU, which is made up of fewer than 20 employees, of which only 11 are
based in Rennes. These employees developed an internal startup culture and benefit from some of
its advantages—mainly a lack of a dress code, multiple short formal and informal meetings, flexible
Introduction 4
working times, free coffee, the occasional meals at nearby restaurants, etc. This sort of advantage
is also beneficial to the company, since it resulted in the consultants working longer duration than
they are supposed to. They also occasionally organize internal training sessions prepared by one of
the consultants, or after-work capture the flag competitions, where they all try to gain access to a
vulnerable virtual machine. These activities result in learning experiences that directly impact their
performance.
2. Proposed work & changes to the ini al subject

The original goal of my internship is to participate in the development of the HardSploit tool.
When I joined the team, this tool was already being commercialized and used internally for other
purposes, such as performing hardware and IoT audits, and during one of the training workshops
provided.
At first, my task was to develop the software of the second version—which was due for late
2020—, and to basically rewrite the application from scratch in a way that meets the requirements
specified, and prepare a base that would be easy to extend when adding more features.
The plan was later changed so that this task would only take up half of my internship, with
the other half split between helping with the penetration tests that the audit team were perform-
ing whenever possible, and various other tasks, like writing my reports and updating the shopping
website.
This change was mainly due to the company not achieving its financial objectives for the first
half of the year, which forced it to temporarily halt all ongoing R&D projects and to make everyone
work on more profitable tasks. Some consultants and researchers were also laid off following this
decision, including the PhD student that was part of our team. The arrival of a second intern after a
few months also contributed to the subject change, since he took care of some aspects of the project,
freeing me from a part of my responsibilities and allowing me to have more time for the other tasks.
3. Report contents
This document is organized into two main parts. In the first part I will talk about the tool that
was initially the main subject of the internship: HardSploit. Here I will introduce the problem this
tool tries to solve, followed by the result of a background study my colleagues and I conducted. I will
then discuss the solution we came up with, along with the choices I made. Finally, I will dismantle
my tasks into several work packages, explain each of them in depth, and provide some details about
their implementations. In the second part, I will talk about the security audits I performed during
Introduction 5
my internship—by first reminding the reader about the importance of performing such audits—
then discuss penetration tests in a general manner and introduce some technical terms and some of
the tools used, as well as the process we generally use when conducting audits. I will then detail some
of the missions I took part in, finishing with the “Hacking Embedded Systems & IoT” training that
I had the chance to undertake, which makes use of the HardSploit tool.
II
Hardsploit
6
1
Context
In 2008, the number of objects or things connected to the internet exceeded the number of
humans for the first time in history. This marked the birth of ”Internet of things” as we know it:
a collection of connected smartphones, cars, wearables, smart city devices, factory-control devices,
health-care devices, etc. In the same year, the National Intelligence Council listed IoT in its Disrup-
tive Civil Technologies report as one of six technologies with potential impacts on US interests out
to 2025. This was for a good reason: IoT has the potential to violate everyone’s privacy.
Nowadays there are billions of connected devices, and the widespread of these generally insecure
devices means a wider attack surface for cybercriminals, as well as a larger threat to individuals and
companies alike.
There are five distinguishable areas in IoT ecosystems:
1. The IoT Device: A machine equipped with sensors and actuators to monitor the device and
control it.
2. The Gateway: This receives and processes information from one or more devices, and com-
municates with the network.
3. The Network: Some sort of network technology (PAN, LAN, WAN, LPWAN) that allows
the gateway to communicate with the servers.
4. The Server or Cloud: This aggregates, stores, filters, and analyses the collected data. The server
is often able to analyze and/or act on the data collected.
5. Applications: These are the key to providing an end-to-end solution. The application acts
based on the received information by alerting users to the required activities and, in some
cases, by automatically controlling the device.
This exposes us to three main categories of attacks:
7
1. Context 8
1. Physical attacks on the device itself.

2. Network or protocol attacks.
3. Server or cloud attacks.
Performing an audit on the physical device is often overlooked, because it requires a wide range
of electronics skills, such as soldering, analog signal processing, FPGA programming, or the use of
specific measurement tools (oscilloscope, logic analyzer, etc.). However, these are generally not in the
skill set of cybersecurity consultants and pentesters. Tools are also not as established or automated
for these types of audits compared to pure IT ones, which means security issues in the device often
go unnoticed into production, and there is generally no fix after distribution, since companies can’t
recall sold devices.
There are a few available security functions for IoT devices (authentication, anti-tamper mea-
sures, secure boot, secure key management, TrustZones etc.), but they’re generally misused and not
as widespread as software and network security solutions, which makes attackers turn their attention
to less secure intrusion vectors: the hardware and the embedded system. These types of attacks can
have a drastic impact on the general security of IoT devices, because physical access to a vulnerable
device means an attacker can tamper with its data and extract sensitive information (hardcoded ac-
cess keys, cellphone data, etc.). The attacker can then make the device perform unwanted actions
(open electronic door locks, send falsified information.), or bypass its protection mechanisms and
gain administrator privileges on the device.
HardSploit, the product I worked on during my internship, tries to address these issues by bring-
ing down the knowledge requirements to perform pentests on IoT devices, so that even people
with an IT background—and not electronics—could perform them. It is a hardware and software
framework that can allow interfacing with a large number of bus types, memory chips and micro-
controllers, and thus interface directly with the hardware of a device in order to interact with its
components. This interaction can range from monitoring the traffic in a bus and dumping the
contents of a memory to injecting instructions into the pipeline of a chip or modifying data in a
memory. This, in turn, allows for testing the possibility of common attacks—such as fuzzing or
buffer-overflows—or even extracting the firmware in order to reverse-engineer it, which would in
the end contribute to raising the security of the device and the level of trust in it.
1. Context 9
Figure 1.1: Photo of a HardSploit board
Figure 1.2: Screenshot of the GUI

2
Preliminary study
2.1. Descrip on of the project

HardSploit is a tool that was developed to help cybersecurity consultants in their IoT security
audits. It is a tool composed of software and hardware parts that facilitates the connection and in-
teraction with electronic components and buses. However, it is by no means an offensive security
platform on its own, as it does not automatically scan, detect or exploit any vulnerabilities in the
audited component.
The usage of HardSploit is simple by design: Using the GUI, the consultant chooses his target
from the list of components distributed with the tool, or adds it to the database if he doesn’t find
the one he is looking for. This list already contains the configuration necessary to interact with the
component. These configurations can include the number and function of the pins and a list of
supported protocols, and protocol specific settings such as the baud rate for UART. The consultant
is then presented with a schematic of the audited component which has clickable pins, and, upon
clicking on a pin, an LED turns on in the HardSploit electronic board just below the pin where he
should link it. After completing the wiring, he can choose to perform some actions that are different
depending on the protocol, such as sending data, capturing the communication between a micro-
processor and a component, or, if it is a memory component, reading parts of the data or modifying
some of its contents.
The consultant can also use the Ruby API provided with the tool to code his own scripts and
extend the functionalities offered by the GUI, such as fuzzing a component or performing an attack.
10
2. Preliminary study 11
2.2. Current state of the project & needs assessment

The architecture of the existing solution currently looks like this:
Figure 2.1: Architecture of the first version of HardSploit
As we can see from this diagram, the current version consists of multiple interconnected parts.
Primarily, the electronic board contains an FPGA and a micro-controller, and the computer runs
a Ruby API and a GUI. The FPGA controls LEDs that help with the wiring of components to
the board, and interacts directly with the target. The micro-controller is a bridge between the USB
interface and the FPGA that can also change its bitstream and restart it when needed. The API
handles the USB protocol, the storage and usage of the different components configurations, and
the crafting of commands to send to the FPGA, among other things. The GUI is a user interface
that simplifies the usage of the tool.
This version reached the objectives fixed at the time of its creation, which were to make a power-
ful and easy-to-use hardware auditing tool available to the public, and subsequently build a business
around it. By making the company a pioneer in the field and presenting the project at national and
international conferences, they quickly became renowned as one of the best IoT security auditing
companies in France and have since started selling a training workshop, called “Hacking Embedded
Systems & IoT training” (cf. chapter 4) along with the tool.
Needs assessment
The lack of updates—as well as the rise of competing projects and the problems that clients had
encountered—made the project lose its position over the years. In particular, the current version
suffers from several problems. On the hardware:
• Components should be upgraded, since most of them are no longer commercialized and oth-
ers are superseded.
• Using more than one hardware protocol at a time is impossible—currently, one FPGA bit-
stream only supports one protocol.
• The speed of the FPGA used is very limited, so high-frequency protocols (such as the Quad-
SPI) cannot be implemented, and listening on high-speed communication (between a mem-
ory and a micro-controller, for example) is not currently possible.
• It does not support all the hardware protocols found on the market.
On the software level:
• The old software will be completely incompatible with the new hardware.
• The API is very tightly coupled with the GUI, so building third-party software around it is
very hard. Furthermore, supporting existing tools like OpenOCD is currently not possible,
since there is no endpoint to which these tools can connect.
• The user interface should be more intuitive and powerful, providing more tools and features
to simplify hardware audits.
• A full rewrite is required using a different architecture and language, as the existing one no
longer supports all the three major OSes, and its dependencies have become deprecated.
• Being built in Ruby, an arguably slow interpreted language, it will not be able to keep up with
the speed required by the new hardware.
The second version of HardSploit (HardSploit V2) aims to resolve all of these problems. It
also aims to be the first hardware auditing tool that supports interfacing with multiple protocols
simultaneously, to achieve a higher speed of communication and processing than its competitors,
and to be easy to use and attractive for beginners, yet flexible, extendable, and open-source, so that
experienced pentesters and programmers don’t find it lacking or limiting.
2.3. Compe tors overview

When comparing HardSploit to its competitors, we quickly realize that it is a bit on the expen-
sive side (€325 for the board along with the open-source software, or €450 for the board, software,
training kit and comprehensive documentation), but there are other criteria to consider when mak-
ing a comparison—such as the number of supported protocols, the usability of the tool (especially
whether it has a graphical interface or not), the support for well-established software in the field (like
OpenOCD), and if a single board can be used to simultaneously audit multiple targets.
Table 2.1 presents a basic comparison between different versions of HardSploit—specifically ver-
sion 2, version 1, and version 1+, which is a free firmware and software update that will be released
shortly—and their competitors.
In this table, interaction means that the tool is able to communicate with components using
that specific protocol. Practically, this means that it is able to send and receive data from and to
the component, and if the component is a memory, it is able to read data from it and write to it.
sniffing means that the tool is able to intercept the communication between the target component
and another one when it occurs over the specified protocol. pin detection means that the tool is able
to correctly identify the correct type of each pin linked to it using algorithms that are generally based
on brute-force.
As we can see from the table, HardSploit is currently lacking in features and protocol support,
and the second version is an ambitious project that aims to make it regain its place as one of the
leading hardware auditing tools on the market by the end of 2020.
2.4. Requirement defini on

Using the shortcomings and feedback of the first version as a base, along with the results of the
competitors analysis, we established the following requirements for the second version:
2.4.1. Func onal requirements
• HardSploit should support the following device communication buses in interaction mode:
– SPI – JTAG – CAN

– I2C – SWD – Parallel memory
– UART – 1-Wire – Multiplexed memory
2. Preliminary study
Protocols Features
Products Price (€)
Parallel multiplexed Parallel
SPI I2C UART JTAG SWD 1-Wire CAN QuadSPI Multi-protocol OpenOCD support GUI
memory access memory access
BusPirate I/S I/S I I I ✗ ✗ I ✗ ✗ ✗ ✓ ✗ 40

Black Magic Probe ✗ ✗ ✗ I I ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ 60
Good Fet42 ✗ ✗ ✗ I I ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 50
JTAGulator I/P ✗ ✗ I/P ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 175
Die Datenkrake I I I I ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ Free
The shikra I I I I ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ 45
FlashCat USB I I I ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 35
RIFF Box ✗ ✗ I I/P I ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ 150
XPROG Box I I ✗ ✗ ✗ I I ✗ ✗ ✗ ✗ ✗ ✓ 700
Hydrabus I I I I I I ✗ I I ✗ ✗ ✗ ✗ 75
Komodo ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ I/S ✗ ✓ ✗ ✓ 450
Aardvark I/S I/S ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ 300
Hardsploit V1 I/S I I ✗ I ✗ I ✗ ✗ ✗ ✗ ✗ ✓ 325

Free
Hardsploit V1+ I/S I/S I I I I I I I/S ✗ ✗ ✗ ✓
for V1 users
Hardsploit V2 I/S I/S I I I I I I I/S I/S ✓ ✓ ✓ 600
I Interaction
S Sniffing
P Pin detection
Table 2.1: Competitors overview.
14
• HardSploit should support the following device communication buses in sniffing mode:
– SPI – I2C – CAN
• Users can choose to either use the GUI or interact directly with the API.
• The API should broadcast changes to all the connected clients so that they stay synchronized.
• Users can use the same board and API or GUI instance to audit more than one target at a
time.
• HardSploit should provide a way to support OpenOCD and other on-chip debuggers.
• HardSploit should provide a way for users to manage their local copy of the components
database.
• Users can search for and use component data that are stored in a remote database.
• Users can contribute to the remote database by submitting their own components.
• A moderator should validate user submissions before they are added to the remote database.
• Errors should be recorded in a way that facilitates debugging.
• Multiple HS boards can be connected to the same computer.
2.4.2. Non-func onal requirements
Efficiency The HS board must be able to reach a speed of 100 MHz, and the HS API has to keep
up with the board;
Reliability HardSploit should not introduce errors in the data transmitted to and from a compo-
nent;
Maintainability The software should be well designed and documented, and composed of low
complexity modules so that it takes less time for other developers to contribute to the project—
especially since the software is open-source;
Usability The GUI should be easy to learn, efficient, have a pleasant design, and the API com-
mands should be logical yet extensive;
Interoperability The use of the API should not be tied to a specific programming language;
Portability The software should work on all three major operating systems and support x86, x86-
64 and ARM architectures.
3
Proposed solution
3.1. General architecture & project sub-tasks

In order to meet the requirements described in the previous chapter, we came up with a solution
represented in the following diagram, which specifies the different components of the tool and how
they are connected:
Figure 3.1: Components diagram
16
3. Proposed solution 17
We also broke down the work needed to accomplish it into smaller deliverables, as detailed in the
work breakdown structure (figure 3.2). Each of these work packages is completely independent, and
at the software level, communication between the different parts occurs through the API according
to predefined protocols. This separation of concerns allows a different person or team to work on
each part without impacting the work of others as long as the communication protocol remains
unchanged.
Similarly to the first HS version, the main and biggest tasks of the software stack are the API and
GUI.
The API allows multiple clients (CLIs, GUIs or third-party tools) to interface with the hardware and
the local and distant databases via the RPC server. It is composed of multiple parallel threads, each
handling a specific part of the communication and the data management.
The GUI is the official way to use the tool. It should be as intuitive and attractive as possible, and
provide the end user with all the functions the API offers without overwhelming him, yet still be
flexible enough so that even power users feel at ease using it.
As for the OpenOCD driver, it is a C plugin contributed directly to the code base of the program
(OpenOCD users will choose whether or not to include it in the built binary) that will allow it to
send raw commands to JTAG components linked to HardSploit via the RPC server.
The modules sharing platform will contain a huge community-driven database (running on Post-
greSQL) containing the configuration of different chips—not only their reference, manufacturer,
and number of pins, but also the protocols they support, the pins used for each protocol, and the
configuration of these protocols that will allow HardSploit to interact with them. A part of this
database will also be cloned locally (on an SQLite-based database) to allow offline usage and cus-
tomization of the settings.
3.2. Technical choices

Choosing a suitable technology to use was by no means an easy task, particularly for the API. We
needed to use a programming language that would meet our requirements and a set of predefined
criteria. Mainly, it needed to:
• Support multiple operating systems (Windows and Unix-based) and architectures (x86, x86-
64 and ARM)
• Support cross-compilation (if compiled)
• Have a small footprint (possibility to run it on a single-board computer like Raspberry Pi)
• Be fast (to keep up with all the requests and the FPGA)
• Have a good concurrency model
• Preferably be garbage collected
Figure 3.2: Work Breakdown Structure

• Support the integration of C shared libraries

• Be easy to learn
• Have a package manager and a good number of available open source packages
After comparing different languages using these criteria as a base and presenting my results on the
team, we chose to code the API using Golang, which was the language that met all of the require-
ments.
As for the GUI, we had a different set of criteria to base our choice on. We were not really looking
for performance—as the data will be processed in the API—so we based our choice mainly on the
ability to produce a pleasant design and cross-platform executables easily, as well as the familiarity of
the consultants of the company with the technology.
The Go Programming Language

Golang is a user-friendly, statically-typed, compiled programming language designed by Google.
It is syntactically similar to C, yet is easier to learn and use, and provides memory safety, garbage col-
lection, structural typing, built-in concurrency, a huge standard library, and an official command
line tool capable of installing third party libraries, running tests, auto-formatting the code, gener-
ating documentations from the source code, etc. It also has many mature IoT, peripherals I/O and
networking libraries by which to be inspired, making the coding step easier.
Golang uses goroutines to handle concurrency, which are functions executing concurrently in
the same address space. They are lightweight and cheap, costing only about 2 kB of memory (com-
pared to a few megabytes for threads). They’re also fast to start and destroy, and a single computer
can host millions of them.
Goroutines are multiplexed onto multiple OS threads (rather than a 1:1 mapping) and if one of
them blocks—for example, while waiting for I/O—others are automatically moved to a different
thread. They’re designed to hide many of the complexities of thread creation and management and
to avoid deadlocks, since in Go, a goroutine does not have access to another one’s internal variables,
and communication does not occur by sharing memory—instead, memory sharing is done by com-
municating using pipes, or “channels” as they are called in Go.
Electron
We chose to use the electron framework for the GUI for various reasons, mainly because it works
on every operating system, allows the use of web technologies on the desktop, and produces arguably
better looking interfaces than other technologies like QT or JavaFX, with native animation support.
Many consultants in the company are also familiar with web technologies, so they can contribute to
the development of the GUI when between contracts.
3.3. Life cycle model

Many development methodologies exist for software development nowadays, and after exam-
ining various ones, we found that the most appropriate one for our needs was the “waterfall with
subprojects” model (figure 3.3).
When using this method, and after identifying the global project requirements, the project is
divided into several modules, with each module developed separately following the waterfall model.
Completed modules are then merged to form a base to which other modules will be added incre-
mentally.
Figure 3.3: Waterfall with subprojects model
Waterfall-based models are often criticized for being inflexible—most developers nowadays claim
that it is impossible to predict all the requirements before seeing the working software, which could
lead to redoing all the steps again to adjust for the additional requirements. However, in our case,
we knew we would not suffer from its usual drawbacks, since we had enough feedback about the
first version and clear objectives for this one. We were sure our requirements would not change until
the initial release at the very least. We also are a small team, with all the members involved in the
full process, so all design decisions took into consideration the implementation details that are often
overlooked when using this sort of strict method.
The way we followed this model was by first specifying our software and hardware requirements
(as briefly described in section 2.4), then designing and splitting the system (as shown in figures 3.1
and 3.2) and making our technical choices based on them. We then moved to the design, implemen-
tation and test of each module (which will be discussed in chapter 4), integrating and testing them
whenever possible.
3.4. Personal contribu on

The first month and a half of my internship were dedicated to researching the subject, debugging
the old code, discovering how to use the tool and the extents of its capabilities, defining the new
requirements, designing the new version and building a prototype. By the end of this phase, I had
the required skills and knowledge to work on any part of the software stack of the project. However,
considering the time frame I had left for this mission, coupled with my tendencies, I decided to focus
on the API—the backbone of the project and the most complex part of the software.
I also had the role of a lead programmer in the team. This means that in addition to developing
the API, I had to come up with solutions to the problems that would arise, take decisions regard-
ing certain aspects of the software (especially concerning the workings of the application and the
communication protocols), and provide support for the other developers when needed.
Deliverable description
As shown in the WBS (figure 3.2), the API is made up of five parts:
1. An RPC Server (over TCP) that handles the connections of all client applications (whether it
is the official GUI, user scripts or the OpenOCD driver). It exposes some functions that the
clients can call using a particular protocol and broadcasts the responses to all the connected
clients
2. The hardware handler that links the API to the hardware. It handles the USB connection
with the FTDIs, the data parser and encoder, as well as the protocol-specific commands to
the FPGA
3. An HTTP client that connects the API to the remote community database;
4. The local component database;
5. The core, that spawns and supervises the different goroutines, connects the different parts
of the API, manages the configuration and the current state of the application, and logs the
errors that are raised during runtime.
The deliverable for each of these work packages is the source code, a usage documentation, as well as
working testing code.
Following the extension of the subject of my internship, I was, however, expected to design the
full API, as well as code, test, and document four out of these five packages—specifically the core, the
RPC server, the components database and part of its access layer, as well as a big part of the hardware
handler.
3.5. Schedule
Appendix A contains the Gantt charts of both the HardSploit and the security audits parts, and
it shows the exact amount of time I took to complete each of the work packages and their sub-tasks.
Ultimately, I spent 66 days working on HardSploit, of which half were for the study, design, test,
and documentation of the software, and the other half for the implementation.
4
Design & implementation of the system
By the end of the previous stage, we had the general architecture of the app, and an idea about
the workings of each of the five parts of the API. In this chapter, I will talk about each of the parts I
worked on in more detail, emphasizing the technical aspect this time.
It should be noted, however, that Golang takes a different approach to object oriented program-
ming than the ones used by traditional languages—including C++ and Java—, resulting in a slightly
different design that takes these differences into account. These differences include:
• Having no notion of a class, instead, structures can have functions attached to them, which
have access to the structures’ variables, and can modifying their data.
• Having no notion of inheritance, instead, Golang uses composition, which means that it is
possible to embed a structure into another.
• Interfaces can have package-private methods, and can be used as a type.
• Golang only has package-private visibility and public visibility, to which I added another one
in UML diagrams that means that the function is exposed through the RPC and can be called
from outside the API. The following table summarizes the visibility symbols that I used:
Icon for field Icon for method Visibility
□ ■ Package-private
▲ Public
● Exposed through the RPC
Table 4.1: Field and method visibility in class diagrams
The class diagrams presented in this chapter take these differences and others into consideration.
23
4. Design & implementation of the system 24
Additionally, I have only represented some of the classes and methods in order to provide better
clarity. Furthermore, the «go» stereotype in these diagrams means the function will spawn at least
one new goroutine when called.
4.1. The core

The core is the first process that is spawned when launching the application. First, it loads the
configuration from a TOML file, which is a configuration language designed to be easy to read and
use. This file contains everything that could vary from a user to another, along with some other data
that could be easily modified to support a custom firmware—that contains a different combination
of protocols supported—without touching the source code or recompiling the application.
It also launches all the other modules and listens on the errors they throw in order to log them
while trying to resolve the issue if possible.
4.2. The hardware handler

The hardware handler is the module that links the API to the HardSploit board. It exposes some
functions to the other modules that allows them to send queries and receive responses, of which
there are some protocol-specific functions used to interact with the audited electronic chip. Because
of hardware constraints, the communication has to go through two different hardware components
both made by FTDI—the first one for changing the current firmware on the FPGA (FT2232H), and
the second for sending commands to it and receiving responses (FT601).
As shown in the class diagram (figure 4.1), this module is made up of three packages fulfilling
different roles:
• The “D3xx” package that contains bindings to the driver of the FT601 and interacts directly
with the FPGA through it
• The “HSBoard” package that exposes higher order functions to the other modules and pack-
ages
• The “Modules” package which contains protocol-specific functions exposed to user scripts
and the GUI. Each of these protocols maps to a module on the FPGA, and because of this
coupling, this package also manages the FPGA firmware changes
I decided not to include the bindings to FT2232H’s driver in this diagram since it has nearly the same
architecture as the “D3xx” package.
All requests sent using this module’s exposed functions are encapsulated into a specific frame of
the form:
0 1 2 3 4 ... PSIZE+3 (bytes)

+-------+-------+-------+-------+------------------
| PSIZE | ID | FUNC | PARAMS
+-------+-------+-------+-------+------------------
Where PSIZE is the length of PARAMS in bytes, ID is the identifier of the FPGA module that
should receive the request, FUNC is the function to execute on this module, which are usually:
READ, WRITE, START_SNIFFING, STOP_SNIFFING, SET_PARAMETERS, and PARAMS
are these functions’ parameters, in a format that is different for each function. In the case of a WRITE
request for the SPI protocol, this is the start address of the memory page to write in, as well as the
data to write.
There is no one-to-one mapping between protocols and FPGA modules, as we could have a
firmware that contains several modules handling the same protocol, allowing to audit more than
one chip of the same type at the same time, in addition to a generic module that handles the LEDs
of the board and other functionalities not listed in the diagram.
As for the response—and because different modules are running concurrently on the FPGA—
when sending the data, it is encapsulated by a middleware to form a frame that looks like this:
0 1 2 3 .... 6 7 8 ... (bytes)

+-----+-----+-----+-----------+-----+-----+-----+-----------
| SIZED1 | ID1 | DATA1 | SIZED2 | ID2 | DATA2
+-----+-----+-----+-----------+-----+-----+-----+-----------
Where SIZEDX is the length of DATAX, and IDX the ID of the module that sent the data. This
frame then gets encapsulated into a USB packet by the FT601 and transmitted to the hardware han-
dler.
During the elaboration of the proof of concept, two main problems were noted:
1. A frame could be split into multiple USB packets during transmission;
2. Data from a module could be split into several incomplete parts that are either carried over
multiple frames, or interrupted by the data of another module.
However, these problems were both solved in the final version.
4.3. The RPC Server

The RPC server is the part giving the API its name. It exposes some internal functions to the
outside, and abstracts all the complexity of handling multiple connections and executing different
functions from the user.
Figure 4.1: Class diagram of the hardware handler

As shown in the class diagram (fig. 4.2), it is made up of multiple classes, of which the main
one is the “RPC” class that provides high level functionalities to other parts of the API, including a
way to register their own functions, by adding them to a list of pointers. It also starts a TCP listener
on a specific port that handles all incoming connections. The way it does so is by spawning two
goroutines for each new connection, one takes care of receiving commands from the client and the
other of sending responses to it. It then spawns a goroutine for each new command sent—that parses
the command, executes the right function, and reconstructs the response before sending it back—,
allowing for a totally asynchronous communication, as detailed in figure 4.3 that shows the example
of sending a command to the hardware.
Because the modules of the FPGA do not support parallel access, the RPC server also takes care
of this aspect, by ensuring that only one command is sent to a module at a time, through the use of
a mutex for each module.
The communication is encoded in Concise Binary Object Representation (CBOR), which is a
data format designed to produce very small payloads in a minimal time, and can be used to transfer
binary data, contrary to other popular formats. It is, however, not meant to be human-readable,
in contrast with other formats such as XML and JSON. CBOR libraries are also available in most
popular languages, making its choice compliant with our interoperability requirement.
4.4. The components database

The component database stores information about the target electronic chips. It contains the
name of the manufacturer of the component, its number of pins, the functions of each pin, the form
of its case, the protocols it supports, and the settings for each one of these protocols. My modeliza-
tion resulted in fifteen tables of various sizes to store all of this data. This data is then used either as
a way for the users to find the right component, or is transmitted to the FPGA that would use them
to interact with the chip. The primary objective of this database is to make the consultant gain the
time that would otherwise go towards reading the component’s datasheet.
4.5. Results & evalua on

All of the deliverables that were expected from me before this phase started were met, including
documentation of every function and a usage guide for each of the four modules that I coded. Con-
sidering the time frame I had, and the fact that I did not have any prior knowledge about Golang and
about hardware security and electronics, I consider this to be a huge success, especially compared to
the progress of other parts of the project, namely the GUI and the hardware, that are both still at
early stages of the work.
Figure 4.2: Part of the class diagram of the RPC server

Figure 4.3: Sequence diagram of an RPC communication

This, however, means that the API was not extensively tested. Indeed, tests of the hardware
handler were only done on a loopback that emulates the real hardware, as it was made using the same
electronic components as the one we decided to use in production. This loopback simply returned
the data it received after some time without any alteration, but it was very useful for testing. As for
the RPC server, I used a script I wrote in JavaScript to emulate requests sent by the GUI and multiple
other clients, and the overall result was quite satisfactory.
This does not mean that there is no room of improvement for the API. In fact it is still incom-
plete, as it is still missing the remote database connector and a small part of the hardware handler.
A possible improvement for the RPC server could also be considered. In fact, because of one of our
requirements (cf. section 2.4), the RPC server is currently broadcasting its responses to all the con-
nected clients, but it might be better to have a mechanism that allows each client to subscribe to the
changes of a specific module.
III
Security audits
31
1
Context
As everything is going online—including crime—companies are struggling to keep up. In fact, in

the 2019 edition of the “WEF Global Risks Report”, cybersecurity was the first technological concern
of the survey’s ∼1000 decision-making participants. This awareness of the dangers and potential
financial losses of cyber-attacks pushes more and more decision makers to allocate sufficient funds
to mitigate them. This budget generally goes towards employing specialists who would either install
and maintain defensive tools on a network or server (firewalls, IDS/IPS, WAFs, honeypots, etc.) and
the fees of these software or hardware solutions, or assess the security of an existing system by posing
as an attacker and trying to extract sensitive data while documenting the steps taken and proposing
solutions to the vulnerabilities found in the process, or towards training their employees and making
them more aware of common attacks and how to avoid them.
S3 provides all of these services to other companies, in addition to safety and governance con-
sulting, compliance audits, and security training sessions. During my internship, I had the chance
to take part in some of the missions the consultants were working on at the time, and I received a
three-day training about hardware auditing—one of the most prestigious trainings on this topic in
the world, and the only one of its kind in France.
32
2
Generalities
2.1. Descrip on
A security audit is an evaluation of the defenses of a program, infrastructure or device, in an
attempt to find vulnerabilities that an attacker could make use of, or to highlight weaknesses in an
organization’s security policy. During this assessment, the cybersecurity expert will usually either test
the compliance of the audited system with a specific standard (ISO 27001, GDPR, PCI-DSS, DSP2,
etc.) or pose as an external attacker and try to gain access to sensitive information.
A pentest is generally categorized as being either white box, gray box or black box. This distinc-
tion comes from the amount of information about the system the pentester has access to during the
audit.
Black Box In a black box penetration test little to no information is given to the auditor. In the
case of an application pentest, no source code is provided, and in the case of a network, only the
target IP range, and a VPN access in specific cases, are given. This kind of audit tries to simulate an
external attacker that has no knowledge of the inner workings of the system.
White Box In a white box penetration test almost all of the relevant information is given to the
auditor, this includes the architecture of the network and the applications installed on it in the case of
a network pentest, and the source code in an application pentest. Unlike the other types of testing,
white box penetration testers are generally able to perform static code analysis and other types of
tests, making the result more comprehensive, but at the cost of the time needed for the auditor to
compile all the information he has access to in order to identify potential points of weakness. The
33
2. Generalities 34
goal of these tests is to simulate a malicious insider who has knowledge of and possibly accounts with
low privileges for the target system. This is the most common type in compliance audits for on-site
pentests.
Gray Box Gray box penetration tests are a combination of white box and black box pentests in
which some information is provided to the auditor and some is hidden. For example, the organi-
zation could disclose the names of the applications exposed on the audited network but not their
versions, or provide partial access to the documentation or some accounts on the system. The pur-
pose of gray box pentesting is to provide a more focused and efficient assessment of the target’s secu-
rity than a black box test. Using the provided information, pentesters can focus their efforts on the
systems with the greatest risk and value from the start, rather than spending time determining this
information on their own.
2.2. Methodology
The methodology we used when realizing our pentests is highly dependent on the type of test
performed. However, it generally consisted of the following steps, as described in the Penetration
Testing Execution Standard (PTES):
1. Pre-engagement Interactions 5. Exploitation

2. Intelligence Gathering 6. Post Exploitation
3. Threat Modeling 7. Reporting
4. Vulnerability Analysis
Pre-engagement Interactions Before starting the technical aspect of the pentest, the client and
the tester must agree on certain aspects, mainly the scope and rules of engagement, what methodol-
ogy would be used, the start and end dates, the milestones, the goals, the payment terms, the liabilities
and responsibilities, whether DoS testing is permitted, etc.
Intelligence gathering In this step, the tester performs reconnaissance against a target to gather
as much information as possible to be utilized when penetrating the target during the vulnerability
assessment and exploitation phases. This information can consist of IP addresses, exposed services
and their versions, domain details, mail servers, network topology, operating systems used, and can
even include the internal workings of the target organization and its physical locations, depending
on the type of test requested. The goal here is to identify the potential attack surface and find infor-
mation that can be used to attack.
2. Generalities 35
Threat Modeling Threat modeling is an analysis which exposes possible threat vectors, leading
to a better understanding of the most critical assets, the possible attackers and the associated risks
and costs of an attack. It is often done following this process:
1. Gather relevant documentation
2. Identify and categorize primary and secondary assets
3. Identify and categorize threats and threat communities
4. Map threat communities against primary and secondary assets
This is interesting for the organization as it allows them to set their priorities and develop defen-
sive countermeasures, and interesting for the pentester as it helps him decide what to focus on and
develop an offensive strategy. However, in practice, this step is only performed in a white box pen-
etration test or when the client specifically asks for it.
Vulnerability Analysis This step is about searching for vulnerabilities either manually or by us-
ing automated scanning tools, and researching the potential exploitability of the findings. In many
cases, the vulnerability will be a reported software vulnerability in a commercial or open source soft-
ware package, and in this case, more details about it can generally be found in the CVE database or
exploit databases, in other cases the vulnerability can be a flaw in a process, or a misconfiguration or
usage of weak passwords or weak cryptographic algorithms. Code analysis (in white box pentests)
and reverse engineering (in black box pentests) are often performed in this step as well.
Exploitation Once the vulnerability analysis is finished and a list of vulnerabilities is properly
established, the tester plans how to establish access to the system or resource using his findings, by
prioritizing the ones with the highest impact and for which little countermeasures are in place. This
step can involve firewalls and IPS evasion, writing custom exploits, privilege escalation, etc. The goal
here is to see how far an attacker could get into the target system within the defined pentest scope.
Post Exploitation The goal of this step is to quantify the amount of damage an attacker could
inflict by exploiting the vulnerabilities found. This is done by determining the value of the compro-
mised machine based on the sensitivity of the data stored in it and its usefulness in further compro-
mization of the network. If additional machines are discovered during this step, and are part of the
scope, the tester may also audit it if he deems it necessary. The system is then returned to its original
state if possible, by removing all files, software, accounts and configuration file modifications.
Reporting The report is the only deliverable of a pentest, and, as such, it should be as complete
and extensive as possible. A good penetration test report contains two main sections: an executive
summary and the technical report. The executive summary is intended for the higher-ups of the
2. Generalities 36
audited organization and the people in charge of the security program, and contains the background
of the test (scope, conditions, limits etc.), a brief explanation of the test methodology and a non-
technical summary of the findings with their risk ranking (CVSS or DREAD), types and impacts.
The technical report provides more details about each vulnerability, we generally find a description,
an attack scenario accompanied generally by screenshots, the system it affects, as well as its type,
impact, severity, and remediation recommendations.
2.3. Tools
Selecting the tools to use during a penetration test depends on several factors like the type and the
depth of the engagement. In this section, I describe some of the ones I used during my internship.
2.3.1. Web & Network
Acunetix A fully-automated web vulnerability scanner that checks for more than 4500 vulnera-
bilities in all types of websites (Single Page Applications included). It also provides proof of
concept HTTP requests and basic remediation recommendations.
Burp suite A software solution that contains a collection of tools that are useful for web appli-
cation testing. It contains a proxy server that allows the tester to visualize and alter requests
and responses sent and received by the browser, an intruder tool that can perform fuzzing
and brute-force attacks, a crawler that maps the website, a repeater that can be used to resend
manually modified version of a request, and many other tools.
Nessus A network security scanner, with more than 100,000 plugins extending its features and the
ability to detect more than 45,000 vulnerabilities.
Nmap A tool used for host and service discovery within a network that can also be used to scan for
certain vulnerabilities.
Sqlmap A powerful, automated SQL injection detection and exploitation tool that supports a
wide variety of databases and injection types.
Wireshark A program used to passively capture and analyze all the traffic passing received or sent
on a specific interface in real time.
2.3.2. Reverse engineering
Binwalk A tool used to analyze binaries and firmware images for embedded files. It outputs the
name of the embedded file, its starting offset, its type and its length, facilitating its extraction
with Linux commands like dd.
2. Generalities 37
Frida A tool that allows the injection of a code into native applications on desktop and mobile
platforms, often used to analyze running processes and extract the content of their memory
or alter their behavior.
Ghidra A reverse engineering framework developed by the NSA. It includes analysis tools that fa-
cilitate the disassembly and decompilation of binary applications among other things.
2.3.3. Android
ApkTool A tool for reverse engineering Android APK files. It can decode resources, reverse the app
into “smali code,” and rebuild the APK after modification.
MobSF An automated open source mobile application pen-testing framework that can be used to
perform static and dynamic analysis and web API testing.
Objection A runtime mobile exploration toolkit based on Frida, particularly useful for bypassing
SSL pinning.
2.3.4. Others
John the Ripper A fast password cracking tool primarily used to recover Unix passwords.
RouterSploit A scanning and exploitation framework for embedded devices and routers.
Reaver A brute-force tool for the Wi-Fi Protected Setup (WPS) registrar PINs, used to recover
WPA/WPA2 passphrases.
3
Audit missions
During my time at S3 , I took part in seven penetration tests, and slightly contributed in several
others. In this chapter, I will briefly present five of them in a chronological order, and for each of
them, I will talk about the target of the test, the technologies it uses, and the threats that may face it.
I will also specify the duration of my intervention, and briefly talk about what I did, the results the
consultants and I achieved, and the main takeaway for me from the mission.
3.1. Pentest of a web pla orm

• Type: Gray box vulnerability assessment.
• Description: This platform centralizes the management of the content displayed on multiple
screens of different organizations—or in our case, hotels—by connecting over the internet to
multiple terminals, which are in turn connected to screens via a cable.
• Number of consultants: 1
• Duration: 11 days
• Duration of my intervention: 4 days
• Fingerprinting: The web platform uses AngularJS for the front-end, ASP.NET for the back-end,
and a Microsoft SQL Server database, and the terminal that manages the screens locally runs
on Windows Embedded.
• Assets & threats: This platform is generally provided as a SAAS, so it contains data from differ-
ent organizations. The assets are: 1. The physical screens of these organizations 2. The database
containing personal information about users 3. The servers hosting the platform. The threats
38
3. Audit missions 39
can either come from attackers targeting either a specific organization or the SAAS provider
itself.
• Personal contribution: In this pentest, I intervened mainly in the vulnerability analysis and the
exploitation phases of the pentest on the web application. Concretely, my task was to check
the results of automated scanners, look for authorization and privilege escalation flaws, and
devise an attack plan that could lead to the system being compromized, in order to see how
far an attacker could reach within the platform’s backend if he has a low privilege account in
one of the organizations.
• Tools used: Nmap, Burp suite, and sqlmap
• Vulnerabilities discovered:
• Two SQL injection vulnerabilities in POST parameters
• An XSS vulnerability, because the application allows the display of HTML pages on the
screens, and generates a preview link. This link could be used to trigger JavaScript code
in the context of the visiting user
• A CSRF on the password changing form
• Multiple authorization and privilege escalation flaws triggered by altering the raw HTTP
requests:
– A user with a “MANAGE_USERS” privilege can create a “super admin” user (a
user with all privileges for all organizations of the platform)
– A low privileged user can manage the terminals of other organizations
– A low privileged user can manage the assets of other organizations
– A disconnected user can view what is displayed on any screen of any organization
• A server side request forgery vulnerability, where an attacker can display internal server
files on one of the screens and take its screenshot, potentially getting access to sensitive
data
• Sensitive information exposure: in this case the hashed password of the connected user
is returned, as well as the internal path of the application on the server and the versions
of the used libraries
• Usage of vulnerable libraries
• Exploitation: Depending on the intents of the attacker and the assets he is after, the vulnera-
bilities presented could be exploited to reach his goal: If the target is the database, the SQL
injections could be used to extract any data; If the goal is a specific organization, different
attacks could be performed: 1. A social engineering attack on the target that makes use of ei-
ther the XSS vulnerability to perform specific actions, or the CSRF to change his password,
2. make use of the privilege escalation or authorization flaws, or 3. use the SQL injection vul-
nerability to change the password of the target user, since stacked queries were allowed in this
application. Lastly, if the SAAS provider is the target, the attacker could either use the SSRF
vulnerability to take screenshots of sensitive configuration files or just destroy or modify the
database using the SQLi. All of these exploitation paths were verified during the penetration
test, except for the one that makes use of the SSRF, since we did not know the exact path of
the application. However, this possibility of exploitation was verified later by the developers.
• Personal feedback: This pentest was the first professional pentest I had ever realized, and it
helped me gain valuable field experience, as well as understand the internals of a pentest and
discover all the official documents that should be produced prior to starting a pentest.
3.2. Code security audit

• Type: Black box vulnerability assessment.
• Description: This pentest targets an application that an aircraft manufacturer distributes to its
clients. It handles maintenance documentation and all the resources related to the aircraft
bought.
• Duration: 10 days
• Fingerprinting: This application is made up of two parts: A server that centralizes the manage-
ment of the documentation and the users, and clients that functions as a reader for their pro-
prietary document format. The server is made in Node.js and uses either SQLite, LDAP, or
Active Directory for authentication, its code is distributed without any obfuscation (which ul-
timately turned this pentest into gray box), the desktop client is made in C# and the Chromium
Embedded Framework, and the administration back-office in React.
• Assets & threats: In this pentest, the documentation in itself is the most important asset, as it is
only available to those who purchase the aircraft. The threats in this case are either the retrieval
of the documents decryption keys or one of the users’ password.
• Personal contribution: In this pentest, my main task was to audit the server and the administra-
tion back-office. The first step I did was use a tool that checks for third party dependencies
with known vulnerabilities, while simultaneously trying to understand how the application
works, determining the attack surface and establishing a checklist for the things I thought
might not be implemented securely. I then proceeded to verify the implemented security mea-
sures that protect the possible points of injection and the things I had noted on the checklist,
such as the robustness of the cryptographic mechanisms in use, brute-force protections, the
unzipping algorithm in use, etc.
• Tools used: Burp Suite, npm-audit, and a custom script.
• LDAP injection
• Vulnerable third party libraries
• Passwords are stored encrypted and not hashed
• Multiple hardcoded encryption keys
• Weak password policy: only digits are allowed, with a minimum of 6 characters required
• No brute-force protection
• Sensitive information disclosure: The whole administrator website’s code is loaded even
for unauthenticated users, revealing the architecture of the API and some other sensitive
information
• Exploitation: The most critical vulnerability found was the LDAP injection which allows an at-
tacker to bypass the authentication and retrieve the documents. However, this only works if
LDAP was in use as an authentication mechanism, which was a rare occurrence according to
the developers. The other vulnerabilities are only exploitable if the attacker has some knowl-
edge about the application (the hard-coded decryption key, the password policy in use, or the
SSL certificate’s private key), making the application fairly secure against outside threats but
weak against internal ones.
• Personal feedback: This pentest was where I had to put my software development expertise to
use the most, since I was already familiar with Node.js-based servers, but I only had a short
amount of time to perform this mission. The OWASP Code Review Guide was very helpful
though as it provided me with a good starting point and an idea about what to look for and
how to approach the code. It was the only pentest I participated in where the client explicitly
demanded to remove all related documents.
3.3. Pentest of an Android app and its cloud services

• Type: Gray box vulnerability assessment.
• Description: This pentest is actually not just for an Android app, but for a smart bracelet made
for people who practice water sports and for children to call for help in case of an emergency.
When a button is pushed, it notifies a rescue organization and family members, and shares
its location with them. The Android app is used to add people to notify or to receive alerts
among other things.
• Duration: 12 (6 for each consultant)
• Fingerprinting: This pentest targets two separate components that require different skill sets to
perform: The IoT device and the service it is connected to, and the android application, made
in React Native, and its cloud services, which are mainly Amazon Web Services like Amazon
Cognito for authentication, AWS AppSync for the GraphQL API and S3 for storing user
photos.
• Assets & threats: To prevent people from sending false alerts to rescue organizations, some in-
formation is collected about the users, such as their name, photo, phone number, and email,
making the user database of this application an attractive asset for attackers. The device also
occasionally sends its location to the servers, and protecting this data is necessary to uphold
the privacy policy of the product. Being able to spoof the identity of a user and send false
alerts on his behalf is also a risk that was considered in this pentest, as well as the ability to
control the device and make use of its multi-operator data plan.
• Personal contribution: In this pentest, my task was to reverse engineer the application and at-
tempt to find hidden information that could be used when attacking the servers, as well as
understand its inner workings and the way it contacts cloud services, and look for ways to
compromise the database. Following the successful decompilation of the application into its
original source code, and the discovery of some vulnerabilities and the AWS keys, this part of
the pentest turned into a code audit, but soon after I switched to the exploitation phase, in
which I had to develop a custom script that mimics part of the app in order to generate and
sign requests to interact with the services. In this pentest, I also wrote part of the report and
took part in the restitution meeting, in which I explained to the client and the developers the
severity of some of the vulnerabilities and suggested some solutions adapted to their case.
• Tools used: MobSF, ApkTool, Objection, Burp Suite and some custom scripts.
• Vulnerabilities discovered: Aside from the cryptographic vulnerabilities in the way the device
encrypts the messages it sends to the server and its firmware during an update, we found several
vulnerabilities in the mobile application:
• Improper Authorization: The GraphQL API only checks for the signature of the re-
quest (with the proper AWS keys) and does not perform any authorization check on
the individual users, making simple users use administrative functions and access sensi-
tive information.
• HTML injection: There is an exposed GraphQL mutation that is used by the applica-
tion to send welcome emails. It takes an email address and the real name as inputs, but
does not check if the email is already registered and does not sanitize the HTML in the
real name field.
• Uncontrolled resource consumption: The GraphQL endpoint executes queries no mat-
ter how expensive they are.
• Amazon S3 publicly-writable bucket: The S3 bucket used to store user photos is publicly
writable, making it usable by attackers as a private storage server or a way to replace any
user’s photo with one of his choosing.
• Information disclosure:
– The GraphQL introspection query is allowed, making the attacker know about
administrative or hidden queries that are possible to send to the API.
– The JavaScript source map file is available in the application assets, making it easy
to deobfuscate the application’s code.
• Exploitation: Several high severity vulnerabilities were discovered during the vulnerability anal-
ysis step that made us aware of even more threats than we initially thought of. The main
threat is in the access to the user database, and its exploitation is quite straightforward: Get
the API keys from the APK (which was made easier due to the source map file) and use them
to generate requests. However, basic knowledge of AWS services and GraphQL is needed to
obtain the list of possible queries and mutations and to use them correctly. The uncontrolled
resource consumption vulnerability is also a big security risk considering a single expensive
request would be able to bring down the server (by exceeding the limits on the AWS plan
used) as was demonstrated during the pentest. The HTML injection is also particularly dan-
gerous because it allows to send custom emails on behalf of the vendor that could be used for
social engineering attacks against any user, by putting a custom message as the target’s name
followed by an HTML comment (<!--) to remove the original text.
• Personal feedback: My previous knowledge about React Native, JavaScript, AWS, and GraphQL
helped me tremendously on this pentest, as I knew the weaknesses of these technologies and
started to look for them directly in the application. Nevertheless, this particular pentest was a
great learning experience for me, as it was the first time I had to communicate with the client
directly and write part of the report.
3.4. Pentest of a router

• Type: Black box penetration test without physical access.
• Description: This is an IT pentest targeting a wireless home hub modem and router distributed
by an internet access provider (ISP), it is one of the two tests our company had to perform for
the client, the other being a hardware gray box pentest which focused on the physical access to
the router. However, the firmware of the router was given to the IT pentest team, because it
was in the scope of the test and was normally retrievable from the hardware and interceptable
during updates.
• Duration: 11 days (2 days with two consultants then 7 days with one)

• Fingerprinting: This router uses the OpenWrt Linux operating system and has a wireless inter-
face that supports WPS, multiple Ethernet ports (LAN and WAN), and can be configured
through a web interface made up of two parts: The client-side JavaScript app built with
jQuery UI, and an RPC server that receives commands in a custom protocol relying on JSON
encoding and XPath queries.
• Assets & threats: The main threats to consider during this pentest is the illicit access to the
router or its network by an unauthorized user either via WiFi or the WAN. Because the router
is distributed by a particular ISP, its owner should also not be able to divert its intended usage
in any way, for example by making it work with other ISPs or as a business router.
• Personal contribution: Aside from quickly checking for WiFi vulnerabilities and scanning the
target, I worked on two main parts of the pentest: the reverse engineering of the firmware—
which led me to finding the XML file used as a database and discovering all the possible queries
of the RPC server— and the web interface, on which I had to look for the usual vulnerabilities
as well as study the process of authentication used and try to bypass it. Reverse engineering
the firmware was particularly challenging since I had to extract the Linux partition from the
firmware, then look for the bash files executed on startup, and finally disassemble and decom-
pile the server binary.
• Tools used: Reaver, Burp Suite, Binwalk, Ghidra, Acunetix, Nessus, Nmap, John the Ripper,
and a custom script.
• Use of an obsolete cryptographic hash function: The passwords are stored hashed in
MD5 in the XML file and are accessible with the right XPath query, including the pass-
word for a hidden super-admin account used for remote support.
• Misuse of the router: Using a special XPath query, the administrator can activate SSH
access on his router, giving him more control than intended for normal use.
• Weak Linux passwords: The password used for the root account of the router was
“root,” making it especially easy to access the router via SSH.
• Unprotected private key of the SSL certificate: The router uses a self-signed certificate
and stores its private key without any protection on the firmware, as such, all the routers
using this particular firmware had the same private key.
• A lack of a password brute-force protection.
• Exploitation: The obvious exploitation path that makes use of the vulnerabilities we found is
to enable SSH on the router and gain root access, since the root password is easy to guess.
However, the user must know the exact XPath expression, and to do so, he must find the
firmware and reverse engineer it first. Another attack route that could be considered is using
an MiTM attack on the user, by being in the same network as him, and waiting for him to
connect to his router by either HTTP or HTTPS (since we already have the private key), then
getting his MD5 hashed password and using it to access the router.
• Personal feedback: This pentest was particularly instructive since I had no idea of how routers
could be attacked at first. However, by the end of the pentest, I had learned the possible hard-
ware attacks on a real commercial device, and I had gained basic knowledge about firmware
reverse engineering and the ARM architecture. However, this test was in a lab setting, so we
did not test anything requiring internet access, such as the update protocol, which made this
pentest somewhat incomplete.
3.5. PSD2 compliance test

• Type: Compliance test, black box penetration test and white box audit.
• Description: Starting from mid-September 2019, all European banks will have to provide specific
payment institutions with an API that facilitates access to their clients’ data and making pay-
ments on their behalf. This API has to comply to the security requirements of the Revised
Payment Services Directive (PSD2) defined in the European Banking Authority Regulatory
Technical Standards (EBA RTS). Being also an auditing organization, S3 was tasked by some
banks with the compliance test to these regulations, and I will be talking in this section about
one of the two bank compliance tests that I had a chance to participate in.
• Duration: 8 days (4 days for each consultant)
• Technical description: There are various frameworks that aim to provide standard and exten-
sive technical documentation for PSD2 implementations, reducing in this way the number
of interpretations of the directive and the differences between bank APIs. The most renown
of these frameworks are the Berlin Group NextGenPSD2 Framework and the STET PSD2
API. These frameworks generally rely on well-established technology standards like REST,
OAuth2, JSON and HTTP-signatures, and this was also the case for the bank we tested.
• Methodology: The compliance test is based on “the frame of reference for the security of pay-
ment accounts access interfaces,” published by the Bank of France. It is divided into seven
security objectives, making up a total of 27 security requirements. The test was conducted
using the following methodology:
1. Documentation analysis, in which the auditor requests the necessary documents he
needs for the compliance test from the bank and analyzes them
2. Technical evaluation, first in black box then in white box
3. Consolidation and report writing

• Personal contribution: In this test, I took care of some of the technical tasks. Mainly—after un-
derstanding the protocols and the technical stack in use—I had to check for authorization and
implementation issues, and analyze the log files produced by various services on the internal
network, to check if the logged information was enough to perform cyberforensics in case of
an attack.
• Tools used: Burp suite, Linux utilities.
• Results: The bank is compliant to fifteen requirements, partially compliant to seven and not
compliant to five. Four of the requirements not satisfied are caused by a bad implementation
of the certificate validation process, causing unrestricted access to the payment API instead of
restricting it to authorized payment institutes. The fifth one is caused by the ability to bypass
user consent when making a payment. A second test was scheduled following this one to
check if the bank has fixed these issues.
• Personal feedback: I found compliance tests very interesting, because they need careful plan-
ning and constant interaction with the client so as not to miss any detail. They are also more
strict, and the consultant needs to be experienced in various fields related to cybersecurity that
are not limited by the technical aspects.
4
Hardware hacking training
As I had introduced in previous parts of this report, this training, officially named the “Hacking
Embedded Systems & IoT Training,” is one of the best-selling trainings about this subject, which
the company developed as a response to demands that followed the initial success of its product
“HardSploit”. It is made up of seven parts presented over three days, and aims to teach the neces-
sary knowledge of how to conduct hardware audits through theoretical lessons and several practical
sessions.
The program is as follows:
1. Basics of Hardware Hacking
• Historical context
• Electronics fundamentals
• Overview of IoT vulnerabilities
• Practical session: Components fingerprinting (identification of the components and
finding their datasheets)
2. How to attack the hardware
• Overview of available tools and ways to audit a product
• Differences between a hardware audit and a software audit
• Practical session: Sensitive data extraction using HardSploit
3. How to attack the software
• Overview of the different types of architectures (micro-controllers, FPGA), and how to
reach the software through electronic protocols (JTAG, I2C, SPI, UART, etc.)
• Introduction to side-channel attacks
• Practical session: Extracting a firmware through different protocols
47
4. Hardware hacking training 48
4. Practical session: Attacking a vulnerable electronic door lock

• Components fingerprinting
• Firmware extraction
• Firmware tempering
• Fuzzing
• Buffer overflow detection and exploitation
5. Securing the hardware
• Secure coding
• Overview of available hardware security measures
• Ways to limit unsolicited JTAG access
6. Hacking software-defined radio (SDR)
• SDR audit methodology
• Overview of available tools
• Practical session: Reverse-engineering a parking lot’s electronic display
7. Capture the flag: Hacking a mini-drone (applies everything learned during the training)
This training helped me gain knowledge of many new concepts and discover the importance of
performing hardware and embedded system audits on IoT devices.
IV
Conclusion
This six-month internship has overall met my expectations and was a valuable learning experi-
ence. It presented me with an opportunity to discover both a pentester’s and a software engineer’s
working lives, and allowed me to deepen my knowledge on both security and software development,
particularly on low level programming, and hardware audits. It also gave me the chance to apply the
theoretical knowledge gained in both of my schools, which aligns perfectly with the objectives of my
double diploma and my career goals. This internship also helped me improve my soft skills, such as
oral speaking, report writing, time management, and teamwork, since they are all skills we used on a
regular basis and during meetings.
Although the subject change was unexpected, I quickly adapted to the new situation that ended
up being in my favor, and tried to get the most out of it. Thus I am quite happy about both the
short-term and long-term results of my work. The short-term result being the improved security
and user privacy protection of various products ranging from a device made to save lives to payment
APIs, and the long-term being the contribution to a tool that might soon be used around the world
to improve the security of IoT devices.
49
Appendices
I
A
Gantt Charts
1.1. Ini al Chart

Figure A.1 represents the Gantt chart that was made during the first few weeks of my internship.
I ended up not following it because of the subject change mentioned in section 2 of part I, and other
various reasons.
1.2. Final Chart

Figure A.2 represents the result of my constant update of the chart whenever I had to change my
plans, to make it as close to the real progression as possible. I did not, however, represent small tasks,
like my unofficial pentest interventions, or some tasks that only took a single day or less.
II
A. Gantt Charts
Figure A.1: Initial Gan chart
III
A. Gantt Charts
Figure A.2: Final Gan chart
IV
Glossary
API (Application programming interface) A set of clearly defined methods of communi-

cation among various components. 10–12, 15, 17, 19, 21–25, 27, 30
CAN (Controller Area Network) A communication protocol, historically used in cars and
trains. 13–15
CBOR (Concise Binary Object Representation) A data format whose design goals include
the possibility of extremely small code size, fairly small message size, and extensibil-
ity without the need for version negotiation. 27
Embedded system A controller with a dedicated function within a larger mechanical or elec-
trical system, oen with real-time computing constraints. It is embedded as part of a
complete device oen including hardware and mechanical parts. 2, 8, 48
FPGA (Field-Programmable Gate Array) An integrated circuit designed to be configured

by the customer aer manufacturing for as many times as needed. 3, 8, 11, 12, 17, 21, 24,
25, 27
FTDI (Future Technology Devices International) A semiconductor device company spe-
cializing in Universal Serial Bus (USB) technology, as well as the common name of some
of their products (a device used to convert between USB and other communication
protocols). 21, 24
I2C (Inter-Integrated Circuit) A serial communication protocol. 13–15

IoT (Internet of Things) The concept of having electronic objects (mostly containing sen-
sors) connected to the internet in order to communicate with other objects or servers,
or to be remote controlled ii, 4, 5, 7, 8, 10, 12, 19, 42, 47–49
JTAG (Joint Test Action Group) A common hardware interface that provides a computer
with a way to communicate directly with the chips on a board. It can be used to test
printed circuit boards, debug embedded soware and flash the firmware on the de-
vice. 13, 14, 17
OpenOCD A free soware on-chip debugging, in-system programming and boundary-scan

testing tool for various ARM and MIPS systems. 12–15, 17, 21
V
Glossary VI
Pentest (Penetration testing) An authorized simulated cyberaack on a computer sys-

tem, performed to evaluate the security of the system. 33–35, 39–45
RPC (Remote Procedure Call) A protocol that one program can use to execute a procedure
or function in a program located in another address space 17, 21–23, 25, 27, 30
SPI (Serial Peripheral Interface) A synchronous serial communication protocol used in short-
distance communication. Usually links electronic components in embedded systems.
13–15, 25
SWD (Serial Wire Debug) A communication protocol. 13, 14
UART (Universal Asynchronous Receiver/Transmier) An asynchronous communication

protocol in which the data format and transmission speeds are configurable. It is used
to transfer data directly to and from controllers and microprocessors without need-
ing to go through intermediary hardware that might be too complex or too expensive.
10, 13, 14
XPath (XML Path language) A query language for selecting nodes from an XML document.
44
References
[1] Hardsploit. [Online]. Available: https://hardsploit.io
[2] Iot security: Game of trust. [Online]. Available: https://cyberstartupobservatory.com/

iot-security-game-of-trust/
[3] T. Marena. (2015, jul) Hardware security in the iot. [Online]. Available: http://www.
embedded-computing.com/embedded-computing-design/hardware-security-in-the-iot
[4] (2016, sep) Jtag explained (finally!): Why “iot”, software security engineers, and manufacturers
should care. [Online]. Available: https://blog.senr.io/blog/jtag-explained
[5] N. I. Council, “Disruptive civil technologies: Six technologies with potential impacts on us
interests out to 2025,” Conference Report CR 2008-07, 2008.
[6] A. Waibel. (2016) The art of bit-banging: Gaining full control of (nearly) any bus proto-
col. [Online]. Available: http://www.irongeek.com/i.php?page=videos/bsidescleveland2016/
202-the-art-of-bit-banging-gaining-full-control-of-nearly-any-bus-protocol-aaron-waibel
[7] J. J. Drake, Z. Lanier, C. Mulliner, P. O. Fora, S. A. Ridley, and G. Wicherski, Android Hacker’s
Handbook. Wiley Publishing, 2014, ch. 13.
[8] World Economic Forum, “The global risks report,” 2019. [Online]. Available: https:
//www.weforum.org/reports/the-global-risks-report-2019
[9] S. McConnell, Rapid Development: Taming Wild Software Schedules, 1st ed. Redmond, WA,
USA: Microsoft Press, 1996.
[10] R. Baloch, Ethical Hacking and Penetration Testing Guide, 1st ed. Boston, MA, USA: Auer-
bach Publications, 2014.
[11] D. Hafele, “Three different shades of ethical hacking: Black, white and gray,” GSEC Practical
Assignment, feb. 2004, version 1.4b, Option 1.
[12] Penetration testing execution standard. [Online]. Available: http://www.pentest-standard.

org
VII
References VIII
[13] OWASP Foundation, “Owasp code review guide,” 2018. [Online]. Available: https:
//www.owasp.org/images/5/53/OWASP_Code_Review_Guide_v2.pdf
[14] C. Heffner, “Exploiting embedded systems,” sep. 2011. [Online]. Available: http://www.
devttys0.com/2011/09/exploiting-embedded-systems-part-1/
[15] Bank of France, “Référentiel de sécurité des interfaces d’accès aux comptes de paiement,” dec.
2018. [Online]. Available: https://www.banque-france.fr/sites/default/files/media/2019/02/
22/referentiel-de-securite-des-interfaces-d-acces-2019-02-22-1138.pdf

Final Year Internship Report Cybersecuriy

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Year Internship Report Cybersecuriy

Uploaded by

Copyright:

Available Formats

Génie informatique - Master 2 IFI (CASPAR)

Soware development of a penetration

Internship ﬁnal report

Intern: Ayoub Ider Aghbal

4 Design & implementation of the system 23

4.4 The components database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

III Security audits 31

4 Hardware hacking training 47

1.1 Photo of a HardSploit board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Architecture of the first version of HardSploit . . . . . . . . . . . . . . . . . . . 11

3.1 Components diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Class diagram of the hardware handler . . . . . . . . . . . . . . . . . . . . . . . 26

A.1 Initial Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

2.1 Competitors overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Field and method visibility in class diagrams . . . . . . . . . . . . . . . . . . . . . 23

ANSSI Agence Nationale de la Sécurité des Systèmes d’information

1. Context of the internship

1.1. The company

SERMA Group is a holding that has subsidiaries offering services in 5 domains:

1.2. HardSploit team

This is a small R&D team working on the HardSploit tool.

1.3. Audit team

1.4. Work environment

2. Proposed work & changes to the ini al subject

1. Physical attacks on the device itself.

Figure 1.1: Photo of a HardSploit board

Figure 1.2: Screenshot of the GUI

2.1. Descrip on of the project

2.2. Current state of the project & needs assessment

Figure 2.1: Architecture of the ﬁrst version of HardSploit

2.3. Compe tors overview

2.4. Requirement deﬁni on

2.4.1. Func onal requirements

– SPI – JTAG – CAN

BusPirate I/S I/S I I I ✗ ✗ I ✗ ✗ ✗ ✓ ✗ 40

Hardsploit V1 I/S I I ✗ I ✗ I ✗ ✗ ✗ ✗ ✗ ✓ 325

Table 2.1: Competitors overview.

– SPI – I2C – CAN

2.4.2. Non-func onal requirements

3.1. General architecture & project sub-tasks

Figure 3.1: Components diagram

3.2. Technical choices

Figure 3.2: Work Breakdown Structure

• Support the integration of C shared libraries

The Go Programming Language

3.3. Life cycle model

Figure 3.3: Waterfall with subprojects model

3.4. Personal contribu on

Icon for ﬁeld Icon for method Visibility

Table 4.1: Field and method visibility in class diagrams

4.1. The core

4.2. The hardware handler

0 1 2 3 4 ... PSIZE+3 (bytes)

0 1 2 3 .... 6 7 8 ... (bytes)

4.3. The RPC Server

Figure 4.1: Class diagram of the hardware handler

4.4. The components database

4.5. Results & evalua on

Figure 4.2: Part of the class diagram of the RPC server

Figure 4.3: Sequence diagram of an RPC communication

As everything is going online—including crime—companies are struggling to keep up. In fact, in

1. Pre-engagement Interactions 5. Exploitation