bebou007

encore dans votre cas c'est debrickable avec un dongle pour passer en fsm moi mon dump a étais modifier pas un virus ou alors en le copiant faut chercher sur google "fixing dex to cex" il explique comment faire mais en anglais jo touriste tu avais dumper ta nand avec quoi? pourrais tu me l'uploader stp? merci

on peut toujours decrypter lv0 du 4.31 lol

c'est pas reelement une clef cpu comme sur xbox mais c'est une clef qui et propre a la ps3 après je sais pas si elle et utiliser pour le bleuray mais elle est utilieser pour decrypter le bootldr et metldr

ben met dump on etait faire sans flasheur depuis preloader est il étais tous identique donc je me suis pas poser la question de les verifier en md5 ce que j'aurais du faire

bon ben j'ai compris pourquoi j'ai un brick sur met 3 dump 1 est différent ils étaient tous identique au passage en dex donc soit un virus soit une erreur au moment de la copie ou autre j'ai encore 2 dump qui sont identique et qui corresponde bien une fois convertie en dex au rflash que je me suis servie pour la conversion donc j'ai plus qu'a attendre que je puisse flasher ma console normalement si j'ai un dump qui fonctionne je devrais pas avoir de problème pour passer en service mode par dongle même si le syscon hash et pas bon? je suis en train d'uploader un des 2 dump valide je vais en faire un save sur dvd au cas ou au moins un virus ne devrais pas pouvoir les modifier

faut pas confondre les clef qui permet de decrypter les self et les clef qui serve a encrypte la nor/nand/disque dur

ben ce qui a de bien c'est que j'ai dump ok dumpe avec le preloader il sont bon car je m'en suis servie pour le passage en dex par contre je pourrais m'acheter les 2 clip que vers le 5 du mois prochain dans 8 jours donc pour le moment je suis coince pour le dump prés a l'emploie comment sa se passe étant donné qu'il est pas encrypte pour que la ps3 arrive a le lire

ce que je comprend pas c'est que j'ai bien flashé mon dump quel sont les synthomes si le syscon hash ne correspond pas au fw dans le ps3 ? j'ai les port usb qui réponde pas donc je peut pas repasser en service mode je vais commander les clip pour dumpé je verrais au moins si les fichier ont bien étais dumpé pour ceux en dex avec ps3 nand il faut en fait passé par multiman lol est ce que l'on peut passer en service mode avec un flasheur?

