ckdo
-
Compteur de contenus
66 -
Inscription
-
Dernière visite
Type de contenu
Profils
Forums
Calendrier
Messages posté(e)s par ckdo
-
-
Non tu n'a pas un CB splittés, mais juste un CB refurbishedUn CB splitté c'est uniquement après la MAJ 14717 donc j'ai envie de dire que c'est un problème lié un flash dump tool vu que j-runner t'affiche ce qu'il faut
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 ?
-
Là la problématique est différente.
Tu ne peux pas conserver un RGH1 (CB non splitté) avec une nand retail en Split CB (à partir de 14717).
En Split CB, c'est le CB_A qui n'est pas révocable et qui une fois modifié, nous permet de lancer un CB_B de notre choix.
Si tu souhaites avoir le dual nand tout en restant en RGH1, cela ne sera pas pour un DN Glitch/retail, mais pour un DN Glitch/dev seulement.
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 !
-
Tout à fait :-)
Si tu fais ta mise à jour officielle sur la partie glitch...........
Or, ta mise à jour officielle ne sera faite QUE sur la partie retail du double nand :-)
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 ?
-
Parcontre ton xell, demarage par eject, lui est un cb zero paired. Il bootera donc toujours.
Il n'est pas revocable.
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.
-
Parce que toi en plus d’être en pre 14717 tu est en Refurbished Split CB's, donc avant le rgh1 ne marchait pas sur ta console mais maintenant tu as accès au rgh 2
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...
-
tu va devoir faire une mise a jour officiel vers un dash supporter , quand tu sera en dash officiel 14719 le CB passera en split CB et tu passera donc part l'effet meme en 5773,
je te conseil d'attendre un peu , p-e que une mise a jours des scrip voiront le jour d'ici peu , t'évitant ainsi de passer au rgh2 qui ne boot pas aussi rapidement que le rgh1
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
Hack now works with all Refurbished Split CB's (4577, 5772, 6752)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...
phat pré 14717Rgh 1 si on a pas la clé Cpu
=> 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):
Pour les vieilles Nand, (pré 14717), on a besoin de la clé Cpu pour crypter le nouveau loader, parce qu'il n'y a pas de CBB duquel on peut tirer la séquence.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.
-
Zephyr, Falcon, Jasper, JasperBB sur Xell/Freeboot jusqu'en Kernel 14699
=> Pas tout à fait exact. Si la xbox est passée par le SAV, on peut avoir des surprises (CB incompatible, c'est ce qui m'arrive sur une Falcon)
Ckdo.
-
Diabolique !
Je me demande bien comment ils ont géré le check du LDV pour le CB !
-
Hack fonctionnel sur les CB 14717/14719
Petit correctif à apporter, mauvaise traduction, ce ne sont pas des versions de CB (Hack now works on new CB's (14717/14719 update))
-
Eh bien... même punition avec ou sans les condos ! (Petite précision, il s'agit d'une zephyr 2.0 -> timings identiques pour la puce ?)
J'ai essayé quand même de modifier légèrement mes passages de fils pour ne pas toucher la carte mère, mais rien n'y fait...
Devant un glitch aussi fastidieux (1 fois par siècle), j'abandonne. J'ai une falcon, mais en CB6752. J'ai bon espoir de pouvoir la glitcher bientôt, étant donné les récentes déclarations de la TX.
-
Pour les fils, lors de mon 1er montage j'étais au taquet, pas moyen de faire plus court.
Maintenant j'ai les fils un peu plus long en testant l'alternative "ZackWarrior"...
Je vais acheter les condos et voir ce que ça donne...
-
Non, rien du tout, à part le lecteur DVD. J'ai essayé sans... KO également.
-
En fait la première fois que Xell est apparu, la clé CPU était affichée mais ensuite les lignes de commandes ont défilées la clé CPU est sorti de l'écran.
Entre temps, elle a booté à nouveau sur le Xell, et je l'ai, c'est bon.
Au premier montage, j'ai respecté les chemin des fils conseillées par la team.
Je viens d'essayer un 2ème montage ( conseillé par Zackwarrior ici http://gueux-forum.net/index.php?s=&sh...t&p=1977693 ), mais ce n'est pas mieux :-(
Donc pour l'instant je suis sec ! ( à part les condos mais je n'en ai pas de la bonne valeur sur moi )
-
Bon... un peu de nouveau...
Pendant mes heures de "forumages" sur Zephir / Glitch, j'ai laissé la 360 tourner, j'ai vu les leds vertes s'agiter.
Le Xell était en train de s'allumer. Le temps d'aller chercher un appareil photo pour prendre la clé CPU, elle avait disparu :-(
Bon de toute façon, si elle met 2 heures à glitcher, c'est un poil long !
-
perso j'ai glicher 2 zephir sans souçi
a tu tenter le montage alternatif
avec les condo
Non, mais montage que pour Jasper ?
-
Bonjour,
Je viens de terminer le montage de ma 360Glitchkey (préprogrammée en Zephir) mais malheureusement, ça glitch pas.
J'ai une zephir en CB4578, donc normalement compatible. Elle est maintenant en Kernel 14699.
J'ai dumpé ma nand 2 fois avec le Glitch360SPI, puis j'ai comparé -> OK.
Ensuite j'ai utilisé ECC Nand Flasher pour générer mon ECC, puis écrit dans ma NAND sans souci.
Malheureusement, le Xell se lance pas. J'entends le ventilo faire une impulsion toutes les 8 secondes environ. La Led centrale reste allumée, c'est tout et rien d'autre ne se passe.
J'ai évidement vérifié mon montage mais il est très propre, je l'ai controlé au multimètre quand même. J'ai utilisé les points classiques.
J'ai essayé avec le cable composite également (avant j'étais en HDMI)
J'ai essayé de générer l'ECC avec "Multi 360 Builder", mais il était binairement identique à celui généré précédemment. J'ai ensuite essayé avec Nandpro, la commande s'est bien déroulée mais le résultat est le même -> pas de glitch.
J'ai également essayé de restaurer ma NAND en 14699, puis débranché le VCC de la puce -> boot ok.
Qu'en pensez-vous, j'ai une zephir "dur à cuire" ?
360 Flash Dump Tool & Cb Ldv...
dans Hardware
Posté(e)
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