ckdo

Bonjour à vous, Je reviens avec la réponse à ma question d'origine... Pourquoi cette valeur "bizarre" indiquée pour le LDV CB ? En réalité, la valeur indiquée par l'outil est non signifiante, d'autres données sont dans le CB sont bien pris en compte pour la vérification, mais ne sont pas reportées. Vous pouvez aller jeter un oeil ici http://www.xboxhacker.org/index.php?topic=16935.0, ce post répond exactement à cette question, et détaille précisément comment le check du LDV du CB est réalisé (voir le post de cory1492 dans le fil de discussion) Il a tellement précisé que je me suis amusé à fait un petit soft pour voir un peu comment ça réagit... je vous laisse les sources en pièce jointe (VS2010 Express C# suffit), c'est juste éducatif... rien d'autre à en tirer ;-) CBChecker.zip Ckdo

C'est bien un CB Splitté, refurbished mais splitté, puisqu'il leur faut le RGH2.

Effectivement, bizarre ! Quand tu m'as dit ça, j'ai eu un doute sur mon dump. J'avais fait un dump en 9199 en LPT en 3 fois et comparés ok, obtenus sans erreur et sans bb. Ensuite j'ai acheté un SPI, puis fait un dump en 14699... Mais ... j'ai la même "bizarrerie" ! (pas de CD=0, CE différent de 1888) sur celui en 14699 ! Par contre J-Runner m'affiche les infos sans problème .... C'est une nand de FAT avec un CB splitté, ça viendrait pas de là le souci avec 360 Flash dump tool ? Mes autres nand retail mais avec des CB non splittés s'affichent sans problème... Par contre, indépendamment de cela (c'était ma question initiale...), ma LDV du CB est toujours à 0, sur n'importe quelle nand... Bizarre non ? Des idées ?

Bonjour à vous, J'ai une question sur l'outil "360 Flash Dump Tool"... En ouvrant un de mes dump de Nand retail, un "détail" m'a intrigué : la LDV sur le CB5772 est à 0... Je lance le Xell, regarde le fuseset#2 .. et là je vois 3 efuses de cramés... Entre ce dump de nand retail et ma version actuelle, aucune mise à jour officielle n'a été effectuée, je l'ai passée à la moulinette RGH2 et ensuite généré des nand FB... Par curiosité, j'ai lancé l'outil sur mes autres nand retails, la CB LDV est toujours égale à 0. Est-ce vous savez si la valeur indiquée par cet outil est fiable ?

Ok, Merci pour les éclaircissements ! Microsoft a commis en tout cas une erreur incompréhensible en déportant la vérifications des efuses du CB dans le CB_B... et a récidivé en la portant sur les FATs !

Oula j'étais parti dans la mauvaise direction pour mon raisonnement effectivement ! Je pensais "Gestion du pire"... donc le kamikaze qui fait son update sur la nand Glitch, effectivement. Par contre.. autre question. Qu'en est-il des FAT en RGH1 ? (et qui veulent évidement rester en version 1!) Elles ont leur CB non splités, et le Glitch est situé après la vérification des efuses pour le CB (donc le fuseset #2), non ? Donc là je me dis: - On pourra pas faire de mise à jour "en aveugle" avec la maj officielle pour la retail, car on peut pas incrémenter ce LDV dans la nand FB... - On pourrait construire une nand retail avec un CB inférieur... Mais... - Qu'en est-il de l'incohérence du coup générée entre la version du Kernel et la version de CB ? Du coup Microsoft pourrait voir ça.... et bannir assez facilement ! J'ai tout bon ou alors je suis à l'ouest ?

Bonjour Soulheaven... j'ai quelques questions, Simples curiosités techniques à propos du RGH... rien à voir avec le choix de mettre ou non un SPI sur le x360DNA ;-) Effectivement j'ai lu que le CB_A n'était pas révocable. Mais je ne vois pas en quoi cela est incompatible avec le fait par Microsoft d'écraser ce même CB_A par un autre. La révocation est pour moi permanent, cad qu'on ne peut pas revenir en arrière. Ma par contre je ne vois pas ce qui empêcherait Microsoft de faire une mise à jour qui écraserait le CB_A, pour par exemple "désactiver" le Glitch. Les gens qui ont un SPI peuvent alors revenir sans souci au CB_A initial puisqu'il n'est pas révocable. Egalement, microsoft pourrait écraser le CB_B pour remettre le retail, non ? D'une manière encore plus générale... maj = controle de la nand, donc M$ peut la remettre en retail, donc je ne vois pas comment le Xell peut se lancer avec ça. J'essaie de comprendre le sens de ta remarque, mais j'avoue que je reste sec.. Je sollicite ta patiente pour éclairer ma lanterne ;-) Ckdo.

Bonjour Zack et merci pour ces précisions. Je me pose quelques questions à ce propos... J'ai des temps de boot assez rapides mais si je peux avoir 5s tout le temps ! Au vu des tests que tu as effectués, qu'est-ce qui permet de gagner le plus... la résistance ou le régulateur ? Autre question... j'ai un peu peur de laisser un potentiomètre, j'ai pas trop confiance dans l'aspect mécanique (usure de la piste carbone, faux contacts... surtout si je me récupère un modèle chinois à 2 balles). Donc tu conseilles de l'utiliser "à vie" ou juste pour trouver la valeur idéale ? (et du coup ensuite remplacer par des bonnes vieilles résistances) Ckdo.

Oui, effectivement. C'est juste que je trouve que ce n'est pas dit clairement, à la fois sur le site TX et dans les fichiers releasés pour le RGH2. Donc, pour ceux qui seraient dans le même cas que moi, j'ai fais l'expérience et ça fonctionne, pas besoin de faire une mise à jour. Je ne suis pas contre la mise à jour du dash en soit, c'est celle du CB qui m'inquiétait (boot moins bon en CB5773 ?, je sais pas donc je préfère essayer avant en CB5772..) Ckdo.

Bon je me réponds à moi même... on sait jamais ;-) Ca fonctionne, ça glitch assez vite (en général direct, sinon moins de 1 minute) A ma première édition de ce message, je n'avais pas connecté P9 & P10, mais essayé avec les svf TX_RGH2_B puis TX_RGH2_C. En connectant P9 & P10, ça ne fonctionnait pas avec TX_RGH2_C mais en revenant sur TX_RGH2_B ça fonctionne bien. Donc les "instructions" ci-dessus ont l'air correctes...

