Aller au contenu


tralala

Inscrit(e) (le) 24 févr. 2012
Déconnecté Dernière activité aujourd'hui, 06:24
*****

Sujets que j'ai initiés

[PS5] PS5 PKG Manager passe en v1.4.1 et corrige les installations USB et disque hors r...

aujourd'hui, 06:25

Le développement de PS5 PKG Manager se poursuit avec la publication de la version 1.4.1 par itsPLK. Cette nouvelle mouture arrive seulement quelques jours après la version 1.4.0 et se concentre sur une correction particulièrement intéressante concernant l'installation de fichiers PKG lorsque la PS5 ne dispose d'aucune connexion réseau active.
 
Pour rappel, PS5 PKG Manager est un outil destiné à faciliter la gestion et l'installation de packages sur les consoles PlayStation 5 compatibles avec les fonctionnalités nécessaires à son fonctionnement.
 
 
 
 
 
Les installations USB et disque corrigées
 
La principale modification de cette version 1.4.1 concerne les installations effectuées depuis un périphérique USB ou un disque local. Auparavant, ces installations pouvaient échouer lorsque la console ne disposait d'aucune connexion réseau active. Ce problème est désormais corrigé.
 
Il devient donc possible de lancer correctement une installation depuis un support local même lorsque la PS5 fonctionne totalement hors réseau.Les développeurs précisent cependant une limitation importante : la progression de l'installation ne peut pas être affichée dans PKG Manager dans ce mode.
 
Cette limitation ne provient pas de l'application elle-même, mais du fonctionnement du système de la PS5. L'installation peut donc se poursuivre normalement sans que son avancement soit visible directement dans l'interface de PKG Manager.
 
Une version 1.4.1 très ciblée
 
Contrairement à la version 1.4.0, qui apportait de nombreuses améliorations, cette nouvelle version est principalement consacrée à cette correction.
 
La v1.4.0 avait notamment largement amélioré la gestion des partages SMB/Samba, avec plusieurs corrections concernant le scan des packages, l'authentification Guest et les performances du chiffrement SMB.
 
Elle avait également introduit :
 
- une meilleure gestion du cache et des métadonnées ;
- un rescan rapide permettant d'éviter une reconstruction complète du cache ;
- une meilleure détection des packages modifiés ou renommés sur SMB ;
- l'affichage des noms de jeux, mises à jour et DLC au lieu des seuls Title IDs ;
- l'affichage des icônes des packages dans les notifications et cartes de téléchargement ;
- une nouvelle fonction permettant de fermer proprement PKG Manager et son serveur ;
- des messages d'erreur plus explicites lors des installations.
 
La version 1.4.1 vient donc compléter ce travail en corrigeant un cas particulier qui pouvait empêcher les installations locales de fonctionner correctement hors connexion.
 
Une mise à jour recommandée
 
Pour les utilisateurs de PS5 PKG Manager, cette nouvelle version constitue donc une mise à jour particulièrement intéressante si les installations depuis USB ou disque sont utilisées sur une console sans connexion réseau.
 
Le fichier disponible pour cette version est pkg-manager_v1.4.1.elf, avec une taille d'environ 1,85 Mo.
 
Cette évolution montre également que PS5 PKG Manager continue de gagner en maturité, avec un développement qui s'attarde désormais sur des cas d'utilisation spécifiques et sur la fiabilité des installations.
 
Téléchargement : PS5 PKG Manager v1.4.1
 
 

[Switch] hekate v6.5.4 et Nyx v1.9.4 : support du firmware 23.0.0

aujourd'hui, 06:19

Quelques heures après la publication d'Atmosphère 1.12.0, le célèbre bootloader hekate évolue à son tour. CTCaer vient de publier hekate v6.5.4, accompagné de Nyx v1.9.4, avec une nouveauté essentielle pour les utilisateurs de Nintendo Switch : la prise en charge du firmware 23.0.0.
 
Cette nouvelle version permet ainsi à hekate de rester compatible avec les dernières évolutions de l'OS de Nintendo, tout en conservant ses fonctions habituelles de gestion du démarrage, de l'emuMMC et des différents environnements disponibles sur Switch.
 
 
 
 
hekate v6.5.4 : support du firmware 23.0.0
 
La principale nouveauté de cette version est simple mais indispensable est le support du firmware 23.0.0 connu aussi sous le nom de HOS 23.0.0, HOS, pour Horizon OS, désigne le système d'exploitation principal de la Nintendo Switch.
 
Cette compatibilité concerne également la gestion de l'emuMMC, qui bénéficie elle aussi du support de HOS 23.0.0.
 
