Gab76

montre la clef obtenue.

hormis répéter: http://gueux-forum.net/index.php?showtopic=236377

normal, XBReboot utilise le dernier CB (6750 sur une Jasper, 1921 sur Xenon par exemple)

tu devais pas être frais alors

retirer la résistance R6T3

moi j'ai fait l'essai avec un kernel 7371, ca fonctionne aussi

de là à cramer le lecteur, non. es ce qu'il s'ouvre et se ferme au moins?

ton lecteur est sans doute mort. tu n'as pas branché le connecteur d'alimentation du lecteur à l'envers par hasard...? une erreur plutôt courante qui grille bien souvent le lecteur. mais tu es des plus chanceux vu que tu as la clef DVD

lorsque tu vois ton lecteur: tu fais N, tu entres le numéro en début de ligne, LITEON E. il te dit erase finished (comme sur la photo quoi), tu coupes l'alimentation du lecteur quelques secondes puis tu la rallume. tu relances dosflash, tu entres le numéro en début de ligne (il ne doit normalement pas te demander Yes ou No) puis tu fais w et tu indiques le nom de ton firmware.

montre la clef DVD que tu as obtenue.

met une photo du PCB pour voir un peu le carnage. quand tu alimentes le lecteur, tu as quelque chose sous dosflash? en fonction de ça je pourrais ptet te filer un coup de main

j'essayerai bien moi aussi

essaye ceci: http://x360.gx-mod.com/modules/news/article.php?storyid=2430

Tuto clair, mais un peu compliqué pour moi, lol, il n'y a pas un moyen de la dumper par nandpro ou gx nand, sans avoir des erreurs a tout bout de champs? je t'ai donné le mieux à faire

un peu suicidaire cette solution. utilise ce tuto, tu assuras mieux ton coup: http://gueux-forum.net/index.php?showtopic=236377

quand je qualifie "hardware", j'entends par là que le montage de programmation est indispensable pour toutes les opérations ce qui n'est pas le cas mais bon si ça te trouble je le retire

Le Jtag est donc toujours actif le temps que la console est allumée? salut non, juste pour le boot ... d'ailleurs pour le prouver quand tu boot avec une console non JTAGGER avec un HDD possédant un loader ==> XEXmenu pour ne cité que lui on le vois apparaitre quelque seconde ! donc je n'y crois pas trop ... comme je le disais déjà plus haut la XBOX360 est bien protégé à la base ... pas de soucis enfin c'est mon avis (les XENON ont toujours été merdique ... et trop gourmande en tension !) ++ la tension n'est pas plus faible sur les nouvelles hein

