👩🏿‍💻 👇🏽 🍢 Protection et piratage de la Xbox 360 (partie 1) 🧑🏼‍🤝‍🧑🏻 🔭 🚌

Vous avez probablement entendu parler de la console de jeu Xbox 360 et qu'elle "clignote". Par «firmware», on entend ici un contournement des mécanismes de protection intégrés pour le lancement de copies de jeux et de logiciels propriétaires. Et ici, des questions se posent! Quels mécanismes, comment se déplacent-ils? Qu'est-ce que les développeurs ont fait, comment ont-ils réussi à le contourner? En fait, le sujet est très vaste et intéressant, en particulier pour la Xbox 360 - vous pouvez trouver ici des vulnérabilités logicielles, des défauts matériels et une magie absolument magique. Intéressant? Venez! Dans la première partie, nous vous présentons l'hyperviseur, les lecteurs et le firmware ...

Rencontrez le sujet

La console de jeu Xbox 360 est sortie en 2005 et n'a pas subi de changements dans les caractéristiques du fer depuis lors. Tout le temps qu'il était sorti, c'était pareil:

Processeur PowerPC 3,2 GHz, / 3 cœurs
GPU 500 MHz
512 Mo de RAM
DVD-ROM SATA
Disque dur SATA (en option)

Oui, la conception a changé avec le temps, les nanomètres ont diminué:

Néanmoins, tous les jeux fonctionnaient aussi bien sur toutes les «révisions» des consoles - c'est exactement le cas lorsque les jeux modernes peuvent être exécutés sur du matériel 2005.

Au moment de la publication, une déclaration forte a été faite que la console a été développée aussi sécurisée que possible - puces personnalisées avec protection au niveau matériel, et en général, les pirates n'ont pas encore vu cela:

Il y aura des niveaux de sécurité dans cette boîte que la communauté des hackers n'a jamais vus auparavant

Qu'est-ce que les développeurs ont trouvé?

Premièrement , ils ont tout fait pour que le code de programme du système ne puisse pas être obtenu . Une ROM de 32 Ko contenant un chargeur principal (1BL) et une SRAM de 64 Ko dans laquelle elle a été exécutée ont été intégrées au processeur central. Il est très, très difficile d'obtenir le contenu d'une ROM à partir d'une puce CPU:

Deuxièmement , des fusibles spéciaux ont été placés dans le même processeur - des cavaliers brûlés (littéralement à haute tension), une sorte de mémoire autrefois programmable. Les fusibles comprenaient:

Bits de verrouillage d'interface JTAG
bits déterminant le but du préfixe (retail / devkit / testkit)
clé de processeur 128 bits unique
Compteurs de valeur de verrouillage (LDV) pour désactiver la rétrogradation

Oui, la quantité de fusion est limitée. Si vous parvenez à mettre à jour votre console 80 fois de suite, le compteur CFLDV se terminera et ... je ne sais pas, je n'ai pas essayé de le faire. Probablement, le préfixe ne sera plus mis à jour.

Troisièmement , les développeurs ont mis en place une chaîne de confiance . Pour vérifier l'authenticité des chargeurs de démarrage, une combinaison d'algorithmes modernes (à l'époque) SHA-1 et RSA-2048 a été utilisée, ce qui excluait la possibilité de lancer votre propre code ou de modifier non autorisé les chargeurs de démarrage même si vous avez en quelque sorte obtenu toutes les clés de la console et avez pu reconstruire le système .

Quatrièmement , les développeurs ont décidé d'aller plus loin sur le principe de "ne faire confiance à personne" et de mettre un module matériel spécial pour protéger la RAM dans le même CPU malheureux ! Avec son aide, toutes les zones avec le code du programme ont été cryptées et la surveillance de l'intégrité a été activée pour les zones les plus importantes (hyperviseur)!

Ce faisant, les développeurs se sont défendus contre les attaques DMA lorsque, via des périphériques externes ayant accès à la RAM, ils modifient le code du programme système dans la RAM.

Enfin , l' hyperviseur a traité de la différenciation des droits en régions mémoire . Seul, il pouvait rendre les pages exécutables, bien sûr, avant de vérifier la signature numérique, il était donc impossible de télécharger du code non signé ou d'exécuter quelque chose à partir de la zone de données, même en raison d'une vulnérabilité dans un pilote ou un jeu (l'axe et les jeux ont été lancés avec les droits du noyau) .