Comme toujours, le fonctionnement de l'emuMMC repose sur le travail réalisé autour du projet de m4xw.
 
Nyx v1.9.4 évolue également
 
L'interface graphique Nyx, intégrée à hekate, passe de son côté en version 1.9.4. Là encore, la modification principale est la prise en charge du firmware 23.0.0. Cette mise à jour permet donc de conserver l'ensemble des fonctionnalités de gestion proposées par Nyx avec le dernier firmware de Nintendo.
 
hekate conserve son positionnement de véritable couteau suisse pour les utilisateurs avancés de la Switch. Le projet permet notamment de démarrer les différents CFW actuels, mais également Android, Linux et différents outils sous forme de payloads. Le gestionnaire de partitions intégré à Nyx reste également disponible. Il permet notamment de préparer une carte SD pour différents environnements.
 
Pour Linux L4T, hekate prend notamment en charge les distributions compatibles avec les versions Ubuntu Bionic 3.4.0 et suivantes.
 
Côté Android, les configurations Android 11 Legacy, Android 13/14 Dynamic et les versions ultérieures restent supportées.
 
Le gestionnaire de partitions peut également être utilisé indépendamment de Linux ou Android, notamment pour reformater une carte SD en FAT32, y compris lorsqu'elle utilise actuellement une partition exFAT.
 
CTCaer recommande d'ailleurs de réaliser le formatage avec hekate afin de préparer la carte SD pour obtenir de bonnes performances, certaines solutions de partitionnement ne prenant pas suffisamment en compte cet aspect.
 
Toujours pas besoin de retirer la carte SD
 
Le projet conserve également l'une de ses caractéristiques appréciées : la gestion des différentes opérations sans avoir besoin de retirer systématiquement la carte SD.
 
hekate continue ainsi de centraliser de nombreuses opérations directement depuis son environnement de démarrage.
 
Une mise à jour simple
 
La mise à jour est particulièrement simple.
 
Il suffit de copier le dossier bootloader fourni avec la nouvelle version à la racine de la carte SD et d'accepter la fusion/remplacement des fichiers.
 
Il n'est pas nécessaire de supprimer préalablement le dossier bootloader. Cette méthode permet notamment de conserver les configurations personnelles ainsi que les payloads déjà présents.
 
Concernant le périphérique d'injection RCM ou le PC utilisé pour injecter hekate, il est possible de mettre à jour ou non le fichier hekate_ctcaer_x.x.x.bin.
 
Dans tous les cas, le fichier :
 
bootloader/update.bin
 
sera vérifié au démarrage et la version la plus récente pourra être chargée automatiquement.
 
Performances USB sous Windows
 
Une note concerne également les utilisateurs de la fonction USB Mass Storage (UMS) sous Windows.
 
Pour obtenir les performances maximales, CTCaer recommande d'exécuter une seule fois par PC le fichier :
 
nyx_usb_max_rate__run_only_once_per_windows_pc.reg
 
Cette modification concerne uniquement le périphérique USB utilisé par hekate. Les utilisateurs de Linux et macOS n'ont pas besoin d'effectuer cette opération.
 
hekate et Atmosphère passent à l'ère 23.0.0
 
Avec Atmosphère 1.12.0 et désormais hekate v6.5.4 / Nyx v1.9.4, l'écosystème homebrew Switch se met donc rapidement à jour pour accompagner le firmware 23.0.0.
 
Pour les utilisateurs ayant mis à jour leur console vers cette nouvelle version de HOS, il est donc recommandé d'utiliser des versions récentes d'Atmosphère, de fusee et de hekate afin d'éviter les problèmes de compatibilité.
 
Téléchargement : hekate v6.5.4 & Nyx v1.9.4
 
 
 

[Switch] Atmosphère 1.12.0 est disponible : support du firmware 23.0.0 et des évolution...

aujourd'hui, 06:14

L'équipe Atmosphère-NX, amis sunriseurs, vient de publier Atmosphère 1.12.0, la 93e version officielle du custom firmware destiné à la Nintendo Switch. Cette mise à jour intervient avec un changement majeur : la prise en charge du firmware 23.0.0 de Nintendo.
 
Cette nouvelle version ne se contente pas d'ajouter la compatibilité avec le dernier firmware. Elle apporte également plusieurs modifications profondes au niveau du kernel, du secure monitor, du démarrage de la console et de la gestion de la mémoire.
 
