krHACKen

Mmm, j'suis peut être parano mais je pense que ça pourrait être l’œuvre de Yeshuachrist ou de son alter ego shiasse trente-deux, qui voudraient torpiller les deux listes officielles pour mieux créer la leur. Je compte me remettre sur le développement de POPStarter. Ayant vu le joli GUI en gsKit de ps2rd créé par root, ça m'a donné des idées. En plus mon SDK est à jour. POPStarter est tellement basique est codé avec les pieds qu'il mériterait d'être recodé de zéro. Je ne sais pas quand je pourrais me remettre dessus vu que le temps me manque cruellement en ce moment, mais j'y songe.

La plupart des homebrews font un (ou deux) IOP reset dès leur démarrage. POPStarter ne le fait pas parce qu'il réalise des tests de sécurité et a besoin de "voir" la mémoire telle que l'utilisateur l'a laissé. Donc c'est plutôt à moi de fixer ma cochonnerie LOL. Néanmoins, je suis étonné que uLE n'en fasse pas avant d'invoquer ExecPS2. Le truc c'est que j'aurais préféré résoudre ça en apportant + de changement à POPStarter, plutôt que de cracher de nouveaux ELFs pour un si maigre truc.

Merci d'avoir testé. J'ai trouvé l'origine du problème : Un conflit de drivers. Ni le loader d'ELF de uLE, ni POPStarter et son lanceur ne font d'IOP reset:lol:. Ce qui fait que quand POPStarter essaie de charger son ps2hdd.irx, il se retrouve emmerdé par celui de uLE qui n'a pas été déchargé. Solution : Mettre un IOP reset avant de charger les modules de POPStarter. Mmmm, ça m'ennuie de sortir un nouveau lanceur rien que pour ça mais je vais bien y être obligé... En attendant, vous pouvez toujours lancer une version antérieure de uLE à partir de la WIP4 pour pouvoir lancer POPStarter:(, si vous utilisez la WIP4 pour tous vos lancements d'ELF. EDIT : Le MBR de uLE WIP 4 est sorti : http://tinyurl.com/mjwsogn

La WIP 4 est sortie hier : * Maintenant toutes les partitions système (commençant par "__") peuvent être ouvertes Si j'ai bien pigé, il n'était pas possible de rooter la partition "__boot" dans la build précédente * L'option DELETE est désactivée dans le HddManager pour les partitions système Ouaip, d'après mes souvenirs, la version ev ne pouvait pas les supprimer non plus. J'étais obligé de les renommer en enlevant un "_" du préfixe avant de pouvoir les supprimer. * Il est maintenant possible de lancer uLE depuis le __mbr Le BSOD est résolu. Quand il est booté en __mbr, il tente de charger le fichier de config depuis hdd0:__sysconf:pfs:/FMCB/LAUNCHELF.CNF. Si il n'y a pas de fichier de config là dedans, il essaiera alors de le charger depuis le dossier SYS-CONF de vos MCs. Et ça rox du poney. EDIT : À confirmer. Le lanceur de POPStarter semble être incompatible avec uLE WIP 4. Je l'ai lancé depuis la clé USB, et apparemment ce con de lanceur échoue à booter hdd0:/__common/POPS/EXECUTE.ELF. Les textes de débogage du lanceur s'affiche, mais après c'est l'écran noir...

