deaphroat

How to dump the bootldr

Rogero 4.21 v4 leak Tortuga Cove has confirmed with Rogero there is no version that is brick proof yet, he is very close...If you install this "leak" and brick then it is your own fault. Trolls will be very busy right now...... We will announce here when it is released and safe.... Tortuga Cove Administrator NE PAS INSTALLER UN CUSTOM QUI NE VIENT PAS DU SITE DE TORTUGA, SITE OFF DE ROGERO

He non parce que ca va tombé dans le commerce et il y a gx annonce pour ca... par contre je parierai plus sur le fait que ta puce n'est pas cramé et que tu fait une fausse manip... elle est encore soudé tu arrive a lire?

PS3 3.70 Appldr Keys Released Following up on recently released lv0 keys, DEFAULTDNB releases firmware 3.70 appldr keys. type = SELF revision = 0016 version = 0003007000000000 self_type = APP erk = A106692224F1E91E1C4EBAD4A25FBFF66B4B13E88D878E 8CD072F23CD1C5BF7C riv = 62773C70BD749269C0AFD1F12E73909E pub = 566635D3E1DCEC47243AAD1628AE6B2CEB33463FC155E4 635846CE33899C5E353DDFA47FEF5694AF priv = ctype = 30 Donc pas beaucoup de news ce sont des clés inférieur au Lv0, mais comme l'autre jour? Tous les jeux 3.70 vont sortir sur les anciens custom?

dump avant et je te dit 90% de réussite

3 methode pour le debrick...sans hardware flasher...l’inconvénient...c'est que si entre un brick et une tentative, on dump ce qu'on a dans la nor avec un peu de chance si elle est pas trop touché on peut patché ce dump et tenté un downgrade, la si vous tenté ca, je pense que ca efface encore un peu plus la nor donc...mais bon http://consolecrunch.com/guide-three-metho...4-21-cfw-brick/

ok merci pour l'info pas de bol enfin c'est comme ca au debut d'un nouveau produit ou revision... Ben repasse quand tu la reçu mais bon normalement tous devrait roulé maintenant...

C'est les nouvelle boite anti vol de microsoft?

green lit la page précédente

merci mais c'est dit depuis hier... tien tu peux te faire une petite lecture http://gueux-forum.net/index.php?s=&sh...t&p=2054413 http://gueux-forum.net/index.php?s=&sh...t&p=2054556

Bon j’arrête la l'essentiel est la.. Pour ceux en 3.55 c'est la belle vie. Pour ceux en 3.56+, un exploit doit voir le jour.... Il se peut qu'il arrive plus vite maintenant mais rien n'est sur...