Bonjour à vous, Je réalisais ce matin le montage RGH2 avec une Glitch360Key V1.1. Donc, si j'ai bien compris: - On ne connecte pas P13 (PLL_BYPASS n'est pas connecté sur le schéma de montage de la TX) - On met en position "Jasper Recalcitrante" 10100 - On ne met aucun condensateur. Sur P40 / CPU_RST, c'est clairement précisé et pour P13 comme rien n'est connecté je suppose qu'il faut rien non plus. - On met une résistante de 10 Ohms en série avec la connection P40 / CPU_RST (Moi j'avais pas et comme j'ai vu les conseils de seb117 sur son site j'ai mis 2 de 33 Ohms en //) - On connecte P9 & P10 comme sur Slim - Bien sur on programme la puce avec les svf fournis par la TX Est-ce que j'ai tout bon ? Pour l'instant elle boot pas (c'est une Falcon en CB 5772) mais je vais la laisser tourner, c'est juste pour avoir la clé DVD...

Je ne peux pas faire de mise à jour (clé perdue sur firm non XGD3, je pense que la maj échouerais) Le CB5772 est déjà splitté. D'ailleurs la team le supporte Ce que je voulais dire, c'est que je pense que ça fonctionne en RGH2, puisque je génère bien le ECC (sans avoir besoin de la clé CPU). Ckdo.

Oui mais... => Je suis dans ce cas. Comment fais-je puisque mon CB est 5772 ? Le RGH1 ne fonctionne pas sur ce CB.

Bonjour à tous, Je suis pas sur de bien comprendre cette phrase (en fait je ne suis pas sur qu'elle soit exacte): J'ai une Falcon en 9199, mais avec un CB 5772, je n'ai pas la clé CPU. J'imagine qu'ils partent du principe que celles avant les 14717 ont des CB non splités... Donc j'ai essayé de soumettre ça à la moulinette... et ça a l'air de passer sans souci. * Encoding ECC... ------------- Written into output/tx_rgh2_image.ecc Donc pour ceux qui seraient dans le même cas que moi... pour l'instant je n'ai pas de quoi le faire donc je ne peux pas confirmer mais le premier step a l'air ok. Ckdo.

Bonjour à vous, J'aimerais bien jeter un oeil, par pure curiosité au process de check du keyvault. Est-ce quelqu'un aurait déjà fait ça dans un soft, je n'arrive pas à trouver ? En gros je voudrais voir le code source qui fait ce qu'il y a décrit ici: http://www.xboxhacker.org/index.php?topic=7872.140 .. donc vérification de l'authenticité du KV. En entrée on aurait NAND+clé CPU, donc d'après ce que j'ai compris extraction du KV décrypté (donc cette partie j'ai vu dans le source de KV moder, merci au passage de l'avoir releasé), calcul des HMAC-SHA1 (avec la clé CPU) des différentes portions et vérification de la signature RSA située à l'offset 0x1DF8 avec la clé publique du certificat CON. Merci à vous, Ckdo.