La fat table de la MC qui est niquée, ou un ECC qui ne convient pas sans doute; mais dans un cas comme celui là, l'OSD parvient quand même à formater la carte. Pour commencer, souffler dans la carte mémoire et dans le slot, ou utiliser un coton tige pour nettoyer les contacts. Sans quoi, faire un dump de la MC au cas où, avec MCA 2.0, HDproject ou l'installateur de FMCB. Ensuite, essayer de la formater avec MCA 2.0 ou de la remplir de zéros. Reste les pannes hardware : Fusible claqué, MCU claqué (c'est extrêmement rare mais ça peut arriver), flash en court circuit, secteur défectueux, sous-alimentation (carte mémoire non officielle dans une slim)...

Pas essayé, mais effectivement ça devrait marcher. Il me le faut absolument en MBR, pour des questions de rapidité et de propreté de la mémoire. J'ai donc fait un rapport à AuH. La WIP2 fonctionne depuis le MBR, avec ou sans MC. La WIP3 ne fonctionne depuis le MBR que si le fichier de config est chargé depuis la MC. Sans avoir regardé sa source, je pense que le problème peut être résolu en forçant boot_path en hdd0:__sysconf:pfs:/FMCB/EXISTEPAS.ELF quand "rom0:" est détecté en 1er argument. Normalement ça devrait faire que uLe charge les modules du HDD et aille chercher la config dans la partition. Peut être que j'aurais pu vérifier ça en envoyant directement l'argument, mais j'ai trop la flemme de recoder le payload pour le MBR:pff:. Donc toujours pas de bidouilles PS2 pour moi en ce moment.

post1760919 post1760920 post1760921

Après un GROS FAIL à me lancer dans la PS3, je me recale sur PS2. Là je reprends mon HDD de 320 GB vierge pour en faire quelque chose de potable et de simple d'utilisation pour le gaming ET les bidouilles. Donc j'ai pompé la WIP3 et je l'ai fichu en MBR. Ça freeze. Écran noir après la séquence de boot. Pareil si je mets un fichier de config dans hdd0:/__sysconf/FMCB/. Pareil si j'utilise un autre packer. Installé manuellement, puis avec FIXMBR, au secteur 8192. Le container est le MBR du PSBBN. Avant que j'essaie de changer de container, de forcer un argument et de me résigner à opter pour le 4.42_ev, est ce que quelqu'un a essayé de le booter via le MBR ?

Je lui a filé les dumps et des scans de ma mobo récemment. C'était aussi une SCPH-50004 (romgen 20030227-193050, romver 0170EC20030227) avec le lecteur DVD 3.00E. La mobo était une GH-023. Une autre que j'avais, SCPH-50004a avec le 3.02E était une GH-026...

J'ai pas fait le test, mes slims sont niquées et ne lisent pas les DVDs. Voilà comment NTGUI2EU.ELF est chargé : - Choisis l'option Réseau dans le menu principal - Arrivé à cet écran... http://img96.imageshack.us/img96/5214/qy77.jpg ... appuies sur carré et ça t'affichera ça : http://img855.imageshack.us/img855/7126/mz00.jpg - Swap ton disque et choisis Oui. Si ça a fonctionné, ton ELF devrait se lancer. Perso je ne pense pas qu'il soit possible d'empêcher la console de lire l'ELF original en collant un bout de scotch sur le DVD original de PES6. NTGUI est trop mal placé. Trop près du ELF principal et du fichier d'indexation : http://img716.imageshack.us/img716/3848/8prh.jpg Si le swap avant d'avoir choisi Oui n'a pas fonctionné, essayer de choisir Oui en premier et de swapper le disque quand l'écran vire au noir.

Non merci. Les fichiers MC du BBN 0.32 sont déjà déplombés (Pastie 8315724) et quelqu'un a dumpé son disque en début d'année. Je viens de me rappeler que le BBN 0.32 et 0.30 de SUDC3 ont leurs installateurs de DVD Player désactivés, vu que les dumps propres de ces disques me sont parvenus après la release. C'est fâcheux, parce que les Utility Discs 1.00 et 1.01 crackés de SUDC3 sont foireux eux aussi. Donc pas moyen d'installer le kernel patch depuis SUDC3, seulement avec les KELFs signés DISK qui ont été leakés. Bon y'a quand même un avantage avec le pack de KELFs, c'est qu'il y a un patch pour le driver ATAD de osd110/130:D. Par MàJ du lecteur DVD Jap, je pensais aux disques d'updates dédiés, comme ceux listés dans "missing dumps".

Du nouveau là dessus ? Aussi, aurais-tu des disques de MàJ du lecteur DVD Japonais ? Vu que je n'en ai pas, je n'en ai cracké aucun. Néanmoins, le PSBBN 0.32 inclus dans SUDC3 devrait être capable d'installer le 3.04. J'ai aussi isolé le firmware signé DISK et balancé des patches pour changer la région du dossier BXEXEC-DVDPLAYER quelque part sur ASSEMbler Games.

Coïncidence. Le nom de l'image était disc0 à l'origine. Je l'ai fait passer en IMAGE0.VCD, parce que c'est le nom que les mecs qui bossaient sur le projet utilisaient. Au final, je me suis dit que si ils venaient à publier leurs travaux, ça aiderait ceux qui ont déjà installé un paquet de jeux (pour ne pas qu'ils aient à renommer toutes leurs images en cas d'update).

[Mode_Anti_TrisoZone] 1x ?? Mouahahah:fonsde:. En même temps, c'est l'autre pauvre gars qui a rédigé ce "tutoriel". Faites un don à Google pour qu'ils cessent d'indexer la merde des forums de TrisoZone. [/Mode_Anti_TrisoZone] Plus sérieusement, 8x ou 16x c'est parfait pour les CDRs et les DVD-R. Ne pas prendre de DVD+R. Verbatim c'est couteux, mais c'est du très bon. J'ai pratiquement jamais eu de foirage avec des MCC 03RG20.

Ouaip donc ça doit être ça, le type de machine qui de correspond pas dans le KELF. J'ai dit une connerie dans mon précédent post. Mes containers ont pour type de machine 0x00, là où les KELFs du HDDOSD et du disque d'installation ont 0x01 (comme dans pratiquement tous les KELFs retails, sauf les loaders DNAS_HDD). Donc en théorie, la TEST ne bouffe que du 0x0000, pas 0x0101 contrairement à ce que je disais. Quand à la TOOL, ce montre m'est beaucoup trop étranger, aucune idée. À la rigueur, tu peux aussi prendre un vieux disque dur et tenter d'y écrire un MBR fonctionnel. Ça éviterait d'avoir à signer le KELF pour ta MC. Le truc c'est que j'y connais pas grand chose en TEST. Je ne sais pas par exemple si uLe fonctionne bien avec, et si le MechaCon ignore le zonage des KELFs. Sans quoi, j'aurais vomi un MBR bootable. Le set d'utilitaires de Kermit ? J'ai été vraiment naze de ne pas m'être procuré un câble firewire plus tôt. J'ai reçu le mien hier, pour les besoins d'un projet; et je pense que j'ai pas fini d'en craquer mon slip:pouce:.

Un HDD Utility Disc cracké devait pouvoir se lancer sur une DEBUG/TEST. Après, reste à savoir si la DEBUG/TEST a le support du décryptage MagicGate, pour pouvoir lancer tout ce qui est KELF, y compris le HDDOSD. Si la DEBUG/TEST supporte le décryptage MG, il sera peut être nécessaire de re-signer les KELFs : Richi (chez ASSEMblergames) m'avait dit que seuls mes containers vides (venant des disques d'updates DVD Player) pouvaient se lancer sur sa TEST. J'en avais conclu que le Machine Type flag (dans l'en-tête du KELF) devait être 0x01 ou 0x0101. Malheureusement, ASSEMBlergames a été hacké récemment et mon post a été perdu. Je suis occupé en ce moment sur un autre truc, mais j'essaierais de te faire parvenir un HDDOSD re-signé dès que je pourrais. Autre truc, dont je pense que tu es déjà au courant : Les retails 10k, 15k et 18k ont besoin du patch pour le Kernel, qui est installé sur la MC.

