Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux

Les développeurs depuis la sortie de l'exploit 4.05 de Specter sont au travail, vous le savez cela ne se fait pas en 5 minutes, il faut leur laisser le temps d'agir mais c'est désormais une certitude, la PS4 va tomber sous le firmware 4.05, le contraire serait étonnant maintenant.         La plupart des développeurs connus sont sur le pont, certains diffusent leur travaux, même partiels, d'autres ont beaucoup de chose en privée. Le développeur eXtreme nous propose par exemple de découvrir la version v0.13 de sont PS4 4.05 UI Mod Alpha Custom Home Menu.         Encore mieux, les développeurs ont traduit le software en version française ! Merci aux développeurs d'extreme-Modding.de c'est vraiment sympathique !         PS4 4.05 UI Mod Alpha 0.13 Custom Home Menu   1. Installez le firmware 4.05 (initialisation) 2. Activez le serveur FTP et copiez le contenu du dossier Mod_UK / Mod_FR à la racine du disque dur PS4 3. Redémarrez la PS4   Quelques précisions :    Info: Le dossier Game/Jeux du menu Accueil apparaît si vous avez installé CUSA00851 et le fichier app.db ne fonctionne que si votre langue système est l'anglais (Royaume-Uni) ou le français.   Trophy Edit ne fonctionnera pas si vous avez déjà gagné des trophées. GAME Launcher et APP_Home (data) apparaissent si vous avez installé GTA V Disc (CUSA00411) et OMSK (NPXS29005). PSN User Avatar est seulement pour une PS4 avec un utilisateur PSN.   Remarque: Ce Mod n'est pas encore complet pour le firmware 4.05, l'icône TV & Vidéo et l'icône Navigateur Internet ne sont pas modifiées. Merci à "Simple Person" et "valentinbreiz" pour le dumping app.db et les tests.   Télécharger: PS4 4.05 UI Mod Alpha 0.13   Ne vous lancer pas dans l'installation si vous ne savez pas ce que vous faites...         D'autres payloads et modifications sont disponibles, nous pouvons citer par exemple les travaux de Skillsofcape (aka @01cedric) ou encore de VVildCard777. Le premier travaille actuellement sur du game modding, il met en ligne le code kernel nécessaire pour aller modifier les jeux, notamment pour désactiver ASLR 4.05, il regroupe ses travaux sur son compte tweeter.   Le second, VVildCard777, lui s'est attaqué à l'uart, mais là il faut un arduino, un usb et souder un fil sur la carte mère.    Enfin, nous apprenons que Zer0Tolerance a trouvé la méthode que Sony utilise pour générer les "métadonnées" dans lv1 fselfs. La documentation va bientôt être mise en ligne.   Téléchargement : randtool implementation  

Le développeur mission2000 vient de porter l'émulateur de LibRetro RetroArch ainsi que l'émulateur SNES9x 2010 sur la Nintendo Switch.   Attention pour le moment ils ne sont pas amorçables car il manque un lanceur d'homebrews, mais cela ne devrait pas tarder selon les dires des développeurs lors de la 34c3.       Pour y parvenir il faut intégrer la Rom dans un SquashFS qui doit lui même être intégré dans un binaire, bref pas simple mais cela fonctionne.      

 

 

    how to build the Snes Emulator (source gbatemp).   - you need to clone libtransistor - check out the graphics-experimental-fs branch  - compile it - compile ace_loader - clone libtransistor-snes9x2010 - build it - clone libtransistor-retroarch - copy libretro_switch.a from snes9x2010 into retroarch - make a directory called fs  - put your ROM in fs - name it what - build retroarch - launch pegaswitch - launch ace_loader - use that to launch retroarch.  

 

 

  Tout ceci étant très frais, il sera possible probablement d'améliorer les étapes, surtout quand un loader d'homebrew sera disponible.     Les émulateurs se trouvent ici : libtransistor-retroarch / libtransistor-snes9x2010  

  Les développeurs plutoo et Derrek viennent de finir leur présentation à la 34C3 et ils ont comme prévu parlé de la Nintendo Switch. Le moment le plus intéressant a été la présentation d'une démonstration mettant en avant un homebrew.         Nous avons eu confirmation que Switchbrew travaille avec l'équipe ReSwitched, et les accès au système de fichiers, à l'USB, au contrôleur et au réseau sont pleinement possibles.    Le rendu graphique est possible même s'il ne s'appuie pas sur la puissance GPU, tandis que la partie sonore n'est pas encore là, par contre ils ont certifié que les homebrews arrivent sur les firmwares 3.0.0 et inférieurs.         On voit clairement que l'exploit est basé sur les crédits du jeu Tetris Puyopuyo Tetris S. Avec les crédits du jeu, il lance un webkit exploit, et il lance un exploit kernel. Ensuite il lance Twistibex du développeur guten abend.         Après ils nous parlent des Fuses rendant impossible le downgrade, de la séquence de Boot et d'une possibilité de glitch, mais ils informent que le kernel est mappé sur deux adresses, et que tous les objets sont protégés ce qui rend difficile leur exploitation, et tout ceci sans compter les sécurités nVidia et ARM.    