et il possible que si je dump via infectus(j'ai que sa) le dump fait pour la conversion dex elle reparte? je demande sa car je devrais acheter un clip 360 48 pin pour eviter la soudure

bon ben je crois que c'est foutu peut être avec flasheur mais je suis pas sur je crois que l'erreur que j'ai fait etais de sortir du service mode apres le flash qui etait ok d'apres le log de preloader je pensser passer en service mode depuis un dongle mais en 3.55 la manip eject+power on étais désactiver [edit] ce que je comprend pas c'est que j'ai dumper le dump original donc elle devrais redémarrer non?

ben le soucis c'est que j'ai une nand et pour passer en dex il fallais se servire de JaiCraB Preloader Advance 3.1 on peut aussi passer en service mode depuis un device usb (ancienne methode) ben j'ai oublier le qa flags

bon je vais tenter un dex to cex mais avec avec JaiCraB Preloader Advance 3.1 etant donne que j'ai une ps3 2 nand je vais redescendre en 3.55 rogero dex puis passer en service mode et dumper mon dump original(cex) ensuite je sais pas si je doit dehash car en dex j'etais en 4.21 ensuite j'essayrai le cfw 4.30 e3 [edit] resultat j'ai bricker ma console voila ce que j'ai fait -installation rogero 3.55 dex -passer en servicemode -mis mon dump original plus Preloader Advance 3.1 -la ps3 s'eteind -j'ai pas vérifier pas qu'elle se rallume bien en service mode -je met le dialoglv2 pour sortir du servicemode -elle redémarre mais diode bleu 3,4 second orange puis rouge parcontre j'ai la diode du hdd qui clignote donc je vais voir si je peut pas redemarrer en service mode avec usb et installation du 3.55 ofw

le dump du lv2 est normale qu'il soit différent il est différentier celons se que tu fait sur ta ps3 le lv2 est dumpe dans la mémoire ram de la play donc sa peut etre des variable ou autre qui sont different

juste une question j'ai une nand faut 'il que je me serve de multiman ou alors de l'outils de jaicrab ? j'avais pas utiliser multiman a cause de la nand donc pour revenir en cex je devrais faire pareil non?

en fait si on peut faire un cfw que sur 3.55 c'est que l'on peut resigner un pup pour qu'il soit reconnue authentique mais sony a bloquer sa avec la mise a jour 3.56 du coup pour installer un cfw sur 3.56+ il faudrais les nouvelle clef pour signer le pup ou alors trouver quel protection supplémentairement a étais ajouter si sa viens pas des clef le problème c'est de faire reconnaître le cfw comme authentique sur 3.56+

on peut decrypter lv0 du 4.30 donc on doit pouvoir faire un cfw 4.30

tous ce que je peut te dire c'est que l'on peut decrypter le lv0 donc sa doit être les clef contenue dans le boutldr si non il pourrais pas lancer le lv0 mais sa doit pas être celle du bootldr car on peut pas le decrypter avec (j'ai pas essayer car je ne l'ais pas le bootldr) si on peut patcher le lv2 kernel je me demande si on peut le faire avec le lv2 dex? même si on peut lancer n'importe quoi en dex on ne peut pas lancer un homebrew en root donc peut être que sa pourrais être utile si on peut lancer des jeux depuis le cfw 4.21 c'est qu'il on peek poke dessus

j'ai une question je suis en dex et je commence a me demander si je vais pas passer en cfw 4.21 peut on revenir en 3.55 une fois en 4.21 quelq'un a essayer? si je demande sa c'est pour savoir que si une fois en 4.21 cfw on est coincer et qu'il sorte un nouveaux cfw il faut que je soit sur que l'on pourras mètre un cfw plus récent ou alors j'attend un cfw dex se qui serait le top on peut revenir a n'importe quel fw

bien toutes c'est info mais comment on patche la mémoire si on a pas peek poke ?

j'ai décrypter le lv0 du ofw 4.25 le lv0 charge le tous les ldr (isoldr,appldr,lv2ldr,lv1ldr) donc dans le lv0 il y a les clef de décryptage de tous les ldr? si non comment il pourrais les charger

Je pense que c est installable que sur 3.55 car Sony a ajouter des Protection sur la vérification du pup a partir du 3.56 Du moins c est ce que je pense

vivement un cfw 4.21 dex

personne na de dex + flasheur pour faire des essaye on peut toujours essayer? pour l'exploit des metadonne sa doit surement venir de l'offset des metadonner qui est dans l’entête du self typedef struct { uint32_t magie; / * = 53434500 SCE \ 0 * / hdr_version uint32_t; / version d'en-tête * / uint16_t key_revision; / * 0x0 de détail (type 0) * 0x1 de détail (0,92 à 3,30) * 0x2 de détail (type 1) * Inconnu 0x3 (npdrm1?) * 0x4 de détail (3,40 à 3,42) * Inconnu 0x5 (npdrm1?) * 0x6 inconnu (npdrm2?) * 0x7 de détail (3,50) * Inconnu 0x8 (npdrm1?) * 0x9 inconnu (npdrm2?) * 0xa de détail (3,55) * Inconnu 0xb (npdrm1?) * 0xc inconnu (npdrm2?) * 0xd de détail (3,56) * Inconnu 0xe (npdrm1?) * 0xf inconnu (npdrm2?) * 0x10 détail (3.60 à 3.61) * Inconnu 0x11 (npdrm1?) * 0x12 inconnu (npdrm2?) * 0x13 détail (3,65) * Inconnu 0x14 (npdrm1?) * 0x15 inconnu (npdrm2?) * 0x16 détail (3,70 à 3,74) * Inconnu 0x17 (npdrm1?) * 0x18 inconnu (npdrm2?) * 0x19 détail (4.00 à 4.11) * Inconnu 0x1A (npdrm1?) * Inconnu 0x1B (npdrm2?) * 0x1C détail (4.20-) * Inconnu 0x1D (npdrm1?) * 0x1E inconnu (npdrm2?) * 0x8000 DEBUG (kit de développement) * / uint16_t header_type; / * 1 auto, 2 inconnues, 3 pqt * / metadata_offset uint32_t; / * offset * métadonnées / uint64_t header_length; / * longueur SCE-tête du fichier * / uint64_t data_length; / * longueur de données encapsulées * /} __ Attribute__ ((packed)) SCE_HDR; j’essayerais demain de changer l'offset sur une app voir si elle plante ou pas peut etre que si on donne un offset en dehors du self sa plante

aparament non il et pas dans le coreos_package donc il et dans la ps3 c'est pour sa qu'il peut pas être mise a jour [edit] en fait si il et dans la nand ou nor bootldr (Boot Loader) NAND (0x000000) / NOR (0xFC0000) SPE(0) Per Console Encrypted at factory No * No Setup Primairy Hardware + load lv0 No mais il est écris en usine

peut etre sa sa vient de l'exploit metldr In a self file, at address 0x0C a value is used to calculate where the metadata is going to be decrypted, the "offset" is at self header + 0x0C its the "meta header offset" in the SCE structure, it takes the SCE offset + that value, so what you have to do is to have a calculation that is equal to 0x3E01F0 which happens to be where metldr copies over the shared metadata from the mailbox (which is sent over by the ppu), the trick is to have metldr to decrypt the metadata located at.So basically you have to:1) set the offset += 0x2000 dump shared lsa and keep increasing 0x2000 until somewhere in the shared lsa changes 0x40 byte2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations3) then dump shared lsa and we have decrypted header knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E01F0 - 0xECF0 = the value you would patch at SCE header + 0x0CROM:0000F6C0 D2 68 87 E6 metadata_erk: .int 0xD26887E6; DATA XREF: ROM:0000F178o for example in CECHA , the address you want to decrypt it to is 0x3E1F0 so it should be 0x3E1F0 - 0xF6C0Once you get the decrypted header, you have the key to decrypt the rest of the metadata. Here you go, you have your decrypted signature.So far so good, now what's next ? [edit] ou alors sa Following up on his previous revision, today PlayStation 3 developer naehrwert has updated PS3 SCETool v0.2.5 which utilizes metadata information for decryption among the changes outlined below.