Ski-lleR

C'est vraiment moins prise de tête avec une console glitché + dual NAND. Quand je veux jouer à MW3, je passe en on-board nand original avec mon profil xbox live et le dvd original, et pour jouer en offline/xlink je passe sur la cygnos avec un autre profil/kv. (le smc étant reset sur ma rev, no soucy ) Avec un dash alternatif sur USB pour pas que la console flag une brèche de sécurité (on sait jamais vu que les xex ne sont pas signé). Mon kv/profil xbox live reste clean de toute sauvegarde ou succès suspect (qui a dit les custom succès de certains homebrew c'est pas bien? ). En fait tout ce qui n'est pas censé être dans le disque dur interne d'une console non modifié se retrouve sur USB. (homebrew, jeux extraits) Le tout avec un lecteur non flashé évidemment, sinon ça casse tout

Ils ont corrigés le timing attack en remplacant 2 memcmp par des memdiff. Quid de faire la même chose avec le RGH ? Pour le glitch, première étape, faire en sorte que toutes les consoles utilise la même chaine de boot, seconde étape, patché le CB pour qu'il utilise memdiff, si c'est applicable bien sûr. Après même si c'est corrigeable, dans tous les cas, il vaut mieux construire soit même ses nand en dernière version au lieu d'utiliser la mise à jour automatique, pour éviter de se retrouver avec une console fixé.

oui c'est bien l'option 1 Il m'a pas donner de détails encore, perso j'étais sur le booter, mais c'est forcément fait depuis le CD, donc en mémoire et pas "physiquement"

Sa c'est faux, c'était bloqué à cause du mfg, et les infos sur son fonctionnement je les ai pris et décortiqué de la doc de tmbinc (my master comme je l'appel, ses connaissances sont just hallucinantes). Dans ida, j'ai vu un check bizarre juste avant le post 0x4F. Mais apparemment, que le flag soit set ou pas, on entrait quand même dans le cf, mais sa ne l'appliquait pas (d'après stoker). Et effectivement, en retraçant de 0x4F (CF init) jusqu'à 0x52 (CF loading), juste avant l'envoi du post code 0x52, on pouvait lire : lhz r11, 6(r25) soit ou était le mfgflag Un simple xori r11, r11, 1, et voila

Autant que je sache, freeboot avait des patch pour le 1bl, donc c'est pas nouveau, mais c'était un rebooter. L'idée c'est d'avoir un meilleur contrôle, genre enlever le check sur le cb, et patcher l'instruction du CB qui fait passer la console en mfg, au lieu que le CB mette le flag, et qu'on le change depuis le CD. Autant attaquer à la source

Mais il y a en plus qu'ils ont investi rgloader pour parler que de ggbuild, et essaie de forcer l’arrêt du travail (genre t'est talentueux tydye, stoker aussi, mais arrêter de divulguer des infos, ont est intéressé par vous,on vous contactera si vous respecter notre volonté). Laissons simplement chacun faire à sa sauce sans drame. J'ai appris plus en 2 semaines sur rgloader et la 360 que toutes les infos que j'ai pu avoir sur freeboot et xbh. De plus, tydye boss en parallèle sur la réinitialisation du boot, autrement dit il recommence au 1bl, avec possibilité de le patché (en gros, contrôle total du bootloader, et donc du système). Il a réussi, reste à paufiner.

mdr, juste apres que stoker25 ai cracké le kernel (dans la nuit). Copie du boulot, ou alors ils voulaient les honneurs pour eux? Quel vendu, les chèvres de gligli, stoker a réussi, ils ont sorti cash leur loader

oui, en tout cas l’étape difficile a été passé. Et le projet c'est surtout lancer un kernel modifié en ne faisant que discuter et partager ses idées, connaissance, en gros pas de master hacker qui se cache / garde tout. Très instructif edit: xex non signé, contenu telechargable, c'est bon ! kernel hacké! Le script : pastebin.com/zJ18gMv9 Le CD patché (xex, xbla, region check): http://stoker25.com/360/cd.8453.RGL-1.0beta2.bin Zephyr/Falcon/Jasper Version beta et réservé au habitué du buld,py, venez rapporter vos résultat sur rgloader Version slim en travaux

