Aller au contenu


eliboa

Inscrit(e) (le) 14 mars 2018
Déconnecté Dernière activité Privé
-----

#1101149 Switch 10.0.3 sx pro

Posté par eliboa - hier, 10:32

Tout dépend, passer du 10.0.3 au 1.0.0 ça peut faire des beaux dégâts (bon après qui veut passer en 1.0.0 on est d'accord), j'ai débrické quelques consoles avec ce souci et sur certaines c'était pas simple et en plus le brick n'était jamais le même, allez comprendre.

Oui tu as raison de le rappeler. Et aussi je pense que dans le cas de @nintendo, il vaut mieux ne pas downgrader sous le FW 9.1 à cause des fuses LOTUS pour son port cartouche.




#1101091 [Switch] ReSwitched a dumpé le stage0 du payload SX Core/Lite

Posté par eliboa - 03 juin 2020 - 22:09

Vous, vous voyez avec vos yeux d'expert, mais le lambda préférera toujours payer un peu ( meme aps le prix d'un jeu ) pour avoir un truc plus "simple" :)

Perso j'en ai rien à foutre de l'avis du lambda qui est prêt à payer pour SX OS mais s'intéresse pas au hack, ne se documente pas, ne suit pas les recommandations de base comme dumper sa NAND et après vient pleurer sur LS car sa console démarre plus. Ça fait déjà un bail que j'ai arrêté de répondre à la plupart de ces gens "lambda" comme tu dis. Je reste admiratif devant la patience de shadow et bien d'autres pour continuer à les aider. Pour moi hacker sa console demande un minimum d'investissement personnel et je me méfie de l'avis du lambda dont on sait très bien qu'il n'est ici (sur LS) que pour une seule chose.

C'est relou, à chaque fois qu'on critique la TX en parlant de faits, faut toujours que certains nous ramènent à "bah oui mais SX OS c'est trop bien parce que c'est super simple et que tu peux pirater tous les jeux". Tant mieux pour eux, mais qu'il arrêtent de ramener leur fraise en nous traitant d'anti TX gnagnagna. C'est super s'il sont contents de SX OS, ou s'ils pensent qu'AMS c'est pourri car ça lance pas les XCI, c'est tout à fait leur droit. Ça à juste strictement aucun rapport avec le fait que la TX ait "volé" du code à AMS, absolument aucun.

Donc, oui d'une certaine manière tu as raison, tout le monde ne voit pas les choses de la même manière, chacun le voit avec ses yeux.




#1101040 [Switch] ReSwitched a dumpé le stage0 du payload SX Core/Lite

Posté par eliboa - 03 juin 2020 - 11:59

Xecuter ils ont pris une partie du boulot d'un autre groupe (que ça soit en prenant du code source ou en prenant le binaire et en réécrivant le code qui correspond, ça ne change pas grand chose fondamentalement car même si on réécrit du code source à partir d'un binaire, c'est comme si on violait la license originale à partir du moment ou le code binaire est quasiment le même, le outils genre https://www.blackducksoftware.com qui détectent les violations de code open source peuvent se baser sur les binaires d'ailleurs) et ils se sont fait descendre à raison par la communauté.
Maintenant des groupes analysent du code que la team Xecuter ont généré eux même (je pense que sur ce coup il n'y a pas débat) et là les gens veulent violer leur license (oui ce n'est pas parce que ce n'est pas open source qu'il n'y a pas de license, c'est juste que ce n'est pas une license open source ...) que ça soit en analysant leurs binaires ou en hackant leurs serveurs et en leur volant leur code source, ça ne change pas grand chose, au final, sauf pour ceux qui veulent trouver une excuse à l'un ou à l'autre. Si un gars qui a déjà cambriolé une maison par le passé se fait cambrioler à son tour, on pourrait se dire que c'est bien fait, mais en soit ça ne le prive pas de son droit d'aller porter plainte, et ça ne rend pas innocent le voleur de ce dernier.
Après sur des sujets aussi polémiques, chacun aura son point de vue et pourra avancer des arguments qui seront certainement valables aussi, ce que je dénonce juste c'est que le voleur est en train de se faire piller son travail, et certains trouvent ça normal parce que ça les arrange, mais au final pour moi c'est juste du même niveau que ce qu'à fait la team Xecuter avant. Mais bon pour certains le fait que la team Xecuter a "commencé", ça fait d'eux les méchants et les autres maintenant ce sont des justiciers !
Pourtant il y a quand même de grandes chances que la team Xecuter a du avancer des sommes d'argent conséquentes pour pouvoir avancer dans la hack mariko, et que donc sans ce qu'ils ont fait, il n'y aurait surement pas de hack mariko avant un moment ... Certains diront que comme la team xecuter s'est fait cet argent en volant du code open source, c'est normal que ces résultats reviennent à la communauté. Ils ont peut être en partie raison, mais bon le fond de ma remarque c'est que voler un voleur ne fait pas de nous un innocent ;)

