[Switch] SciresM confirme l'accès à la TrustZone sous Mariko

664 visiteurs sur le site | S'incrire

Accédez aux coordonnées de l’ensemble des techniciens professionnels recommandés par logic-sunrise 20 derniers dossiers et tutoriaux
Wii / Wii U
[Switch] SciresM confirme l'accès à la TrustZone sous Mariko
Dans une longue vidéo de quatre heures tournée en live en streaming sur Twitch, le développeur SciresM vient de dévoiler comment il a eu accès à la TrustZone sous une Switch Mariko.  
 
 
 
 
Le développeur SciresM s'est donc penché sur le reverse enigneering de la TrustZone liée à la zone de sécurité de Secure Monitor de sa Nintendo Switch Mariko (une des dernières révisions de Switch). Cette zone n'est qu'une partie de la TrustZone comme nous pouvons le voir sous le slide ci-dessous.
 
Le Securite Monitor fournit deux gestionnaires de niveau supérieur dont chacun fournit une gamme de sous-gestionnaires. Les calls sur le Secure Monitor suivent la convention d'appel ARM SMC avec une petite modification, la mémoire Erista est de la LPDDR4, tandis que la mémoire Mariko est de la LPDDR4X, le Securite Monitor effectue certaines opérations cryptographiques d'exécution.
 
Ces recherches, bien que fortement intéressantes, doivent encore être approfondies pour parvenir à du concrêt. Cela a déjà été le cas puisqu'il a pu dumper les clés Mariko, reste à analyser en détail cette TrustZone vu qu'elle est désormais accessible. 
 
SciresM informe qu'un résumé des différences entre TrustZone de Mariko et TrustZone d'Erista (le modèle OLD) sera bientôt publié sur le wiki.
 
 

 

Mardi 02 Juin 2020, 11:59 par tralala
Source : youtube.com
Utilisateur en ligne
02 juin 2020, 19:34
Approuver ce commentaire (+1)
+3
Si sa pourrait aidée a trouver une entrée pour le hack software sa serait vraiment amusant
Répondre à ce commentaire
02 juin 2020, 19:37
Approuver ce commentaire (+1)

Si sa pourrait aidée a trouver une entrée pour le hack software sa serait vraiment amusant

Ouai mais bon faut pas trop rêver non plus, une faille software comme sur les Switch non patchées ça reste très rare. Après sait-on jamais...

Répondre à ce commentaire
02 juin 2020, 19:51
Approuver ce commentaire (+1)
+5
Quel talent ce SciresM :)

Joli taff
Répondre à ce commentaire
02 juin 2020, 20:15
Approuver ce commentaire (+1)
+7

Super stream de SciresM "I VAPE" même si je suis pas allé au bout car trop complexe pour moi.

Je retiens qu'il a obtenu les clés mariko hyper facilement en patchant le stage0 du bootloader de gateway (comme il dit). Aussi ça m'a fait sourire de voir à quel point la doc officielle NVIDIA lui est utile (merci NVIDIA ^^). C'est sympa ce genre de stream ou il fait du RE en direct, tu peux voir à quels problèmes il est confronté et comment ça fuse dans son cerveau pour trouver des solutions. Impressionnant.

Répondre à ce commentaire
02 juin 2020, 20:20
Approuver ce commentaire (+1)
+4
Merci la Team Xecuter, sans eux on aurais pas eu ça :)
Répondre à ce commentaire
02 juin 2020, 20:22
Approuver ce commentaire (+1)
+7

Merci la Team Xecuter, sans eux on aurais pas eu ça :)

Ouaip, et merci SciresM, et merci Nintendo, et merci NVIDIA. Sans eux on aurait pas eu ça :).

thnaks.png

Répondre à ce commentaire
02 juin 2020, 21:08
Approuver ce commentaire (+1)
+1

Merci la Team Xecuter, sans eux on aurais pas eu ça :)


