[PS4] Le hack PS4 rendu possible grâce à un RAM Dump (CTurt)

Après une annonce choc d'un exploit kernel sur PS4, le développeur CTurt vient de faire de nouveaux progrès en faveur d'un hack PS4 futur. Ainsi, il a récemment affirmé avoir réussi à dumper la RAM, rien que ça. Prochaine étape ? La patcher. En d'autres mots, faire en sorte que la PS4 effectue des actions qu'elle n'est pas censée faire de base, ce qui constituerait la première vraie et importante étape vers le hack de la console.

Cturt a récemment confirmé sur Twitter qu'il était déjà capable de dumper la RAM de la PS4 via l'exploit kernel en sa possession. La suite logique serait donc qu'il puisse modifier sélectivement la RAM lors de l'exécution afin de faire réaliser à la console ce qu'elle ne veut pas faire. De là, un SDK et un homebrew loader, ou un Custom Firmware pour la PS4 pourrai(en)t être crée(s).

Par ailleurs, le codeur a promis qu'il écrirait des explications techniques de la façon dont sont exploit fonctionne prochainement.

Vers un hack pour PS4... en firmware 1.76 ?

Le hack a déjà été confirmé par de nombreux autres hackers de la scène underground PlayStation. Ne vous excitez cependant pas trop vite : premièrement, ce genre de choses prend beaucoup de temps (de multiples mois) ; secondement, il ne devrait être accessible que par les PlayStation 4 en firmware 1.76 ou inférieur... Eh oui...

Vous vous en souvenez peut-être, mais c'est sur le firmware 1.76 que les hackers avaient trouvé la faille WebKit. Ce qui signifie que si vous avez une PS4 à jour (3.11), vous ne pourrez tout simplement pas profiter du hack actuellement en cours de réalisation par CTurt. Attention, cela ne veut pas dire que ce jailbreak ne sera disponible que pour une petite poignée de gens, il permettra surtout aux devs d'en savoir plus quant au fonctionnement interne de la console de Sony.

De cette manière, ils pourront analyser le système entièrement, et sûrement trouver beaucoup d'autres vulnérabilités restées intactes en 3.11. Cela dit, il semblerait que certaines personnes se sont déjà lancés à la recherche de bundles de PS4 en 1.76 en Amérique du Nord.

Piraterie et spéculations

Si vous êtes possesseur d'une PS4, vous êtes très certainement impatient à l'idée d'avoir une console hackée. L'obtention d'un accès au noyau (kernel) sous-entend généralement que les verrous anti-piratage de l'appareil peuvent être facilement brisés, mais rien n'a été confirmé à ce sujet. Les personnes qui enfreignent d'ailleurs la sécurité initialement ne sont pas forcément ceux qui lancent la piraterie sur l'appareil. Bref, tout reste très incertain là-dessus, tant mieux ou tant pis selon vos envies.

Faites attention aux nombreuses spéculations et fakes présents un peu partout sur le Net. En général, le grand public, qui ne va pas aller s'informer sur Custom Protocol (bouh les vilains :P), n'ont aucune idée de la réelle avancée du hack PS4, et peuvent très facilement tomber dans des pièges en apparence très alléchants et sérieux. Évitez donc tous les sites qui vous assurent d'avoir des PS4 hackées en leur possession, ou bien un hack pour PS4 tout simplement : ils ne cherchent qu'à vous soutirer de l'argent pour une grosse arnaque. Si un hack PS4 était mis en ligne un jour, Custom Protocol vous chargera de vous en informer le plus rapidement et en détails possible. 🙂

Du teasing qui montre la racine des fichiers système

CTurt a souhaité teaser quelque peu ses prouesses via un dump des fichiers sytème à la racine ainsi que le processus exécuté dans la RAM. En ce qui concerne le filesystem, on peut percevoir des similitudes avec une installation standard de FreeBSD, avec des répertoires tels que "/dev" ou "/mnt."

