Ski-lleR

- Our exploit buffer, which is DMA'ed into the kernel/HV - The code we want to run (XeLL, for example) "The exploit basically allows jumping into any 32-bit address in hypervisor space. To jump into an arbitrary location, we just used a "mtctr, bctr"-register pair in hypervisor, which would redirect execution flow into any 64-bit address. This is important, since we need to clear the upper 32bit (i.e., set the MSB to disable the HRMO), since the code we want to jump to is in unencrypted memory. This code would usually load a second-stage loader, for example XeLL, into memory, and start it. XeLL would then attempt to catch all cpu threads (because just the primary thread is affected by our exploit), and load the user code, for example from DVD." "We chose the Payload to read the Idle Thread Context, the Context Restores and the loader code. The ECC data will carry the HV offset." Donc le payload charge Xell, mais on peux très bien chargé autre chose (pour peu qu'on l'injecte dans la NAND) L'avantage de Xell est qu'il fait office de librairie bas niveau pour la Xbox 360 (en l'état, on a pas de XDK). Le mot de la fin qui fait plaisir : "This hack can also be used to reboot into a Microsoft kernel, in order to keep the possibility of playing games locally. This is not within the scope of this document, and is actually not related to this hack at all. This hack allows you the execution of software - and YOU decide what software that should be. It could be linux, your favourite emulator, or a rebooter." Donc on peux aisément penser à un kernel microsoft modifier qui ne fait plus aucune vérification, ou comme la Xbox, à un dash alternatif type unleashX En complément, je précise que l'exploit permet une communication avec le PC. En gros, par défaut, ça utilise le bootloader, mais si une connexion est détecté, on peux flasher des blocs dans la NAND "By default, the following memory map is used: 00000000..00100000: SMC, KV, CB, CD, CE, CF, CG, backup bootloader 00100000..00140000: main bootloader 00140000..00f7c000: empty space 00f7c000 : smc config block 00ffc000 : exploit buffer" "This allows some kind of recovery if you want to update the in-flash bootloader." C'est génial je trouve, ça permet de faire plein de test en flashant juste le bootloader, et on s'en moque s'y on flash un truc mauvais, le bootloader de sauvegarde est là. Dans le genre motivation pour les programmeurs Voila voila, je reprend directement les bouts de texte, même s'il ne sont pas 100% compréhensible, ça résume bien Edit : Désolé pour le double post Edit 2 (avant d'aller au taf ) : Pour zouzzz : Le "! please flash outpu/image_*.ecc, and setup your JTAG device to do the DMA read from 00ffc000", alors les différente partie du flash je ne sais pas encore comment on les flash au bonne endroit. Pour le "setup your JTAG...", et bien, pas d'inquiétude, on a hacké le SMC pour faire le fameux DMA read (d'ou les 3 résistances). " "The SMC can read the NAND, because it requires access to a special NAND page" "the SMC can access the NAND controller all the time, even when the kernel is running" "by programming the DMA target address via JTAG > En définissant l'adresse DMA ciblé, and launching the attack via SMC -> Lancement du code payload The attack can be launched as soon as the kernel is running, and quite early, it does query the SMC for the RTC. We abuse this call > La modification dans le fichier SMC, on remplace l'instruction "query rtc" par l'attaque to start the attack instead, which is a perfect point for us." Oufff, en espérant réussir à orienter les plus téméraires

Une grosse correction de ma part car il y avais un problème avec le secret_1BL Si elle n'est pas écrite comme la clé CPU, ça ne fonctionne pas. secret_1BL = "\xDD\x88\xAD\x0C\x9E\xD6\x69\xE7\xB5\x67\x94\xFB\x68\x56\x3E\xFA" J'ai extrais la NAND de xbins, et elle contient bien le bon CB/CD/CE Par contre le SMC apparait comme étant l'original décrypté sans hack pour le DMA Read

C'est plus compliquer que ça kogami