Atmosphère 1.12.0 intègre hbl 2.4.5 ainsi que hbmenu 3.6.1, cette version apporte le support du firmware 23.0.0, c'est d'ailleurs le changement principal. Plusieurs composants internes d'Atmosphère ont dû être adaptés afin de reproduire le comportement du nouveau système Nintendo.
 
 
 
 
Le travail réalisé porte notamment sur :
 
- exosphère, mis à jour pour correspondre au comportement du secure monitor officiel 
- mesosphère, adapté aux évolutions du kernel 
- boot, avec notamment une correction concernant la gestion de l'arrêt de la batterie via I2C  
- loader, erpt, pgl et ro, mis à jour pour refléter les dernières évolutions officielles 
 
Le kernel de la version 23.0.0 prend notamment en charge un espace d'adressage de 42 bits et introduit une nouvelle région mémoire appelée ShadowStack. Le générateur de nombres aléatoires du kernel évolue également vers CTR-DRBG.
 
Une mémoire encore plus contrainte
 
L'une des conséquences les plus importantes du firmware 23.0.0 concerne la mémoire disponible pour les modules système personnalisés.
 
Nintendo a réduit davantage la quantité de mémoire pouvant être récupérée depuis l'applet pool. Atmosphère indique que la marge disponible est désormais inférieure à 7 Mo, ce qui entraîne notamment des plantages lors du lancement de certaines browser applets, comme celles utilisées par l'eShop.
 
Pour contourner cette limitation, Atmosphère introduit plusieurs patches visant les browser applets.
 
Depuis la refonte opérée par Nintendo avec le firmware 22.0.0, trois applets principales sont concernées : systemWeb, openWeb et LibAppletOff
 
Atmosphère peut désormais neutraliser certaines allocations mémoire réservées par ces composants afin de récupérer environ 9 Mo supplémentaires.
 
D'après les développeurs, cette mémoire est considérée comme inutilisée : les applets la déclarent comme réservée mais n'y accèdent pas réellement.
 
Avec cette méthode, Atmosphère peut expérimentalement porter la mémoire disponible pour les modules système personnalisés jusqu'à 16 Mo.
 
Les premiers tests n'ont pas mis en évidence de problème particulier avec le fonctionnement général du système ou des browser applets. Les développeurs demandent néanmoins aux utilisateurs de signaler tout comportement anormal, cette solution pouvant encore être ajustée ou abandonnée si une meilleure approche est trouvée.
 
Correction de la compression ZBIC
 
Atmosphère 1.12.0 apporte également une implémentation complète de la compression et décompression ZBIC.
 
Les applications utilisant ce format devraient désormais pouvoir être lancées et fonctionner correctement.
 
Autre évolution intéressante : les fichiers NRO peuvent désormais être compressés au format LZ4 Frame, grâce à l'adaptation du composant ro.
 
Une correction qui concerne potentiellement la batterie
 
Les développeurs ont également identifié une modification introduite par Nintendo dès le firmware 18.0.0 concernant l'activation de l'arrêt de la batterie via I2C.
 
Cette modification n'avait pas été correctement reproduite dans Atmosphère jusqu'à présent.
 
L'équipe indique qu'il est possible que cette différence soit liée à un problème connu de décharge de batterie qui aurait commencé à apparaître autour du firmware 18.0.0. Des tests supplémentaires seront toutefois nécessaires avant de pouvoir établir un lien définitif.
 
Autres améliorations
 
Cette version poursuit également le nettoyage interne du code avec l'adoption du macro R_DISCARD dans l'ensemble du projet lorsque cela est pertinent. Cette évolution, commencée avec Atmosphère 1.10.0, permet notamment d'éliminer les avertissements nodiscard lors de la compilation.
 
Un Dockerfile fait également son apparition dans le projet, grâce au travail d'@alula, afin de faciliter certaines opérations liées à la compilation et au développement.
 
Enfin, comme à chaque nouvelle version, Atmosphère 1.12.0 embarque diverses corrections destinées à améliorer la stabilité générale du système.
 
Atmosphère continue son évolution
 
Avec cette version 1.12.0, Atmosphère démontre une nouvelle fois l'importance du travail réalisé pour suivre les évolutions internes de Nintendo. Le passage au firmware 23.0.0 nécessite plusieurs adaptations profondes, notamment au niveau du kernel et de la gestion de la mémoire.
 
La situation devient cependant de plus en plus complexe pour les modules système personnalisés, Nintendo réduisant progressivement les marges mémoire disponibles.
 
Pour les utilisateurs d'Atmosphère qui souhaitent passer au firmware 23.0.0, la mise à jour d'Atmosphère et de fusee est donc indispensable.
 