Tu peut surtout remercier scireM sans lui y aurai plus d sx os depuis le firmware 9.0
Répondre à ce commentaire
02 juin 2020, 21:11
Approuver ce commentaire (+1)
C'est un tueur ce mec !!! Dommage qu'il traine pas sur One ou ps4
Répondre à ce commentaire
02 juin 2020, 21:19
Approuver ce commentaire (+1)
+3
I vape
Répondre à ce commentaire
02 juin 2020, 21:50
Approuver ce commentaire (+1)
+2

Tu peut surtout remercier scireM sans lui y aurai plus d sx os depuis le firmware 9.0


Je dirais meme le 7.0 hihi
Répondre à ce commentaire
02 juin 2020, 22:16
Approuver ce commentaire (+1)
+2
Merci à la tx
Répondre à ce commentaire
02 juin 2020, 22:31
Approuver ce commentaire (+1)

jeternephew.gif

Répondre à ce commentaire
02 juin 2020, 23:18
Approuver ce commentaire (+1)
il pu la merde la tx, c'est des plagieurs!
par contre le mec dans la video ( Michael a priori)... c'est du lourd
Répondre à ce commentaire
02 juin 2020, 23:44
Approuver ce commentaire (+1)
Apparement Nvidia ont "oublier" d'ajouter les protections contres le type de glitch utiliser dans le bootrom lors d'un check d'un hash important... Alors qu'ils ont implementer les protections ailleurs (d'ou le tweet de hexquyz que "c'est le meme exploit" qu'ils avaient utiliser pour obtenir les clées de la switch originale)

Le pire dans tout ca, c'est que sansNvidia, on serait pas bien loin dans le hack sur les versions post 5.0.0 en ce moment.
Répondre à ce commentaire
Utilisateur en ligne
03 juin 2020, 01:21
Approuver ce commentaire (+1)
+1

il pu la merde la tx, c'est des plagieurs!
par contre le mec dans la video ( Michael a priori)... c'est du lourd


C'est pourtant les premiers a avoir sortie une puce et un loader de XCI sur Switch
Répondre à ce commentaire
03 juin 2020, 01:47
Approuver ce commentaire (+1)

il pu la merde la tx, c'est des plagieurs!
par contre le mec dans la video ( Michael a priori)... c'est du lourd


C'est pourtant les premiers a avoir sortie une puce et un loader de XCI sur Switch

Je ne souhaite même pas répondre il faut le dire à un moment sxos c’est servit du code de ams et c’est pas plus mal donc dire que c’est les premier c’est faux mais après ce n’est pas grave que ils ai copié. Donc dire ça c’est pas très logique mais pourquoi pas
Répondre à ce commentaire
03 juin 2020, 04:07
Approuver ce commentaire (+1)
+1


C'est pourtant les premiers a avoir sortie une puce et un loader de XCI sur Switch

On va pas recommencer comme sur cette news dans laquelle je crois que tout a été dit.

Répondre à ce commentaire
03 juin 2020, 09:21
Approuver ce commentaire (+1)
J'espère que ça débouchera ver un hack soft, ou une solution hen.
Répondre à ce commentaire
03 juin 2020, 09:36
Approuver ce commentaire (+1)

J'espère que ça débouchera ver un hack soft, ou une solution hen.

Je crois que cela a été dit de nombreuses fois, un hard hardware est obligatoire pour lancer l'exploit.
Corrigez-moi si je me trompe.
Répondre à ce commentaire
03 juin 2020, 09:48
Approuver ce commentaire (+1)
+1

J'espère que ça débouchera ver un hack soft, ou une solution hen.

Je crois que cela a été dit de nombreuses fois, un hard hardware est obligatoire pour lancer l'exploit.
Corrigez-moi si je me trompe.

Pour l'instant un hardware est obligatoire
Mais n'oublie pas que la ps3 ultra silm était aussi soit disant inhackable
Répondre à ce commentaire
03 juin 2020, 09:52
Approuver ce commentaire (+1)

Ce qui est "embêtant " c'est que Nvidia  c’est "concentré" sur la partie graphique et "moins" sur la partie sécurité qui semblais important au vu de la cible embarqué du soc .

Les clients qui l'utilise comme Nintendo doit êtres un peu remonté sur ce sujet .

Par contre on pourras pas reprocher à Nvidia de ne pas fournir de bonne docs :D

Répondre à ce commentaire
03 juin 2020, 10:41
Approuver ce commentaire (+1)
+2

Apparement Nvidia ont "oublier" d'ajouter les protections contres le type de glitch utiliser dans le bootrom lors d'un check d'un hash important... Alors qu'ils ont implementer les protections ailleurs (d'ou le tweet de hexquyz que "c'est le meme exploit" qu'ils avaient utiliser pour obtenir les clées de la switch originale)

Le pire dans tout ca, c'est que sansNvidia, on serait pas bien loin dans le hack sur les versions post 5.0.0 en ce moment.

Oui, j'avais pas trop compris au début mais en lisant les explications de hedgeberg sur discord, c'était plus clair.

Pour ceux que ça intéressent voici une traduction grossière :

"Au début on a pensé que la puce (sx core) ne glitchait pas le BCT check, parce que la bootrom était supposément pleine de délais aléatoires. On avait en fait décidé de ne pas continuer avec ce glitch sur mariko car nous supposions que le délai entre la dernière lecture emmc et le BCT check était "aléatoire". Et bien non. NVIDIA semble avoir... oublié... d'ajouter un délai aléatoire entre la fin de la dernière lecture emmc, avant le BCT check, et le BCT check en lui-même. Ce qui veut dire que même si la bootrom est remplie de timings aléatoires, cela n'affecte pas la partie qui compte le plus. Il semblerait bien que nvidia ait merdé à nouveau".

Selon hexkyz, la TX n'aurait pas pu faire du RE (soft) sur cette nouvelle bootrom pour y arriver, elle aurait plutôt observé les timings et recherché un déterminisme dans les délais. Pour dumper/déchiffrer la bootrom d'autres glitchs seraient nécessaires.

 

edit : ça discute aussi sur le discord pour savoir si une nouvelle version iPatched de mariko pourrait bloquer la puce TX ou si celle-ci saurait s'adapter à des délais aléatoires. A priori, la puce s'adapte déjà dans un sens ou les paramètres du glitch varient d'une console à une autre (la puce ajuste les paramètres jusqu'à ce qu'ils soient corrects pour la dite switch), ce qui ne veut pas dire qu'elle puisse s'adapter à des délais aléatoires. En fait le délai va varier d'une switch à une autre mais l'essentiel est qu'il y ait toujours un déterminisme à l'oeuvre dans ce délai. Verrons-nous bientôt apparaître une révision de Mariko ? C'est bien possible.

 

edit2 : apparemment il y a autre chose qui intéresse la team RS, c'est de pouvoir dumper le firmware de la puce TX (en glitchant la puce qui glitche ^^), c'est pourquoi ils tentent de connaître le type de MCU utilisé (peut-être une série STM32F3). Ce qu'ils voudraient c'est obtenir la clé du firmware afin de comprendre ce qui se cache derrière la mise à jour du fw du mcu qui est faite au premier boot (il passe de 1.0 à 1.1)

Répondre à ce commentaire
03 juin 2020, 11:26
Approuver ce commentaire (+1)

J'espère que ça débouchera ver un hack soft, ou une solution hen.

Je crois que cela a été dit de nombreuses fois, un hard hardware est obligatoire pour lancer l'exploit.
Corrigez-moi si je me trompe.

Pour l'instant un hardware est obligatoire
Mais n'oublie pas que la ps3 ultra silm était aussi soit disant inhackable

C'est clair, de tout façon l'espoir fait vivre, alors soyons optimiste ☺.
Répondre à ce commentaire
03 juin 2020, 11:38
Approuver ce commentaire (+1)
De toute maniere les hacks c est toujours un oublie de securisation a quelque part. Si tout etait ultra securise il n y aurait aucun hack disponible

Vive les failles
Répondre à ce commentaire
03 juin 2020, 12:25
Approuver ce commentaire (+1)
putain il nous faut ce genre de devs sur les autres platformes, des mecs doués et humbles qui pètent pas plus haut que leurs fesses pas les gamins qu'on a sur ps4 (même si sur ps4 on a aussi d'excellent
devs mais qui malheureusement ne peuvent pas tout faire seuls)
Répondre à ce commentaire
03 juin 2020, 12:25
Approuver ce commentaire (+1)

Merci la Team Xecuter, sans eux on aurais pas eu ça :)

