the-green

Bonjour pour l'émulation PS one sur PSP? te voici un tuto utile http://gueux-forum.net/index.php?showtopic=258386 Laise l'UMD iso mode en ME driver, c'est le top bah pas de guide des fonctions du menu vsh, c'est en anglais suffit de lire, puis tout est parfait pars défaut donc ne change pas grand chose va voir le menu recovery, lui aussi est très riche de fonctions/customisations oui pour une autre carte mémoire suffit de mettre le Launcher dans le dossier psp/game/ de la deuxième carte mémoire pour les MAJ du light CFW ME, suffit d'installer les nouveaux modules du CFW ME, ils vont écraser les anciens sur la nand puis de mettre le nouveau launcher sur la carte mémoire et hop.. pour le CFW PRO, tu peux facilement installer et avoir les deux CFW PRO et ME au même temps sur ta PSP, suffit de lancer un des deux au démarrage de ta console ! un pro n'écrase pas un ME et vice-versa

oh oh lisez ce que dit kakaroto !!! We got the confirmation (by finding the public key used and verifying the signatures) yesterday and since sharing this information will not help Sony in any way to block our efforts in a future release, we have decided to share it with you si c'est vrai et qu'ils vont partager avec la scène les clés publiques ça serait la grosse fiesta !!! A moins que ça serait autre chose, les clés publiques sont ceux utilisées pour décrypter les eboot mais aussi les firmwares 3.6+/3.7+