Pour expliquer, le smc de gligli est modifié pour redémarrer en boucle jusqu’à réussite de l'attaque. Comme on est en zero-paired, le CB défini le flag mfg, qui fait que quand le cd le vérifie, au lieu d'extraire la nand de base (CE 1888) et lui appliqué le CF/CG (pour etre en 13599), se contente d'extraire le CE, et lancé le kernel, qui voyant le flag defini, boot en mfg (manufacturing), donc plantage. (et de toute facon en 1888 c'est useless) Dans le cd, une fonction maison est appelé, pour remettre le flag à zéro, du coup, sa boot Le rotsumsha n'a pas été patché, car ils ne vont pas utilisé le delta patching du cf/cg, c'est le moteur de patch maison qui va faire le job (patch xex, disque dur) une fois le cf/cg appliqué On peut se dire pourquoi ne pas avoir patché directement le kernel (ce) pour ne pas tenir compte du flag, simplement car le 1bl check le 2bl, qui check le 4bl, qui check le 5bl (ce) / 6bl(cf), cf qui check le 7bl (cg). Le 1bl/2bl étant non modifiable, il restait de passer par un patch en mémoire grâce au cd

Sa y est c'est fait, ya plus qu'a patcher pour les xex non signé, les disque dur ... comme freeboot,mais sinon c'est bon, le dash se lance avec le moteur de patch et le smc modifié (le flag du mode mfg a été trouvé et patché). Sachant que freeboot fournis ses patch, et qu'ils les ont déjà extrait, hacked kernel soon

C'est bel et bien actif. Perso j'en étais à remettre le flag du mode MFG à 0. Quand j'ai demandé ou ils en étaient (stocker et 2/3 autres), ont m'a dit qu’apparemment ils auraient trouvé. Mais je suis pas sur, car il y a actuellement 8 CD de test portant l’appellation MFG, et 3 autres

Perso... MFR : 31-05-2011 Type: Slim Mat Hana : Présent au même endroid qu'avant (donc carte mère trinity j'imagine) N° lot: 1123X Pack: 4 Gb Standard Chez mister bon affaire

C'est bien tout est utile dans leur produit Avec le ck3i il update le nand-x, et avec le nand-x leur coolrunner (no, it's not catch'em all, it's buy'em all )

Après, Microsoft a peu être fait d'autre modification, car l'unification n'est pas anodine (nouvelle carte mère inside). J'ai reçu ma slim mate, mais j'ai pas encore fait les montages. Quand ce sera fait, on pourra déjà voir avec le dump s'il y a eu des modifications de CB/CD/CF/CG Après si vraiment sa fout en l'air le glitch, sa pique! surtout pour mon développement...

Le Gboot était un fake, il était annoncé alors que rien. Pour le RG Loader c'est autre chose. Un mec (stoker25) travail dessus depuis quelques temps. Les interventions de TheFallen ne sont pas roses, mais dans la scène 360 c'est souvent comme sa que sa se passe. Et malgré ses propos parfois dur, il fournit des informations importantes à la modification/lancement d'un kernel modifié. Genre défois TheFallen dit à stoker25 : t'étais sur la bonne voie, la plus logique, et là tu vire complet, pourquoi ? et stocker répond: bah à ta manière je bloque sur tel ou tel truc, donc je fais autrement. stoker25 n'a pas forcément le niveau de certain "maitre" de la scène 360 (xbh la plupart), mais il se donne vraiment du mal/s’investit dans ce qu'il fait (regarder le changelog de leur wiki, c'est assez parlant!). Et un petit groupe d'utilisateur contribue à faire des tests, d'autre réfléchisse/réagisse au pourquoi sa marche pas quand il y a tel ou tel modification faite dans leur patch, ou suivant la structure du build_rgloader.py Si vous voulez appeler un fake un projet dont les élitistes rigoles, ok, libre à vous, mais le projet et tout ce qu'il y a de plus sérieux, c'est juste que sa ne "tombe pas du ciel" car les mecs sont moins calés. Au moins, ils partagent leur savoir, leur découverte, leur avancé, et sa, sa fait plaisir Y'a qu'à voir comment le wiki se remplis, une mine d'or pour celui qui souhaite travailler sur le lancement d'un kernel modifié. Et au final, je préfère personnellement le projet qui met 3 mois à aboutir, mais dont je tire quelques choses (autant au niveau éducatif, que pour reprendre le travail, si un jour le mec arrête, y'a tout le travail disponible en ligne), que le projet qui sort en 1 mois, mais dont personne ne sait rien, à part qu'on a un programme exe qui construit la nand si on lui fournis certains éléments de notre nand.