Un peu de lecture ? http://wololo.net/2012/10/25/clarifying-th...s3-development/ La première étape du bootLoader est dans la ROM et c'est une clé unique à chaque console. La seconde étape du boot (bootldr) est cryptée avec la première clé, mais elle est irrévocable et commune à toutes les consoles. Ce second stage vérifie le Lv0 et Sony signe le Lv0 en utilisant le même mauvais processus qu'il utilise pour le reste, (ce qui avait fait fuir leur clé privée au début). Cela signifie que la clé privée lv0 était condamnée dès le début, depuis le Chaos Communication Congress il y a deux ans. Cependant, le lv0 est également crypté, y compris son bloc de signature, nous avons besoin de cette clé de décryptage (qui fait partie de bootldr) avant que nous puissions déchiffrer la signature et appliquer l'algorithme pour déduire la clé privée. Nous avons fait cela pour plusieurs étapes ultérieures en utilisant un exploit. Geohot l'a fait pour le metldr (le "seconde root" du processus bizarre du démarrage de la PS3) alors on l'a utilisé (nous l'avons reproduit, mais modifié), . À l'époque, ce fut assez pour casser la sécurité de tous les firmwares publiés, puisque tout ce qui comptait était enraciné dans le metldr (qui est le frère du bootldr et est également décrypté par la clé per-console). Toutefois, Sony a fait un dernier effort après ce hack et à enveloppé tout ce qui suit le metldr dans le lv0, en utilisant leur dernière sécurité (bootldr et lv0) pour tenter de re-sécuriser leur plate-forme. Le Bootldr souffre du même exploit que le metldr donc il été également condamné. Cependant, en raison que le bootldr est conçu pour fonctionner à froid, il ne peut pas être chargé dans un SPU isolé comme le metldr le peut (ce que nous avions par l'intermédiaire de l'exploit lv2), donc l'exploit est difficile à réaliser parce que vous n'avez pas de contrôle sur le reste du logiciel. Pour l'exploit que nous connaissions, il aurait exigé plusieurs redémarrages de la PS3 et une sorte d'émulateur du Flash pour mettre en place l'exploit avec plus ou moins de paramètres à chaque démarrage et il aurait sans doute fallu plusieurs heures ou jours d'automatisation pour tenter de toucher la bonne combinaison (l'exploit pourrait fonctionner en exécutant des données aléatoires et en espérant qu'à un moment, il passe à l'intérieur d'un segment que l'on contrôle, les probabilités sont assez élevées pour que cela fonctionne dans un délai raisonnable). Mais personne n'a jamais pris la peine après tous les procès de Sony. On peut supposer que, 18 mois plus tard, un autre groupe a enfin compris cela et a utilisé notre exploit et de l'aide matérielle, ou quelques autres trucs équivalents pour dumper le bootldr. Une fois la clé de décryptage lv0 connut, la clé de signature privée peut être calculée (merci l'échec épique de Sony). L'effet de cela est essentiellement le même que lors de la clé du metldr : tous les firmwares actuels et futurs peuvent être déchiffrés, sauf que Sony n'a plus le truc du lv0 dans sa manche. Ce qui veut dire qu'il n'y a aucun moyen pour Sony de refaire ce genre d'enveloppement, parce les anciennes PS3 doivent être en mesure d'utiliser tous les firmwares à venir (en supposant que Sony ne décide pas simplement de toutes les brické ...) et ces vieilles PS3 n'ont plus de sécurités restante inconnus. Cela signifie que tous les firmwares futurs et tous les jeux sont déchiffrables et cette fois ils ne peuvent pas vraiment faire quelque chose. Par extension, cela signifie que, compte tenu de l'habitude du chat et de la souris (analyse et patch du firmware), chaque utilisateur actuel de firmware hacké ou vulnérable devrait être en mesure de maintenir cet état pour toutes les futures mises à jour, comme tous les firmwares futurs peuvent être déchiffrés et resignés pour les vieilles Ps3. Du côté des l'homebrews, cela signifie qu'il devrait être possible d'avoir des hombrew/linux et les jeux en même temps. Du côté de la piraterie, cela signifie que tous les futurs jeux peuvent être piratés. Notez que cela ne signifie pas que ces choses seront faciles (Sony peut masquer des choses pour compliquer), mais du point de vue de la sécurité fondamentale, Sony n'a plus de béquille de sécurité maintenant. Cela ne signifie pas que les firmwares actuels sont exploitables. Les mises à jour sont encore signées, il vous faudra un exploit dans votre firmware actuel afin de downgrader. En outre, les nouvelles PS3 ont sans doute fixé cela (probablement en utilisant un bootldr / metldrs plus récent et une meilleure signature). Ce sont en effet les clés bootldr (j'ai été en mesure de déchiffrer un lv0 avec eux). Cela peut-il être utilisé pour signer des binaires afin de lancer des homebrews sur Ps3 Retail ? (comme la fuite des clés PSP) Non, les clés sont utilisées à deux fins: la "chain of trust" et la "chain of secrecy". Les clés actuels compromettent totalement la "chain of secrecy" de la PS3. Cependant, la "chain of trust" peut être rétablie à tout moment tant que la ligne peut être mise à jour. La "chain of trust" est enracinée dans le matériel ce qui est presque impossible à modifier (la ROM CPU’s et les clés eFuse). La chaîne suivante a été compromise (le bootldr) et celle-ci ne peut pas être mise à jour, car elle est spécifique à chaque console, de sorte que la "chain of trust" a maintenant un maillon faible permanent. Toutefois, la troisième liaison, le lv0, peut être mise à jour, car il est situé dans le flash et signée au moyen de la clé publique. Cela permet à Sony de sécuriser toute la chaîne à partir de là. Sauf si vous trouvez une vulnérabilité dedans, vous ne serez pas en mesure de les attaquer directement (par exemple les homebrews, sont vérifiés beaucoup plus bas dans la chaîne). Le seul moyen garanti pour briser la chaîne est d'attaquer directement le maillon faible, ce qui signifie l'aide d'un flasher hardware pour remplacer le Lv0. Une fois cela fait, la chaine entière s'effondre (enfin, vous avez encore besoin de faire quelques travaux sur les échelons inférieurs pour patcher les sécurités, mais c'est facile). Les vieilles PS3 sont maintenant dans le même bateau que les vieilles Wii, et en fait, nous pouvons établir une comparaison directe du processus de démarrage. Sur une vieille Wii, le boot0 (la ROM puce) charge en toute sécurité le boot1 depuis le Flash, qui est vérifié contre un hachage eFuse, et le boot1 charges le boot2 mais ne vérifie pas signature. Sur une vieille PS3, la ROM Cell boot en toute sécurité le bootldr depuis le flash, il est déchiffré et vérifié à l'aide d'une clé eFuse, puis le bootldr charge le lv0 mais vérifie sa signature avec une clé codée en dur dont la contre partie est maintenant connu. Dans les deux cas, le système peut être compromis si vous pouvez écrire dans le Flash, ou si vous pouvez déjà lancer du code non signé. Toutefois, dans les deux cas, vous devez utiliser une sorte d'exploit de haut niveau pour pénétrer dans le firmware d'abord, surtout si vous avez mis à jour le firmware. Il se trouve que c'est trivial sur la Wii, car il n'existe pas de système de patch pour les jeux et Nintendo semble avoir cessé de s'en préoccuper, tout cela est beaucoup plus difficile sur la PS3 parce que le logiciel système a plus de couches de sécurité et il y a un système de patch des jeux. Pour décomposer en des mots simples et faciles à comprendre Q : Qu'est-ce qui a été exactement récupéré? R : Les clés utilisées par le bootldr pour déchiffrer / vérifier le lv0 et en inversant le processus, les clés privées utilisées par Sony pour signer le lv0. Si nous consultons notre très pratique diagramme "3.60+ chain of trust", nous pouvons voir que le bootldr est à la racine de la chaîne, avec le lv0 comme premier module chargé. Q : Alors, que pouvons-nous faire avec les clés de signature lv0 ? R : En bref, nous pouvons les utiliser pour déchiffrer le lv0, le modifier pour patcher tous ses contrôles de sécurité, et le resigné avec une clé légitime que le bootldr acceptera. Avec la "chain of trust" brisée et le Lv0 qui ne check plus la sécurité des modules qu'elle contrôle, nous pouvons alors commencer à modifier les lv1ldr, lv2ldr, appldr, isoldr, etc et ajouter des fonctionnalités au CFW. Q : Sony peut-il fixer ça comme ils l'ont fait pour l'exploit 3,55 ? R: Non. Avec le 3,55, les clés metldr utilisées pour vérifier ses modules dépendants ont été récupérées. Donc Sony a simplement cessé d'utiliser le metldr et a commencé à utiliser le bootldr (qui était encore plus sûr). Sony ne possède pas de modules plus sûrs. La seule chose qu'il lui reste, ce sont les modules qui utilisent la clé "per-console" qui sont inutiles pour le démarrage du firmware (qui doit être déchiffrable par toutes les PS3)

