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

Il nous ne aura pas fallu attendre bien longtemps avant que Linux ne débarque sur firmware 4.05 sur Sony PlayStation 4. Voilà que le dernier jour de l'année 2017 nous a apporté Linux sur ce firmware.   Comme sur firmware 1.76 cela passe par un payload qui va permettre de lancer Linux, il vous faut compiler le kexec avec make CFLAG='-DPS4_4_05 -DKASLR -DNO_SYMTAB' et utiliser une clé USB formatée en FAT32 avec les images bzImage et initramfs.cpio.gz que vous trouverez ici.         Tout est expliqué ici par valentinbreiz : PS4-Linux-Loader  et ici sur Twitter   Bonne année 2018 !   

Voici un petit Playground pour les PS4 en 4.05, à la base crée par SpecterDev et Red-eyeX32 pour les PS4 en 3.55 pour le POC 3.55 (Webkit), que je me suis permis de modifier afin d' y intégrer les 2 exploits kernel disponibles.

 

En effet, avec la publication du FULL FTP, il y a dorénavant 2 exploits kernel.

Le 1er de SpecterDev comprenant certaines restrictions empêchant le FULL FTP et celui de IDC sans restrictions.

 

J ai donc rassembler les 2 exploits sur une seule page (Playground), comme on peut voir sur Wii U avec les différents exploits, mais aussi mis un lien directement vers google.com.

Vous trouverez également des raccourcis vers différents sites d informations comme Logic-Sunrise.com, Mod consoles.fr ou encore PSXHax.com, afin de savoir où suivre l' actualité de la scène PS4 ( il est possible d' en rajouter très facilement ^^ ).

 

 

Vous pourrez utiliser ce "Playground" seulement si vous possédez un server local, il vous suffira de décompresser l'archive dans votre dossier C:\xampp\htdocs\document\ca\ps4.

 

Toute personne voulant apporter des modifications sur ce Playground est libre de le faire, je ne pense pas le maintenir à jour, modifié à la base pour mon server local, je vous le partage après avoir rajouter l exploit Kernel de IDC.

 

video:

 

 

Je tiens à remercier SpecterDev pour ses nombreux travaux, ansi que Red-EyeX32 et IDC qui ont permis ce mini-Playground 4.05.

 

Télécharger: Playground 4.05

 

 

 

Le développeur d0k3 nous offre probablement ce qui sera la dernière version de l'année de GodMode9. Les innovations apportées par chaque version sont nombreuses, cette mouture ne déroge pas au travail toujours conséquent de d0k3.             Désormais les fichiers d'exportation DSiWare et les Rom .gba sont supportées, et les fichiers d'exportation .TAD.   Désormais GodMode9 affiche également les informations des titles pour les homebrews 3DSX et ajoute un éditeur d'attribut de fichier.    L'aeskeydb.bin peut maintenant être également installé dans la NAND et d'autres informations ont été ajoutées aux informations système.              Si une action dangereuse est faite, GodMode9 vous demande explicitement si vous voulez vraiment faire cela et vous devez entrer une combinaison de boutons - dans cette version, elle sera générée aléatoirement.   GodNMode9 supporte fastboot3DS et le support de script a été grandement amélioré par des actions comme "if", "elif", "else", "end" et "goto".     

Tout est dans le changelog.

 

  * [new] Full support for DSiWare Exports / .TAD files (thanks @ihaveamac for help) * [new] Limited .GBA rom image support (title info / renaming) * [new] Title info support for a .3DSX * [new] File attribute editor (thanks @angelsl) * [new] aeskeydb.bin can be installed to NAND, eliminating the need to have it on the SD card * [improved] Improved string input tool, now with alphabet preview * [improved] Write permission unlocker now uses random button sequences * [improved] PCX support for splash bitmaps, reducing GM9 .firm size (thanks @Wolfvak) * [improved] Slightly tweaked bootloader * [improved] Additional entries in system info * [improved] New battery color scheme (thanks @JoshuaDoes) * [improved] A gigaton of smaller improvements, many of them under the hood * [fix] Several bugfixes, fixing freeze issues with fastboot3DS (thanks, @profi200) * [fix] Unified handling of tar (when compiling, on all OSes), via a Python script (thanks @ihaveamac) * [scripting] Control flow support via if, elif, else, end, goto (thanks @windows-server-2003) * [scripting] labelsel command, allowing the user to select from a range of labels to jump to * [scripting] strsplit command, allowing to extract substrings from a string * [scripting] New REGION environment var

 

 

Edit du 02.01.2018

  Téléchargement : GodMode9 v1.5.1        

Comme nous vous l annoncions il y a peu, la scène PS4 vient de se réveiller et s' active, pour notre plus grand bonheur, à mettre à jour les payloads 1.76 à jour pour nos PS4 4.05.

 

Alors que les payloads FTP pleuvent sur le net, ils ne permettaient pas d' accéder à la totalité des dossiers et fichiers présents dans votre PS4, cela n avait donc que peu d intérêt (d' où l' absence de news à ce sujet).

 

 

 

 

Le soucis est maintenant résolu, en effet depuis peu le FULL FTP est disponible et permet ainsi l'accès total aux dossiers et fichiers de votre console (Testé et fonctionnel) mais bien plus encore (Customisation du menu, Mods, Dump...^^ etc...).

 

 

 

 

Pour activer le Full FTP, il vous faudra utiliser les fichiers présents dans la description de la vidéo-tuto de Spoofayy, ci dessous.

 

- Local Exploit host tool

- Netcatgui

- Payload pour FTP (hello.bin)

- Avoir Python d' installé sur son PC ou le faire ^^

- Client FTP (Filezilla ou autres)

 

Petite indication supplémentaire, il vous faudra OBLIGATOIREMENT modifier le fichier hello.bin ou 405ftp.bin afin d' y intégrer l' IP de votre PS4, sans ça un message d' erreur sera affiché dans votre client FTP (Filezilla ou autre...).

 

- Ouvrez le fichier hello.bin avec un éditeur HEX

- Offset 00005900 modifiez l IP 192.168.1.37 par celui de votre PS4.

- Le port pour Filezilla est 1337.

 

 

 

 

Tuto vidéo:

 

 

Notre ami sunriseur Red-J nous informe que Kodi est arrivé légalement sur Microsoft Xbox One, même son développement se fait progressivement sur le store, le mediacenter qui va fêter ses 10 ans d'existence, débarque enfin sur cette plate-forme pour notre plus grand plaisir.          Entièrement personnalisable, pour installer Kodi il suffit d'aller sur le Windows Store et de chercher l’application.         Pour le moment, il s'agit d'une version Bêta v18 mais gageons qu'une version stable verra le jour rapidement, car Kodi se révèle être pleinement utilisable sans bugs.        Tout est là : https://kodi.tv/article/kodi-xbox-one

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