Ouaip, et merci SciresM, et merci Nintendo, et merci NVIDIA. Sans eux on aurait pas eu ça :).


Ça fais les aveugles mais aucun problème, ça change rien à la réalité :)
Répondre à ce commentaire
03 juin 2020, 12:39
Approuver ce commentaire (+1)
+1
Purée, je commence à en avoir marre de voir cette guerre de...
sur TX et Atmosphère c'est bon depuis longtemps ça était prouvé que TX a utilisé du code d'Atmosphère.
Après TX ta juste les XCI et le disque dur externe en plus.
Je suis désolé mais suffit de regarder à chaque nouveau firmware si ta pas SciresM on pourrait attendre des mois que TX ne mettrait pas à jour.

PS : J'utilise SX OS/Atmosphère.
Bien que je préfère largement Atmosphère vu toutes les possibilités dessus maintenant.

On dirait les guerre des... sur les consoles : À non la ps4 est mieux que la Xbox Blabla.
Répondre à ce commentaire
03 juin 2020, 12:59
Approuver ce commentaire (+1)
Bonjour,

On dit Nvidia a laisser des failles mais bon il doit pas avoir beaucoup de personne comme SciresM pour les trouver. :)
Répondre à ce commentaire
03 juin 2020, 12:59
Approuver ce commentaire (+1)
En tout cas nvidia perd très gros, la prochaine gen de nintendo.
il vont pouvoir ce mettre un gros doigt dans le fi..
Je pense pas que nintendo seront prêt à retravailler avec eux .
Répondre à ce commentaire
03 juin 2020, 13:02
Approuver ce commentaire (+1)