La scène PS4 se reveille enfin depuis la publication du Kexploit 4.05 de Specterdev, les devs ne cessent de mettre à jour pour 4.05 les payloads déjà disponibles pour 1.76.

 

Entre les FTP ou autres Loaders .bin qui apparaissent un peu partout sur le net, voici un autre payload très pratique,enableWebBrowser405.bin developpé par 2much4u.

 

 

 

 

Comme son nom l' indique il permet d activer le navigateur internet PS4, et de façon permanente...

En effet, tous les possesseurs de PS4 non activées (console jamais connecté à internet) non pas accès au navigateur de la console, ce qui est assez ennuyant sachant que le hack se lance principalement par le navigateur.

 

Il existe une manip avec le guide d' utilisateur, afin de retrouver une page Google et ainsi profiter du navigateur, mais cette dernière bien que simple est assez longue à faire.

 

 

 

Vous l'aurez compris, tous ceux étant bloqué au niveau du navigateur internet peuvent maintenant l'activer et de manière permanente, même une fois votre console éteinte, le navigateur restera activé et fonctionnel, plus besoin de passer par le guide utilisateur.

 

Attention ceci ne remplace pas, et n' est pas spécialement utile pour lancer les exploits, si vous utilisez un server local afin de les herberger vous même.

 

 

Tuto: 

- Lancez le Kexploit sur votre PS4 4.05

- Exécuter enablewebbrowser.bin avec n importe quel loader .bin

 

 

Testé sur PS4 pro 4.05 jamais connecté, fonctionne impec...

Merci à Red-j pour le lien

 

 

Télécharger enablewebbrowser.bin