L'écran noir, c'est le foirage du décryptage du lanceur, un KELF, pour cause de zonage. La solution à ça c'est de deXorer l'exécutable du disque, secteur 20000 si je me souviens bien, et de se débarrasser du lanceur (ou de re-signer le lanceur mais c'est moins fun). Pour l'installateur du DVD Player, on le décrypte, on hardcode la cdvdKey dedans, et on transforme le SifLoadElfEncrypted dans l'exécutable principal en un SifLoadElf. Selon la build, le package du DVD Player a une ou deux couches de crypto en moins. Free McBoot entre autre, mais surtout..... ça . Ont ouvert de nombreuses portes magiques, jusqu'à celles du matos d'arcade basé sur la PS2...

LOL, j'savais pas ça. Je croyais que cette là bootait osdsys.elf (le patch Kernel) quand les autres bootent osdmain.elf (30k+). Mais ça me parait legit, vu que si 5ony a intégré l'update du kernel en ROM (18k), elles n'ont plus besoin de charger l'updater (conçu pour les 10k et 15k), juste l'update OSD. Puis le package d'update OSD officiel se compose du osdsys.elf (kernel updater + bootstrap), osd110.elf (update OSD, invoqué après l'update du kernel et le reboot) et osd130.elf (doublon de osd110.elf, pour la 18k).

Donc si le HDD est de taille supérieure à 137 GB, enlevez le HDDOSD. FHDB patchera OSDSYS et vous permettra de booter les ELFs que vous avez installé sur le HDD. Comme l'a indiqué ShaoliAss, le HDDOSD est surtout pour l'esthétique et pour la jouissance d'une fonctionnalité supplémentaire. Mais plus on y installe de trucs, plus ça devient chiant à utiliser. Sans oublier que chaque installation bootable bouffe un minimum de 128 MB. Le HDDOSD/OSDSYS hacké par FHDB offre la possibilité de lancer des ELFs de la même manière que FMCB. C'est simple, rapide, customisable, et sans les maudites restrictions du HDDOSD.

De rien. Ouais. En plus, $ony a réutilisé les mêmes numéros de versions dans le menu. Ouais, c'est toujours dans le dossier "osd100", situé dans la partition "__system" : __system/osd100/FNTOSD __system/osd100/ICOIMAGE __system/osd100/JISUCS __system/osd100/SKBIMAGE __system/osd100/SNDIMAGE __system/osd100/TEXIMAGE __system/osd100/hosdsys.elf Bien veiller à remplacer tous les fichiers et à ne pas intervertir les versions, sinon ça ne marchera pas. Par exemple, le hosdsys.elf 1.10U ne peut pas fonctionner avec le SNDIMAGE du 1.00U...

Me souviens plus. Je viens de survoler les trucs vite fait : 1.00U : Beta. Le timestamp de son IOPRP est 20010618-012804 1.00J : Version prête pour la distribution, basée sur la 1.00U, mais sans les textes Euro/US. Les Japs n'ont pas eu de 1.10, sans doute parce qu'ils ont eu le PSBBN. Le timestamp de son IOPRP est 20010927-134550. Le disque du PSBBN 0.10 Prerelease recèle une version inconnue du HDDOSD que je n'ai pas encore eu le temps de bidouiller. 1.10U : Le timestamp de son IOPRP est 20031216-141644. Les modules ont été mis à jour (libs 22xx -> libs 24xx) et le code a été réaménagé. Truc marrant, l'IOPRP a été compilé dans "hddosd_AE_remocon_progressive" (A = America ? E = Europe ? remocon = Remote Controller ? progressive = Progressive Scan ?). À cette époque, $ony commençait à troller lourdement les hackers et les compagnies sans licence, avec des trucs comme les routines de sabotage sur le lecteur DVD, la mise HS de certaines fonctions de CDVDMAN... Dans un même temps, la ROM de la PS2 a été alourdie par les nouveaux pilotes de la télécommande (IR interne), le mappage de la mémoire a changé, la NVRAM du MechaCon a changé de structure et une partie a été protégée en écriture... puis y'a eu le Progressive Scan aussi. Enfin bref, je pense qu'une màj s'imposait pour les R et les 50k. Les trois fonctionnent de la même façon, y'en a pas un qui a un truc plus innovant que l'autre. J'ai mis les fichiers du 1.00J, du 1.00U et du 1.10U dans le Pastie 8248383 Les fsck ne sont pas inclus, ni le MBR, mais on s'en tape. À coller à la racine de la partition __system une fois que FHDB est installé.

Je confirme que FHDB ne parvient pas à patcher le 1.00J frelaté que contient SUDC3. C'était attendu. Tous les trucs recompressés et/ou réinjectés dans des DVDELFs sont à foutre à la poubelle. FHDB ne pourra pas s'accrocher au stub pour patcher le HDDOSD après son chargement. Bon, j'vais essayer de vous faire un 1.00J de remplacement temporaire (SUDC4 c'est pas pour maintenant)...

Normal. Je suppose que c'est un HDDOSD+PSBBN ? Si oui, alors la séquence de boot est cette du PSBBN (avec le MBR du PSBBN), c'est à dire que le HDDOSD est lancé à partir de __system/p2lboot/osdmain.elf. FHDB et le HDDOSD original bootent sur __system/osd100/hosdsys.elf. Vu que le PSBBN a besoin de son MBR original pour pouvoir se connecter au net et lancer les applis, il n'est pas possible de le remplacer par celui du HDDOSD. C'est pour ça qu'on utilise le MBR du PSBBN pour les mixtures HDDOSD+PSBBN, même quand le HDDOSD est le premier à se lancer. Ça veut aussi dire qu'en installant FHDB sur un HDD qui contient le PSBBN, vous "détruirez" le PSBBN. Edit :

Me voilà soulagé. J'ai testé les versions No Debug de LAUNCHER.ELF et EXECUTE.ELF sur Free HD Boot, ça marche:pouce:. Pas besoin de renommer les ELFs, suffit de copier l'un des 2 à la racine de la partition contenant IMAGE0.VCD. Exemple d'items dans FHDB.CFG : name_OSDSYS_ITEM_6 = Regist. Users Demo 02 (r12 LNC) path1_OSDSYS_ITEM_6 = hdd0:PP.Registered_Users_Demo_02:pfs:/LAUNCHER.ELF name_OSDSYS_ITEM_7 = Regist. Users Demo 02 (r12 EXE) path1_OSDSYS_ITEM_7 = hdd0:PP.Registered_Users_Demo_02:pfs:/EXECUTE.ELF Celui qui s'exécutera le plus rapidement est bien entendu EXECUTE.ELF. Si vous utilisez LAUNCHER.ELF, ne pas oublier de mettre EXECUTE.ELF dans le dossier POPS de la partition __common. Pas testé les versions normales, mais ça devrait aussi marcher. Si vous souhaitez ne pas afficher les icônes des partitions dans le navigateur, créez des partitions avec le préfixe __. au lieu de PP..

Ouais ça marchera surement. J'utilise ce genre de container à chaque fois que j'en ai besoin. Jamais eu de problème pour exécuter uLe là dedans. Au cas où l'ELF de uLe packé ne fonctionnerait pas dans mon container, tu peux aussi essayer de le dépacker, y'a largement la place pour le coller (1792624 octets d'utilisables dans ce container).