Pas une "team" en particulier, mais plutôt 1 ou 2 mec calés en désassemblage et ayant une bonne connaissance de la xbox 360 (pour ça c'est pas dur, sur xbh + freeboot y'a tout le nécessaire). Ensuite ça a déjà été dit, GliGli a release l'exploit à des fins "légale". Pouvoir développer en toute liberté pour sa console ne devrait quand même pas être un si gros luxe! Et il encourage le développement avec libxenon, ce que beaucoup respect, pour le moment. "et puis plus rien..." non pas plus rien, il y a ceux qui boss dessus dans l'ombre, et ceux qui boss dessus au grand jour, comme un mec sur xbh (stoker). Suis le fil, fait des recherches, sa ne stagne pas. Il y a aussi un channel irc pour en parler. Le nécessaire à faire est connu, il faut savoir l'appliquer, c'est tout Hall of fame c'est le mot magique, patience edit: Free60 est une mine pour les infos techniques aussi

C'est pas mal en tout cas, car je voulais absolument une double nand pour pouvoir jouer sur le live, et à coté profiter des émulateurs et de pouvoir développer sur libxenon sans avoir à reflasher sans arrêt. (une slim ça m'a couté 150e c'est déjà beaucoup...)

Du coup de cette manière c'est safe pour le CPU, car le glitch se déroule de manière normal et le post est valide du premier coup. Y'a juste un pulse inutile à la limite. Comme Razkar a bien étudié la question, un petit retour la dessus ?