D'abord merci pour ta réponse argumentée. Bon après je suis toujours pas d'accord avec toi :). Pour moi réécrire du code source sur la base d'un binaire décompilé n'est pas une violation de la licence. Le RE ne viole pas les licences. Par contre, copier/coller du code source sous licence GPL dans un programme closed source et revendre l'exécutable, là c'est une violation de la licence. Mais bref, passons sur l'aspect licence.

On parle ici de comparer deux teams. Ces deux teams ont toutes les deux fait du RE sur le hardware et le software de Nintendo et Nvidia. Moi j'appelle pas ça voler du code, d'ailleurs ça ne l'est pas. La rétro-ingénierie n'est pas du vol, elle est d'ailleurs souvent utilisée pour détecter si un produit ne viole pas un brevet. Ok, ici c'est du RE dont le but est aussi le hack, là au niveau légal c'est différent (neutraliser un mécanisme de contrôle par ex) mais c'est un autre sujet. Aujourd'hui, la team RS vient faire du RE sur du software de la TX, quelle différence ? En quoi c'est comparable à une utilisation illégale et immorale de code sous licence ? Vraiment, même en restant prosaïque, je ne vois absolument aucun rapport. Est-ce que la team RS à recopié/réécrit le soft de la TX ? Pour le moment non, elle l'a utilisé pour avoir accès au firmware mariko, c'est pas du software TX.

 

Ce qui a été reproché à la TX c'est pas de faire du RE ni même d'avoir repris du code d'Atmosphère. Le problème c'est qu'elle a repris du code sans le dire (violation de licence) et qu'elle a ensuite fait payer ses clients pour du code libre (en partie en tout cas). Elle aurait simplement crédité les auteurs et rendu open-source cette partie de son software et elle aurait été dans les clous.

La question qu'on peut se poser alors, c'est pourquoi ? Pourquoi la TX n'a t'elle pas simplement respecter les conditions de la licence alors que ça n'aurait en rien entravé son commerce ? A mon avis elle ne voulait pas que ses potentiels clients sachent qu'une alternative gratuite existe à son produit.

Enfin, pour répondre à tous ceux qui nous reprochent ici de critiquer sans cesse la TX, j'ai envie de leur demander, si eux en tant que consommateurs du SX OS, ils auraient appréciés de NE JAMAIS SAVOIR que SX OS reprenait du code d'AMS, une alternative gratuite ? Moi perso je trouve normal que les gens soient au courant et ce n'est pas forcément être anti TX que de dire ça, c'est juste rétablir une vérité que la TX ne veut pas dévoiler à ses clients. Ensuite chacun fait son choix.




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

Posté par eliboa - 03 juin 2020 - 09:41

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)




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

Posté par eliboa - 02 juin 2020 - 19:22

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




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

Posté par eliboa - 02 juin 2020 - 19:15

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.




#1100961 [Switch] Hactool adapté par Sciresm pour Mariko

Posté par eliboa - 02 juin 2020 - 17:55

Mais serait-il possible de pouvoir télécharger des jeux sans forcément utiliser un CFW comme il est possible de faire aujourd’hui sur Wii U ?