En conséquence, le système d'exploitation Xbox 360 était bien protégé et, par conséquent, le DVD-ROM a été choisi comme premier vecteur d'attaque.

Nous commençons ... des sauvegardes!

Dans la Xbox 360, un DVD double couche a été choisi comme support principal pour les jeux. Naturellement, des mécanismes de défense étaient également présents ici:

l'échange de données avec DVD-ROM a été crypté avec une clé unique
au début du disque, il y avait des «secteurs de sécurité» spéciaux pour confirmer les licences
les fichiers exécutables sur le disque ont été signés numériquement

Mais beaucoup moins d'attention a été accordée à la protection du lecteur de DVD qu'au système principal. La console de jeu a montré trop de confiance au lecteur de DVD - c'est le DVD-ROM qui a déterminé la licence du disque. De plus, le firmware était stocké dans la mémoire externe et pouvait être lu par le programmeur:

En conséquence, le 14 mai 2006, commodore4eva (c4eva) a publié le premier firmware modifié pour piloter le modèle TS-H943:

LISEZ-MOI pour la version du firmware

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

Le micrologiciel lisait les secteurs de sécurité à partir de zones fixes sur un disque DVD et trompait la console, ce qui faisait penser qu'un disque sous licence avait été inséré.

Dans le même temps, le firmware 0800 est sorti, conçu pour créer des copies de jeux et lire les secteurs de sécurité. Le lecteur Xbox 360, flashé avec un tel firmware, a été détecté sur l'ordinateur et pouvait lire entièrement les secteurs du disque de jeu.

LISEZ-MOI sur l'utilisation du firmware 0800

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Un autre jeu pourrait être partiellement copié avec l'astuce suivante:

mettre dans un ordinateur DVD-ROM disque ordinaire à deux couches
attendez qu'il se calme et cesse de tourner
avec un trombone, ouvrez le plateau et changez le lecteur pour le jeu depuis la Xbox 360
fermez le plateau et créez une image disque!

(Cela ne fonctionnait pas sur tous les modèles de DVD-ROM)

La chose la plus importante est que le lecteur a été flashé exclusivement par logiciel, avec des commandes ATA spéciales. Le kit comprenait un programme spécial pour lire le firmware d'origine et écrire modifié. Dans le firmware d'origine, la clé précieuse était stockée, avec laquelle le disque était lié à la Xbox 360:

La perte de la clé signifiait que même les disques sous licence ne pouvaient pas être lancés, donc certains ont écrit la clé dans un cahier, l'ont enregistrée dans la mesure du possible, c'était la connaissance la plus chère.

Un autre sujet était la panique du jeu en ligne. Tout le monde avait peur que Microsoft découvre que le lecteur avait été modifié et désactiverait la console à distance. Certains ont même fait un mod matériel pour basculer entre le firmware d'usine et le firmware modifié:

Ils ont joué sur le firmware d'origine «sous licence» et, avec une connexion au réseau, les ont honteusement déconnectés sur le câble Internet modifié. Soit dit en passant, la panique n'a pas été en vain, mais de tels mods ont été complètement vains, tout a été enregistré sans connexion au réseau.

Exactement un mois plus tard (15 juin 2006), le micrologiciel a été porté sur un autre modèle de lecteur, installé à l'époque sur la Xbox 360 - Hitachi GDR3120L. Il avait également un lecteur flash externe contenant le firmware:

Ce disque était mieux protégé:

le firmware a été stocké dans la ROM sous forme cryptée
il y avait un contrôle d'intégrité dans le firmware
pour écraser le firmware, vous deviez entrer dans un "Mode B" spécial

Et si les chercheurs géraient eux-mêmes les deux premiers points, l'exploit de traduction en «Mode B» devait être répété par tous les ~~jeunes~~ flashers.

Cette action a été proposée pour être effectuée à l'aide d'un disque de démarrage spécial avec Slax Linux, ou en court-circuitant les fils au démarrage. Il était nécessaire de court-circuiter les contacts 0 et 9 du connecteur d'alimentation du variateur. Par exemple, avec des épingles!

Dans les deux cas, après de tels abus, le lecteur a été défini dans Windows comme un lecteur de DVD ordinaire, où il a été ramassé, ~~violé~~ et cousu.

Après la première version, les firmwares personnalisés ont été finalisés, la stabilité a été améliorée, le support des nouveaux jeux a été ajouté, en général, tout était comme d'habitude.

Réponse de Microsoft

