the-green

90% des PC du monde utilisent Windows mon ami je ne suis pas là pour défendre tel ou tel coté je dis juste mon avis, après que monsieur X utilise Windows et monsieur Y utilise Ubuntu (que j'ai moi aussi sur mon PC sur un disque dur à part) ça c'est fait partie de la liberté personnelle. Revenons au sujet les gars...il parait que ce que dit cette team AC1D soit un fake d'après pas mal de sources.

coup de mal chance...ça arrive vérifie bien la PCB pour voir s'il y a un composant grillé sinon essaye comme je t'ai dit, intro/device ID avec l'aiguille source de masse GND sur le point MPX 01 t'utilise quoi comme source de masse GND ?

Soit il est grillé et là...... soit il est bloqué, là essaye avec intro/device ID avec l'aiguille sur le point MPX01 Je n'ai jamais vu ce problème !!

Merci sh4n oui cette thérorie a fait trop de bruit de telle sorte qu'elle me parait réelle, le problème et la question c'est comment récupérer ces eboot exactement ?? certains disent qu'il suffit de faire une MAJ du jeu en utilisant le jeu original 3.6+ sur une console debug !! est ce vraiment la méthode ?

non bugess, le problème vient de chez toi essaye avec F5, essaye sur un autre navigateur les photos sont tous cliquables.

Impossible, il faut se casser la tête et il faut du matos ce tuto est surtout destiné à ceux qui ont leur dump au préalable mais qui n'ont pas de CK t'es en quel firmware actuellement ?? tu as quoi comme lecteur ?

Ce tuto va te servir, suis-le http://gueux-forum.net/index.php?showtopic=257634

lentille fatiguée

c'est quoi le firmware actuel de ton samsung ?

https://twitter.com/#!/SKFU_PS3

Je ne donne pas de fausses rumeurs, je connais linux depuis deux ans sur PC, j'ai utilisé plusieurs distributions...mais la vérité rien ne remplace le beau Windows. Ce que je dis c'est une console de jeu restera une console de jeu, pas une plate-forme pour installer linux dessus. Je ne dis à personne n'installe pas linux sur ta console, je m'en fou, chacun se débrouille, chacun est libre. Puis on revient au sujet, peu de gens se servent de linux sur PS3...soyons réalistes un peu Miles Prower Après tout je ne suis pas ici pour créer des problèmes ou des conflits inutiles...je donne juste mon avis, je respecte beaucoup l'énorme travail réalisé par le hacker allemand graf chkolo, j'apprécie beaucoup aussi le beau travail de la team gitbrew (Glevland, Durandal et Snewy Dev) leurs CFW et leurs outils other OS. Puis je respecte vos avis tous y compris le tien. Bonne fin de journée

S'il y a un hombrew que je veux voir sur PS3 c'est un iso laoder PS one, lancer les backups PSX sous format iso comme le fait le dongle cobra les divx...je ne suis pas très fan de ça, je préfère les MKV sur PC ou directement lire les DVD originaux avec windows media player Linux sur PS3, l'ayant dèja installé et utilisé une fois crois-moi c'est presque inutile !! c'est un peu lourd et très problématique sur console Linux c'est sur PC pas sur consoles désolé ils nous ont dit au départ que linux va faciliter le hack PS3 mais après presque 8 mois ce n'est pas encore le cas....

Alors de quoi veux-tu qu'on parle ?? lancer un émulateur SNES !!! on a le PC pour ça et il le fait mille fois mieux que la PS3 d'ailleurs

Je suis très pessimiste que vous tous mais je crois qu'en 2012 au moins on aura accès aux jeux 3.6+ sans devoir s'acheter le trueblue, ça peut venir dans qq mois comme ça peut venir jusqu'au mois de décembre 2012 !! lol qui vivra verra

et sa team de 10 développeurs , merci aussi à cet anonymous qu'il dit avoir largement contribué à ce HEN récemment. Le bout du tunnel peut être

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