Comme promis, le développeur qui fait trembler la scène PlayStation 4 vient une nouvelle d'assurer ses dires. Après avoir promis il y a deux mois de porter l'exploit dévoilé par la Team fail0verflow sur le firmware 4.05 de la PlayStation 4, voilà qu'il détaille désormais son fonctionnement.    Le développeur Specter vient en effet cette nuit de dévoiler le code utilisé, assurant une nouvelle fois de ses connaissances importantes, mettant en avant l'écriture du code et les tables de matière qui ont été employées.           En plus de 5500 mots il explique toutes les procédures utilisées pour parvenir à l'exploit, commençant par le fait qu'il ne tolère ni ne cautionne le piratage, et que l'exploit n'a pas été créé pour cela. Dans cet article, il fourni une explication détaillée de la façon dont est mise en oeuvre l'exploit publique le décomposant étape par étape. Vous pouvez trouver la source complète de l'exploit, l'exploit userland n'est bien entendu pas décrit, mais il rappelle qu'il l'a déjà fait par le passé.      Les changements depuis le 1.76   Certaines choses notables ont changé depuis le firmware 1.76, Sony a corrigé le bug où nous pouvions allouer la mémoire RWX à partir d'un processus non privilégié. Le processus que nous détournons via l'exploit WebKit ne dispose plus d'autorisations de mappage de mémoire RWX, car JiT est désormais correctement géré par un processus séparé. L'appel de sys_mmap () avec l'indicateur d'exécution fonctionne, cependant, toute tentative d'exécution de cette mémoire de code entraînera une violation d'accès. Cela signifie que notre exploit noyau doit être entièrement implémentée dans les chaînes ROP, pas de payloads C ici.     Le kASLR et de nouveaux system calls   Un autre changement notable est le kernel ASLR (kASLR) qui est désormais activé après le firmware 1.76.   Certains nouveaux system calls ont également été mis en oeuvre depuis la version 1.76. Sur 1.76, il y avait 85 system calls personnalisés. Sur 4.05, nous pouvons voir qu'il y a 120 system calls personnalisés.   Sony a également supprimé le system call 0, de sorte que nous ne pouvons plus appeler un system call que nous souhaitions en spécifiant le numéro d'appel dans le registre rax. Nous devrons utiliser des wrappers du module libkernel.sprx qui nous est fourni pour accéder aux system calls.   On le voit Sony a tout mis à oeuvre pour protéger l'architecture interne de sa console mais cela n'a pa suffit.     Toutes les étapes   Le développeur détaille ensuite chaque étape, la première étape de l'exploit consiste à obtenir des informations importantes du noyau, pour cela il faut s'appuyer sur 3 informations, la divulgation / fuite d'informations sur le kernel. Cela se produit quand il est copié par l'userland mais sans que le tampon ne soit initialisé. Cela signifie que si une fonction est appelée avant de stocker des pointeurs (ou des données d'ailleurs) dans cette mémoire, il y aura une fuite.    Les développeurs peuvent utiliser ceci à leur avantage, et utiliser une fonction de configuration pour leaker de la mémoire spécifique afin de créer des exploits. C'est sur cette théorie que l'exploit kernel est basé. Specter a pris le soin d'expliquer ensuite le fonctionnement des préfixes d'adresses FreeBSD car il est important de distinguer les pointers du kernel et de l'userland.      Le system calls 634   Il explique ensuite qu'on va utiliser le system calls 634 (Vector sys_thr_get_ucontext) qui permet d'obtenir des informations sur un thread donné. Le problème est que certaines zones de la mémoire copiées ne sont pas initialisées, et donc la fonction perd de la mémoire à certains endroits. Ce vecteur a été corrigé en 4.50, car maintenant, avant que le tampon soit utilisé, il est initialisé à 0 via bzero ().   Le plus gros problème avec cette fonction est qu'elle utilise beaucoup d'espace de pile, donc nous sommes très limités à ce que nous pouvons utiliser pour notre fonction d'installation.   C'est cette partie de l'exploit qui a pris le plus de temps et de recherches, car il est difficile de savoir ce que vous leakez sans débogueur, il faut faire quelques suppositions et des expérimentations pour trouver un objet approprié. Obtenir des résultats parfaits ne sera pas très utile non plus car les fonctions peuvent changer  entre les firmwares, surtout quand c'est un saut du firmware 1.76 au firmware 4.05. Cette étape m'a pris environ 1-2 mois dans mon exploit original (il faut rappeler que Specter disait qu'il avait déjà l'exploit avant la publication de la Team fail0verflow qui lui a surtout permi de savoir quel objet était exploitable).   L'exploit se base sur la création d'un thread qui implique l'implémentation d'une fonction, cela est possible grâce à un appel dans le WebKit sur 4.05 par l'offset 0x11570 dans libkernel.   Ensuite, Specter explique qu'il faut faire sauter la protection de kASLR, pour cela il faut manipuler le registre cr0 pour désactiver la protection en écriture du kernel pour les correctifs du noyau. Pour le faire il va utiliser un pointeur de .text pour trouver l'adresse du kernel, pour ensuite injecter l'objet exploitable détaillant chaque étape (stage1, stage2, l'implémentation, stage3, stage4, stage5, la sortie vers l'userland, stage6 et stage7)     La sortie vers l'userland   La sortie vers l'userland a été difficile a mettre en oeuvre, le fait de quitter la chaîne kROP pouvait provoquer le crash du noyau. Pour éviter cela, nous devons restaurer RSP à sa valeur avant les modifications. Il donne les instructions a appliquer pour appliquer un correctif RSP en faisant apparaître la fuite de la pile + 0x3C0 dans le registre RSP, et lorsque le ret final du gadget reviendra à une exécution correcte. Bref un énorme travail là aussi.     Conclusion    Vous l'aurez compris le travail accompli est tout simplement énorme, alors encore une fois soyez patient, un exploit se doit d'être le plus stable possible, cela ne se trouve pas en 5 minutes, et même quand le moyen de lancer l'exploit kernel est trouvé, il faut ensuite un travail gigantesque derrière pour pouvoir l'utiliser (pour rappel il a fallu un an entre la sortie de l'exploit kernel 1.76 et les premières sorties publiques de dumps).   Cet exploit est un exploit assez intéressant pour Specter, mais il a fallu beaucoup de devinettes et il aurait été beaucoup plus amusant de travailler avec s'il avait entre les mains un débogueur de kernel approprié. Pour obtenir un objet exploitable cela a été assez long et épuisant, dans l'ensemble, cet exploit est incroyablement stable, en l'exécutant 30 fois, le kernel ne s'est écrasé qu'une fois. Specter conclue en disant qu'il a beaucoup appris de sa mise en oeuvre en espérant que certains développeurs apprendront de nouveaux éléments.      Remerciements à - CTurt - Flatz - qwertyoruiopz - d'autres contributeurs anonymes      Tout est là : Exploit-Writeups

