# Dossier Démonstrateur V0
## Introduction
Le projet **Steganodon** a pour objectif d'aider les investigateurs forensique dans leurs tâches de stéganalyse. Concrètement, l'outil permettra d'identifier les probabilités d'utilisation de LSB dans une image.
Ce document a pour vocation de présenter le système établi : conception, développement et fonctionnement.
## Conception du système
### Schéma d'architecture

### Configuration du serveur de calcul
| Critère | Description |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| OS | Ubuntu Server 20 LTS |
| Alimentation | Corsair TX650M 80PLUS Gold |
| GPU | ASUS Carte Graphique ROG-STRIX-RTX2070-O8G-GAMING (OC Édition, Nvidia GeForce RTX 2070, 8Go Mémoire GDDR6) |
| RAM | Corsair Vengeance LPX 32Go (2x16Go) DDR4 3000MHz C16 XMP 2.0 Kit de Mémoire Haute Performance |
| Stockage | Western Digital Blue WD20EZRZ Disque Dur Interne 3,5 pouces 2 To SATA 6.0Gb/s + Crucial CT250MX500SSD1(Z) SSD interne MX500 (250Go, 3D NAND, SATA, 2,5 pouces) |
| Utilitaire de configuration | Ansible |
| Mode d'accès | Distant via openssh |
Table: Caractéristiques du serveur
| De/Vers | Machine | VPN | Internet |
| -------- | ----------- | --- | ------------ |
| Machine | - | - | DNS, HTTP(S) |
| VPN | SSH | - | - |
| Internet | Wake On Lan | - | - |
Table: Matrice de flux du serveur
Pour configurer le serveur, nous avons choisi d'utiliser **Ansible**. C'est un framework de déploiement de configuration, qui permet d'automatiser les tâches d'administration. Un avantage de cette solution est qu'elle ne nécessite pas d'agent qui s'exécute sur la machine distante, un accès SSH suffit.
Par rapport à un script bash, la mise à l'échelle est plus simple, même si nous n'en avons pas l'utilité puisque nous n'utilisons qu'une seule machine. On gagne aussi du temps de développement, car on indique l'état désiré sans se soucier de comment y parvenir. Ce temps gagné est important, car on peut alors passer plus de temps sur le coeur du projet.
Un autre avantage est que la description de l'état désiré de la machine est plutôt claire, ce qui permet de passer moins de temps à documenter notre paramétrage.
## Environnement de développement
Pour développer le système, nous utilisons les technologies suivantes :
* **Github** : utiliser un système de gestion de version permet à notre équipe de collaborer à distance ;
* **Python** : nous utilisons ce langage de programmation haut niveau pour le traitement des images ;
* **TensorFlow** : framework open source d'apprentissage automatique développé par Google, et développer en python ;
* **HTML/CSS/JS** : langages web pour la construction de l'interface en ligne.
Ainsi, la création du modèle de machine learning et son entraînement seront effectués grâce à Python et TensorFlow. Une fois que le modèle sera opérationnel, il sera exporté en JavaScript pour être intégré au sein d'une application web dédiée, qui sera, elle développée en HTML/CSS.

Pour le développement en python, nous avons respecté en partie la convention [PEP8](https://pep8.org/) et la convention [PEP257](https://www.python.org/dev/peps/pep-0257/), qui donne les règles de rédactions des docstrings. Les docstrings permettent de commenter un code python suivant une syntaxe qui permet la génération automatique de la documentation technique.
Pour documenter les deux programmes python que nous avons rédigés, nous utilisons ensuite `pdoc`, qui génère un document HTML. Ils se trouvent en annexe de ce dossier démonstrateur V0.
### Taux de couverture de la conception
| Tâches | Etat |
| ---------------------------------------------------------- |:----------:|
| Configuration du serveur de calcul | à faire |
| Création du dataset LSB | **fait** |
| Chargement du dataset à partir de données locales | **fait** |
| Création du modèle CNN | *en cours* |
| Entraînement du modèle | **fait** |
| Enregistrement de checkpoints au cours de l'entraînement | **fait** |
| Sauvegarde du modèle Tensorflow à la fin de l'entraînement | **fait** |
| Chargement des checkpoints pour reprise d'un entraînement | **fait** |
| Restauration du modèle entraîné | **fait** |
| Affichage des statistiques avec tensorboard | **fait** |
| Tests et corrections de l'entraînement | à faire |
| Chargement du modèle entraîné final dans une page web | à faire |
| Interface web pour utiliser le modèle en ligne | à faire |
Pour calculer le taux de couverture du développement, nous avons utilisé la formule suivante :
$T_{couverture} = \frac{(0.5 \times nb_{tâches\ en\ cours}) + nb_{tâches\ complétées}}{nb_{tâches}} \times 100$
Ce qui donne : $T_{couverture} = \frac{(0.5 \times 1) + 8}{13} \times 100 = 65\ \%$
Pour ce jalon 3, le taux de couverture de notre code est donc de **65 %**.
L'image suivante montre l'arborescence du démonstrateur V0 :
```
démonstrateur-V0
├── dataset-generator/
│ ├── cover-images/
│ │ └── sample.png
│ ├── dataset-generator.py
│ ├── dico.txt
│ ├── README.md
│ └── stego-images/
├── lsb-cnn/
│ ├── dataset/
│ │ ├── cover/
│ │ │ └── parrot.jpg
│ │ └── stego/
│ │ └── parrot_paint.jpg
│ ├── lsb-cnn.py
│ └── README.md
└── README.md
```
## Modèle CNN retenu
A ce stade du projet, nous n'avons pas encore déterminé le modèle le mieux adapté pour détecter du LSB, car nous n'avons pas encore pu tester notre code.
## Annexes