l'avantage c'est qu'il n'y a pas que Rogero qui brick MAJ en mousse comme d'hab blog Fr blog US

le rgh ne fonctionne pas sur ton dashboard... donc oui pour le 1175 il te faut le rgh mais tant qu'il ne marche pas en 15xxx tu peux pas...

4.03.03 normalement... ****************** Dump Nor par multiman : - Installer et lancer "multiMAN ver 04.04.03 BASE (20120722).pkg" (et non "multiMAN 04.04.03 BASE DEX") - Aller dans le gestionnaire de fichiers (L1 ou R1), cliquer sur "File Manager/mmOS", puis double cliquer sur l’icône "multiMAN" - Dans la nouvelle fenêtre, sur n'importe quel fichier (fichiers sur clé usb, dans le disque dur...), faire "Carré", "Open in HEX Viewer", puis [sELECT], puis [sTART], répondre non à DUMP LV2, répondre non à DUMP LV1, puis oui à "DUMP FLASH" - Sur la clé Usb, un fichier caché et système (ne vous inquiétez pas si vous le voyer pas, il suffit d'afficher les dossier caché ET dossier système) du type 20120725-193611-FLASH-NOR-FW3.55.NORBIN apparait Dump Nand par jaicrab : Logiciel utilisé : - "Preloader Advance" de Jaicrab - "FactoryServiceMode.gnpdrm.pkg" pour CEX ou "FactoryServiceMode.pkg" pour DEX I ) Dump de la console Préparé vos téléchargement et votre clé usb. Elle doit contenir - Le Pkg adéquat pour le mode Factory - Le "Lv2diag.self" du "Preloader Advance" - Le "advance.cfg" du "Preloader Advance" configuré comme suit : ######################################################## #JaiCraB 2011. Preloader Advance 3.1 Config File # #jaicrab@gmail.com # ######################################################## ######################################################## #Backup "rflash" to "/dev_usb000/Backuprflash.bin" # 0 = Disabled # 1 = 16MB Nor models and first 16MB from NAND models. # 2 = 16MB Nor models and 256MB from NAND models.;2 ######################################################## #Restore "rflash" Fichero origen "/dev_usb000/rflash.bin" # 0 = Disabled # 1 = Delete and restore all sectors. # 2 = Check sectors and only delete/write the differents sectors.(SLOW);0 ######################################################## #Backup "/dev_flash" to "/dev_usb000/Backupflash1.bin" #0 = Disabled #1 = Enabled;1 ######################################################## #Backup "/dev_flash2" to "/dev_usb000/Backupflash2.bin" # 0 = Disabled # 1 = Enabled;1 ######################################################## #Backup "/dev_flash3" to "/dev_usb000/Backupflash3.bin" # 0 = Disabled # 1 = Enabled;1 ######################################################## #Restore "/dev_flash" from "/dev_usb000/flash1.bin" # 0 = Disabled # 1 = Enabled;0 ######################################################## #Restore "/dev_flash2" from "/dev_usb000/flash2.bin" # 0 = Disabled # 1 = Enabled;0 ######################################################## #Restore "/dev_flash3" from "/dev_usb000/flash3.bin" # 0 = Disabled # 1 = Enabled;0 ######################################################## #Dump Lv2(need lv2 peek) to "/dev_usb000/DumpLv2.bin" #Only if exist SC 6 (PEEK) # 0 = Disabled # 1 = Enabled;1 ######################################################## #Dump Lv1(need lv1 peek) to "/dev_usb000/DumpLv1.bin" #Only if exist SC 8 (Lv1_Peek) # 0 = Disabled # 1 = Enabled;1 ######################################################## #No Function;0 ######################################################## #Service MODE function # 0 = Nothing # 1 = Exit Service mode # 2 = Entering in Service mode. (need lv1 patch or JFW MA);1 ######################################################## # 0=Shutdown # 1=Reset;0 Ce qui pour expliquer brièvement les fonctions : - Enregistrera un backup de votre Nand (complète) ou Nor sous /dev_usb000/Backuprflash.bin - Enregistrera un backup de "/dev_flash" dans "/dev_usb000/Backupflash1.bin" - Enregistrera un backup de "/dev_flash2" dans "/dev_usb000/Backupflash2.bin" - Enregistrera un backup de "/dev_flash3" dans "/dev_usb000/Backupflash3.bin" - Enregistrera un backup du Lv2 dans "/dev_usb000/DumpLv2.bin" (custom firmware avec syscall 6 requit) - Enregistrera un backup du Lv1 dans "/dev_usb000/DumpLv1.bin" (custom firmware avec syscall 8 requit) - Quittera le mode factory - Éteindra la console Ce sera seulement une phase de dump et non d'écriture. - Branché votre clé sur le port le le plus prés du lecteur Blu-ray - Installer et lancer Pkg pour le mode factory Vous devriez entendre un seul bip et la console va redémarrer en mode Factory, si ce n'est pas le cas et que vous entendez 3 bips, le passage en Factory Mode a échoué, renouvellez l'opération (relancez le pkg) jusqu'à réussite. -Si votre clé USB dispose d'une led témoin, elle s'activera, preuve du dump et de la copie des fichiers sur celle-ci, attendre l'extinction de la console - Débranché votre clé USB, vous pouvez vérifier que votre console se rallume Sur l'ordinateur, branché votre clé, pour que les fichiers apparaissent, décoché masqué les fichiers système dans les options fichiers. Ce ci est pour sécurisé sa console en cas de brik...