Comme je vous l'annoncez il y a quelques jours, dans le cadre du 34C3 cette année nous avons droit à une conférence hack concernant la Nintendo Switch.

 

Vous pourrez suivre la conférence directement en streaming ici:

http://streaming.media.ccc.de/34c3/halla#schedule

 

Les explications qui vont être données ne déboucheront pas forcément sur un hack mais permettrons de comprendre un peu plus les sécurités de la console.

 

 

Rendez-vous à 19h45 le 28/12 pour une heure de conférence sur la sécurité de la console

  Que se passe-t-il si un périphérique sécurisé a un format crashdump visible ? Et si ce même périphérique permettait de mettre de la mémoire arbitraire dans le crashdump ? Étonnamment, la PlayStation 4 prend en charge ces deux fonctionnalités, et c'est la Team fail0verflow qui nous en informe !         Deux parties, le crashdump et le lancement de code arbitraire dans la mémoire !   Crashdumps sur PS4   L'infrastructure de gestion dr crash dans le kernel ps4 est intéressante pour 2 raisons :   - C'est un code spécifique à la PS4 (susceptible d'être bogué) - Si le crashdump peut être décodé, nous obtiendrons des informations très utiles pour trouver des bogues et créer des exploits fiables     Sur un système FreeBSD normal, une panique du kernel créera une sauvegarde en appelant kern_reboot avec l'indicateur RB_DUMP. Cela conduit alors à l'appel de doadump, qui va déverser une quantité plutôt minime d'informations sur l'image du kernel elle-même sur un périphérique de stockage.   Sur la PlayStation 4, le remplacement de doadump est mdbg_run_dump, qui peut être appelé dès la panique ou directement depuis trap_fatal. La quantité d'informations stockées dans la sauvegarde est gigantesque - l'état du kernel pour tous les objets process, thread et vm sont inclus, ainsi que des métadonnées sur les bibliothèques chargées.    D'autres changements évidents de la méthode FreeBSD à la vanille sont que le mdbg_run_dump code les données enregistrées dans la sauvegarde, champ par champ, et crypte en plus le tampon résultant avant de le stocker sur le disque.           Dumper n'importe quoi   La Team fail0verflow explique qu'il est possible d'utiliser sur une partie spéciale de mdbg_run_dump où sont gérés tous les threads du processus et essaie de vider l'état de pthread.     dumpstate est un tampon temporaire qui finira par arriver dans le crashdump. Pour résumer, sysdump__internal_call_readuser peut être configuré pour fonctionner comme un oracle accessible en lecture. Ceci est dû au fait que fsbase pointera vers l'espace d'adresse usermode de notre processus webkit.    Ainsi, même sans changer la valeur fsbase réelle, nous pouvons changer librement la valeur de tcb_thread, qui est stockée à fsbase + 0x10.   De plus, sysdump__internal_call_readuser lira heureusement à partir d'une adresse de kernel et placera le résultat dans la sauvegarde.   Nous pouvons maintenant placer n'importe quel emplacement du kernel dans le dump, mais nous devons encore le déchiffrer et le décoder...   En dehors de cela, il y a aussi le problème que nous pouvons seulement ajouter 0x10 octets par thread de cette manière ...   La Team explique après ce que sont le Crypto Crashdump, Crashdump Décodage et le Crashdump Automation en disant que les clés sont les mêmes depuis le firmware 1.01, et que la limité de 0x10 octets n'a qu'une limite de 600 threads ! 600 threads en même temps avant que le processus du navigateur ne se bloque, ou refuse de faire plus de threads.   Avec une telle capacité, l'automatisation des processus est simplifiée, il est alors possible avec une modification matérielle de la commutation d'alimentation de la ps4 au réseau et simuler l'entrée de la ps4 avec l'API gadget usb de Linux, d'aller lire les processus.   Ces problèmes sécuritaires liés aux clés ont été corrigés avec le firmware 4.50, la méthode de génération des clés crashdumps a été modifiée par une reconnaissance d'une clé asymétrique afin de déchiffrer le contenu du dump.   Le processus reste long, juste pour dumper via cette méthode il faut pas moins de 6 jours, cette analyse est une nouvelle fois très intéressante, peut être un moyen de faire une nouvelle fois progresser les recherches sur des firmwares plus récent que le 4.05 par exemple.     Tout est là : ps4-crashdump-dump  