Dans la nand, on a modifié le SMC pour qu'il fasse un dma read. C'est une instruction qui pointe sur Xell, donc le loader de linux sera lancé. Sachant que perso j'ai compilé le Xell par défaut, il ne se passera rien, on verra juste que Xell s'exécute. Mais faut pas aller trop vite, il m'a fallu un certain temps pour réunir toutes les infos, et les comprendre Après il faut adapter Xell pour faire ce qu'on veut

Maintenant je suis bien sur que l'extraction de la nand qu'on trouve online ne fonctionne pas, car de l'offset 0x270 à 0x390 dans le CB, ça ne doit être que des 00, hors celui téléchargé est rempli avec des données print " * checking if all files decrypted properly...", assert allzero(CB[0x270:0x390]) assert allzero(CD[0x20:0x230]) assert allzero(CE[0x20:0x28]) assert allzero(CF[0x30:0x230]) assert allzero(CG[-0x20:-0x18]) assert allzero(SMC[-4:]) print "ok" On à droit à un jolie assertionError sur celui de xbins Edit : Pour zouzzz, au départ il y a E5 30 12 xx xx 22, donc au final 75 F5 07 22 22 22 ou alors 75 F5 07 22 90 90 Normalement ça n'a pas d'importance, dans le mesure ou de toute façon le 22 est un ret, donc si ça fait le premier les 2 autres ne s'exécuteront jamais, ce qui revient à les noppé (90). Techniquement c'est plus sur de les noppé, comme ça si le code tombe sur l'adresse du deuxième nop, ça continuera les instructions qui se situe après

zouzzz > Tu essais d'extraire celui de xbins ? car si c'est ça cherche pas, on peut pas. Je dit ça car j'ai essayé déjà, et j'ai eu la même erreur Au fait encore une fois merci TheTool, tes CB/CD sont valide, contrairement à ceux qu'on extrait de celui de xbins

Direction le fichier build.py : assert smc_len == 0x3000, "never saw an SMC != 0x3000 bytes" Donc 12288 octets Par contre celui de xbins il me répète encore et toujours qu'il est valide. L'impossibilité d'en extraire les données viendrait du fait que la NAND à déjà été préparé, et que son extraction foire. Donc impossible d'en extraire CB/CD correctement, ce qui est très useless pour toute personne voulant préparé sa propre NAND (comme moi) Edit : Merci à TheTool pour les fichiers. Et n'hésiter pas si la crosscompil reste obscure, je vous fait une explication

Ah ben cool que vous ayez réussi Par contre je me pose des questions sur le CB/CD de xbins, car ils ne passe pas le test du build.py : assert allzero(CB[0x270:0x390]) assert allzero(CD[0x20:0x230]) Avec vos nand décrypté avec la CPUKey, vos CB/CD passent le test ? Si possibilité, j'aimerais bien récupérer vos CB/CD/SMC pour comparer avec celui de xbins (mp me si vous avez le temps). ---------------------------------------------------------- 5) Pour obtenir xell-1c.bin et xell-backup.bin : Il suffit de compiler Xell, vous obtener xell-1f.bin Pour celà, pas de mystère, crosstool pour obtenir powerpc64-gcc Avec un petit lien symbolique s'appelant xenon-gcc pour pas que le makefile vous embête Celui ci sera utilise en lieu et place de xell-1c.bin/xell-backup.bin (en fait, le backup ne sers qu'au cas ou le premier serait endommagé dans la NAND, pour X raison, ils ont tout prévu !!!). De plus, on peut apparemment ne flasher qu'une partie de la NAND, donc dans le cas d'une mise à jour c'est très utile, vous flasher toujours le même Xell, si un jour ça foire, on bascule sur la copie qui se situe autre part dans la NAND

Essaye ca : D'abord créer un dossier output à coté du fichier build.py Ouvre le fichier build.py, et cherche "def decrypt_CD(CD, CB, cpukey = None):" Tu le remplace par : "def decrypt_CD(CD, CB, cpukey = "\x10\xxx\xxx\xxx...\xb0"):" En gros tu met ta clé entre les "", et tu met \x tous les 2 caractères Ensuite pour ces lignes, tu enlève le # devant : # assert cpukey or build(CD) < 1920 # if build(CD) >= 1920: # key = hmac.new(cpukey, key, sha).digest()[0:0x10] Mais tu ne supprime pas les #, tu les sélectionnes, et tu met un espace à la place assert cpukey or build(CD) < 1920 if build(CD) >= 1920: key = hmac.new(cpukey, key, sha).digest()[0:0x10] Enfin tu tape build.py nand.bin (ou nand.bin est ta nand associé avec la clé). Normalement dans le dossier output tu aura CB, CD, CE, SMC (dans un premier temps, si déjà t'arrive à avoir sa je te dirais la suite) Ah oui, as tu mis secret_1BL = "DD88AD0C9ED669E7B56794FB68563EFA" (ne pas oublier les "")