Et voila, le dual nand Xell/Glitch est en route (si c'est réel, mais le mec annonce posté les détails bientôt) : C'est fait avec la Cygnos, mais y'a d'autre méthode (Xd card par exemple). Pour ceux qui veulent faire une console homebrew/multimédia/backup offline d'un coté, et jeux online avec originaux de l'autre avec un lecteur non flashé. Par contre j'ai pas bien lu le sujet, mais le mec à surement faire en sorte que le glitch soit désactivé pour booter sur la nand officiel quand il switch, car dans la vidéo, on le voit jouer sur le dash officiel, switcher de nand sur la cygnos et booter sur Xell Edit: remarque si c'est la nand officiel pas besoin de désactiver le glitch. Dans tous les cas la nand est valide, donc ça boot. A la limite même si y'a une impulsion (la première), après le retour à la fréquence normal le CPU ne renverra pas F2 car tout les hash check passent d'office.

Oui, C/C++ Mes consoles sont toutes HS, donc pas de date de sortie. Mais bon, beaucoup risque de ne pas utiliser IngeniouX Reloaded, mon idée étant (je sais pas si tu as lu/compris mon explication sur un des sujets dans News) de développer le dash sur libxenon, car j'ai plus d'expérience de cette manière (quitte à devoir réinventer la roue (comme m'avais répondu quelqu'un) pour mettre au point un système d'interface graphique par exemple). J'avancerais bien plus vite sur ma roadmap, et ce sera plus agréable. Le gros hic, c'est que depuis libxenon, c'est un petit défis technique pour pouvoir lancer des Xex, mais j'ai mon idée, j'attend juste ma console pour appliquer/tester (mais un reboot/patch sur autre que Xell c'est possible depuis la même nand). Si ça n'aboutit pas (que je ne trouve pas le moyen de reboot la console et lui forcer le lancement d'un Xex), le développement reprendra sur le SDK officiel dans tous les cas, même si je l'éviterais au maximum au départ. Dernier point, Microsoft a amputé quelques fonctions bien utiles de DirectX, qui ne facilité pas le portage/développement, même si ça ne l'empêche pas car une même action peut se faire de 1000 façon différente en programmation, mais c'est quand même gênant. L'avantage sur libxenon, c'est OpenGL

A la base le nom c'est mupen64, pas muppen64. Sinon super boulot, voila une belle preuve des capacités de libxenon Je sais pas si je l'ai déjà dit, mais c'est plus facile de porter les lib avec libxenon, car on compile avec gcc, et ça, c'est pas rien, car sur linux, c'est pas ce qui manque les lib!!! La plupart des programmes open source utilise des lib open source (logique), donc dans 99% des cas (pour les émulateurs), ça tournera avec SDL, OpenGL etc...qui sont très bien connu des programmeurs en général, et qui se compile plus facilement avec un GCC Peut être que sa demande plus de boulot pour les interfaces, car il faut dire ce qui est, Xui, c'est une perle en son genre. Mais pour le côté performance, avec une lib de base bien foutu (que devient libxenon), je préfère de très loin bossé avec OpenGL (et surement reste des mes affinités avec le matériel, qui a dit le C y'a rien de mieux? ). Encore une fois, bravo pour le taf! Sur xbox1, il y avait un émulateur qui employait le core de 3 des émulateur les plus connu (1964, Project64 et le défunt mais mythique UltraHLE). Sa donne des idées pour la suite. Bien que pour Pj64 c'était basé sur les vieilles mais seul source 1.2, depuis c'est closed (et c'est dommage, car Pj64, c'est juste une bombe niveau compatibilité, certes lourd, mais on a une 360 entre les mains ) Enfin tout ça pour dire les incompatibilités c'est normal, mupen64 est ultra portable, mais le core est bien moins compatible contrairement à ses "concurrents". Et apparemment, dernière mise à jour officiel des sources en 2005 J'espère de tout cœur que libxenon ne sera pas abandonné une nouvelle fois, car c'est un projet que je défend et auquel j'adhère.

Dans les commentaires sur le blog de Gligi, on peut lire : Razkar > Lost source (je le referais rapidement quand j'aurais ma console, comme ça y'aura une petite contribution en plus pour aider les nouveaux sur libxenon)

Déjà pour le sdk, il faut attendre que les leaks soit leaké, et rien que ça, c'est agaçant. Les mecs l'ont, mais ne veulent pas le donner (la dernière version officiellement releasé: 7641 ou un truc du genre, alors qu'il y a la version 12xxx) Détrompe toi, c'est très simple de faire autant avec libxenon qu'avec n'importe quoi d'autre. Il est facile d'utiliser les lib en tout genre (sdl par exemple) sur 360. A l'heure actuel, avec le sdk, tu as les fonctions de directx, les fonctions d'interface (xui), et tout le reste (accès fichier etc...) Sur libxenon, y'a OpenGL (bien mieux, personnellement je suis plus à l'aise dessus), avec la SDL, il est facile d'utiliser des systèmes d'interface genre CEGUI (encore que from scratch c'est pas dur), encore plus facile de compiler des lib open source (avec mingw, c'est la porte ouvert au lib audio, vidéo, réseau, etc...). Avec le sdk Microsoft et Visual Studio, c'est moins simple de les compiler toutes ces lib. "seulement des homebrews, ou seulement des jeux officiels," je parle d'allier les 2 justement. Avec libxenon, le champ est plus libre. On peut si on veut rajouter le support d'un périphérique usb en particulier, sa marchera sans broncher. Avec le sdk officiel, sa ne risque pas d'arriver. Après c'est une philosophie, si j'obtiens les infos nécessaire, je partirais sur libxenon, autrement ce sera le sdk mais avec moins de motivation. Puis, y'a FSD, alors ceux qui veulent pas chambouler leur habitude n'ont pas besoin de le faire. C'est aussi un choix par rapport au habitude de coding. J'ai passé ma vie sur linux, du coup, avalé du DirectX et des fonctions Windows sa a du mal à passer. Je pense produire plus et de meilleur qualité avec quelque chose que je connais déjà.

Dash alternatif pour moi oui, mais j'aimerais qu'il soit compilé avec libxenon (.elf), donc légal à 100%, tout en ayant la possibilité de lancer un jeu en redémarrant la console sur le dash officiel ou un truc du genre.

L'idéal, serait de concentre les efforts sur le développement avec libxenon, pour tout ce qui est émulateur, homebrew (mplayer pour les films par exemple). Pour le lancement de jeux c'est différent, il faut les library qui vont avec, donc oublier le lancement de jeu depuis libxenon (techniquement possible, difficilement réalisable). Mais laisser le dash officiel s'occuper de ça, avec des raccourcis quickboot. Et encore que, imaginons dashlaunch installé (ou un programme du genre) : - Je boot sur libxenon - qui lance un programme genre menu alternatif, qui liste les xex d'un dossier (fsd, ingenioux like) - On choisi le jeu, il modifie le fichier dashlaunch.ini pour booter sur ce xex au lancement du dash officiel - et on reboot sur le dash officiel, qui lance automatiquement le jeu, car dashlaunch pointe dessus Sa me ferais passer la 4ème pour développer sur 360, car en tant que développeur, on pourrait faire en toute légalité, tout en ayant la possibilité de lancer ses jeux favoris, sans avoir à switcher de CD. L'idée du dash tout intégrer remplaçant le dash officiel, et codé avec le sdk, bof bof. Je suis bien du coté de GliGli pour ça, comme je l'étais avec tmbinc à l'époque (qui à dit j'ai perdu les sources de Pong? ). Évidemment IngeniouX premier du nom était fait avec le sdk, mais c'est la demande qui provoque ça, c'est soit on release car ces tout ce qui intéresse les gens, soit non et à ce moment là on passe pour le radin qui partage rien. Pour le moment j'ai pas encore ma console, mais quand je l'aurais, je travaillerais aussi sur tout ça, jtag, glitch, rebooter etc... IngeniouX Reloaded sur libxenon, je l'espère