Purée, je commence à en avoir marre de voir cette guerre de...
sur TX et Atmosphère c'est bon depuis longtemps ça était prouvé que TX a utilisé du code d'Atmosphère.
Après TX ta juste les XCI et le disque dur externe en plus.
Je suis désolé mais suffit de regarder à chaque nouveau firmware si ta pas SciresM on pourrait attendre des mois que TX ne mettrait pas à jour.

PS : J'utilise SX OS/Atmosphère.
Bien que je préfère largement Atmosphère vu toutes les possibilités dessus maintenant.

On dirait les guerre des... sur les consoles : À non la ps4 est mieux que la Xbox Blabla.


Ben pour le coup la ps4 est bien mieux que la Xbox,
Par contre la Xbox one est bien mieux que la playstation.
;)
Répondre à ce commentaire
03 juin 2020, 13:21
Approuver ce commentaire (+1)

Oui, j'avais pas trop compris au début mais en lisant les explications de hedgeberg sur discord, c'était plus clair.
Pour ceux que ça intéressent voici une traduction grossière :
"Au début on a pensé que la puce (sx core) ne glitchait pas le BCT check, parce que la bootrom était supposément pleine de délais aléatoires. On avait en fait décidé de ne pas continuer avec ce glitch sur mariko car nous supposions que le délai entre la dernière lecture emmc et le BCT check était "aléatoire". Et bien non. NVIDIA semble avoir... oublié... d'ajouter un délai aléatoire entre la fin de la dernière lecture emmc, avant le BCT check, et le BCT check en lui-même. Ce qui veut dire que même si la bootrom est remplie de timings aléatoires, cela n'affecte pas la partie qui compte le plus. Il semblerait bien que nvidia ait merdé à nouveau".
Selon hexkyz, la TX n'aurait pas pu faire du RE (soft) sur cette nouvelle bootrom pour y arriver, elle aurait plutôt observé les timings et recherché un déterminisme dans les délais. Pour dumper/déchiffrer la bootrom d'autres glitchs seraient nécessaires.
 