Les fichiers un peu plus spécifiques à la PS4 sont facilement discernables, tels que SceBootSplash.elf et SceSysAvControl.elf. Les fichiers ELF sont pour rappel des exécutables (un peu à l'instar des PBP), et il est certain que tous ces fichiers doivent être cryptés, mais il serait très intéressant de voir comment ils pourraient être remplacés. Enfin, vu le niveau actuel du hack, ce serait plutôt une mauvaise idée puisque ces fichiers doivent être essentiels au démarrage de la console. Et étant donné que l'on ne sait pas encore débricker une PS4, ça serait con... :3

On peut noter enfin la présence d'un dossier "update", qui doit contenir les informations relatives aux mises à jour (merci Captain Obvious), et déjà existant sur les PSP et les PS3.

[+] Entered shellcode
  [+] UID: 0, GID: 0
[DIR]: .
[DIR]: ..
[DIR]: adm
[DIR]: app_tmp
[DIR]: data
[DIR]: dev
[DIR]: eap_user
[DIR]: eap_vsh
[DIR]: hdd
[DIR]: host
[DIR]: hostapp
[FILE]: mini-syscore.elf
[DIR]: mnt
[DIR]: preinst
[DIR]: preinst2
[FILE]: safemode.elf
[FILE]: SceBootSplash.elf
[FILE]: SceSysAvControl.elf
[DIR]: system
[DIR]: system_data
[DIR]: system_ex
[DIR]: system_tmp
[DIR]: update
[DIR]: usb
[DIR]: user

Le processus quant à lui est un gros mélange de choses et d'autres processus de la PS4. Tous ceux spécifiques à la PlayStation 4 commencent par l'annotation "Sce" ou bien "orbis_" (le nom de code du développement PS4).

  [+] PID 0, name: kernel, thread: mca taskq
  [+] PID 1, name: mini-syscore.elf, thread: SceRegSyncer
  [+] PID 2, name: SceHidAuth, thread: SceHidAuth
  [+] PID 3, name: hidMain, thread: hidMain
  [+] PID 4, name: SceCameraDriverMain, thread: SceCameraDriverM
  [+] PID 5, name: SceCameraSdma, thread: SceCameraSdma
  [+] PID 6, name: hdmiEvent, thread: hdmiEvent
  [+] PID 8, name: xpt_thrd, thread: xpt_thrd
  [+] PID 9, name: iccnvs, thread: iccnvs
  [+] PID 10, name: audit, thread: audit
  [+] PID 11, name: idle, thread: idle: cpu0
  [+] PID 12, name: intr, thread: irq273: xhci2
  [+] PID 13, name: geom, thread: g_notification
  [+] PID 14, name: yarrow, thread: yarrow
  [+] PID 15, name: usb, thread: usbus2
  [+] PID 16, name: md0, thread: md0
  [+] PID 17, name: icc_thermal, thread: icc_thermal
  [+] PID 18, name: sflash, thread: sflash
  [+] PID 19, name: sbram, thread: sbram
  [+] PID 20, name: trsw intr, thread: trsw intr
  [+] PID 21, name: trsw ctrl, thread: trsw ctrl
  [+] PID 22, name: SceBtDriver, thread: SceBtDriver
  [+] PID 23, name: pagedaemon0, thread: pagedaemon0
  [+] PID 24, name: pagedaemon1, thread: pagedaemon1
  [+] PID 25, name: vmdaemon, thread: vmdaemon
  [+] PID 26, name: bufdaemon, thread: bufdaemon
  [+] PID 27, name: syncer, thread: syncer
  [+] PID 28, name: vnlru, thread: vnlru
  [+] PID 29, name: softdepflush, thread: softdepflush
  [+] PID 31, name: SceSysAvControl.elf, thread: SceAvSettingPoll
  [+] PID 33, name: SceSysCore.elf, thread: SysCoreAppmgrWat
  [+] PID 34, name: orbis_audiod.elf, thread: AoutMonitorPid40
  [+] PID 35, name: GnmCompositor.elf, thread: CameraThread
  [+] PID 36, name: SceShellCore, thread: SceMsgMwSendMana
  [+] PID 38, name: SceShellUI, thread: SceWebReceiveQue
  [+] PID 39, name: MonoCompiler.elf, thread: MonoCompiler.elf
  [+] PID 40, name: SceAvCapture, thread: SceAvCaptureIpc
  [+] PID 41, name: SceGameLiveStreamin, thread: SceGlsStrmJobQue
  [+] PID 42, name: ScePartyDaemon, thread: SceMbusEventPoll
  [+] PID 43, name: SceVideoCoreServer, thread: SceVideoCoreServ
  [+] PID 44, name: SceRemotePlay, thread: SceRp-Httpd
  [+] PID 45, name: SceCloudClientDaemo, thread: SceCloudClientDa
  [+] PID 46, name: SceVdecProxy.elf, thread: proxy_ipmi_serve
  [+] PID 47, name: SceVencProxy.elf, thread: SceVencProxyIpmi
  [+] PID 48, name: fs_cleaner.elf, thread: fs_cleaner.elf
  [+] PID 49, name: SceSpkService, thread: SceSpkService
  [+] PID 50, name: WebProcess.self, thread: selectThread
  [+] PID 51, name: orbis-jsc-compiler., thread: SceFastMalloc
  [+] Triggering second kernel payload
  [+] Entered main payload

Rien d'exceptionnel pour l'instant, puisque tout ce que l'on a appris est que CTurt a accès à la RAM et aux processus en cours d'exécution, si ce n'est une très grosse attente et excitation de la part d'un peu tout le monde. Quoiqu'il en soit, nous vous conseillons de rester au taquet, une nouvelle peut venir n'importe quand (qu'elle soit bonne ou mauvaise ceci dit) ! 😀