Kakaroto, célèbre développeur et hacker canadien d'origine marocaine nous livre aujourd'hui de nouvelles informations concernant le statut d'avancement de leur Homebrews ENabler 4.0, désormais kakaroto et sa team de 10 développeurs ont réalisé d'énormes progrès à commencer par terminer le processus d'installation des pkg, le lancement de ces derniers se limite pour le moment à seulement la version 3.56, les firmwares 3.60 et supérieur nécessitent plus de travail lié aux signatures npdrm. Après avoir éliminé une des signatures npdrm, c'est une deuxième qui pose problème. La team dit avoir réussi à trouver la première clé privée qui sert à signer les applications pour pouvoir les lancer en firmware 4.00 en HEN, mais pour le moment ça ne marche pas car ça nécessite une deuxième signature propre présente dans les firmwares plus récents. Dans son texte, c'est surtout un passage très important qui attire l'attention, Kakaroto parle des clés publiques qu'ils ont utilisé pour décrypter les firmwares récents, ils parlent même de partager ces clés !! wait & see Le voici le texte: Here's a "quick" status update on the 4.00 HEN (Homebrew ENabler) for PS3. Following my clarifications from almost 2 months ago here, there has been a lot of progress. We have not been slacking off, we're a group of about 10 developers working together for the last 2 months, for sometimes 15 hours everyday in order to bring back homebrew support to the latest version of the PS3. There are three major parts to the HEN, first, getting the packages to install on the PS3, that part is done, completed, tested, debugged, etc.. the second part is to get the apps to run, that one still has major issues… the last part is something I will not discuss for now (it's a surprise) but it's about 60% to 70% done (and it has nothing to do with peek&poke and has nothing to do with backup managers or anything like that. This is and will stay a piracy-free solution for the PS3). Now, running apps is the biggest challenge that we've been working on for the past 2 months. As some of you know, if you've been following me on Twitter, we originally had hoped for Mathieulh to give us the "npdrm hash algorithm" that was necessary to run the apps, but he was reluctant, he kept doing his usual whore so people would kiss his feet (or something else) so he'd feel good about himself. But in the end, he said that he refuses to give us the needed "npdrm hash algorithm" to make it work… So what I initially thought would be "this will be released next week" ended up taking a lot more time than expected, and we're still nowhere near ready to make it work. Mathieulh kept tossing his usual "riddles" which he thinks are "very helpful for those who have a brain", and which pisses off anyone who actually does… so he told us that the solution to all our problems was to look in appldr of the 3.56 firmware.. and that it was something lv1 was sending appldr which made the "hash check" verified or not… so we spent one month and a lot of sweat and after killing a few of our brain cells out of exhaustion, we finally concluded that it was all bullshit. After one month of reading assembly code and checking and double-checking our results, we finally were able to confirm that that hash algorithm was NOT in the 3.56 firmware like he told us (at all). He said that it was an AES OMAC hash, but after tracking all the uses of the OMAC functions in appldr, we found that it was not used for the "hash"… he then said "oh, I meant HMAC", so we do that again and again come up with the same conclusion, then we're sure it's not in appldr, and then he says "ah no, it's in lv1".. have a look for yourself to what he decided to write : http://www.ps3devwiki.com/index.php?title=...Jailbreak%C2%B4 That happened after the huge twitter fight I had with him for being his usual arrogant ass and claiming that he "shared" something (For your information, the code that he shared was not his own, I have proof of that too (can't show you the proof because even if I don't respect him, I gave him my word to not share what he gave me, and I respect my word) since he forgot to remove the name of the original developer from one of the files… also it was completely useless and was not used at all, just made me waste a day reading the crappy undocumented code. So why is he still trying to force his "advice" through these riddles even after we had that fight? Well to sabotage us and make us lose all those months of hard work! So anyways, we had all accepted that Mathieulh was full of shit (we knew before, but we gave him the benefit of the doubt) and decided to continue working without considering any of his useless riddles. So we then tried to exploit/decrypt the 3.60+ firmware in order to get the algorithm from there. Now, a few more weeks later, we finally have succeeded in fully understanding that missing piece from the "npdrm hash algorithm", and here it is for everyone's pleasure with some prerequisite explanation : A game on the PS3 is an executable file in a format called a "SELF"file (kind of like .exe on windows), those "self" files are cryptographically signed and encrypted.. For PSN games (games that do not run from a bluray disc), they need to have an additional security layer called "NPDRM". So a "npdrm self" is basically an executable that is encrypted and signed, then re-encrypetd again with some additional information. On 3.55 and lower, we were able to encrypt and sign our own self files so they would look like original (made by sony) "npdrm self" files, and the PS3 would run them without problem. However, it wasn't really like an original file.. a real NPDRM self file had some additional information that the PS3 simply ignored, it did not check for that information, so we could put anything in it, and it worked. Since the 3.60 version, the PS3 now also validates this additional information, so it can now differentiate between NPDRM self files created by sony and the ones that we create ourselves for homebrew. That's the "npdrm hash algorithm" that we have been trying to figure out, because once we can duplicate that information in the proper manner, then the PS3 will again think that those files are authentic and will let us play them. Another important point to explain, I said a few times that the files are "signed".. this means that there is an "ECDSA signature" in the file which the PS3 can verify. The ECDSA signature is something that allows the PS3 to verify if the file has been modified or not.. it is easy to validate the signature, but impossible to create one without having access to the "private keys" (think of it like a real signature, you can see your dad's signature and recognize it, but you can't sign it exactly like him, and you can recognize if your brother tried to forge his signature). So how were we able to sign the self files that were properly authenticated on 3.55? That's because this "ECDSA signature" is just a very complicated mathematical equation (my head still hurts trying to fully understand it, but I might blog about it in the future and try to explain it in simple terms if people are interested), and one very important part of this mathematical equation is that you need to use a random number to generate the signature, but Sony had failed and used the same number every time.. by doing that, it was easy to just find the private key (which allows us to forge perfectly the signature) by doing some mathematical equation on it. So to summarize, a "signed file" is a file which is digitally signed with an "ECDSA signature" that cannot be forged, unless you have the "private key" for it, which is impossible to obtain usually, but we were able to obtain it because Sony failed in implementing it properly. Now, back on topic.. so what is this missing "npdrm hash algorithm" that we need? well it turns out that the "npdrm self" has a second signature, so it's a "encrypted and signed self file" with an additional layer of security (the NPDRM layer) which re-encrypts it and re-signs it again. That second signature was not verified in 3.55 and is now verified since the 3.60 version of the PS3 firmware. One important thing to note is that Sony did NOT make the same mistake with this signature, they always used a random number, so it it technically impossible to figure out the private key for it. To be more exact, this is the exact same case as the .pkg packages you install on the PS3, you need to patch the firmware (making it cfw) so that those .pkg files can be installed, and that's because the .pkg files are signed with an ECDSA signature for which no one was able to get the private key. That's why we call them "pseudo-retail packages" or "unsigned packages". The signature on the NPDRM self file uses the exact same ECDSA curve and the same key as the one used in PS3 .pkg files, so no one has (or could have) the private key for it. What this means is that, even though we finally figured out the missing piece and we now know how the NPDRM self is built, we simply cannot duplicate it. The reason we wasted 2 months on this is because Mathieulh lied by saying that he can do it.. remember when the 4.0 was out and I said "I can confirm that my method still works" then he also confirmed that his "npdrm hash algorithm" still works too? well he didn't do anything to confirm, he just lied about it because there is no way that he could have verified it because he doesn't have the private key. I said I will provide proof of the lies that Mathieulh gave us, so here they are : he said it's in 3.56, that was a lie, he said it's an AES OMAC, that was a lie, he said it's an HMAC, that was a lie, he said it's in appldr, that was a lie, he said it's in lv1, that was a lie, he said that he can do it, that was a lie, he said that "it takes one hour to figure it out if you have a brain", that was a lie, he said that he verified it to work on 4.0, that was a lie, he said that he had the algorithm/keys, that was a lie, he said that once we know the algorithm used, we can reproduce it, that was a lie, he kept referring to it as "the hash", that was wrong. The proof ? It's an ECDSA signature, it's not a hash (two very different terms for different things), it was verified by vsh.self, it was not in lv2, or lv1, or appldr, and the private key is unaccessible, so there is no way he could build his own npdrm self files. Now you know the real reason why he refused to "share" what he had.. it's because he didn't have it… So why do all this? was it because his arrogance didn't allow him to admit not knowing something? or was it because he wanted to make us lose all this time? To me, it looks like pure sabotage, it was misleading information to steer us away from the real part of the code that holds the solution…. That is of course, if we are kind enough to assume that he knew what/where it was in the first place. In the end, he wasn't smart enough to only lie about things that we could not verify.. now we know (we always knew, but now we have proof to back it) that he's a liar, and I do not think that anyone will believe his lies anymore. Enough talking about liars and drama queens, back to the 4.0 HEN solution… so what next? well, we now know that we can't sign the file, so we can't run our apps on 3.60+ (it can work on 3.56 though). What we will do is look for a different way, a completely new exploit that would allow the files we install to actual run on the PS3. We will also be looking for possible "signature collisions" and for that we will need the help of the community, hopefully there is a collision (same random number used twice) which will allow us to calculate the private key, and if that happens, then we can move forward with a release. When will the "jailbreak" be released? If I knew, I'd tell you, but I don't know.. I would have said in last november, then december, then before christmas, then before new year, etc… but as you can see, it's impossible to predict what we will find.. we might get lucky and have it ready in a couple of days, or we may not and it will not be ready for another couple of months.. so all you need to do is : BE PATIENT (and please stop asking me about an estimated release date)! I would like to thank the team who helped on this task for all this time and who never got discouraged, and I'd like to thank an anonymous contributor who recently joined us and who was instrumental in figuring it all out. We all believe that freedom starts with knowledge, and that knowledge should be open and available to all, that is why we are sharing this information with the world. We got the confirmation (by finding the public key used and verifying the signatures) yesterday and since sharing this information will not help Sony in any way to block our efforts in a future release, we have decided to share it with you. We believe in transparency, we believe in openness, we believe in a free world, and we want you to be part of it. If you want to know more about this ECDSA signature algorithm, read this interesting paper that explains it in detail, and you can also watch Team Fail0verflow's that first explained Sony's mistake in their implementation, which made custom firmwares possible. Thanks for reading, KaKaRoTo Source: http://kakaroto.homelinux.net.nyud.net/