Le développeur Specter vient de mettre en ligne son exploit PlayStation 4 sous firmware 4.05. A l'origine cet exploit s'appuie sur une publication de la Team Failowerflow, et sur l'exploit Webkit 4.05 de qwertyoruiopz, Specter s'étend chargé de l'implémentation de l'objet exploitable.           Dans ce projet, vous trouverez une implémentation complète de l'exploit noyau "namedobj" pour la PlayStation 4 sur firmware 4.05. Il vous permettra d'exécuter du code arbitraire dans le kernel, afin d'autoriser les modifications au niveau du kernel et du jailbreak dans le système.    Cette version, cependant, ne contient aucun code lié au lancement de jeux ou d'exécution d'homebrew. Cet exploit inclut un loader lit les payloads sur le port 9020 et les exécute lors de la réception.   Les détails de l'implémentation seront publiés dans les prochains jours, à priori il est possible de porter l'exploit sur les firmwares inférieurs.       

 

Les patches inclus les correctifs suivants sont faits par défaut dans la chaîne ROP du kernel :   - Désactivation de la protection d'écriture du noyau - Autorisation du mappage de la mémoire RWX (lecture-écriture-exécution) - Résolution dynamique (sys_dynlib_dlsym) autorisée à partir de n'importe quel processus - System call personnalisé # 11 (kexec ()) pour exécuter du code arbitraire en mode kernel - Autorisation pour les utilisateurs non privilégiés à appeler setuid (0) avec succès. Fonctionne comme une vérification d'état, et comme des privilèges.

 

 