Atmosphère 1.12.0 est disponible dès maintenant sur le dépôt officiel du projet.
 
 
Téléchargement : Atmosphère 1.12.0
 
 
 

[PS3] Zecoxao dévoile son write-up de glitch sur PS3

hier, 17:13

Notre ami sunriseur Sendel nous informe que la scène PlayStation 3 vient de franchir une nouvelle étape particulièrement intéressante. Dans un long write-up baptisé « Glitching the "Almost" Perfect Code... », le développeur zecoxao revient en détail sur plusieurs années de travaux autour des mécanismes de sécurité de la PS3 et dévoile une faiblesse située au niveau des tout premiers éléments de la chaîne de démarrage. Cette découverte pourrait, à terme, avoir des conséquences considérables : possibilité de contourner certaines protections sur les modèles jusqu'ici considérés comme impossibles à customiser, restauration de consoles brickées et même remplacement de certains composants de sécurité.
 
Il faut toutefois insister sur un point : une partie importante des possibilités évoquées dans le document reste encore théorique. La découverte de la clé et de la faiblesse constitue une étape fondamentale, mais transformer ces travaux en outils publics et fiables demandera encore du développement.
 
 
 
 
Des années de travaux en arrière-plan
 
zecoxao commence son analyse en rendant hommage aux nombreux chercheurs ayant travaillé sur la sécurité de la PS3. Parmi les personnes citées figurent notamment wildcard, ZeroTolerance, jestero, MikeM64, DJ, flat_z, Mina Ralwasser, sagemono, Kafuu, esc0rtd3w, naehrwert, mysis, skgleba, xorloser, Myria, bguerville, Proxima et golden, ainsi qu'une personne restée anonyme. Les travaux historiques autour du SYSCON, des firmwares et des clés maîtresses ont notamment permis de comprendre et de déchiffrer une partie des mécanismes internes de la console. Ces recherches ont également contribué à des projets comme Project Frankenstein, dont l'objectif est notamment de maintenir en vie certaines PS3 rétrocompatibles et de permettre la réparation de consoles présentant des problèmes matériels complexes.
 
PS3 Syscon research
 
QuasiCFW et la piste BadWDSD
 
Le write-up revient également sur les travaux de Kafuu, avec esc0rtd3w et bguerville, autour de la vulnérabilité WDSD. À partir d'une ancienne publication datant de 2010 décrivant une potentielle faiblesse du registre de commande WDSD, les chercheurs ont progressivement développé ce qui est devenu QuasiCFW. L'idée est particulièrement intéressante : permettre de modifier certaines régions de LV0, LV1 et LV2 sur des consoles considérées comme « unhackable », en intervenant après le chargement de lv0ldr.
 
 
 
 
BadWDSD sur GitHub
 
Cette avancée constitue une pièce importante du puzzle puisque les modèles plus récents de PS3 ne peuvent pas simplement être traités comme les premières générations exploitables par les méthodes historiques.
 
La chaîne de démarrage de la PS3
 
Pour comprendre l'intérêt de la découverte, il faut revenir au fonctionnement de la chaîne de boot de la PS3. Au démarrage, plusieurs composants se chargent successivement. lv0ldr permet notamment de lancer LV0, avant que la chaîne ne poursuive son exécution avec metldr, puis différents loaders comme :
 
- isoldr, chargé des modules SPU isolés 
- appldr, chargé des applications utilisateur 
- rvkldr, chargé des listes de révocation 
- lv1ldr, chargé de l'hyperviseur 
- lv2ldr, chargé du kernel
 
Sur les modèles plus récents, Sony a notamment renforcé les protections cryptographiques afin d'empêcher la création et l'injection de code signé frauduleusement.
 
À première vue, la chaîne semble donc pratiquement impossible à contourner.
 
Mais selon les travaux présentés par zecoxao, les deux premiers maillons de cette chaîne, lv0ldr et metldr, constituent justement un point particulièrement intéressant.
 
Une ROM cachée dans le processeur
 
L'une des étapes les plus impressionnantes du travail a consisté à rechercher une ROM directement dans le processeur.
 
La méthode utilisée est particulièrement lourde : décapsulation du composant et analyse physique de ses zones mémoire.
 
Fin 2025, les chercheurs ont obtenu des images de différentes régions du processeur grâce à une personne anonyme. L'objectif initial était de retrouver la ROM SPU.
 
 
 
 
La première découverte fut cependant une déception.
 
