diff --git a/content/exercices/Attaque protocolaire.md b/content/exercices/Attaque protocolaire.md
deleted file mode 100644
index bdae6a6..0000000
--- a/content/exercices/Attaque protocolaire.md	
+++ /dev/null
@@ -1,59 +0,0 @@
----
-date: 2023-03-24T13:34:21+01:00
-title: Protocoles
----
-
-{{% tag %}}Attaque protocolaire{{% /tag %}}
-{{% tag %}}Protocole{{% /tag %}}
-
-Contexte du défi
-----------------
-
-Vos machines en production ne fonctionnent plus, elles n’arrêtent pas de crash. Vous investiguez.
-
-Infrastructure à mettre en place
---------------------------------
-
-Minimum 2 Windows Serveur ou Client dans la version permettant la CVE de fonctionner.
-1 machine dans le réseau infecté (pour une raison quelconque) par le binaire malveillant, origine de l’attaque.
-
-Pas-à-pas
----------
-
-Vous mettez en place un programme permettant de prendre le contrôle ou faire tomber une machine sous Windows, en utilisant la vulnérabilité CVE-2022-34718.
-
-Choisir une des machines, c’est la machine infectée. Il n’est pas obligé de justifier pourquoi ni par quoi cette machine a été infecté.
-
-La machine infectée sert de base pour l’attaquant.
-
-L’attaquant utilise la CVE-2022-34718 pour empêcher le fonctionnement des autres machines du réseau. 
-
-
-Risques
--------
-
-Comprendre un minimum IPv6.  
-Implémenter une vulnérabilité en vrai.  
-Trouver la bonne version de Windows.
-
-Traces à enregistrer
---------------------
-
-Fichiers à fournir :
-- Logs windows (tout type)
-- PCAP ou logs réseaux
-- Dump de RAM des machines, l’un d’entre eux doit contenir le binaire malveillant
-
-Questions à poser :
-- Que fait le binaire malveillant en détail 
-- Questions sur les impacts réseaux (PCAP)
-- Questions sur les impacts logs systèmes
-
-Liens
------
-
-[Article Forbes](https://www.forbes.com/sites/daveywinder/2022/09/14/new-microsoft-windows-zero-day-attack-confirmed-update-now/?sh=120cee4b7ba3)
-
-[PoC CVE-2022-34718 (windows IPv6)](https://github.com/SecLabResearchBV/CVE-2022-34718-PoC)
-
-[Analyse de la vulnérabilité](https://medium.com/numen-cyber-labs/analysis-and-summary-of-tcp-ip-protocol-remote-code-execution-vulnerability-cve-2022-34718-8fcc28538acf)
diff --git a/content/exercices/Healthcare.md b/content/exercices/Healthcare.md
new file mode 100644
index 0000000..26d91e0
--- /dev/null
+++ b/content/exercices/Healthcare.md
@@ -0,0 +1,49 @@
+---
+date: 2024-04-25T13:34:21+01:00
+title: Healthcare
+---
+
+Face à la surprenante découverte d'un produit concurrent étrangement similaire lors d'un salon technologique, la société Healthcare, pionnière en détection par imagerie médicale, se trouve contrainte d'initier un audit de sécurité rigoureux pour évaluer l'intégrité et la confidentialité de ses développements en recherche et développement.
+
+{{% tag %}}Social engineering{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Lors d’un salon technologique, la société Healthcare – startup pioniere dans la détection par imagerie médicale - découvre qu’un concurrent présente au salon un produit étrangement similaire a un de leurs produit en R&D.
+
+Afin de s’assurer qu’aucun vol de données n’est été réalisée au sein de leur entreprise, la société mandate un audite de sécurité.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+Aidez les étudiants à identifier le travail préparatoire à faire pour mettre en place cet exercice.
+
+Lorsque l'exercice se déroule sur un réseau, il convient de leur donner un schéma plutôt qu'une longue explication.
+
+
+Risques
+-------
+
+Si votre exercice n'est pas clef en main, quels éléments doivent encore être précisés/trouvés avant qu'il ne soit possible de commencer la réalisation de l'exercice (par exemple l'attaque initiale peut être laissé à l'appréciation des étudiants, ou bien peut-être faut-il trouver le logiciel vulnérable qui va bien, ...).
+
+
+Pas-à-pas
+---------
+
+A l’aidede social engineering, un ingénieur de la société Healthcare a été
+pris pour cible.
+
+1. Une pièce jointe envoyé par l’attaquant afin d’avoir un reverse-shell sur le PC de la victime.
+1. Vous utiliserez la CVE-2023-7028 afin de réinitialiser le mot de passe du GitLab interne. (Le gitlab n’estpas exposer sur internet).
+1. Vous exfiltrer le contenu du gitlab via la boite mail.
+
+
+Traces à enregistrer
+--------------------
+
+- Boite mail avec mail de phishing ciblé et piece jointe
+- Trafic réseau
+- `gitlab-rails/production_json.log`
+- `gitlab-rails/production_json.log`
diff --git a/content/exercices/Morse Attaque !.md b/content/exercices/Morse Attaque !.md
deleted file mode 100644
index b380124..0000000
--- a/content/exercices/Morse Attaque !.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-date: 2023-04-11T23:00:00+01:00
-title: Morse Attaque !
----
-
-Afin de diversifier des exercices sur des ordinateurs Intel, pourquoi ne pas travailler sur de l’Arduino ? Et faire un peu d’électronique par la même occasion ! Et puis, pourquoi pas ne pas apprendre le morse aussi ?
-
-{{% tag %}}Arduino{{% /tag %}}
-
-{{% tag %}}Système{{% /tag %}}
-
-{{% tag %}}Électronique{{% /tag %}}
-
-{{% tag %}}Moyen/Difficile{{% /tag %}}
-
-## Contexte
-
-JustHack est la boîte concurrente de votre entreprise, Hack’N’Snack. Depuis le lancement de son dernier prototype, elle vous fait de l’ombre.
-
-Afin de remédier à cela, votre directeur vous ordonne de vous y faire embaucher, afin de récupérer les plans de leur prochain prototype.
-
-Une fois arrivé à JustHack, ni une ni deux, vous réfléchissez au meilleur moyen d’exfiltrer des données sans que personne ne s’en rende compte : utiliser l’Arduino qu’on vous a fourni, en faisant clignoter en morse la/les LEDs qu’elle possède !
-
-À votre insu, votre collègue, trouvant bizarre de voir la/les LEDs de votre Arduino clignoter constamment, décide d’investiguer.
-
-## Infrastructure à mettre en place
-
-Seront nécessaires dans l'infrastructure :
-- 1 Arduino (ou une machine Linux avec une led si vous ne pouvez pas vous procurer un Arduino)
-
-## Pas-à-pas
-
-Apprendre le morse.
-Encoder les données à exfiltrer en morse.
-Faire clignoter la/les LEDs en morse.
-
-## Traces à enregistrer
-
-Fichiers à fournir :
-- Dump de RAM de l’Arduino
-- Et/ou dump de disque de l’Arduino
-
-Questions à poser :
-- Liste des condensats des fichiers exfiltrés
-
-## Liens
-
-[Le morse](https://fr.wikipedia.org/wiki/Code_Morse_international)
diff --git a/content/exercices/OLD New GOOD News.md b/content/exercices/OLD New GOOD News.md
deleted file mode 100644
index c1f4941..0000000
--- a/content/exercices/OLD New GOOD News.md	
+++ /dev/null
@@ -1,19 +0,0 @@
----
-date: 2023-03-24T13:34:21+01:00
-title: OLD New GOOD News
----
-
-OLD New GOOD News
-
-À ce jour, bien que le fax est très méconnu de la génération actuelle, il est encore énormément utilisé dans les entreprises. Il y a plus de 300 millions de numéros de fax encore utilisés à ce jour. Cette technologie peut cependant être un vecteur d’attaque de nos jours.
-Ce vecteur d’attaque a fait l’objet d’une étude par les chercheurs dans l’étude ci-dessous.
-
-## Infrastructure et pas-à-pas
-
-Décrit dans l’article ci-dessous.
-https://research.checkpoint.com/2018/sending-fax-back-to-the-dark-ages/
-
-## Traces à enregistrer :
-- Logs du fax,
-- Jpeg contenant le payload,
-- Logs du firewall montrant la latéralisation sur le réseau,
\ No newline at end of file
diff --git a/content/exercices/Once open a time, Long time ago.md b/content/exercices/Once open a time, Long time ago.md
deleted file mode 100644
index f936a4e..0000000
--- a/content/exercices/Once open a time, Long time ago.md	
+++ /dev/null
@@ -1,28 +0,0 @@
----
-date: 2023-03-24T13:34:21+01:00
-title: Once open a time, Long time ago…
----
-
-Once open a time, Long time ago …
-
-Certains attaquants ayant pris le contrôle d’une infrastructure peu surveiller  peuvent installer des services comme une plateforme de phishing.
-
-## Contexte
-Une injection sur un site vitrine a permis à l’attaquant de s’infiltrer sur le système. Il réalise une élévation de privilège et installe par la suite son infrastructure de phishing. 
-
-## Infrastructure  
-- 1 routeur 
-- 1 pare-feu
-- 3 serveurs/VM ;
-- 2 postes clients.  
-
-## Pas-à-Pas
-
-CVE-2021-21972
-Le client vSphere est affecté par une vulnérabilité d'exécution de code à distance dans un plugin vCenter Server. Un acteur malveillant disposant d'un accès réseau au port 443 pourrait exploiter ce problème pour exécuter des commandes avec des privilèges non restreints sur le système d'exploitation sous-jacent qui héberge le vCenter Server.
-Cette vulnérabilité est suivie en tant que CVE-2021-21972. Le plugin vCenter de vRealize Operations est à l'origine de cette vulnérabilité. Un attaquant peut exploiter le système vulnérable à distance en téléchargeant un fichier
-
-
-## Printnightmare :
-PrintNightmare est une vulnérabilité de sécurité critique affectant le système d'exploitation Microsoft Windows. La vulnérabilité se produit dans le service de spooler d'impression. Il existe deux variantes, l'une permettant l'exécution de code à distance (CVE-2021-34527), et l'autre conduisant à une élévation de privilèges (CVE-2021-1675).
-https://blog.sygnia.co/demystifying-the-print-nightmare-vulnerability
diff --git a/content/exercices/Tickets-toxiques.md b/content/exercices/Tickets-toxiques.md
new file mode 100644
index 0000000..d7a204d
--- /dev/null
+++ b/content/exercices/Tickets-toxiques.md
@@ -0,0 +1,26 @@
+---
+date: 2024-04-25T13:34:21+01:00
+title: Tickets toxiques
+---
+
+En pleine période de tension pour les hôpitaux, un prestataire spécialisé en systèmes informatiques hospitaliers se trouve face à un sérieux casse-tête : un déni de service frappe son système de gestion de tickets GLPI, menaçant le fonctionnement critique du support client.
+
+{{% tag %}}Escalade de privilèges{{% /tag %}}
+{{% tag %}}DoS{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Dans le cadre d’un support client, un prestataire spécialisé dans les SI hospitaliers expose un GLPI pour la gestion des tickets et du parc. Un déni de service est alors remarqué pendant une période de tension pour les hôpitaux et le prestataire.
+
+
+Pas-à-pas
+---------
+
+Vous utiliserez la CVE CVE-2022-35914 et CVE-2022-35947 pour provoquer un déni de service sur le GLPI mais également déposer fichiers malveillants pour permettre de maintenir un accès au système compromis.
+
+
+Traces à enregistrer
+--------------------
+
+- voir [CERTFR-2022-ALE-010](https://www.cert.ssi.gouv.fr/alerte/CERTFR-2022-ALE-010/)
diff --git a/content/exercices/ca_tourne.md b/content/exercices/ca_tourne.md
new file mode 100644
index 0000000..176873a
--- /dev/null
+++ b/content/exercices/ca_tourne.md
@@ -0,0 +1,46 @@
+---
+date: 2023-04-24T23:00:00+01:00
+title: Ça tourne !
+---
+
+Sur Windows, toutes les exécutions sont tracées par divers moyens. L’un d’eux est appelé « Prefetch ».
+
+L’objectif de l’exercice est de vous faire découvrir ce que sont les Prefetch.
+
+{{% tag %}}Windows{{% /tag %}}
+{{% tag %}}Prefetch{{% /tag %}}
+{{% tag %}}Moyen{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Le SOC d’une PME s’est rendu compte qu’elle s’était faite compromettre. Votre équipe de réponse à incidents a été appelée pour évaluer la situation et préparer la remédiation. Votre première tâche consiste à déterminer si l’attaquant est toujours présent, depuis quand et s’il a vu qu’il avait été repéré.
+
+Infrastructure à mettre en place
+--------------------------------
+
+Seront nécessaires dans l'infrastructure :
+1 VM (Windows)
+
+Pas-à-pas
+---------
+
+Réfléchir aux possibles actions/exécutions de l’attaquant et rendre cela crédible
+Faire du bruit pour que la réalisation ne soit pas trop rapide
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+un dump de disque de la VM
+
+Questions à poser :
+Date de la première apparition de l’attaquant : il y a un délai de 10 secondes après l’exécution pour que le fichier soit écrit sur le disque (petit piège pour le joueur)
+L’attaquant sait-il qu’il a été détecté ? Utilisation d’un wiper suite à sa détection (*sdelete* par exemple)
+…
+
+Ressources
+-----
+
+Outils d’Eric Zimmermann pour visualiser les prefetchs : PECmd.exe
+Outil de Nirsoft WinPrefetchView
\ No newline at end of file
diff --git a/content/exercices/do_not_cheat.md b/content/exercices/do_not_cheat.md
new file mode 100644
index 0000000..1cc6eb7
--- /dev/null
+++ b/content/exercices/do_not_cheat.md
@@ -0,0 +1,67 @@
+---
+date: 2024-04-24T13:34:21+01:00
+title: Tricher, c'est mal  
+---
+
+Les composants noyaux s'exécutant sur un système d'exploitation permettent une liberté d'action quasiment totale sur l'ensemble du système.
+
+À partir d’un composant noyau malveillant, un attaquant compromet une machine critique au sein d’une entreprise ou d’un particulier.
+
+Le logiciel malveillant doit mimer le comportement d'un cheat noyau.
+
+Ce Petit-Exercice est aussi l'occasion de voir comment fonctionne un cheat pour votre jeu préféré.
+/!\ Merci de ne pas l'utiliser hors de votre PFE.
+
+Ce Petit-Exercice peut être utilisé par plusieurs groupes facilement en changeant l'OS du composant noyau.
+
+{{% tag %}}Bas niveau - Noyau{{% /tag %}}
+
+{{% tag %}}Driver{{% /tag %}}
+
+{{% tag %}}Très difficile{{% /tag %}}
+
+Contexte du défi
+----------------
+
+L’utilisateur remarque que son PC ne fonctionne pas très bien depuis qu'il utilise le dernier cheat pour son jeu préféré.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+Il faut un PC capable de charger un driver noyau
+
+Pas-à-pas
+---------
+
+Vous devez créer un driver noyau linux/windows/macos malveillant.   
+Le driver fait des actions malveillantes et impacte le système du joueur.   
+Le joueur doit reconnaître les impacts, comprendre les actions, reverse le driver.  
+En reversant le driver il explique comment les actions ont eu lieu.
+
+Risques
+-------
+
+La mise en place de l’exercice peut être compliquée.   
+Il faut développer ou modifier un driver Windows/Linux ou MacOS.  
+Exercice bas-niveau, il faut se documenter pour comprendre le fonctionnement de l’environnement noyau de votre OS favori.
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- un dump de RAM de la machine cible
+- des logs pertinents de l’attaque
+
+Questions à poser :
+- Questions sur le code de votre driver
+- Questions sur les impacts du driver malveillant 
+
+
+Liens
+-----
+
+* [Ressources sur le développement noyau Windows](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/)
+* [Ressources sur le développement noyau MacOS](https://developer.apple.com/documentation/kernel)
+* [Ressources sur le développement noyau Linux](https://lwn.net/Kernel/LDD3/)
+* [How to become an evil cheater](https://www.unknowncheats.me/forum/anti-cheat-bypass/271733-driver-aka-kernel-mode.html)
\ No newline at end of file
diff --git a/content/exercices/engineering.md b/content/exercices/engineering.md
new file mode 100644
index 0000000..e5df57a
--- /dev/null
+++ b/content/exercices/engineering.md
@@ -0,0 +1,57 @@
+---
+date: 2024-04-24T13:34:21+01:00
+title: Engineering 
+---
+
+L'objectif de cet exercice est d'implémenter un engine SSL qui permettrait de réduire la sécurité cryptographique de celui qui l'utilise.
+
+Le joueur devra comprendre ce qui a été rendu vulnérable et déchiffrer lui-même le contenu chiffré avec l'aide de l'engine.
+
+{{% tag %}}Cryptographie{{% /tag %}}
+
+{{% tag %}}OpenSSL Engine{{% /tag %}}
+
+{{% tag %}}Facile / Moyen{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Une entreprise remarque que des informations internes se retrouvent divulguées sur Internet. Pourtant, ces informations sont chiffrées de bout en bout...
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+2 PCs et 1 routeur
+
+Pas-à-pas
+---------
+
+Vous devez créer ou modifier un engine OpenSSL.   
+L'engine doit être utilisé pour réduire la sécurité des secrets.   
+Le joueur doit reconnaître les impacts, comprendre les actions de l'engine.  
+
+Risques
+-------
+
+OpenSSL peut être assez lourd à prendre en main.
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- un dump de RAM de la machine cible
+- des logs pertinents de l’attaque
+
+Questions à poser :
+- Questions sur le code de votre engine
+- Questions sur les impacts de l'engine
+- Le contenu des fichiers chiffrés 
+
+
+Liens
+-----
+
+* [openSSL](https://www.openssl.org)
+* [openSSL engines](https://www.openssl.org/docs/man1.0.2/man3/engine.html)
+* [openSSL SSTIC paper](https://www.sstic.org/media/SSTIC2023/SSTIC-actes/exploring_openssl_engines_to_smash_cryptography/SSTIC2023-Article-exploring_openssl_engines_to_smash_cryptography-goudarzi_valadon.pdf)
diff --git a/content/exercices/full_power.md b/content/exercices/full_power.md
new file mode 100644
index 0000000..95da8fa
--- /dev/null
+++ b/content/exercices/full_power.md
@@ -0,0 +1,63 @@
+---
+date: 2024-04-24T13:34:21+01:00
+title: Unlimited power !  
+---
+
+Les composants noyaux s'exécutant sur un système d'exploitation permettent une liberté d'action quasiment totale sur l'ensemble du système.
+
+À partir d'une vulnérabilité d'un composant noyau légitime, un attaquant compromet une machine critique au sein d’une entreprise ou d’un particulier.
+
+Vous créez ou utilisez un driver noyau vulnérable comme point de départ.
+
+Ce Petit-Exercice peut être utilisé par plusieurs groupes facilement en changeant l'OS du composant noyau.
+
+{{% tag %}}Bas niveau - Noyau{{% /tag %}}
+
+{{% tag %}}Driver{{% /tag %}}
+
+{{% tag %}}Moyennement difficile{{% /tag %}}
+
+Contexte du défi
+----------------
+
+L’utilisateur remarque que son PC ne fonctionne pas très bien. Il lui arrive d'avoir des erreurs impossibles à corriger (BSOD, Grey screen, kernel paninc, ...). Vous investiguez.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+Il faut un PC capable de charger un driver noyau
+
+Pas-à-pas
+---------
+
+Vous devez créer ou utiliser un driver noyau vulnérable linux/windows/macos.   
+Le driver présente une vulnérabilité permettant de faire des actions malveillantes et impacte le système du joueur.   
+Le joueur doit reconnaître les impacts, comprendre les actions, reverse le driver.  
+En reversant le driver il explique comment les actions ont eu lieu.
+
+Risques
+-------
+
+La mise en place de l’exercice peut être compliquée.   
+Il faut développer ou modifier un driver Windows/Linux ou MacOS ou utiliser un vieux driver déjà vulnérable.
+Exercice bas-niveau, il faut se documenter pour comprendre le fonctionnement de l’environnement de votre OS favori.
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- un dump de RAM de la machine cible
+- des logs pertinents de l’attaque
+
+Questions à poser :
+- Questions sur le code de votre driver
+- Questions sur les impacts du driver malveillant 
+
+
+Liens
+-----
+
+* [Ressources sur le développement noyau Windows](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/)
+* [Ressources sur le développement noyau MacOS](https://developer.apple.com/documentation/kernel)
+* [Ressources sur le développement noyau Linux](https://lwn.net/Kernel/LDD3/)
\ No newline at end of file
diff --git a/content/exercices/hello_from_the_other_side.md b/content/exercices/hello_from_the_other_side.md
new file mode 100644
index 0000000..5e580a9
--- /dev/null
+++ b/content/exercices/hello_from_the_other_side.md
@@ -0,0 +1,54 @@
+---
+date: 2024-04-24T13:34:21+01:00
+title: Hello from the other side  
+---
+
+L'objectif de l'exercice est de faire communiquer deux appareils qui échangent des informations de manière discrète.
+
+Le but est d'extraire des données d'un ordinateur n'ayant pas internet à un autre ordinateur qui jouera le rôle de l'extracteur. 
+
+Les deux appareils dialoguent via des sons de fréquences très hautes ou très basses de sorte qu'un être humain ne puisse pas entendre la conversation.
+
+Vous pouvez adapter le moyen de communication.
+
+{{% tag %}}Beep boop{{% /tag %}}
+
+{{% tag %}}Difficile{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Vous remarquez que certains de vos appareils réagissent bizarrement ces derniers temps. Les capteurs de sons détectent constamment des interférences. Le joueur doit investiguer.
+
+Vous pouvez adopter le contexte en fonction de votre élément déclencheur ou techno utilisée.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+2 PCs
+
+Pas-à-pas
+---------
+
+Vous devez mettre en place un protocole d'échange de données.
+Les deux machines doivent communiquer entre elles sans connexion internet ou locale physique.
+
+Risques
+-------
+
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- des enregistrements qui permettent d'élucider l'affaire
+- quand le joueur a compris, le contenu du logiciel qui permet l'échange
+
+Questions à poser :
+- La méthode utilisée
+- Comment fonctionne le protocole
+- Le fonctionnement du logiciel
+
+Liens
+-----
diff --git a/content/exercices/imprimante_malveillante.md b/content/exercices/imprimante_malveillante.md
new file mode 100644
index 0000000..6fa1ba6
--- /dev/null
+++ b/content/exercices/imprimante_malveillante.md
@@ -0,0 +1,68 @@
+---
+date: 2024-04-04
+title: imprimante malveillante 
+---
+
+L'objectif du défi est d'auditer un système de contrôle d'imprimante 3d, afin de trouver les soucis.
+
+L'idée de serait d'avoir un système linux gérant un parc d'imprimante 3d avec pa exemple Octoprint. Ce logiciel de gestion permet d'utiliser des plugins permettant d'influer sur la gestion des impression. On pourrait imaginer qu'une entreprise concurante ai voulu causer des soucis. Plusieurs piste à explorer :
+
+- problème sur l'authentification sur le soft
+- logiciel exposé sur internet
+- installation d'un plugin backdooré
+- modification d'un plugin déjà existant
+
+Les plugins sont en python.
+
+Dans les trucs marrant qui pourrait être à faire:
+
+- modification du GCODE envoyé à l'imprimante (par exemple enelver une couche sur 2 pour rentre que l'impression fasse n'importe quoi, ou modifier un peu les coordonnées généré pour que le resultat soit moche, ou forcer l'impression d'un message de rançon ?)
+
+Le but serait de faire trouver les différents soucis au joueur.
+
+
+{{% tag %}}Python{{% /tag %}}
+
+{{% tag %}}Audit de code{{% /tag %}}
+
+{{% tag %}}Moyen{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Votre super entreprise d'impression 3d est au bord de la faillite ! Toutes les impressions que vous réalisez pour des clients échoue !
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+- Un serveur qui simulera le serveur de gestion (ça peut être un raspberry pi)
+- Idéalement un accès à une vrai imprimante 3d pour tester mais sinon il est possible de setup une imprimante virtuelle pour debug (https://docs.octoprint.org/en/master/development/virtual_printer.html). 
+
+Pas-à-pas
+---------
+
+
+Risques
+-------
+
+- Si aucun accès à une vrai imprimante il pourra être difficile de valider le resultat final
+
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+
+- le file system du server
+
+Questions à poser :
+
+- vulnérabilité(s) ? 
+
+
+Liens
+-----
+
+- https://docs.octoprint.org/en/master/development/virtual_printer.html
+- https://octoprint.org/
\ No newline at end of file
diff --git a/content/exercices/la_cle_du_succes.md b/content/exercices/la_cle_du_succes.md
new file mode 100644
index 0000000..8786c51
--- /dev/null
+++ b/content/exercices/la_cle_du_succes.md
@@ -0,0 +1,49 @@
+---
+date: 2023-04-24T23:00:00+01:00
+title: La clé du succès
+---
+
+L’objectif de cet exercice est de vous faire découvrir les traces laissées par les clés USB.
+
+{{% tag %}}Evtx{{% /tag %}}
+{{% tag %}}Registres{{% /tag %}}
+{{% tag %}}USB{{% /tag %}}
+{{% tag %}}Moyen{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Malheur ! La startup Rob’Bot a sorti son nouveau chien robot : c’est le même modèle que celui que votre équipe allait dévoiler deux jours plus tard ! Vous en êtes sûrs, ils ont réussi à vous voler les plans et probablement plus… mais comment ?
+
+Infrastructure à mettre en place
+--------------------------------
+
+Seront nécessaires dans l'infrastructure :
+1 VM (Windows)
+
+Pas-à-pas
+---------
+
+Utiliser RegistryExplorer pour visualiser les registres et trouver les clés contenant les valeurs demandées
+Déterminer les logs EVTX (Event Viewer), qui permettent aussi de répondre à certaines questions
+Dans les « Documents Récents », il est possible de voir si un fichier a été ouvert sur une clé
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+un dump de disque de la VM
+
+Questions à poser :
+Date de première connexion/dernière connexion de la clé USB
+Nom et modèle de la clé
+Numéro de série
+Lettre où elle a été montée lors de son dernier branchement
+Quel(s) fichier(s) a/ont été ouvert(s) par inadvertance sur la clé ?
+…
+
+Ressources
+-----
+
+Outils d’Eric Zimmermann : RegistryExplorer (a un certain nombre de plugins pour aider l’investigateur)
+Utiliser l’Event Viewer de Windows pour visualiser les logs
\ No newline at end of file
diff --git a/content/exercices/packing_infini.md b/content/exercices/packing_infini.md
new file mode 100644
index 0000000..848e7ff
--- /dev/null
+++ b/content/exercices/packing_infini.md
@@ -0,0 +1,58 @@
+---
+date: 2024-04-04
+title: Packing vers l'infini
+---
+
+Un malware peut souvent utiliser du packing pour se dissimuler. Ils existe des packer connu ainsi que des solutions pour "unpack" ces malwares. L'unpacking peut aussi se faire à la main (analyse dynamique en essaynt par exemple de break au moment ou le binaire est dechiffré).
+
+Il pourrait être marrant de faire son propre système de packing, puis de faire en sorte que le malware se pack par exemple 1000 fois? 5000 fois ?. Le flag se trouvant dans la version finale. Cela obligerait le joueur a automatiser l'unpacking. 
+
+
+
+
+{{% tag %}}Reverse{{% /tag %}}
+
+{{% tag %}}Malware{{% /tag %}}
+
+{{% tag %}}Moyen{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Un malware a reverse
+
+Infrastructure à mettre en place
+--------------------------------
+
+
+Pas-à-pas
+---------
+
+- réaliser un packer custom (si possible pas non plus trop complexe)
+- faire en sorte de pouvoir pack N fois le malware
+- cacher le flag dans le binaire final packer de très très nombreuse fois.
+
+
+Risques
+-------
+
+- Ne pas utiliser de packer connu et avec un système d'unpack déjà automatisé
+- faire un packer trop complexe
+- Ne pas avoir un binaire final gigantesque (après on peut se supposer que ça peut être ok d'avoir un binaire de plusieurs dizaines de mega voir plus suivant comment votre packing se fait)
+
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- le malware packé X fois
+
+Questions à poser :
+
+- flag final
+- question sur le packer ? 
+
+
+Liens
+-----
+
diff --git a/content/exercices/passthrough.md b/content/exercices/passthrough.md
new file mode 100644
index 0000000..4344847
--- /dev/null
+++ b/content/exercices/passthrough.md
@@ -0,0 +1,54 @@
+---
+date: 2024-04-24T13:34:21+01:00
+title: Passthrough  
+---
+
+L'objectif de l'exercice est de modifier openSSH pour qu'il puisse vous laisser entrer dans n'importe quel système sur lequel il serait installé.
+
+{{% tag %}}Compromission{{% /tag %}}
+
+{{% tag %}}OpenSSH{{% /tag %}}
+
+{{% tag %}}Facile{{% /tag %}}
+
+Contexte du défi
+----------------
+
+Une entreprise voit ses serveurs déconnectés à un moment inopportun. Elle doute que ce soit un hasard et investigue.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+1 PC faisant tourner openSSH
+
+Pas-à-pas
+---------
+
+Vous devez modifier openSSH.   
+L'openSSH modifié doit vous permettre de rentrer sur n'importe quel PC (windows/linux/macos).
+Après être rentré sur la cible, vous devez exécuter des actions que le joueur devra comprendre.
+Le joueur doit reconnaître les impacts, comprendre les actions de l'openSSH modifié.
+  
+
+Risques
+-------
+
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+- un dump de RAM de la machine cible
+- des logs pertinents de l’attaque
+
+Questions à poser :
+- Questions sur le code de votre openSSH
+- Questions sur les impacts
+- Les actions entreprises après la connexion SSH
+
+
+Liens
+-----
+
+* [xz-vuln](https://xeiaso.net/notes/2024/xz-vuln/)
diff --git a/content/exercices/voyage_en_Ouifi.md b/content/exercices/voyage_en_Ouifi.md
new file mode 100644
index 0000000..9a0504b
--- /dev/null
+++ b/content/exercices/voyage_en_Ouifi.md
@@ -0,0 +1,54 @@
+---
+date: 2024-04-04
+title: 
+---
+
+{{% tag %}}facile{{% /tag %}}
+
+{{% tag %}}Osint{{% /tag %}}
+
+
+Contexte du défi
+----------------
+
+L'idée est de jouer le role d'un enquêteur voulant retrouver le parcours d'un criminel arrêté. Après investigation de son téléphone on a pu récupérer les logs de tous les wifi qu'il a pu récupérer (trouver une raison / application / justification que ces logs sont stocké, un peu comme si il avait un "iwlist scan" en permanence, on peut justifier qu'il s'agit d'un pc si sur téléphone ce n'est pas possible).
+
+Le parcours du criminel pourrait être analysé en comparant les ssid découvert à une carte publique des ssid (comme sur https://wigle.net/).
+
+Libre court à votre imagination pour trouver des questions à poser / lieux visité / etc.. mais je suppose qu'il y moyen de faire un truc marrant.
+
+
+Infrastructure à mettre en place
+--------------------------------
+
+- Soit vous générez vos données
+- soit un setup (téléphone/ pc) pouvant logs les wifi, et vous faites vous même le parcours dans paris par exemple. (plus fun?)
+
+Sachant que vous pouvez contribuer aussi à wiggle en exportant sur le site des resultats de découvertes de ssids (https://wigle.net/uploads)
+
+Pas-à-pas
+---------
+
+
+
+Risques
+-------
+
+
+Traces à enregistrer
+--------------------
+
+Fichiers à fournir :
+
+- les logs wifi
+
+Questions à poser :
+
+- libre court à votre imagination, c'est une sorte d'osint du coup il y a pas mal de possiblités
+
+
+Liens
+-----
+
+- https://wigle.net/
+- https://openwifimap.net/
\ No newline at end of file