Remarques de Specter :    Cet exploit est en réalité incroyablement stable à environ 95% dans mes tests. Le WebKit (navigateur) plante très rarement et il en va de même avec le kernel. J'ai intégré un correctif pour que l'exploitation du kernel ne soit exécutée qu'une seule fois sur le système. Vous pouvez toujours créer des correctifs supplémentaires via des payloads.   Un syscall personnalisé est ajouté (# 11) pour exécuter n'importe quelle mémoire RWX via le kernel, ceci peut être utilisé pour exécuter des payloads qui veulent faire des choses amusantes comme jailbreaking et patcher kernel.   Un SDK n'est pas fourni dans cette version, cependant, un barebone avec lequel commencer peut être publié à une date ultérieure.   J'ai publié un exemple de payload ici qui va faire les correctifs nécessaires pour accéder au menu de débogage du système via les paramètres, jailbreaks, et sortir de la sandbox.   Impressionnant ! 

 

    Tout est là : github.com/Cryptogenic/PS4-4.05-Kernel-Exploit     Il tient à remercier les développeurs   :     qwertyoruiopz Flatz CTurt Anonymous     Edit : Flatz va rétroporter des outils du 4.55 vers le 4.05.      Attention, ne mettez pas à jour en 4.05 si vous êtes sur un firmware inférieur, la plupart des développeurs affirment vouloir porter l'exploit sur des firmwares inférieurs ! Pas de précipitation, sur les firmwares plus anciens le lancement ou la stabilité de l'exploit pourraient être meilleurs...            Pour le moment aucun payload ne permet de lancer des jeux, le seul disponible permet de lancer les debug settings.   

Voilà avec quelques heures de retard débarquent enfin les ReStore et ReNpDrm, deux plugins proposés en open-bêta par CelesteBlue à destination des PlayStation Vita sous 3.60 et sous Enso ou HENkaku. Le but de ces plug-ins est de restaurer le PlayStation Store et d'activer sa console hackée pour profiter des contenus, des jeux ou des utilitaires téléchargés/achetés sur le PSN auparavant.             Les deux plugins sont :   ReStore.suprx Ce plugin user (suprx) va se charger de rétablir l’activation du système depuis les « Paramètres » et ainsi de profiter des téléchargements depuis le PlayStation Store.     ReNpDrm.skprx Ce plugin kernel (skprx) va vous permettre de profiter d'une fausse licence « act.dat » installée avec ReStore. Il permet donc d'activer des consoles qui n'ont jamais été activées, ou désactivées pour reprofiter des jeux téléchargés, de réaliser des backups de jeux PSP, PS1, Vita et PS3 et de reprofiter du PSN.     Ne rêvez pas non plus, cela ne vous permettra pas d'utiliser de jeux nécessitant des clés supérieures au firmware 3.60, ou de télécharger un jeu illégalement tiré du store.      NB : A manipuler avec précautions...      Tutoriel   Après avoir placé les fichiers, il faut éditer le fichier ux0:tai/config.txt   Sous la ligne « *KERNEL » ajoutez en dessous ur0:tai/renpdrm.skprx   A la ligne « *ALL » ajoutez en dessous ur0:tai/restore.suprx   Comme le signale Nepto, il faut supprimer ou désactiver NoNpDrm dans le config.txt, et supprimer le ID.DAT pour le réinitialiser. Il faut aussi créer le dossier data/rif et redémarrer la console. 

 

  Téléchargement (Beta v3) : renpdrm.customprotocol.com/release_page.php  