Il dit i've heard, il dit pas j'ai testé J'ai vérifié, le SMC du fichier de xbins n'est pas modifié, et il ne contient pas le CF/CG 80Y> donne plus de détails, tu utilise quel nand ? et c'est quoi l'erreur que te sors le script python

Je pense que oui, après c'est possible que le script python extrait d'une façon différente, donc au final ça serait pas bon. Puis de toute façon il faut l'utiliser pour créer la nand avec l'exploit, donc autant extraire CB/CD avec lui

Alors déjà pour flashé, il n'y aura pas forcément besoin d'une puce (bien qu'une double nand ne soit pas un luxe). " 52 - A possibility to reprogram the NAND flash. You can use an external 53 programmer, a SPI programmer (which will be released soon), or some 54 dedicated hardware. 55 " "JTAG is NOT used for flashing. JTAG is part of the exploit process." "Nand flashing is a different process and tmbinc mentioned a new tool for that (unreleased)" Comme on peux le voir, le JTAG (smc) fait partie de l'exploit, mais ne sers en aucun cas à flasher. "What you might need in the end is an LPT cable to reprogram your flash, pending the release of the flash programmer." Le câble LPT sera utilisé pour reprogrammer la NAND "No, you don't need a jtag cable, as the SMC can do the jtag work fine. " Sa c'est ce qu'il m'a fallu le plus de temps à comprendre Une fois le SMC (qui se trouve dans la NAND) extrait, il faut le modifier pour qu'il se rendent dans une fonction spécifique (pour ça, juste une petit coup d'hexadécimal pour remplacer une instruction). En gros, il lance l'exploit avec le DMA Read. En l'état, on doit pouvoir atteindre Xell --------------------------------------------------------- TheTool > Je l'ai déjà dit, la nand qu'on trouve online ne contient que les sections CB/CD, mais c'est suffisant. Maintenant un petit tutoriel 1) Pour obtenir image_backup.bin : Vous dumper votre nand actuelle. 2) Pour obtenir C{B,D}.1920 et le SMC (qui au final nous donnera smc_hacked.bin): Il faut les extraire en tapant : python build_image.py xenon_nand.bin (si c'est la NAND téléchargé, la le script plante, c'est normal, le reste c'est du dummy) 2 bis) Pour obtenir le SMC (si vous avez la NAND téléchargé): Modifier le build.py, en commentant ces lignes : open("output/CF", "wb").write(CF) open("output/CG", "wb").write(CG) Retaper> python build_image.py xenon_nand.bin 4) Pour obtenir 4532_upd.bin : Utiliser wxPirs pour extraire le fichier xboxupd.bin de l'update 4532 5) Pour obtenir xell-1c.bin et xell-backup.bin : Il faut que je regarde, le compiler c'est pas dur, mais j'ai pas trop compris le "xell-1c.bin and xell-backup.bin are XeLLs linked to 0x01c00000" 6) Pour obtenir le smc_hacked.bin : Ouvrer le fichier SMC, et chercher la chaîne hexadécimal suivante > E5 30 12 xx xx 22 (les XX étant sûrement différent suivant les versions de smc) Remplacer la par : 75 F5 07 22 (la aussi c'est une chaîne plus courte, mais je pense qu'on peut mettre 75 F5 07 22 Ensuite, il ne reste plus qu'à taper > python build_image.py image_backup.bin CB.1920 CD.1920 4532_upd.bin xell-backup.bin xell-1c.bin smc_hacked.bin Voila voila, je vais essayer de compléter ce qu'il manque ce matin

J'ai répondu ici à propos de la nand "universelle" et le fait que la clé CPU ne soit pas nécessaire (ce qui explique le pourquoi qu'une NAND par type de console soit possible) : http://gueux-forum.net/index.php?showtopic...p;#entry1582074 Demain matin je m'y met à fond, j'essaierai de détaillé dans une langue compréhensible pour le commun des mortels.