Nous verrons dans ce tutoriel une solution alternative au flash complet via un module USB ou encore le bon vieux câble LPT. Elle consiste à flasher un loader (Xell) afin d'y lancer un Live CD Linux sur la console qui permettra le dump de la NAND puis la flasher avec un script magique nommé xbrflash. L'avantage de cette méthode est la rapidité (quelques secondes pour dump/flash) mais aussi la gestion des badblocks qui évite la prise de tète sur les NANDs de type 256/512mo. Exemples de durées de dump/flash pour une NAND 16mo: - LPT: ~ 40 minutes - USB: ~ 5 minutes - xbrflash: ~ 10 secondes Comme on peut le constater, la rapidité de flash en 'interne' est nettement plus rapide, de plus la qualité des transferts est parfaite. Cette méthode est ultra recommandé aux personnes avec du matos de pauvre (un malheureux câble LPT) étant donné que vous avez moins de risque d'erreur sur un dump/flash de 2mo plutôt que la NAND intégrale! Pré requis: Montage JTAG en place (celui avec les diodes ou résistances) Un moyen de programmer la NAND (USB ou LPT) Nandpro dans sa dernière version LiveCD Debian Client SSH (Putty sous Windows) WinSCP Le fichier binaire Xell pour votre modèle de carte mère Câble vidéo RGB, YUV ou VGA (tout sauf HDMI) I- Dump des premiers mégaoctets La première chose à faire est de sauvegarder les 2 premiers Mo de la NAND qui seront écrasés lors du flash de Xell. Pour cela: nandpro lpt: -r2 2mo.bin ou nandpro usb: -r2 2mo.bin Faites au minimum 2 dumps et comparez les avec la commande fc par exemple: fc 2mo.bin 2mo_2.bin /b Si vous n'avez pas de différences, vous pouvez continuer. En revanche, si fc vous craches une liste de différences, redumpez jusqu'à obtenir des dumps identiques. II- Récupération du KV Cette opération est un petit gain de temps mais aussi une petite sécurité supplémentaire. NAND 16mo: nandpro lpt: -r16 rawkv.bin 1 1 nandpro lpt: -r16 rawkconfig.bin 3de 2 NAND LargeBloc: nandpro lpt: -r64 rawkv.bin 1 1 III- Flash du Xell Rien de plus simple: nandpro lpt: -w16 xell.bin 0 Si tous ce déroule correctement, vous devez arriver sur ceci en démarrant votre console: Vous êtes sur la bonne voie IV- Dump de la NAND complète Votre Xell permet maintenant de lancer un LiveCD Linux sur la Xbox. Gravez l'image ISO du LiveCD Debian puis insérez là dans le lecteur lors du démarrage. Bienvenue chez les pingouins: La séquence de boot terminé, vous devez vous retrouver face à ça: En fonction de la configuration de votre réseau, l'IP peut différer, ici elle est délivrer par serveur DHCP. Vous devez vous connectez en SSH avec l'adresse IP donnée. Dans l'exemple, l'IP est 192.168.0.211: Login: root Mot de passe: xbox360 Une fois la connexion SSH établie, on peut constater un espace disponible grâce à un point de montage dans la mémoire vive de la console (rootfs) Nous utiliserons cet espace pour récupérer la NAND puis uploader notre image XBReboot, le tout par protocole SCP. Utilisez maintenant la commande qui correspond: NAND 16mo: xbrflash -d 16mb.bin NAND LargeBloc: xbrflash -d 64mb.bin Il faut maintenant récupérer notre dump, nous utiliserons WinSCP: Le dump se trouve sur dans la partie droite de la fenêtre, utilisez la touche F5 ou glisser/déposer le fichier sur votre ordinateur. Vous avez maintenant un dump pour remettre la console d'origine, ou presque: la NAND récupérée contient le Xell flashé au début, il faut donc reconstruire la NAND 100% origine: NAND 16mo: nandpro 16mb.bin: -w16 2mo.bin NAND LargeBloc: nandpro 64mb.bin: -w64 2mo.bin Ceci fait, vous pouvez maintenant extraire le rawkv et le rawconfig du dump 100% stock avec les commandes dites au paragraphe II. Il suffit de remplacer lpt: / usb: par le nom de votre dump complet. V - Flash de XBReboot Vous avez donc votre rawkv (et rawconfig pour les 16mo), il faut maintenant les injecter dans votre image XBReboot à l'aide des commandes suivantes: NAND 16mo: nandpro XBR.bin: -w16 rawkv.bin 1 1 nandpro XBR.bin: -w16 rawconfig.bin 3de 2 NAND LargeBloc: nandpro XBR.bin: -w64 rawkv.bin 1 1 Votre image enfin prête doit être upload vers la Xbox, rebelote on glisse/dépose ou utilise la touche F5 avec WinSCP. Il est maintenant temps de finir le travail avec la commande qui va bien: Toutes les NANDs: xbrflash -w XBR.bin VI - Récupération de la clef CPU (optionnel) Il peut être interessant de récupérer sa clef CPU pour des opérations diverses (décryptage du keyvault afin de mettre n'importe quel lecteur DVD sans spoof par exemple) Très simple: cat /root/FUSES/FUSES.TXT L'addition des fuses 03+05 ou 04+06 donne votre clef CPU (32 caractères hexadécimal) VII - Suppression de la partition mémoire sur NAND 256/512mo (optionnel) Étape non obligatoire mais ultra recommandé pour les consoles disposant de 256/512mo de mémoire interne. Il faut savoir que XBReboot ne gère pas encore bien la partition de sauvegarde, le simple fait de sauvegarder dessus peut corrompre la NAND et la console ne démarrera plus. Il est possible d'y remédier simplement avec le reflash de la NAND mais inutile de prendre des risques si vous n'avez pas de moyen de reprogrammation "hardware" permanent qui vous obligeras à ré-ouvrir la console. NAND LargeBloc: xbrflash -ep Voici à quoi la mémoire ressemblera dans l'onglet mémoire du dashboard: Tant que vous ne la formatez pas, elle ne sera pas utilisable. VIII - Conclusion Vous pouvez maintenant couper via le bouton en façade ou plus proprement avec la commande "halt" Si tout c'est bien passer vous devez arriver sur le dashboard NXE avec un kernel 8955. Cette méthode est la meilleur à mon gout pour ce qui est des NANDs 256/512mo, si vous êtes équipé avec un programmateur USB et face à une NAND de 16mo, vous pouvez directement dump/flasher car le gain de temps n'est pas vraiment interessant Images/rédaction: Gab76

Ce n'est pas MS qui est responsable, ce sont des badblocks dans la mémoire physique. Si c'est un modèle 256-512mo, utilise ceci: nandpro.exe usb: -r64 64mb.bin Tout le reste est inutile, c'est l'espace utile aux sauvegardes qui n'est pas utilisable avec XBR sous peine de corrompre la NAND

ptin mais qu'es ce que tu crois, ca fait 5 ans que la console est sortie et la chose la plus concrète sortie est le hack JTAG depuis environ 7 mois. si c'était si facile tu penses pas que ca serait déjà en piste? et si c'était appliqué tu crois pas que Microsoft aurait arrangé le problème aussitôt?

le but ne serait pas de le maquer mais de spoofer les packet d'autentificaion par des packet fake commence tout de suite

pour commencer c'est pas CODE9999 mais C0DE9999

8400 c'est l'offset, pas le CB. tu dump 2mb et tu ouvres ca avec CD Info de Zouzzz, tu auras ta réponse.

pour les jasper 256/512 je ne peux que te conseiller la méthode sous Linux. en cas de badblocks tu te fais chier pour déplacer manuellement alors que xbrflash s'en occupe. tu dump plusieurs fois 2mb avec cette commande: nandpro.exe usb: -r2 2mb.bin tu les compares, si tu n'as aucune différence, tu flash Xell et tu t'occupes du dump intégral sous Linux (tu réinjecteras les 2mb dumpés ensuite pour avoir une NAND 100% stock) deuxième chose, oublie l'injection du rawconfig, ca crée plus de problème que ça n'en règle.

y a pas plus fiable qu'un dump shakin