Notre ami sunriseur Spycos23 nous informe de la disponibilité de RetroArch dans sa version stable v1.7. La Team LibRetro a diffusé hier à l'occasion de Noël la toute nouvelle mouture de l'émulateur multiplate-forme, un bien beau cadeau qui est arrivé à l'heure.                   Les changements de cette version sont aussi nombreux que le nombre de cadeaux dans la hôte du père-noel le 24 décembre au moment de l'apéritif ou quand vous commencez à manger des huîtres, une liste longue comme le bras qui confirme une nouvelle fois la suprématie de la Team LibRetro en la matière.   L'équipe de développement vous souhaitant d'excellentes fêtes de fin d'année, vous invite à découvrir le changelog, qui fait état notamment de l'intégration du support de Bliss-box 4-Play, de celle des badges, de l'amélioration du support des pistolets virtuels comme les Wiimote,  de celui de Windows 95/Windows 98 (non-SE), du retour des portages PSP et Wii U, ainsi que l'amélioration de celui de la PS3.         Voici à titre d'exemple la liste des changements uniquement pour la version PS3 :    - Téléchargements maintenant fonctionnent - Netplay fonctionne maintenant.  - Vous pouvez faire un netplay entre deux PS3, ou avec un autre système qui est aussi de l'architecture big-endian. Par exemple - netplay entre RetroArch PS3 et RetroArch Wii U fonctionne. NOTE: Il peut toujours y avoir du code spécifique à l'endian dans certains cores qui peut causer des bogues. - Content Downloader fonctionne. Vous pouvez télécharger de nombreuses démos et des hombrews freeware. - Thumbnail Downloader fonctionne. Vous pouvez télécharger des boxarts et des titres / snaps pour vos jeux d'ici. - Core Updater fonctionne. Désormais, vous pouvez directement télécharger des cores fraîchement mis à jour directement via Core Updater intégré. De nouveaux cores seront ajoutés au fil du temps, et surtout, vous n'avez pas besoin d'installer une nouvelle version de RetroArch pour les obtenir. - Amélioration du rendu des polices dans le menu. Les langues non-occidentales sont maintenant également supportées par ce rendu de police amélioré, y compris le japonais, le coréen, le chinois, le russe...   Le changelog général quand à lui se trouve ici, il est tellement long, que nous ne préférons pas le rajouter, nous ne voulons pas vous causer une indigestion.     L'intégralité du Changelog v1.7.0    Téléchargement : RetroArch v1.7.0   Merci Spycos23

Alors que nous attendions tous la sortie du plugin ReNpDrm, Celesteblue a mis en ligne, via son compte Twitter, Storage Manager dans sa version v1.0, le retard dans la diffusion de ReNpDrm semble lié à un problème de fournisseur d'accès internet ou d'hébergeur ( il annonce avoir un problème de Freewifi ).               En attendant, le développeur a publié un tout nouveau plugin Storage Manager qui est distribué en version v1.0 et qui va vous permettre de gérer les emplacement de mémoire ux0, ur0 ou uma0 en allant modifier le fichier txt présent dans l'emplacement ur0:tai/storage_config.txt .   L'idée est sympathique, vous pouvez attribuer une partition ur0 ux0 gro0 grw0 xmc0 umA avec soit une SD2Vita (Gcd) soit une carte mémoire Sony (Mcd). Espérons désormais qu'il puisse rapidement proposer son plugin ReNpDrm attendu par de nombreux utilisateurs de PlayStation Vita.     Tutoriel d'utilisation :    - Téléchargez le fichier - Insérez les 2 fichiers (storagemgr.skprx et storage_config.txt) dans le chemin d'accès: ur0:tai - Editer le fichier config.txt en ux0 en entrant la chaîne ci-dessous   *KERNEL ur0:tai/storagemgr.skprx   - Redémarrer la console     Téléchargement : Storage Manager v1.0      

Noël est là, et avec lui effervescence de l'ouverture des cadeaux et autres craintes face à l'homme barbu qu'il soit porteur d'une hôte ou d'une crosse, mais ce que certains d'entre vous attendent est surtout des nouvelles de Specter et de son futur hack sous PlayStation 4 sous firmware 4.05.         C'est ainsi que nous apprenons que l'expoit 4.05 de Specter sera une page qui permettra de charger des payloads que vous allez envoyer, l'exploit qui sera releaser sera une sorte de petit jailbreak qui sera livré avec un correctif du debug menu pour lancer les payloads.         De plus, Specter annonce que son exploit se base également sur un binloader, et que les modders peuvent s'amuser avec le jeu une fois qu'il est lancé.   Selon Specter, l'exploit devrait être proche de son finalisation dans les prochains jours, même s'il n'est pas encore question de release car il s'est lancé dans le développement d'un jeu.     Source : Discord et HydrogenNGU