J'ai pas réussi à extraire le CF de ce fameux fichier tout prêt avec build.py, et c'est le smc d'origine, donc la viabilité de cette nand toute prête...

Après avoir extrait le smc, afin de voir si j'étais sur le bon chemin (http://www.xboxhacker.net/index.php?topic=12208.0), j'ai bien le E5 30 12 xx xx (E5 30 12 23 8E). Donc je le remplace par 75 f5 07 22 comme indiqué " 200 Fortunately, the NAND controller allows doing DMA reads where the payload 201 data is split from the "ECC"-data. Each page has 512 bytes of payload, and 202 16 bytes of ECC data. Thus, a single DMA read can be used to load all 203 required memory addresses. We chose the Payload to read the Idle Thread 204 Context, the Context Restores and the loader code. The ECC data will carry 205 the HV offset. " En théorie, on obtiens le fameux smc_hacked.bin, mais je ne sais pas si ce seul code suffit, sur le topic c'est marqué "That's it.", mais dans le titre y'a "Part 1". Si certains pouvais faire la concordance avec le hack.txt, histoire de démystifier tout ça Bon je vais bosser, faut que je relise le hack.txt demain matin, car c'est très technique et j'ai le cerveau qui chauffe un peu trop

Je ne sais pas si ça a été dit (si c'est le cas je m'en excuse d'avance). Pour ceux qui aurait mal compris, c'est le SMC qui fait office de JTAG. Du moment que les 3 résistances sont installé, le cable n'a besoin d'aucune spécificité, si ce n'est être un cable LTP Manque juste les points ou le connecté

Pour zouzzz (à propos de la CPUKey qui n'est pas nécessaire) > D'ailleurs c'est bien commenté dans imgbuild : 116 def decrypt_CD(CD, CB, cpukey = None): 117 # enable this code if you want to extract CD from a flash image and you know the cup key. 118 # disable this when this is a zero-paired image. 119 # assert cpukey or build(CD) < 1920 120 secret = CB[0x10:0x20] 121 key = hmac.new(secret, CD[0x10:0x20], sha).digest()[0:0x10] 122 # if build(CD) >= 1920: 123 # key = hmac.new(cpukey, key, sha).digest()[0:0x10] 124 CD = CD[0:0x10] + key + RC4.new(key).decrypt(CD[0x20:]) 125 return CD

Il y a 2 jours > http://gueux-forum.net/index.php?s=&sh...t&p=1579976 Faut lire le sujet avant de post

Tu laisses prétendre que cette avancée n'en est pas une, excuses moi mais je trouve ça déplacé. C'est une énorme avancée. Honnetement en regardant ce que tu écris, ça n'est pas du tout la même chose que j'éclaircis ensuite. Alors soit tu parles sans savoir, soit tu n'expliques pas bien ce que tu penses. En tout cas les faits sont là EDIT : Ce n'est pas une agression, je préfère le préciser :-) Non on échange c'est tout t'inquiète Pour moi ça n'est pas une avancé, dans la mesure ou tant qu'il n'y aura pas les programmeurs derrière, on en restera au même point. Et à l'heure actuelle, si on code, c'est en assembleur (car pas de sdk), et l'asm sur ppc, bah ... c'est pas de la tarte ! Je suis en contact avec la team free60, c'est d'ailleurs pour ça que j'ai parlé des 3 résistances 330 ohm quand la faille a été annoncé, car ils m'ont proposé de me fournir le nécessaire. Seulement je n'ai pas de cygnos, mais je vais en trouvé une rapidemment, kit à l'a prendre à l'étranger, histoire que nous fassions nos propre recherche sur gueux. Il y a pas mal de gros bidouilleur ici, moi je suis programmeur depuis 12 ans (C/C++/ASM), donc y'a de quoi faire

Voila pour toi : Tmbinc on XS> you just have to add 3 resistors from the "SMC LED"-port to the GPU JTAG port Les résistances c'est du 330 ohm (je l'ai posté hier déjà sur gueux)