Les développeurs aux allégations selon lesquelles la console "incassable" a été piratée, ont répondu simplement:

Le système n'a pas été piraté, nous venons d'apprendre à lancer des copies de jeux, nous y travaillons

réponse originale

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

Ce qui a vraiment été fait pour corriger la situation:

Samsung TS-H943 a commencé à venir avec le firmware ms28, qui n'est pas entré en mode firmware par la célèbre commande ATA
Hitachi GDR3120L est apparu avec le firmware 0078 et 0079, ne clignotant pas même en mode B
Les nouveaux disques BenQ-LiteOn VAD6038 apparaissent
La première "interdiction" pointue des pirates sur Xbox Live a commencé, les pirates ont été interdits de jouer en ligne pour toujours

Si tout était sans ambiguïté et irréparable avec l'interdiction (à ce moment-là), les chercheurs ont vite compris les motivations:

Pour Hitachi trouvé déverrouiller le mode firmware via un disque audio spécial
Samsung ms28 et BenQ VAD6038 sont parfaitement passés en mode firmware via des contrôleurs SATA VIA 6421 peu coûteux

Laissons le champ de bataille pour le firmware du lecteur pendant un certain temps, il n'y a pas eu de période très intéressante où les chercheurs ont essayé de créer le firmware «Stealth», afin de ne pas être banni de Xbox Live, de s'adapter aux nouveaux jeux avec de nouvelles «vagues» - versions de mise à jour du système et portez les résultats sur tout une variété croissante de micrologiciels et de lecteurs. Tout de même, tout était cousu, les «sauvegardes» lancées avec succès, la Xbox 360 gagnait en popularité auprès des gens ...

Briser l'axe!

Comme vous vous en souvenez de la première partie de l'histoire, le système Xbox 360 avait un hyperviseur qui contrôlait tout et tout. Alors voilà. Dans une version du système, une vulnérabilité est soudainement apparue dedans! Comment exactement les chercheurs ont reçu les échantillons de code de l'hyperviseur ne me sont pas connus avec certitude. Mais le fait est qu'à la fin de 2006, les chercheurs ont lancé du code non signé sur la Xbox 360, et au début de 2007, la vulnérabilité a été corrigée par les développeurs:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

L'hyperviseur avait une fonctionnalité - contrairement au reste du code, il n'était pas exécuté dans l'espace d'adressage virtuel, mais dans le physique (mode réel). La diffusion n'a pas été utilisée, les appels ont été effectués directement (adresses de la forme 0x00000000'xxxxxx). Soit cela a été fait pour la vitesse, soit pour la simplicité ... Et voici une caractéristique de l'espace d'adressage Xbox 360.

Le mode d'accès à la mémoire était déterminé par son adresse physique. À savoir, les bits les plus significatifs de l'adresse avaient un but officiel. Par exemple, l'adresse 0x00000 0 00'0000201C signifie un accès direct à l'adresse 0x201C, et 0x00000 1 00'0000201C signifie que vous devez décrypter et vérifier l'intégrité à la volée lors de la lecture de la même adresse physique 0x201C.