Bonjour fireball, j'ai lu les deux passages de Deank hier, c'est simple, il dit que posséder les clés et ainsi décrypter les eboots 3.6+/3.7+ puis les encrypter en 3.55 serait suffisant pour lire les jeux récents sur CFW 3.55 jusqu'au jour ou les jeux vont réellement nécessiter des fonctions qui ne sont pas présentes que dans les firmwares 3.6+ là un eboot 3.55 ne va pas nous permettre de jouer à un jeu 4.00, ce jour là risque de venir prochainement

Pourquoi compliquer l'histoire l'ami suffit d'avoir les clés de décryptage 3.6+/3.7+ pour décrypter les eboots encrypter ces eboot avec leurs clés spécifiques 3.55,vérifiables grâce au dongle sans quoi l'eboot et donc le jeu ne se lancera pas Le dongle serait toujours là pour vérifier que tu as bien payé !

On choisit le bon numéro du port SATA correspondant à notre liteon, toujours le 3 dans mon cas, on confirme. Que va-t-on faire maintenant? C'est simple, on a fait l'erase, le liteon est en mode vendor, maintenant on va écrire le firmware préparé LT plus 3.0 Donc W dans ce cas et on confirme. (pour Write) Dosflash vous demande sagement le nom du firmware situé à la racine de votre clé USB qui va servir au flash. Dans mon cas c'était lite donc ça sera lite.bin. On confirme. Dosflash refait un erase du chip puis écrit les 4 bank du firmware liteon. Voilà, flash réussi, vous voyez le message writing finished. Il ne reste plus qu'à éteindre la console/CK ou autre, remettre tout en place et tester le lecteur avec vos originaux et leurs backups. N'oubliez pas de remettre la chaine de boot dans le BIOS à son ordre initial pour booter comme d'habitude sur votre disque dur. Voilà notre tutoriel terminé, comme d'habitude on passe nos remerciements à tout ceux qui ont rendu le flash possible depuis des années. - C4eva, le commodore à qui on doit les firmwares ixtreme et LT plus depuis des années, ainsi que ses solutions face à la protection AP25, CIV et sa solution pour la gravure des XGD3, t'es tout simplement fantastique c4eva. - Geremia, ModFreakz et KaiSctrom pour leurs travaux et pour dosflash. - La team xecuter, team maximus et tout ceux qui ont participé de près ou de loin au hack des lecteurs XBOX 360. - Le ( ou les) développeur derrière cette belle application Bootable USB Drive Creator Tool - Zouzzz pour sa belle application GX Tuto helper . Tutoriel réalisé pour GX-Mod, Amicalement the green