Que je me remette au gout du jour ? Avant que le boot de Xell avec KK voit le jour, j'utilisais déjà le code readcd de Tmbinc, donc bon. Ca ne marche pas car sa touche au CB fuses, mais c'est amener à fonctionner. Et pour 1, tu ne m'apprend rien, regarde l'autre sujet sur la faille, j'explique que ça va avancer plus vite. Mais en attendant, ils ont juste simplifié un exploit et l'ont rendu accessible à plus de personne. Et perso la cygnos v2 je l'attend depuis son annonce, car le système XD restant un peu "bourrin" pour moi. J'attend juste qu'un site français la propose

Ca fait juste 2 ans qu'on peux booter linux sur la 360 Ils ont réussi sans king kong, mais ça ne change rien au avancé, on en est toujours au même point, mais ça les gens ont du mal à la comprendre j'ai l'impression Quentin : Faux, la cygnos permet d'avoir 2 nand, en l'occurrence la deuxième nand utilisé est détourné pour booter sur Xell, mais ça marche parfaitement sans cygnos, le gars utilise la cygnos pour garder sa nand principal intacte est ainsi profiter du live sans avoir à reflasher sans cesse

Pour simplifier, la faille utiliser avec king kong pourra être utilisé sans celui ci (donc un gain de temps énorme pour ceux qui bossent aux hack), mais tout reste à faire. La seconde étape sera de finaliser le projet de redémarrer la console avec un kernel microsft non signé, et seulement là on pourra voir apparaître du homebrew comme sur xbox 1 (custom dash). En somme, les développeurs auront beaucoup moins de contrainte, et ça avancera plus vite. Mais il faut comprendre que quand ils vont release leur travail, le commun des mortels ne pourra encore rien faire.

Quelques informations en plus, maigre mais c'est déjà ça. Tout ce qu'ils ont pu me dire, c'est qu'il est préférable d'avoir une Xenon (mais il y a un support expérimental des autres cartes mères, c'est juste qu'ils ne veulent pas aller plus vite que la musique), un cable vga (vu que xell ne se lance qu'en 640x480, pour le moment), et 3 résistance 330 ohm. Apparemment il n'y aurait pas a touché à une éventuelle infectus/cygnos déjà installé (par contre, nécessaire de flasher la console, comme indiqué dans la news). Le JTAG ne serait pas nécessaire, tout ce qu'il faut c'est un moyen de reprogrammer la NAND. Par exemple l'Infectus/Cygnos, ou un projet qui va être annoncé, utilisant le mode spécial du southbridge (les détails seront donné en temps voulu) avec simplement le port imprimante des PC. Pas de date, mais il devrait me fournir le nécessaire afin de mettre en pratique. Sachant qu'ils ont insisté sur le fait que sa se comptait vraiment en heures/jours. Si j'ai d'autre info je ferais suivre.

Pour info, xbmc tourne déjà sous linux, c'est juste le manque de pilote qui bloque. Et non le port n'est pas long. Le plus dur reste les pilotes, ATI font déjà bien les difficiles sur les spécifications matériel des cartes graphiques PC, alors en faire un pour le GPU de la 360 ... faudra du temps. A l'heure actuelle, les avancés permettent au maximum un support partiel de X (aucune accélération 2D/3D), support clavier et souris. Y'a aussi le support du réseau, le son je me rappel plus.