La ROM identifiée était en réalité une ROM de microcode, utilisée pour traduire et préparer certaines instructions complexes du PPE afin qu'elles puissent être exécutées par le processeur.
 
Les recherches se sont donc poursuivies.
 
La découverte de la SPU ROM
 
En insistant sur l'analyse des différentes régions SPU, alors que plusieurs d'entre elles semblaient identiques, les chercheurs ont finalement découvert quelque chose de beaucoup plus intéressant.
 
Une ROM contenant environ 8192 bits, soit environ 0x400 octets après décodage, était présente dans le processeur.
 
L'équipe a alors commencé à analyser son fonctionnement et à rechercher d'éventuelles faiblesses.
 
Différents outils ont été utilisés pour observer le comportement du code et communiquer avec le système, notamment via l'UART du SYSCON.
 
L'analyse a révélé que cette petite ROM contenait notamment les mécanismes liés au traitement AES de lv0ldr et metldr.
 
Le problème était évidemment de taille : la clé elle-même n'était pas directement accessible.
 
Elle était transmise via le channel 66, avec des lectures de 32 bits, puis l'accès était verrouillé afin d'empêcher toute nouvelle récupération.
 
Les chercheurs ont tenté différentes approches pour obtenir cette information, mais une conclusion s'est progressivement imposée : il faudrait probablement passer par une attaque physique ou une technique de glitching.
 
« Register Evil 7 »
 
 
C'est à ce moment que jestero a identifié le comportement qui allait changer la situation.
 
En utilisant les outils d'analyse développés autour de la ROM, il a constaté que certains registres SPU conservaient leur contenu entre plusieurs exécutions de code SPU.
 
Ce comportement ouvrait une possibilité inattendue.
 
Si une clé ou une clé dérivée était laissée dans l'un de ces registres, il pouvait être possible de la récupérer après l'exécution du code.
 
Le registre 7 s'est alors révélé particulièrement intéressant.
 
Celui-ci n'était utilisé que lors de l'expansion de clé AES associée à la clé dérivée du channel 66.
 
L'idée était donc de provoquer un glitch au moment précis où le système nettoie ces informations, puis de récupérer le contenu résiduel du registre.
 
Le résultat est particulièrement important : l'équipe est finalement parvenue à récupérer la clé body par console de lv0ldr d'une PS3 CECHL.
 
Autrement dit, une information considérée comme protégée par la chaîne de sécurité de la console a pu être récupérée en exploitant un comportement inattendu des registres.
 
Pourquoi cette découverte est importante
 
La récupération de cette clé ne signifie pas immédiatement qu'un CFW universel est disponible.
 
En revanche, elle démontre que la chaîne de sécurité n'est pas aussi hermétique qu'on pouvait le penser.
 
Les clés récupérées pourraient notamment permettre, selon les travaux présentés dans le write-up :
 
- Récupérer la clé du Channel 66
 
Cette clé permettrait théoriquement de travailler directement avec les mécanismes cryptographiques utilisés par lv0ldr et metldr.
 
- Chiffrer et signer son propre lv0ldr ou metldr
 
Une possibilité qui ouvrirait la porte à la modification beaucoup plus profonde de la chaîne de démarrage.
 
- Déchiffrer lv0ldr.2 et metldr.2
 
Ces composants contiennent notamment d'autres éléments cryptographiques et clés de signature.
 
- Étendre le CFW à tous les modèles de PS3
 
C'est probablement la perspective la plus spectaculaire.
 
Combinés aux travaux de Kafuu et QuasiCFW, ces résultats pourraient théoriquement permettre d'étendre les possibilités du custom firmware aux PS3 Slim 3000 et aux Super Slim, qui ont toujours constitué une frontière importante pour la scène.
 
- Débricker potentiellement toutes les PS3
 
Avec les informations nécessaires, comme la clé CPU, la HW Master Key ou la clé Channel 66, certaines opérations de récupération qui étaient auparavant extrêmement complexes pourraient devenir envisageables.
 
- Contourner certains composants matériels défaillants
 
Les chercheurs évoquent également la possibilité de pouvoir démarrer une console malgré une carte Blu-ray défectueuse ou certains problèmes liés au Wi-Fi.
 
- Réaliser des opérations de remariage
 
Le travail pourrait également ouvrir la voie à des opérations de remariage du SYSCON et du lecteur Blu-ray, avec des implications importantes pour la réparation des consoles.
 
Une découverte majeure, mais encore au stade de la recherche
 
Il faut néanmoins conserver une certaine prudence.
 