Par conséquent, pour que l'exécution soit effectuée avec le chiffrement et la protection activés, vous devez vous référer à des adresses comme 0x00000 1 00'xxxxxxxx. Ce n'est qu'alors que le module matériel comprenait des mécanismes de protection. Par conséquent, au niveau matériel, le bit souhaité a été ajouté automatiquement (le registre spécial HRMOR en était responsable - Registre de décalage du mode réel de l'hyperviseur)!

Encore une fois - dès que l'hyperviseur accède à une adresse comme 0x00000 0 00'xxxxxxxx, la MMU change automatiquement cette adresse en 0x00000 1 00'xxxxxxxx, y compris le chiffrement et la protection! Ainsi, toute tentative d'exécution du code "directement" à partir de la mémoire physique, sans protection ni cryptage, est vouée à l'échec ... ou pas?

Regardons le code vulnérable de l'hyperviseur version 4532:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

Tu vois le gopher? Mais il est! L'instruction Cmplwi fonctionne avec des valeurs 32 bits , mais rldicr - avec 64 bits ! Autrement dit, nous pouvons passer la valeur 0x20000000'0000002A comme numéro d'appel système, il passera le test (car la partie inférieure de 32 bits est inférieure à 0x61), et par conséquent, au lieu de l'adresse 0x10EC, l'adresse du gestionnaire sera prise de 0x80000000'000010EC!

Et puis, comme on dit, surveillez vos mains. Les bits les plus significatifs de l'adresse ne sont pas égaux à zéro, respectivement, HRMOR n'est pas ajouté ! Et puisque l'espace d'adressage réel est de 32 bits, le 63 bits défini par nous est simplement ignoré. Nous avons redirigé l'hyperviseur vers une mémoire non chiffrée et non sécurisée, simplement en soumettant un numéro d'appel système incorrect!

Mais attendez, pour qu'il y ait où sauter, nous devons pouvoir écrire nos données dans la mémoire physique. Comment y parvenir?

C'est là que le deuxième facteur entre en jeu - le GPU sur la Xbox 360 était intelligent, même trop intelligent. Il a pris en charge une instruction spéciale de shader, MemExport, pour télécharger des données de géométrie dans la mémoire physique. Autrement dit, vous pouvez compiler le shader, l'exécuter sur le GPU et ainsi enregistrer n'importe quoi n'importe où! Et surtout, les shaders n'étaient pas signés, si vous modifiez le disque du jeu de quelque manière que ce soit, vous pouvez facilement remplacer le code du shader.

Une question restait. Comment remplacer le code shader sur le disque de jeu? Et ici, le piratage du lecteur DVD de la console a été très utile. Nous avons écrit un shader, l'avons remplacé à l'image du jeu, l'avons enregistré sur un disque et lancé Linux!

Oui, pour l'exécuter, j'ai dû démarrer le jeu à chaque fois, attendre que l'exploit fonctionne, mettre le disque de démarrage avec Linux, mais c'était au moins quelque chose!

Comme déjà mentionné, Microsoft a publié une mise à jour du système dans laquelle ils ont corrigé la vulnérabilité de l'hyperviseur. Mais que faire si vous retournez un noyau vulnérable?

Rétrograder!

En général, l'architecture de la Xbox 360 a été définie des mécanismes de protection contre la rétrogradation. Dans les fusibles matériels du processeur, chaque fois qu'un bit était brûlé pendant la mise à jour (valeur de verrouillage, LDV augmenté), et si ce LDV ne correspondait pas dans les fusibles et dans le système, la console ne démarrait tout simplement pas.

Considérez la structure du chargeur de démarrage Xbox 360, à savoir, «Sections du chargeur de démarrage»:

On peut voir qu'il y a plusieurs ensembles de chargeurs de démarrage dans l'image, chacun correspondant à certains LDV. Dans l'exemple, ce sont 1888 pour LDV 0, 16767 pour LDV 3 et 16756 pour LDV 2

Ainsi, toutes les mises à jour du système lui-même ont été enregistrées dans les sections 6BL / 7BL et simplement «appliquées» comme correctifs au «core» de base 5BL 1888 . Mais quel ensemble de correctifs à appliquer a été sélectionné en fonction du LDV prescrit dans les en-têtes des fusibles et du chargeur de démarrage! Et juste à 5BL, l'en-tête pouvait être modifié, avec un gros MAIS - l'en-tête a été comparé à la somme de hachage HMAC-SHA-1 qui y était enregistrée. Et il a été vérifié par memcmp ordinaire .

Si vous ne comprenez toujours pas où vont les choses, ici vous avez réussi à appliquer une attaque temporelle (Timing Attack). La fonction memcmp standard termine la comparaison immédiatement après le premier écart. Par conséquent, en modifiant le premier octet du hachage et en détectant le temps d'exécution de memcmp, vous pouvez sélectionner la valeur souhaitée (le temps de vérification augmentera avec lui). En continuant, vous pouvez récupérer tous les octets de la somme de hachage!

Pour la mesure, le bus de débogage POST_OUT a été utilisé. Il fonctionne comme un PC, à différents moments du chargement, une valeur à un octet est affichée, par laquelle vous pouvez juger où le processeur est actuellement en cours d'exécution et quelle erreur s'est produite. En fait, ce sont 8 points sur la carte mère, dont chacun est responsable d'un bit de valeur spécifique:

Après avoir soudé ces points, vous pouvez simplement mesurer le temps d'exécution de chacune des étapes de téléchargement et voir si une erreur s'est produite.

L'ensemble du processus de sélection du hachage prend environ une heure:

En conséquence, nous obtenons une image dans laquelle le LDV actuel est installé pour le noyau, car aucun correctif n'est appliqué et la version la plus ancienne du système 1888 est lancée! D'où il est déjà possible de passer à la version vulnérable 4532:

Bien sûr, Microsoft a corrigé cette vulnérabilité en mettant à jour le tout premier chargeur de démarrage mis à jour (2BL, «CB») et en brûlant le fusible CBLDV, ce qui a rendu la rétrogradation impossible à nouveau. Maintenant, au lieu de memcmp, sa version sûre a été utilisée, avec le même temps d'exécution indépendamment des valeurs d'entrée.

JTAG Hack!

Mais ici, les chercheurs n'ont pas abandonné et ont trouvé une faille. Oui, tel que les développeurs ne pouvaient même pas imaginer.

Dans le mode de fonctionnement normal de la console, tous les chargeurs de démarrage sont connectés les uns aux autres dans une chaîne. Par conséquent, le déchiffrement de chaque chargeur de démarrage dépend de la zone de données dans l'en-tête du chargeur de démarrage précédent (Pairing Data). De plus, le cryptage du code dépend de la clé de processeur unique, vous ne pouvez donc pas prendre et assembler une image de travail sans connaître CPU_Key. Ou est-ce possible?

Au stade de la production de la console (lorsque la clé du processeur n'a pas encore été gravée dans des fusibles), un mode de lancement spécial Xbox 360 est utilisé lorsque le couplage des données est nul (Zero-Pairing). Et une telle image (avec un noyau vulnérable!) Peut être exécutée sur n'importe quelle console sans même connaître la clé du processeur!
Malheureusement, il n'y aura pas de lancement à part entière, cette erreur se produira comme ceci:

Autrement dit, le jeu King Kong ne peut pas être démarré, l'exploit via les shaders ne peut pas être activé ... Mais le noyau vulnérable commence déjà! Peut-être qu'il existe une autre façon d'enregistrer la RAM? Il s'est avéré que oui.

Pour commencer, nous soudons trois GPIO gratuits de la console sud de la console aux broches JUAG du GPU:

Ensuite, nous modifions le firmware du pont sud (il est crypté mais pas signé) et collectons l'image avec le noyau vulnérable. Puis la magie opère:

Au démarrage, le pont sud du GPU JTAG monte sur PCI Express et configure le contrôleur NAND
Maintenant, lors de la lecture, le contrôleur NAND va écrire des données dans la zone de mémoire dont nous avons besoin
Le cœur du système démarre et informe le pont sud que le système a démarré
Le pont sud tire le contrôleur NAND, écrasant la RAM au bon endroit et exploite la vulnérabilité de l'hyperviseur!
Le contrôle est transféré à notre code, faites ce que nous voulons

En bref, ils ont tout fait de la même manière que dans King Kong Shader Exploit, mais plus cool - il n'est pas nécessaire de démarrer le jeu et de changer de disque.

Sur la base de JTAG Hack, des versions modifiées du système ont été créées - XBReboot, Freeboot, avec vérification de signature désactivée, où les pirates se promenaient déjà. Les jeux pouvaient être lancés non seulement à partir de lecteurs et disques USB, mais également via le protocole SMB directement à partir d'un ordinateur.

Surtout, un piratage du système à part entière a donné une chance à ceux qui ont perdu la clé DVD et ne pouvaient pas jouer - ayant la clé du processeur, il n'était pas difficile d'extraire la clé DVD.

Bien sûr, ici, Microsoft a rapidement corrigé la vulnérabilité, mettant à jour à nouveau 2BL et augmentant la valeur de CBLDV. Sur ce, l'épopée de l'hyperviseur vulnérable terminée, les gens ont couru pour acheter les restes des consoles "compatibles JTAG" dans les magasins - tout le monde voulait jouer avec des clés USB sans aucun problème. Des discussions ont eu lieu sur des forums sur les bundles avec quelle date de sortie convenaient pour le piratage ...

Le sujet des modifications du système Xbox 360 a calé pendant près de deux ans, mais le thème du firmware a continué à se développer. Et juste dans le micrologiciel des lecteurs LiteOn, la bataille la plus étendue entre les chercheurs et Microsoft a éclaté. Mais plus à ce sujet dans le prochain article :)

Liens:

rapport GoogleTechTalks
King Kong Hack
Timing Attack
JTAG / SMC Hack

Protection et piratage Xbox 360, Partie 1
Protection et piratage Xbox 360 , Partie 2
Protection et piratage Xbox 360, Partie 3

PS Toute personne intéressée par les détails, je répondrai à toutes les questions sur le sujet dans les commentaires!