pour l’instant il faut une console en 3.55 et faut attendre quelque jour voir si le psn va revenir sur custom 3.55 V7 ou le nouveau rogero qui viendra...du a la mise a jour 4.30 qui a du changé la passephrase...

Bon ben j'ai testé pour vous Après une aprem de downgrade et une évaluations des risques je dirais : - En partant d'une Dex - Downgrade sous rogero sans check lv1 (V7) - Mise du qa flag - Installation du 3.55 off par le recovery - Installation du 4.21 par le recovery Donc backupé sa ps3 avant et faire un reset syscon... Ceux partant de kmeaw normalement pas de risque vue que vous êtes sur un custom aussi dangereux que le 4.21...ceux venant de 3.15 pas de reset non plus... Mais c'est pas une science exacte... Voila donc pas plus d'actu ma console est une Slim cech 2004B downgradé de 4.11 puis passé en Dex

réponse de Kakaroto Techniquement, c'est "lv0ldr keys" pas "bootldr keys", depuis que le bootldr est du code PPC dans la Rom qui charge le lv0ldr dans le SPU. Cela devrait être "isoldr keys" pas "metldr keys" et "lv0 keys" au lieu de "lv0ldr keys". Bon c'est quand qu'il arrête avec leur histoire de noms et qu'il nous dise si oui ou non se sont les clés pour installer ce qu'on veut sur une console en 3.60

oui plus qu'a acheté un E3 ou une progskeet

Marcan Le vrai nom des clés n'est pas "lv0 keys" mais "bootldr keys"

j'ai oublier une phrase faut que le logiciel te dise 3.55 sinon c'est mort...

Minimum Version Checker pour connaitre le firmware minimal de sa console (celui-ci doit être de 3.55 minimum) + donwgrade comme avant (puce, hash syscon,...) Ou patience comme avant

1er log pour patché le Lv2 avec les dires de kakaroto plus haut Foo release un utilitaire appelé PS3 4.21 LV2 Patcher. Celui-ci vous autorise à lancer des homebrews en désactivant les valeurs venant de appldr dans le LV2. Fonctionne sur un Lv2 décrypté. LV2 Patcher.exe

Tu prends le dernier ici : [ Maj 4.08.00 ] MultiMAN 4.07.00 Cex and Dex et tu peux prendre memdump aussi si ca marche pas tu prend celui du pack de deank [tuto] Cex To Dex Et pour la procédure ben lit mon tuto cex to dex la première partie tu apprendra a différencier si ta une Nand ou une Nor et ca te dira quoi faire....

c'est valable pour toi qui est en 3.55 mais si le hack se démocratisent à toutes les consoles c'est mieux