A mon avis non, deux raisons :

- L'accès à l'eshop sur Switch nécessite forcément un certificat, contrairement à la 3DS ou WiiU. C'est pour ça qu'il existe pas de vrai freeshop sur Switch (ça c'est pour la partie téchargement)

- Et sur WiiU il te faut le ticket d'un jeu original ou le générer via un outil il me semble. Sur Switch, pour installer un backup il te faut les sigpatches qui sont des patchs ES (pour installer des NSP illégaux) et les patch FS (pour installer des xci et homebrew en NSP), le but étant toujours d'installer des programmes qui ne sont pas signés par Nintendo. Aujourd'hui ces patchs sont appliqués au boot (pour les FS patch, pour les ES j'ai un doute, c'est peut-être après le boot). Bref, impossible d'appliquer tous ces patchs via un exploit userland ou même kernel, il te faut un CFW.




#1100959 [Switch] Hactool adapté par Sciresm pour Mariko

Posté par eliboa - 02 juin 2020 - 17:14

Mais donc on pourra probablement jamais hacker les switch sous mariko sans une puce ?

Probablement en effet. En tout cas s'agissant d'un exploit bootrom.

Il pourrait peut-être apparaître un autre type d'exploit, avec un point d'entrée en userland (webkit par ex) comme pegaswitch, nereba, cafeine. Mais du coup l'exploit ne fonctionnerait que sur certaines version de FW donc moins pratique qu'un exploit bootrom comme l'exploit RCM ou le nouveau mod de la TX. Il dépendrait aussi d'autres exploit pour attaquer le kernel et la TrustZone donc pas forcément compatible CFW.




#1100933 [Switch] Hactool adapté par Sciresm pour Mariko

Posté par eliboa - 02 juin 2020 - 15:03

Et tu penses qu’il serait possible de trouver un exploit grâce aux infos divulgées par SciresM ?

Un exploit software pour mariko ? Non je pense pas, en tout cas si j'en crois SciresM.

Pour le moment il semble plutôt impressionné par la qualité de la nouvelle bootrom, il est pas en mode "elle est à chier" (sous entendu avec des bugs exploitable). Mais bon à voir, on ne sait jamais.

Après faut voir, peut-être que de nouvelles failles dans le code de la TrustZone dédiée à mariko seront identifiées. De là à pouvoir en faire un exploit j'y crois pas trop. Comme on dit qui vivra verra ^^




#1100916 [Switch] Hactool adapté par Sciresm pour Mariko

Posté par eliboa - 02 juin 2020 - 11:47

Je me souviens de la première fois quand le SX OS a été décompilé avec un script Python, tout le monde s'attendait à avoir un loader XCI pour CFW et on n'a jamais rien vu venir. Et SX OS nécessite toujours une licence pour fonctionner à 100 %, personne ne l'a cracké il me semble. Je croise les doigt mais ne vous faites pas trop d'illusions non plus...

Déchiffré avec un script python, pas décompilé. La décompilation ça vient après.

En gros la TX fait ça : code source -> obfuscation (optionnel) -> compilation -> chiffrement du binaire -> distribution du binaire (executable)

Et hexkyz avec son script fait : binaire chiffré > binaire déchiffré. Mais ça reste un binaire, du code compilé. Si tu veux le "décompiler" ensuite tu passes par un logiciel qui s'appelle IDA mais ça ne te donne que du code en assembleur, sans aucun label ou nom de variable explicite.

 

Sinon pour le loader XCI, s'il n'existe pas sur la scène libre ce n'est pas parce qu'il n'a pas été cracké à mon avis (mais c'est possible). Des gars comme SciresM, fincs, hexkyz, stuckpixel, etc ont sans doute la compétence pour le faire. Le problème ce sont les DRM et la morale je pense.

 