Le write-up de zecoxao présente surtout une chaîne de recherche et une preuve extrêmement importante sur la possibilité de récupérer des secrets cryptographiques. Toutes les conséquences évoquées ne sont pas encore disponibles sous la forme d'outils simples à utiliser.
 
Le passage de la récupération d'une clé sur une CECHL à une méthode reproductible sur l'ensemble des modèles demandera notamment de comprendre précisément les différences matérielles et les mécanismes de sécurité de chaque génération.
 
Mais le principe est désormais particulièrement intéressant : une partie de la sécurité considérée comme inaccessible peut être attaquée directement au niveau du code exécuté dans les premiers étages du bootrom.
 
La scène PS3 dispose donc désormais d'une nouvelle piste particulièrement sérieuse pour repousser encore les limites des modèles les plus récents.
 
Après des années de recherches sur le SYSCON, les clés maîtresses, les vulnérabilités WDSD et QuasiCFW, cette nouvelle découverte pourrait bien constituer une nouvelle pièce essentielle dans le puzzle du CFW universel.
 
Et si les travaux futurs confirment toutes les possibilités évoquées par zecoxao, les conséquences pourraient dépasser largement le simple lancement d'un homebrew : réparation, débrick, remariage et custom firmware sur les modèles jusqu'ici considérés comme définitivement verrouillés pourraient devenir techniquement envisageables.
 
 
 
Merci Sendel pour le lien 

[PS5] PS5 RetroArch : Dolphin, PS2, Wii et la GameCube s'émule désormais jusqu'...

hier, 06:56

Le développement de PS5 RetroArch s'accélère à un rythme particulièrement impressionnant. Quelques jours seulement après l'arrivée de l'Alpha 3 et de l'émulation GameCube via Dolphin, Mihawk vient de publier la version v0.4.0-alpha.4, une nouvelle pré-release qui franchit encore un cap important sur PlayStation 5.
 
Cette quatrième Alpha ajoute en effet l'émulation PlayStation 2 et Wii avec rendu GPU, en complément de la GameCube et de la PSP déjà prises en charge. Le projet utilise toujours PS5_Vulkan, le pilote Vulkan développé spécifiquement pour permettre à RetroArch d'exploiter directement le GPU de la PS5.
 
Le projet reste expérimental et les jeux annoncés comme fonctionnels correspondent aux titres testés directement par le développeur. Il n'en demeure pas moins que, quelques jours après les premiers tests, RetroArch est désormais capable de faire tourner des jeux issus de plusieurs générations de consoles, dont certaines particulièrement exigeantes.
 
 
 
 
 
De cinq cores à huit cores
 
Lors de sa première Alpha, PS5 RetroArch proposait principalement des systèmes rétro fonctionnant avec un rendu logiciel : NES, Game Boy, Game Boy Advance, SNES, arcade et Mega Drive.
 
La situation a considérablement évolué depuis.
 
L'Alpha 2 avait ajouté PPSSPP, permettant à la PSP de profiter d'un rendu matériel via PS5_Vulkan. L'Alpha 3 avait ensuite introduit Dolphin, ouvrant la porte à l'émulation GameCube avec un rendu GPU et jusqu'à 6x de résolution interne.
 
Avec l'Alpha 4, le projet passe désormais à huit cores, avec notamment :
 
- FCEUmm pour la NES/Famicom 
- mGBA pour Game Boy, Game Boy Color et Game Boy Advance 
- Snes9x pour la Super Nintendo 
- FinalBurn Neo pour l'arcade 
- Genesis Plus GX pour les consoles Sega 
- PPSSPP pour la PSP 
- Dolphin pour la GameCube et désormais la Wii 
- LRPS2 pour la PlayStation 2
 
La différence majeure réside surtout dans les trois derniers cores. PPSSPP, Dolphin et LRPS2 exploitent le GPU de la PS5 via PS5_Vulkan, ce qui permet de dépasser largement le fonctionnement classique des cores RetroArch en rendu logiciel.
 
La PlayStation 2 débarque sur PS5 RetroArch
 
La nouveauté la plus spectaculaire de cette Alpha 4 reste probablement LRPS2, le core basé sur l'émulation PlayStation 2.
 
Le core utilise son renderer Vulkan matériel, avec une résolution interne configurée par défaut à 6x, soit une cible proche de la 4K selon le jeu et le réglage utilisé.
 
Le port exploite également le traitement multithread du VU1 afin d'améliorer les performances de l'émulation.
 
Plusieurs jeux ont déjà été utilisés pour valider cette intégration, notamment :
 
God of War II 
Final Fantasy X 
GTA San Andreas
 