edit : ça discute aussi sur le discord pour savoir si une nouvelle version iPatched de mariko pourrait bloquer la puce TX ou si celle-ci saurait s'adapter à des délais aléatoires. A priori, la puce s'adapte déjà dans un sens ou les paramètres du glitch varient d'une console à une autre (la puce ajuste les paramètres jusqu'à ce qu'ils soient corrects pour la dite switch), ce qui ne veut pas dire qu'elle puisse s'adapter à des délais aléatoires. En fait le délai va varier d'une switch à une autre mais l'essentiel est qu'il y ait toujours un déterminisme à l'oeuvre dans ce délai. Verrons-nous bientôt apparaître une révision de Mariko ? C'est bien possible.
 
edit2 : apparemment il y a autre chose qui intéresse la team RS, c'est de pouvoir dumper le firmware de la puce TX (en glitchant la puce qui glitche ^^), c'est pourquoi ils tentent de connaître le type de MCU utilisé (peut-être une série STM32F3). Ce qu'ils voudraient c'est obtenir la clé du firmware afin de comprendre ce qui se cache derrière la mise à jour du fw du mcu qui est faite au premier boot (il passe de 1.0 à 1.1)


On le voit tout de suite que la puce s’adapte, au premier lancement de la console avec mochip installé le demarrage pour ma part a ete un tentinet plus long que les boots suivants. Ca me fait pensez au timming du srgh pour Ace V3 qui peuvnt aussi faire cela temps que la console n’est pas debrancher elle garde en memoire le meilleur timming pour ellee.
Répondre à ce commentaire
03 juin 2020, 13:33
Approuver ce commentaire (+1)

Merci la Team Xecuter, sans eux on aurais pas eu ça :)

Ouaip, et merci SciresM, et merci Nintendo, et merci NVIDIA. Sans eux on aurait pas eu ça :).


Ça fais les aveugles mais aucun problème, ça change rien à la réalité :)

Y'en a qui font les aveugles comme tu dis,mais bon toi t'as oublié tes jumelles.
Répondre à ce commentaire
03 juin 2020, 13:35
Approuver ce commentaire (+1)

On le voit tout de suite que la puce s’adapte, au premier lancement de la console avec mochip installé le demarrage pour ma part a ete un tentinet plus long que les boots suivants. Ca me fait pensez au timming du srgh pour Ace V3 qui peuvnt aussi faire cela temps que la console n’est pas debrancher elle garde en memoire le meilleur timming pour ellee.

Intéressant mais je me demande si ce délai, dans le cas du premier boot, est lié à soit :

- comme tu dis, l'adaptation du glitch en lui même

- le temps pour flasher la BCT et le package1 sur la NAND. Allez il faut dumper, déchiffrer, réécrire, rechiffrer et restaurer à peine 0x800 Kb à tout casser mais ça doit prendre un peu de temps quand même.

- le temps pour flasher le firm du MCU qui si j'ai tout compris est lu dans boot.dat sur la mmc.

 

C'est sans doute un peu des trois j'imagine. Par contre, par rapport à ta ref au glitch du Ace v3, je me demande comment ça fonctionne sur le SX Core, est-ce que le meilleur timing est enregistré autre part que sur la mémoire volatile ? Autrement dit est-ce l'adaptation du glitch ne se fait qu'au tout premier boot ou à d'autres moment ?