Enfn pour revenir au sujet de la news, il n'y a rien de particulier à espérer. Si ce n'est qu'Atmopshère sera rendu facilement compatible avec les Switch mariko, ce qui ne sert à rien pour le mec lamba car il n'existe pas d'exploit pour lancer le CFW (hormis la puce de la TX évidemment).

 

@Jarod190 mariko c'est le nom de la nouvelle révision du SoC Tegra (processeur NVIDIA ARM) qui équipe les nouvelles Switch (dont la lite). 




#1100904 [Switch] ReSwitched a dumpé le stage0 du payload SX Core/Lite

Posté par eliboa - 02 juin 2020 - 11:04

la seul chose scirm a baisser dans mon estime en donnant le moyen de pirater les puce tx a part sa j utiliserai encore sx et atmosphere

Juste un truc que tu comprends pas, ReSwitched n'a pas hacké la puce (hardware) de la TX, ils ont fait du RE sur une version leakée de SX OS v3.0 (software). Si tu sais pas faire la diff entre hardware et software on est mal barré.

 

tx ont fourni une puce ouverte aux autre cfw leur permettant de l utilise a leur guise

Etre obligé de passer par le bootloader de la TX t'appelles ça une puce "ouverte" ? Sérieux ?

T'es au courant que tu peux déjà booter sur un payload via le bootloader TX existant ? Ca fait belle lurette que ça existe... Tu veux un scoop ? Tu peux même lancer SX OS en passant d'abord par Hekate.

 

mon avit est d ailleurs que tx est retourner au puce pour être dans sont élément au lieu de cherchez un moyen non soudez suite a vos connerie 

vous allez faire coulez la scène avec vos connerie

lol, au moins tu me fais rire. 




#1100846 [Switch] ReSwitched a dumpé le stage0 du payload SX Core/Lite

Posté par eliboa - 01 juin 2020 - 22:23

C'est marrant tout le monde criait au scandale sur la team Xecuter quand il reprenaient du code open source, et là les team font tout pour qu'il soit possible de piquer leur travail, mais ça c'est normal XD

Tu ne dois pas connaitre la différence entre :

1) dumper, déchiffrer puis dé-compiler un exécutable et faire du reverse engineering pour reconstruire un code sur la base d'instructions en assembleur

2) reprendre un code open source sans respecter sa licence, le compiler et revendre l’exécutable

 

Tous les hackeurs font du RE (1). Comment crois-tu que la TX à fait pour créer le SX Pro et SX OS ? 

ReSwitched fait du RE sur SX OS v3.0, quel est le problème ? Je vois pas le rapport avec le fait de "voler" du code open-source. Pour moi c'est pas comparable




#1100785 [Switch] Le SXOS 3.0.0 a été leaké

Posté par eliboa - 01 juin 2020 - 14:47

Pour la modification de BOOT0 par contre si ça le fait aussi sur les Switch non patchées ça risque de ne pas plaire à la communauté surtout que ça n'aurait que très très peu d'intérêts sur ces consoles d'avoir à faire çà, après ça fera peut-être comme la première version de l'emunand de SX OS qui était sur la nand de la console qui a été une méthode vivement critiquée et la TX a revu ensuite la méthode.

 

A mons avis seuls les SoC "Mariko" sont concernés. Si on en croit cette citation de hexkyz qui indique que la puce (sx core) flashe BOOT0 avec une BCT et un nouveau package1 (bootloader), chiffré avec la BEK de Mariko et une clef de la TX. C'est donc ce package1 qui est lancé par la puce au lieu du package1 officiel. Ce custom bootloader irait d'abord vider les keyslots afin d'éviter qu'un tiers puisse obtenir les clés Mariko en utilisant la puce sx. Mais bon ça n'a servi à rien puisque SciresM et hexkyz les ont trouvé en moins de 24h héhé 

The modchip itself flashes a custom BCT and bootloader to the boot0 partition on the eMMC. These are stored encrypted with the Mariko BEK (Boot Encryption Key) and signed with TX's own key. Once the glitch succeeds, TX's bootloader will run instead of Nintendo's. 