Selon les tests publiés par Mihawk, ces titres atteignent la pleine vitesse sur sa console.
 
Il faut toutefois rappeler qu'il s'agit toujours d'une Alpha et que la compatibilité n'est évidemment pas celle d'un émulateur mature sur PC. L'utilisation de LRPS2 nécessite également de fournir son propre BIOS PlayStation 2, placé dans system/pcsx2/bios/.
 
Cette arrivée est particulièrement intéressante pour la scène PS5 : RetroArch n'est plus uniquement en train de reproduire des machines 8, 16 ou 32 bits, mais commence désormais à s'attaquer à des systèmes beaucoup plus lourds à émuler.
 
Dolphin s'attaque désormais aussi à la Wii
 
Dolphin avait fait son apparition dans l'Alpha 3 avec la GameCube. L'Alpha 4 élargit maintenant son périmètre à la Wii.
 
Le core utilisé est Dolphin 2609, avec son JIT et son système de mémoire rapide.
 
Plusieurs jeux GameCube et Wii ont déjà été testés :
 
The Legend of Zelda: The Wind Waker ;
Resident Evil 4 ;
Super Smash Bros. Melee ;
Mario Kart Wii ;
Star Wars Rogue Leader.
 
Les tests de stabilité sont également plus poussés. Wind Waker aurait notamment fonctionné pendant environ une heure sans crash, tandis que Resident Evil 4 a été testé durant environ 30 minutes.
 
L'arrivée de la Wii constitue une évolution logique de Dolphin, mais elle représente également un nouveau défi pour le pilote graphique PS5_Vulkan.
 
La PSP continue de monter en résolution
 
PPSSPP reste également présent dans cette nouvelle version avec son renderer Vulkan et son JIT.
 
Deux jeux ont notamment été utilisés pour les tests :
 
God of War: Ghost of Sparta ;
Yu-Gi-Oh! GX Tag Force.
 
Ils ont été testés jusqu'à 10x la résolution interne, ce qui montre une nouvelle fois que la puissance disponible sur PS5 permet d'envisager des niveaux de résolution très supérieurs à ceux de la console d'origine.
 
L'Alpha 4 corrige surtout les problèmes de stabilité
 
Cette nouvelle version n'est toutefois pas uniquement consacrée à l'ajout de nouveaux systèmes.
 
Une partie importante du travail de Mihawk concerne désormais la stabilité du port.
 
Plusieurs problèmes remontés par les premiers testeurs ont été corrigés.
 
Un crash apparaissant après la fermeture d'un jeu SNES a notamment été identifié. Le problème venait de la création du pilote vidéo depuis un thread RetroArch disposant de seulement 64 Ko de pile, une limitation particulièrement restrictive sur PS5.
 
Les threads utilisés par RetroArch disposent maintenant de 2 Mo de pile, tandis qu'une partie du code nécessitant beaucoup de mémoire a été déplacée vers le heap.
 
Un autre crash concernait PPSSPP avec Ratchet & Clank: Size Matters. Le problème venait cette fois de listes internes du pilote graphique modifiées simultanément par plusieurs threads sans verrouillage approprié.
 
Le pilote a été corrigé et un test spécifique permettant de reproduire cette corruption a été ajouté.
 
Un autre correctif important concerne le mode 120 Hz.
 
Sur certains écrans limités à 60 Hz, RetroArch pouvait auparavant sélectionner le mode 120 Hz alors que l'écran ne fonctionnait réellement qu'à 60 Hz. Résultat : chaque image pouvait être affichée deux fois, donnant l'impression que les jeux tournaient à mi-vitesse avec la V-Sync activée.
 
Le pilote mesure désormais le taux de rafraîchissement réel et repasse correctement en 60 Hz lorsque cela est nécessaire.
 
Le mode V-Sync activé est ainsi recommandé avec cette Alpha 4.
 
Le problème de crash de Rogue Leader a également été corrigé. Il provenait d'une condition de course dans le FIFO GPU de Dolphin en mode dual-core.
 
Des améliorations jusque dans la gestion des sauvegardes
 
La gestion des sauvegardes et des save states continue également d'évoluer.
 
L'Alpha 4 améliore notamment l'écriture des gros save states. Un état de sauvegarde PlayStation 2 de 50 Mo peut désormais être écrit sans passer par stdio, qui constituait auparavant un goulet d'étranglement. Cette optimisation devient particulièrement importante avec l'arrivée de LRPS2, les états de sauvegarde pouvant rapidement devenir beaucoup plus volumineux que ceux des consoles 8 ou 16 bits.
 