Suite... Maintenant que la clé USB soit préparée, redémarrez votre PC, au reboot appuyez sur la touche DEL ou Supp pour accéder au BIOS. Le but serait de modifier la chaine de boot afin de booter sur la clé USB bootable ms-dos (c'est variable selon les cartes mères, donc trouvez votre chemin) Là je passe à Advanced BIOS Features. La voici la fonction boot sequence, je passe dedans avec Enter. (entrée) Voilà, à l'était habituel, c'est mon disque dur sata qui passe en premier, suffit d'appuyer sur entrée et de le remplacer. Je vais choisir ma clé USB préparée qui passe en premier. Changement effectué, on fait marche arrière avec Echap Save & exit setup. On confirme par OK. Maintenant, alimentez votre lecteur liteon en allumant la console ou le CK/xtractor/CK Home-made ou je ne sais pas quoi ... OK, le PC va redémarrer automatiquement, puis dans quelques secondes vous allez vous retrouver sur l'invite de commande ms-dos de la clé USB, here we are [] C'est le temps de prendre du sérieux pour le flash, écrivez dosflash. Sur MS-DOS, le Q c'est le A, le Z c'est W donc vous allez écrire dosflqsh avec le clavier. Conformez par entrée. L'application historique-toujours utile du flash de slecteurs XBOX 360 développée anciennement par le trio Geremia, ModFreakz et Kai Schtrom va se lancer puis analyser un par un vos ports SATA et IDE. ...Hop, elle tombre sur un liteon DG-16D2S firmware 0251 !!! c'est notre liteon. Il vous dit que la tentative de faire passer le liteon 0251 en mode vendor a échoué et qu'il faut faire un cycle OFF/ON Rapide. pas besoin de tout ça, nous sommes passé par dosflahs juste pour éviter le cycle OFF/ON dans le cas ou on ne possède pas de CK/xtractor ou autre mais qu'on utilise la console. On va répondre par non avec n puis on conformant la commande par Entrée. Dosflash va finir l'analyse des autres ports SATA, puis il vous demande sur quel périphérique voulez-vous agir. Ceci en vous demandant le numéro correspondant. Dans notre cas, le liteon 0251 porte le numéro 3 comme vous le voyez sur la photo dessous. ça peut être un 1, 5 ou 11 pour vous, c'est selon vos résultats. On tape 3 et on confirme. Maintenant dosflash vous ce que vous voulez faire de votre lecteur, dans notre cas, on veut faire un erase de ce liteon donc on va taper liteon e (pour liteon erase). liteon e et on confirme. L'erase commence et se termine en quelques secondes avec le message de réussite OK. LiteOn Erasing.....OK. De nature et pour de meilleurs résultats, on préfère éteindre la console complètement, attendre 10 secondes puis l'allumer une deuxième fois avant de continuer (idem pour le CK ou autres). Donc console ré-allumée; on relance dosflash. Comme un grand, il va faire l'analyse des ports SATA et là il trouvera notre liteon FAT en mode vendor avec les bonnes informations du chip (Winbond ou MXIC, taille de 262144 bytes...etc) si c'est le cas, tout va bien, si vous trouverez autre chose, un 0 sur la taille...là il y a un problème, vérifiez votre connexion SATA, la console, essaye de nouveau l'erase.

Bonsoir tous le monde, bonsoir les gueux, je suis de retour aujourd'hui avec un nouveau petit-long tutoriel parlant du flash des liteons sous ms-dos avec le fameux vieux Dosflash de Kai-Schtrom dans sa dernière version 2.0. De nos jours, de moins en moins de gens utilisent dosflash pour flasher leurs lecteurs vu la performance et l'évolution de Jungle Flasher mais aussi l'apparition du Lizard 360/X360 USB PRO. Toutefois, Dosflash garde son intérêt chez l'old-school mais aussi garde son intérêt dans le debrikage des liteons/benq, il le garde aussi pour ne pas dire obligatoire pour ceux qui ont un ancien dump/firmware de leur liteon mais qui n'ont pas de CK( connectivity kit) ou autre gadget autonome d'alimentation des lecteurs XBOX 360. Pourquoi? C'est simple, lors du flash d'un liteon avec Jungle Flasher, le software vous demande lors de l'erase un cycle OFF/ON rapide et sans CK/xtractor ou autre, en utilisant la console comme source d'alimentation, vous risquez un retard qui engendre le brick de votre lecteur! On parle toujours du cas ou vous possédez un ancien dump votre clé DVD, un ancien dummy.bin, OFW, ixtreme 1.X, LT ou LT plus X.X. Avec dosflash sous ms-dos (oui il existe dosflash 32bit sous windows et même 64 bit), vous pourrez faire l'erase directement,éteindre, allumer la console puis flasher le lecteur. Donc pas besoin du CK ou autre donc vous pourrez utiliser la console pour alimenter le lecteur durant l'erase/flash. Aller, on commence. Votre clé DVD (ancien dummy.bin, OFW, ixtreme, LT ou LT plus) Jungle flasher dernière version, voici son lien: Jungle Flasher. Dosflash 2.0, vous aurez besoin de la version 16 bit seulement, voici son lien: Dosflash 2.0. Le pack des firmwares de c4eva pour préparer votre LT plus 3.0, vous le trouverez avec google ou ailleurs. Une bonne clé USB ou disquette (mais à éviter de nos jours) Le logiciel Bootable USB Drive Creator Tool avec les fichiers de boot ms-dos à prendre d'http://www.mediafire.com/?x56fyhnxebfqz58. Votre liteon bien sur. La console pour alimenter le lecteur ou si vous en-avez, un CK/Xtarctor 3 ou autre gadget d'alimentation destiné aux lecteurs de la 360 (ce tuto est destiné aux gens qui n'ont pas de CK et doivent utiliser la console pour l'alimentation de lecteur lecteur durant le flash) Voilà, tout est prêt !! Let's go. NB: Toutes les photos/images sur ce tuto sont cliquables, si vous voulez agrandir une de ces photos, suffit de cliquer dessus On lance jungle flasher pour préparer le firmware LT plus 3.0. Une fois l'application se lance, cliquez sur Open Source firmware. Cherchez maintenant votre ancien firmware/dump qui contient votre belle clé DVD, dans mon cas ça sera un dummy.bin. Deux clics et vous serez de nouveau sur Jungle Flasher, la clé DVD apparait dans la case DVD Key. Maintenant si vous avez déjà mis au départ les firmwares du pack de c4eva dans le dossier firmware de Jungle Flasher, il va tout-seul vous proposer de charger et de faire le spoof avec le LT plus 3.0 liteon 0251 (dernier firmware de c4eva destiné aux 4 liteons). Le cas échéant, cliquez sur Open target firmware. Cherchez manuellement le firmware LT plus 3.0 liteon 0251 et sélectionnez-le. Les deux firmwares en place, suffit d'appuyer sur Spoof source to target. Et hop, comme par magie, les données nécessaires vont passer du dummy au nouveau LT plus 3.0 à commencer par la clé DVD. Pensez maintenant à sauvegarder le firmware obtenu fraichement préparé à un endroit précis, on va l'utiliser après. Par défaut jungle Flasher lui donne le nom Lite_CFW, suffit de confirmer. On a terminé maintenant avec jungle Flasher, on va préparer notre clé USB bootable ms-dos pour accueillir dosflash. On relie la clé USB au PC. (NB: pour cette opération, la clé sera formatée donc sauvegardez vos données au préalables !!!) Maintenant on passe au logiciel Bootable USB Drive creator tool v1.0, logiciel gratuit qui va vous permettre de formater votre clé USB et la rendre bootable ms-dos avec quelques fichiers. Lancez-le. Par défaut, il détecte directement la clé USB connectée au PC, la voici la mienne avec la lettre I. Cochez maintenant la case Make bootable drive et appuyez sur le bouton situé dessous (regardez bien la souris). OK, maintenant rendez-vous au dossier de l'application ou vous allez cherchez le sous-dossier MS-DOS. sélectionnez-le et appuyez sur OK. Maintenant tout est prêt suffit d'appuyer sur Start. Un dernier avertissement pour vous rappeler que tout ce qui est existe sur cette clé USB sera perdu !! OK on le sait allons y. Le formatage commence puis l'installation des fichiers de boot ms-dos. (fichiers cachés à l'occasion, c'est normal que vous ne verrez rien dans la clé par la suite !) Opération réussie. OK Maintenant, passons au dossier de l'archive dosflash 2.0, au sous-dossier dosflash 16. Suffit de copier l'application Dosflash.exe à la racine de votre clé USB rendue bootable. On va aussi copier à la racine le firmware LT plus 3.0 liteon 0251 qu'on a préparé auparavant avec la bonne clé DVD. Pensez à renommer le nom du firmware en un nom simple comme lite, ainsi sur ms-dos et lorsque dosflash vous le demandera, vous écrirez lite.bin.

OK, passe à la version 0.1.87b de jungle flasher, tu peux flasher en LT plus 3.0 avec cette version bien qu'elle va détecter le firmware comme étant un LT plus 1.92.

Une PSP FAT ne se charge pas via USB, seulement via le chargeur.. impossible d'activer cette option via des options, plugins ou autre, oublis ça

ah OK

as-tu la PCB originale du 9504 ?

oui deaphroat, mais il dit que sa PSP est en 3.95, non ??

La nand c'est la mémoire intégrée dans la carte mère, celle qui accueille le firmware de la PSP, elle a une taille de 64 MO, les firmwares officiels ne dépassent pas en général 31 MO, les reste va donc nous permettre d’accueillir les modules .prx du CFW qui ne font que qq KO. Tu peux riper tes UMD avec le super logiciel Iso Tool de Takka, va le voir dans la section news, il est super et facile d'utilisation. Tu pourra toujours lire tes UMD sur CFW, ça n'a absolument rien à voir dedans.

Ok, pas de problème pour le bug, j'ai supprimé ton premier message oui ta PSP ne supportera pas le retour en 6.20 et donc pas de CFW PRO-B 6.20 permanent dessus tu va pouvoir toutefois passer en OFW( firmware officiel 6.60, le dernier est toujours le mieux) puis installer dessus soit le light CFW ME 1.6 soit le CFW non permanent PRO-B10 6.60 non permanent. Dans les deux cas, on installe les modules du CFW par le ME Installer ou le PRO Update puis on supprime l'application car les modules sont installés définitivement sur la nand (pas la RAM comme les HEN) Puis pour lancer le CFW à chaque démarrage on lance soit le ME Launcher pour le ME soir le fast recovery pour le PRO le PRO est mieux que le ME niveau compatibilité jeux PSP avec son fameux driver Inferno mais le ME est aussi super avec son driver ME Oui suffit de supprimer l'application de la carte mémoire à travesr la PSP, c'est simple. 1GO ou 16 GO, pas de soucis, tu peux même garder le ME Launcher ou le fast recovery sur les deux cartes mémoires En cas de soucis/question, je suis et on est tous là Bonne fin de journée

Voilà...le reste c'est du fake das du fake...dans le hack vive c4eva et les hackers derrière le JTAG/Glitch sur la 360. la scène PS3 est catastrophique

T'as oublié l'étape du dump le flash des slim pose souvent problème via SATA une fois tu passe en mode vendor avec Intro/device ID, faites un read pour lire le firmware actuel puis un spoof avec le LT plus 3.0 puis par la fin le write du nouveau LT plus 3.0 t'as dèja flashé des lecteurs xbox dans le passé ?? tu comprends le langage de flash, clé dvd, dump, spoof write..etc ?? qui a flashé cette console auparavant ? tu as ton ancien dump ?

S'ils ont les clés de décryptage, ça va perdurer, de toute façon "peut être" on ne verra jamais de CFW 3.6+ ! CFWPRPHT dit qu'il va proposer un truc aujourd'hui...on verra http://www.ps3hax.net/showthread.php?p=318069

Oui seule la forme complète des XGD3 passe sur les lecteurs Hitachi, il faut respecter les 4 règles: - Graveur liteon iHAS X24 B - Dump iso de ton original XGD3 patché avec les topology data via abgx v1.0.6 - Utilisation de meédia verbatim MKM01 ou MK03 - Gravure avec ImgBurn 2.5.6.0 Bonne chance

Pour les 3 jeux que tu as cité en premier (FIFA 12, PES 12 et batman arkham city) le problème c'est que ces jeux sont vendus depuis la chine sous forme de BluRay dèja gravés par de grands sites chinois, donc surement des contrats ont été faites entre la team trueblue et ces sites, donc les eboot de ces jeux ne seront pas lancés tant que les stocks de ces BluRay ne soient pas terminés. Ceci me dit autre chose, je ne sais pas mais je crois que Trueblue est une seule personne pas une team !! c'est un seul gars qui fait tout, ça explique le retard et la lenteur des release qu'éprouve le dongle et sa solution jealbreak attendez-vous aussi à un nouvel update du dongle histoire de freiner encore une fois le JB-King avant de voir apparaitre de nouveaux eboots

Bonne chance à cette team

You're wellcome

Pourquoi le downgrade les gars ??!! Le CFW GEN 2 3.95 est un CFW permanent avec protection 9.90 empêchant l'installation de nouveau firmware officiels dessus pas besoin de pandora ou memory stick magic ou autre suffit de passer à un CFW 4.XX puis utiliser l'update GEN-D3 final pour re-passer en firmware officiel 5.50 Delà la voie sera libre vers le dernier firmware officiel 6.60, sur lequel tu va pouvoir installer le meilleur CFW pour ta PSP qu'est le CFW PRO-B10 6.60 avec son patch permanent custom IPL. Passe à la section tuto à publier du forum, tu trouvera qq tutos utiles dedans

garde ton fichier origvsh.prx sur ton PC formate ta carte mémoire sur la PSP pour créer les dossier seplugins et sio puis met les dumps iso/cso de tes originaux dans le dossier iso voilà Les PSP 300X 7G et 9G sont flashables mais ne peuvent pas descendre en 6.20 pour bénéficier du patch permanent du CFW PRO-B 6.20 ils peuvent prendre les CFW non permanent PRO-B10 6.39 ou 6.60 mais aussi le light CFW ME 1.6 6.60

Pourquoi t'aime pas ce gars sephi ?