The initial stages focus mostly on DRM and clear out all keyslots (except keyslot number 6) that were filled by the bootrom as a way to block any other third party from obtaining Mariko keys using the modchip. This is, however, ineffective. 

Je me demande par contre comment est flashé BOOT0, j'imagine que le package1 "normal" (offset 0x100000) est remplacé, mais quid du "backup" (offset 0x140000) ? Est-ce qu'il est flashé aussi ou s'agit-il du package1 officiel ? A moins qu'il ne soit backupé plus loin dans BOOT0, à un endroit non alloué habituellement).

 

 

Ben disons ce que je ne comprends pas ceux qu il me semble c'est que la TX avait indique que leur puce fonctionnerai avec atmosphere..... donc forcement il aurait fallait ce fameux boot.dat

C'est pas la puce de la TX qui permettra de lancer Atmosphère (ou n'importe quel payload), c'est leur bootloader (comme c'est déjà le cas en fait). Donc oui il faudra boot.dat mais à priori pas besoin de licence SX OS.




#1100683 [Switch] Le SXOS 3.0.0 a été leaké

Posté par eliboa - 31 mai 2020 - 18:05

Concrètement cela va apporter quoi à la scène switch ? Désolé je ne vois pas en quoi ces clés sont utiles. Intégrer SXOS pour les utilisateurs d'atmosphère ? Merci à tous pour vos réponses ;)

Les clés, ça veut juste dire qu'ils ont réussi à avoir les 2 clés les plus importantes qui permettent de dériver toutes les clés et donc déchiffrer tout le contenu des nouvelles switch (mariko), en gros ^^.

Donc SciresM a maintenant accès au secure monitor et peut étudier la TrustZone sur ces Switch. Pour te répondre ça va apporter des connaissances pour adapter Atmosphère aux switch Mariko, mais ça n'apporte rien comme nouvel exploit. Donc il faudra à priori passer par une puce pour injecter un bootloader et lancer Atmosphère, si toutefois c'est un jour possible (à mon avis oui).




#1100681 [Switch] Le SXOS 3.0.0 a été leaké

Posté par eliboa - 31 mai 2020 - 17:59

Oui j'ai vu ça ce matin sur Twitter, c'est cool si SciresM and co ont pu avoir accès à ce leak, visiblement ça leur a été bien utile.

D'après les tweets de ScriresM, ce serait encore NVIDIA qui aurait merdé, visiblement c'est pas un nouvel exploit, c'est la même technique que pour l'exploit RCM (sauf qu'il faut un mod hardware maintenant)

 

Hexkyz aussi à posté son script pour décompresser SX OS 3.0 :

Scripts for the leaked SXOS v3.0.0 (SHA-256 of 54ce0f58cac9643559991b0b86252424c1bbc59c5c77496110d999814a4a7d52)

As for a changelog, this version's purpose is to support Mariko and the modchip ecosystem, so there are no new features.
Aside from removing all KIPs except for Loader, most of the changes are DRM related. 
Bootloader has new code to interact with and update the modchip.
Patchers now include full copies of each Mariko package1 encrypted with a T210B01/T214 specific key.
All applications have been updated and rebuilt to match current AMS and libnx. 
On the very first boot the bootloader will attempt to update the modchip from version 1.0 to 1.1. Update firmware is stored encrypted inside the bootloader and is likely meant to patch a handful of vulnerabilities and broken code already identified. 
The modchip itself flashes a custom BCT and bootloader to the boot0 partition on the eMMC. These are stored encrypted with the Mariko BEK (Boot Encryption Key) and signed with TX's own key. Once the glitch succeeds, TX's bootloader will run instead of Nintendo's. 
The initial stages focus mostly on DRM and clear out all keyslots (except keyslot number 6) that were filled by the bootrom as a way to block any other third party from obtaining Mariko keys using the modchip. This is, however, ineffective. 
...
It's not a new exploit per se, in fact it's the exact same technique used to achieve code execution on the original units: glitch the PKC hash check.
This was made more difficult with Mariko but the modchip is capable of self-adapting the timings.

Source : Twitter