Le rendu Vulkan continue de s'enrichir
 
Les avancées de PS5 RetroArch sont directement liées à celles de PS5_Vulkan.
 
Lors de l'Alpha 3, plusieurs fonctions avaient déjà été ajoutées afin de permettre à Dolphin de fonctionner correctement, notamment le MSAA, les résolutions contrôlées par le GPU et les render targets linéaires. Le pilote avait également reçu le support du MSAA 2x et 8x ainsi que des corrections concernant le 4x MSAA.
 
L'Alpha 4 s'appuie désormais sur cette base pour faire fonctionner plusieurs cores beaucoup plus complexes. L'objectif est donc double : faire progresser RetroArch lui-même, mais également continuer à améliorer la couche graphique capable de traduire les appels Vulkan vers le GPU de la PlayStation 5.
 
Une stabilité qui devient progressivement la priorité
 
L'autre enseignement de cette Alpha 4 est que le projet entre progressivement dans une nouvelle phase. Les premières versions étaient principalement consacrées à démontrer que RetroArch pouvait fonctionner nativement sur PS5. Aujourd'hui, le développeur commence à multiplier les tests de stabilité, les tests multithread et les scénarios de longue durée.
 
Avant la publication de cette version, chaque core a notamment été lancé avec un jeu afin de vérifier :
 
le démarrage ;
l'ouverture du menu ;
la fermeture du jeu ;
l'utilisation du Quick Menu ;
le fonctionnement avec Threaded Video ;
le fonctionnement avec V-Sync.
 
Aucun crash n'aurait été observé lors de cette campagne de validation.
 
Quelques limitations subsistent
 
Malgré ces avancées, PS5 RetroArch reste une Alpha.
 
Le principal problème actuellement identifié concerne la compilation des shaders. Lorsqu'un jeu utilise pour la première fois un nouveau shader, une saccade peut apparaître pendant sa compilation. Une fois celui-ci placé dans le cache, les lancements suivants sont plus fluides.
 
Le développement d'une compilation asynchrone des shaders fait partie des prochaines étapes.
 
Rogue Leader reste également particulièrement exigeant et peut descendre entre 72 et 85 % de vitesse pendant certaines séquences, même lorsque les shaders sont déjà en cache.
 
D'autres limitations concernent les jeux PS2 PAL à 50 Hz, les images disque PS2 au format .7z qui ne sont pas décompressées automatiquement, ainsi qu'un problème de scintillement noir observé dans Mario Party sur Wii.
 
La compatibilité doit donc encore être largement étendue.
 
Une progression particulièrement rapide, en seulement quelques jours, le projet est passé d'un RetroArch PS5 capable de faire fonctionner des cores rétro classiques à une solution capable de lancer des jeux PSP, GameCube, Wii et PlayStation 2 avec rendu GPU.
 
La progression est particulièrement visible :
 
Alpha 1 → cores rétro et interface native
 
Alpha 2 → PSP avec rendu Vulkan
 
Alpha 3 → GameCube avec Dolphin jusqu'en 6x
 
Alpha 4 → GameCube + Wii + PlayStation 2 avec rendu GPU
 
Et tout cela repose sur une même infrastructure : RetroArch + PS5_Vulkan + les cores libretro adaptés à l'environnement PS5.
 
Le projet n'est évidemment pas encore un émulateur universel et les performances doivent être évaluées jeu par jeu. Mais la trajectoire est claire : la PS5 commence progressivement à devenir une plateforme particulièrement intéressante pour l'émulation native.
 
Et maintenant ?
 
La feuille de route reste ambitieuse. Parmi les pistes évoquées figurent notamment Beetle PSX HW pour la PlayStation 1, les cores Nintendo 64 comme Mupen64Plus-Next ou ParaLLEl-N64, davantage d'améliorations pour Dolphin et PPSSPP, mais aussi les shaders, l'upscaling 4K, le VRR, le HDR, la faible latence, RetroAchievements et les fonctions réseau.
 
Avec l'Alpha 4, le projet franchit toutefois déjà une étape symbolique : RetroArch sur PS5 ne se contente plus d'émuler les anciennes générations, il commence à exploiter directement le GPU de la console pour s'attaquer à la GameCube, la Wii, la PSP et maintenant la PlayStation 2.
 
La prochaine étape sera donc de transformer ces démonstrations encore expérimentales en une compatibilité plus large et surtout en performances suffisamment constantes pour envisager une véritable utilisation quotidienne.
 
 
Téléchargement : PS5_RetroArch