Répondre à ce commentaire
03 juin 2020, 14:39
Approuver ce commentaire (+1)
+1
Ca sur le chan ils ne veulent absolument pas s’avancer sur comment elle fonctionne. Au tout debut des test j’ai demandé de comment la hack agissait sur la console. La reponse a ete simple on est pas la pour parler de cela. J’ai demandé si une fois rendu publique ils allaient en parler et je m’etais avancé sur la possibilité que ce soit un hack bootroom. La reponse a ete oui c’est un hack du bootroom via glitch pour le reste tu le sauras bien assez vite une fois la puce sortie...
Répondre à ce commentaire
03 juin 2020, 14:40
Approuver ce commentaire (+1)
En rêvant un peu(vu que je ne sais pas du tout comment on pourrait faire sans passer par un dongle,un trinket M0 ou un smartphone/tablette)cela pourrait aboutir à faire booter un cfw sur une switch non patchée sans passer par ces gadgets.
Répondre à ce commentaire
03 juin 2020, 14:59
Approuver ce commentaire (+1)
tout le monde parle de guerre ...mais en fait y a un seul truc ...et c est le hack payant de sxos ! et quand la version est foireuse , les gens s en donnent a coeur joie....et moi le premier !
Répondre à ce commentaire
03 juin 2020, 15:01
Approuver ce commentaire (+1)
Sa sent bon tout sa ;)
Répondre à ce commentaire
03 juin 2020, 15:39
Approuver ce commentaire (+1)

Sa sent bon tout sa ;)


Bha ca te donnera pas de hack soft que peut etre un clone des modchips plus rapidement.
Répondre à ce commentaire
03 juin 2020, 19:38
Approuver ce commentaire (+1)
+1
Encore une console inviolable sans modchip, tout comme le furent la ps3 metldr2 et la ps vita...
La vrai question pour la mariko n'est pas si elle sera hackée software mais plutot quand.
Répondre à ce commentaire
03 juin 2020, 20:17
Approuver ce commentaire (+1)

Encore une console inviolable sans modchip, tout comme le furent la ps3 metldr2 et la ps vita...
La vrai question pour la mariko n'est pas si elle sera hackée software mais plutot quand.


Bha pour l’instant c’est loin d’etre le cas meme Mscire lui meme en parlait mais bon peut etre que l’avenir nous le dira mais ca reste que la 360 meme si hacké de tout les coté aucune alternative au rgh est sorti...
Répondre à ce commentaire
03 juin 2020, 23:29
Approuver ce commentaire (+1)

Encore une console inviolable sans modchip, tout comme le furent la ps3 metldr2 et la ps vita...
La vrai question pour la mariko n'est pas si elle sera hackée software mais plutot quand.


Bha pour l’instant c’est loin d’etre le cas meme Mscire lui meme en parlait mais bon peut etre que l’avenir nous le dira mais ca reste que la 360 meme si hacké de tout les coté aucune alternative au rgh est sorti...


Je suis entièrement d'accord avec toi sauf que la sécurité chez nintendo et chez Microsoft ce n'est pas le même niveau ont me dira que nvidia sont pour beaucoup mais nvidia ne sont pas les seule à concevoir la console
Répondre à ce commentaire
04 juin 2020, 01:11
Approuver ce commentaire (+1)
J'espère qu'un clone open source verra le jour afin que le mec qui fait la dragon-mmc décide de l'adapter pour les switch mariko :D
Répondre à ce commentaire
04 juin 2020, 19:51
Approuver ce commentaire (+1)
Salut a tous

Franchement vous travaillez avec eux, qui vous dit qu'il n'y a pas d arrangement de bon procédé entre eux ? que se soit la tx atmosphere Scires M et y en a surement d'autres qui travaille derriere ca a un cout tous ca n est ce pas? Donc merci d'arrêtez les guerres débiles et inutiles de respecter le travaille de chacun et si vous avez les capacités de donner du temps et de mieux faire faites sur ceux bon games a tous
Répondre à ce commentaire
05 juin 2020, 07:52
Approuver ce commentaire (+1)
+1

Salut a tous

Franchement vous travaillez avec eux, qui vous dit qu'il n'y a pas d arrangement de bon procédé entre eux ? que se soit la tx atmosphere Scires M et y en a surement d'autres qui travaille derriere ca a un cout tous ca n est ce pas? Donc merci d'arrêtez les guerres débiles et inutiles de respecter le travaille de chacun et si vous avez les capacités de donner du temps et de mieux faire faites sur ceux bon games a tous

Merci pour ce somptueux commentaire a la syntaxe irréprochable qui est, par ailleurs, truffé d'informations dont la véracité n'aura, sans doute, échappé a personne.
Répondre à ce commentaire
Cliquer ici pour continuer sur le forum
Envoyer