fornorst

pour moi, le débit est normal. Et ma 360 se trouve à une dizaine de mètres de la LiveBox (avec un mur entre les deux)

pas au jeu : il fonctionne sans problème chez moi. je l'ai fini et n'ai constaté aucune baisse de framerate (sauf quand l'effet blur se déclenche mais c'est voulu et ce n'est pas considéré comme une baisse de framerate)

Félicitations sliders58 ! Je ne pensais pas que ça marcherait et j'ai eu complètement tort. Aussi je m'excuse de mon empressement. Pour la création du fichier .xex, il faudrait voir si un exécutable simple de Xbox1 pourrait être recompilé pour la 360. Mais ceci obligerait à disposer d'un kit de développement (uniquement logiciel) ce qui reste illégal à l'heure actuelle. En supposant que l'on arrive à obtenir ce fichier .xex, il me parait envisageable de récupérer la position d'un fichier xex dans une iso puis de le remplacer bite à bit par le nouveau fichier xex. je regarderai les sources du logiciel de Gael ce soir pour voir la faisabilité de la chose. Faudrait aussi voir sur le forum si on aurait pas un expert en fichier ISO (quand je dis expert, je parle de quelqu'un qui a déjà développé un exreacteur d'iso, pas quelqu'un qui sait les graver...)

Faux pour la Xbox1 (ou alors très très mal dit) : si c'était le cas, aucune méthode sans puce ne marcherait. Lors que tu es sous un dash et que tu lances un exécutable (jeu ou homebrew), si la console reboot et que tu utilises un exploit alors ton exploitdevrait diaparaitre, ce qui n'est pas le cas. L'explications est grossière mais le principe est là. Mais peut-être voulais-tu dire que c'était la lecture du DVD qui était relancée...

la 3ème solution à l'air pas mal :-D Tant pis pour legueux ;-)

amusez vous bien alors... je vois même plus quoi dire maintenant que tu reprends mes arguments à ton compte pour me dire que j'ai tort ("les resultat de test qui on etait fait sur la xbox 1 ne sont pas bligatoirement les meme sur la 360"). Un incice : le composant retiré par certains membres d'Xbox-Scene et qui n'est présent que sur certaines consoles n'est pas contrôlé par l'hyperviseur car in ne représente pas un point sensible pour le système. Idem pour l'absence de lecteur DVD. En tout cas, bonne chance dans vos tests.

lol completement n'importe quoi ça a mis 6 ou 7 mois mais certainement pas 1 mois ! Dans mes souvenirs les premiers isos sont arrivés relativement vite (à peu près aussi vite que sur 360) et les puces sont arrivées très peu de temps après la sortie européenne, ce qui fait environ 6 mois après la sortie US. Si mes souvenirs sont bons bien sûr.

De mémoire la majorité des homebrew, dont XBMP/XBMC, ont un code région non défini correspondant au code région international. Il pourrait être intéressant de recompiler une application avec un code région PAL pour faire un test là dessus. Néanmoins, cette manoeuvre équivaudrait à celle consistant à tester un jeu Xbox PAL gravé sur une Xbox360 PAL. Ce qui a déjà été testé sans succès.

Et vous avez appris quoi de réellement concret ? J'ai lu les 18 pages du topic et je n'ai rien vu de nouveau (si ce n'est la pseudo méthode de knyx pour aller, via le Media Center, explorer le DD. M2thode qui n'a jamais marché pour personne soit dit en passant) par rapport à ce qu'on savait déjà ou avait deviné avant même la sortie de la 360. Comment on aurait su qu'il était signé ? Du moment que Microsoft permet de démarrer un exécutable sur un CD que tout un chacun peut graver et sans accès au net (on aurait alors pu voir une méthode à la Steam avec demande d'activation à un serveur lors du lancement dudit exécutable), la protection sur cet exécutable ne peut pas se trouver ailleurs que sur l'exécutable lui même. Et dans ce genre de situation, pour éviter qu'un exxécutable soit modifier, le mieux est de calculer une clé qui est fonction, d'au moins le CRC du fichier et d'une clé de signature unique à MS (en gros : clé publique = f(CRC, clé privée)). Le seul point obscur est le type d'algorithme utilisé pour créer cette clé (et bien évidemment l'algorithme en lui même ). Mais ce topic n'a pas fourni de preuve tangible qu'il s'agisse d'une signature RSA. C'est ce qui parait le plus probable mais rien ne le prouve clairement. Quant à savoir qui valide la signature, je suis convaincu que c'est l'hyperviseur lui même. Je suis convaincu qu'il existe deux niveaux de protections pour les jeux originaux : . une clé pressée sur le DVD (et non non reproductible par nos simples graveurs) qui est fonction de la taille du DVD ou du CRC de la TOC, ... ainsi que d'une clé privée. Celà permet d'avoir la même clé pour chaque exemplaire d'un jeu mais une clé différente entre deux jeux. Le lecteur DVD ne renvoie alors que les informations du DVD (taille du DVD, CRC de la TOC, ....) et la clé pressée. C'est alors l'hyperviseur qui se charge de vérifier la validité de la clé. . une clé associée à l'exécutable, calculée suivant le principe évoquée ci-dessus et elle aussi validée par le superviseur après lecture des informations du default.xex. Pourquoi je pense que c'est l'hyperviseur qui fait ça ? . l'intelligence de la validation / non validation d'un media n'a pas à se trouver dans le lecteur DVD. Celui ci est un bête composant qui retourne ce qu'on lui demande sans chercher à mettre plus d'intelligence qu'il n'en faut dans sa tâche. C'est là un grand principe de la programmation par objet. . le simple fait de modifier le firmware DVD invaliderait tout le travail fait le superviseur en lui passant une information erronée. 2 ans de boulot sur un hyperviseur pour laisser les gens modifier tranquillement le firmware du lecteur DVD et s'en tirer à bon compte ? Je pense pas que Microsoft ait fait cette erreur. En passant, j'ai de très gros doute sur le fait que l'on puisse flasher un firmware modifié sur le lecteur DVD. L'hyperviseur connait le modèle du lecteur DVD et sait parfaitement ce qu'il doit y avoir dans le firmware. Il y a donc de grandes chances que l'hyperviseur refuse de laisser démarre la console si il arrive à voir que le firmware du lecteur DVD a été modifié (encore faut-il qu'il ait accès à cette information, ce qui n'est pas forcément sûr) . c'est tout simplement le rôel pour lequel il a été conçu : valider un contexte d'utilisation. donc toi tu atack directement l'hyperviseur ! admeton que devan toi il y est un bouclié qui block toute attack. ba toi tu frape dedans c'est sa ? toute idéé peu etre mené en ridicule .mais pourtan se que tu dit est tou sauf idiot ! mais avan d'en arrivé la il nou faut des basses ! T'as pas faux là dedans : je propose une idée (plutôt pertinente il me semble bien que difficilement réalisable) sans proposer de mode opératoire pour la réaliser. Je ne vais pas essayer de me cacher derrière le fait que beaucoupd e gens sur ce topic l'ont fait avant moi : non ! Je dis simplement que j'ai pas les compétences pour imaginer une méthode pour réaliser celà. Je suis au même niveau qu'un directeur de département demande un outil à son département informatique dont il donne la description mais n'a aucune idée de comment réaliser celà. Cette situation arrive tous les jours. On sait ce qu'on veut mais on n'a pas les compétences pour le réaliser soi même. Quant à ta métaphore du bouclier, je te rappellerai bien qu'à l'image de l'hyperviseur sur la 360, le bios de la Xbox centralisait la majorité des méthodes de sécurisation de Microsoft. Et c'est principalement ce centre de sécurité qui a été le premier attaqué et c'est aussi le seul par lequel on est arrivé à faire quelquechose sur Xbox. Idem pour la majorité des virus qui, avant de faire quoi que ce soit, font leur possible pour désactiver ton centre de sécurité (antivirus, antispyware, parefeu). Tous ces exemples ne sont pas des hasards : quand tu veux attaquer un système ou le détourner de son usage premier, tu fais ton possible pour désactiver les sécurités avant de commencer à mettre en place ton contexte d'utilisation. Biaiser les systèmes de sécurité est bien plus fastidieux que de les éteindre Piur l'instant je ne propose que de les biaiser : je n'ai pas idée de comment éteindre ce satané hyperviseur. Peut-etre via une puce à brancher sur le processeur...

Là où je vois la "faille" (le mot semble couru ici) c'est dans l'hyperviseur. J'ai décrit celà plus haut en expliquant qu'il parait concevable de ne lui passer que des informations "valides". Développer un tel outil (logiciel et matériel) dépasse mes compétences au niveau matériel et très probablement logiciel (je suis bien plus habitué à développer en Java, bash, C, ... qu'en ASM). L'idée est là et me semble être une pierre ajoutée à l'édifice. knyx : par définition, tout émulateur est un logiciel. Et contrairement aux idées reçues, tout logiciel n'a pas de faille. Si le démarrage ne suit que l'algorithme (très simplifié pour ne rentrer que dans le cas de l'insertion d'un jeu Xbox signé ou d'un default.xex gravé mais signé (mise à jour de l'émulateur par exemple)) suivant : . démarrage des systèmes. lecture du disque . lecture du type de disque . si jeux . vérifier génération du jeu (Xbox1 ou Xbox360) . si jeux Xbox . vérifier signature . si signatureOK . lancer émulateur . sinon si disque de donnée . vérifier présence d'un default.xex . si présenceOK et default.xex signé . lancer default.xex alors je ne vois pas où trouver une faille. La vois-tu ? Sachant que l'émulateur ne fait que transformer à la volée une instruction compilée pour le jeu d'instruction x86/Nvidia vers une instruction pour le jeu d'instruction IBM/ATI (je ne connais aps l'architecture du processeur IBM : surement pas du x86 déjà). Sachant de plus que tout instruction entrainant une perte de stabilité du système est refusée par l'hyperviseur et empêche tout type de buffer overflow par exemple. Pour info, as-tu lu les spécifications des exploits de type font qui créent un bufferoverflow au moment de leur chargement ? Essaie donc de les lire si tu arrives à les retrouver et explique comment la Xbox360, qui a surement tenu compte des erreurs du passé, a bien pu laisser passer une faille moins complexe à détecter ? Car ce que tu (vous) proposes n'est strictement rien au niveau complexité en comparaison de l'exploit des fonts. sliders58 : où as-tu vu que l'émulateur a été fait à la va vite ? Ce n'est pas parce que Microsoft a annoncé sa disponibilité tardivement qu'il a été développé en une semaine ! Il est plus que probable que cet émulateur ait commencé à être développé dès le début du processus de développement de la 360 mais, que pour des raisons tant marketing que techniques (pourquoi s'embêter à mettr une protection de haut niveau si c'est pour mettre un émulateur véritable gruyère remplis de trous de sécurité), Microsoft n'ait décidé que tardivement d'officialiser la présence de cet émulateur. Moi je dirais plutôt que cet émulateur ne représente que très peu de risque pour Microsoft du point de vue de la sécurité. Comrpenez moi bien, je ne dis pas que vos tests ne servent à rien mais vous ne semblez pas prendre en compte le niveau de complexité nécessaire à la détectione t à l'exploitation de failles sur un tel système. Il me paraitrait bien plus intéressant par exemple que knyx nous explique de façon détaillée ce qu'il souhaitait faire avec son Media Center mais qui parait classé "Secret Défense" à l'entendre parler (comment ça, ça me rappelle les chinois du FBI qui poursuivaient Yoshihiro ? ) ou que quiconque nous ponde des tutoriaux sur la façon de connecter facilement un Media Center, un DD externe, un routeur, ... à la 360. Il me parait bien plus probable que nous découvrions des choses intéressantes (notez que je ne parle pas de failles : ce n'est certainement pas par là qu'il faudrait chercher) par ce biais que par des tests tous aussi folkloriques les uns que les autres et sans le moindre fondement logique. Maintenant, vous pouvez estimer que je n'apporte pas ma pierre à l'édifice mais je pense avoir déjà rpouvé sur la scène Xbox française et sur gueux en particulier que je n'étais pas le dernier à venir donner un coup de main, à passer des heures à écrire un tutorial, à faire une traduction pour mettre à portée de tout un chacun des informations réservées aux seuls anglophones, ...

Bon, mon dernier post déviant sur ce topic : Je ne pense jamais avoir traité quelqu'un de mytho que ce soit sur ce topic ou sur tout le forum gueux. Je n'affirme que deux choses : . faire des tests dont on connait le résultat à l'avance n'a aucun sens dans la démarche de hack d'une console, quelle qu'elle soit. . la (ou les) méthode(s) de hack sur la 360 seront d'un bien plus haut niveau que celles sur la Xbox. Donc les techniques : je grave un CD avec un xbe non signé, je renomme un .xex en .xbe, je renomme un .avi (qui, soit dit en passant n'est qu'un conteneur et en rien un indicateur comme quoi le codec utilisé est du Divx, quelque soit sa version...) en .mp3 et j'entendrai au moins le son, ... n'ont strictement aucune chance d'aboutir. Celà ne marchait déjà pas avec la Xbox première du nom qui avait un niveau de protection plus que médiocre. Alors avec une console qui atteint des sommets dans la sécurité, je n'en parle même pas. Maintenant si des gens ont envie de faire de tels test, grand bien leur en fasse. Mais évitez d'arriver, de lancer une idée complètement irréalisable (les gens se reconnaitront) et de demander aux gens d'essayer. Ca frise le ridicule. Je continuerai à lire ce topic ainsi que ses alter ego sur d'autres forums en ne postant que pour apporter ma pierre à l'édifice, comme chacun d'entre nous devrait faire. Encore désolé pour ce hors sujet mais remettre les pendules à l'heure n'a jamais fait de mal à personne.

10 ans que tu est à fond sur les PC, que tu les connais de "A à Z" et tu continues à dire que des tests dont on connait le réultat avant de les lancer ont le moindre intérêt ? C'est le cas dans un contexte d'évolution d'un composant logiciel ou matériel dans le cadre de tests de régression mais il n'est absolument pas question de tests de régression dans le cas de la Xbox360 !

Déjà je n'ai aucune envie d'ouvrir ma 360 pour faire ce genre de test : je tiens trop à mon lecteur DVD n'étant pas un grand manuel Et puis même si tu arrivais à lancer un exécutable Xbox (chose à mon avis très très peu probable), ceci aurait quoi comme utilité ? Lire le contenu du DD ? Chose impossible car les systèmes de fichiers sont différents. Au mieux, tu pourrais lire les 8Go alloués à la reproduction du DD Xbox1. Or la structure du DD Xbox1 est plus que largement connu et n'apporterai rien. Lancer un serveur FTP ? Idem que précédemment : la structure de fichiers de la 360 n'a rien de comparable à celle de la Xbox1. Le serveur FTP ne pourrait te donner, au mieux et c'est très peu probable, un accès aux partitions de la Xbox1. A ce moment là, tu pourrais penser à copier une sauvegarde hackée de 007, Splinter Cell ou Mechassault en espérant que le lancement du jeu original puis de cette sauvegarde te donnerait les mêmes effets que sur Xbox 1. Et là encore tu te tromperais : le bufferOverflow créé par cette sauvegarde serait intercepté par l'hyperviseur (et non superviseur : je me suis trompé de terminologie, désolé) et serait bloqué. Pour conclure : non seulement cette méthode n'a que très peu de chance de réussir mais, même dans le cas où elle réussirait, ne serait que très peu d'utilité. Voilà donc les multiples raisons pour lesquelles je ne la tenterai pas Un indice quand même pour le cas où tu voudrais vraiment tester et résoudre ton problème de TOC incorrecte : il te faut découvrir l'emplacement, au bit près, du début du default.xbe que tu veux supprimer dans ton ISO. Une fois fait, et supposant que le default.xbe que tu veux injecter fait n bits, il te faut remplacer les n premiers bits du default.xbe d'origine par ceux de ton propre default.xbe. Ca me semble être la seule solution et je n'ai pas les compétences pour t'assurer que celà fonctionne. Il faudrait pour celà savoir quels sont les premiers bits appelés lors du lancement d'un default.xbe

Information diffusée sur Xbox-Scene puis sur Gueux il y a déjà quelques temps. Il ne regarde pas ce que fait le programme "à l'intérieur" (la notion de "intérieur" pour du code exécutable reste très vague...) mais regarde l'état du contexte du système. Or ton contexte a changé : le DVD à l'intérieur du lecteur n'est plus le même. Le seul fait de modifier un bit de l'iso que fournit Microsoft pour la mise à jour de l'émulateur invalide cette mise à jour. Tu ne peux donc pas modifier cet ISO. Comprends bien que si tu pouvais modifier cette mise à jour et la resigner avec une clé valide, tu pourrais en faire de même avec n'importe quel contenu : homebrew, backups, .... Si c'était si simple, la 360 offrirait déjà ce que la Xbox n'a offert que de longs mois après sa sortie. De plus, analyser cette mise à jour reviendrait à décompiler du code exécutable pour en ressortir du code source. Je ne pense pas que tu ais déjà fait un truc comme ça mais le résultat est tout sauf trivial à lire. Déjà qu'avec de la décompilation du ByteCode Java, tu n'as pas des résultats extraordinaires, avec du C, je ne t'explique même pas... Dernier point : si c'est une idée en vrac, vérifies d'abord sa cohérence avant de la soumettre. Ca évitera de polluer ce topic et d'embrouiller l'esprit des gens

Pourquoi ça ne marchera pas : . le default.xex est compilé en utilisant le jeu d'instruction propre au système de la 360 (CPU et GPU). . la Xbox360 et la Xbox ne partagent pas le meme jeu d'instruction (mais alors pas du tout !!) . la puissance nécessaire à l'exécution d'un fichier xex est largement hors de portée de la Xbox (hormis pour la mise à jour de l'émulateur mais bon...) En gros, imagine que tu es en train de renommer un exécutable mac en exécutable Windows en espérant le faire tourner sous Windows... Explications sur la connectivité Xbox360 - Media Center . pour ce qui est de la lecture de fichiers multimédias en streaming, c'est le fichier qui est envoyé en streaming à la 360. C'est la 360 qui se charge de le décoder. Donc si la 360 n'a pas de codec pour le Divx alors tu ne pourras pas lire ce type de fichier. . pour ce qui est de la lecture des futures évolutions du WMV (WMV11 en tête), la console sera incapable de le faire sans une mise à jour du lecteur multimédia (en particulier un ajout de codec) étant donné qu'elle n'intègre pas ce codec actuellement (ce qui est normal vu que ce codec n'existe pas encore) . pour ce qui est de l'exécution d'applications du MediaCenter sur la télé en passant par la Xbox360, c'est un flux vidéo qui est streamé. La 360 n'a qu'à décoder le flux vidéo. Pour les raisons vues précédemment (incompatibilité du code exécutable à cause des jeux d'instructions différents), il n'est pas possible que la 360 exécute du code écrit et compilé pour un couple x86/Windows Explications sur l'émulateur : . sur la mise à jour de l'émulateur. Il semblerait que Microsoft installe une base pour l'émulateur et que les mises à jour que l'on fait se rapprochent plus de l'ajout de fichiers de configuration propres à chaque jeux qu'à une véritable mise à jour. C'est ce qui permet de mettre facilement à jour avec la version de décembre sans avoir besoin de la mise à jour de novembre et sans nécessiter que la mise à jour de décembre inclue celle de novembre. Si vous mettez la mise à jour de décembre, il y a fort à parier que vous n'ayez pas celle de novembre (à vérifier mais le principe resterait même si la mise à jour de décembre est cumulative). . sur le contenu de l'émulateur : si Microsoft est malin (et les dizaines d'ingénieurs qui ont planché sur le sujet le sont forcément) alors ils n'ont pas émulé les instructions nécessaires au parcours des répertoires. D'origine, ces instructions étaient uniquement utiles au dashboard Microsoft. Le dashboard de la Xbox n'ayant pas à être émulé par la 360, ces instructions sont inutiles. Or ces instructions sont la base des dashboards modifiés de la Xbox. Donc adieu au parcours de l'arborescence des 8Go réservés à l'émulation via un dashboard "classic" tournant, via émulation, sur la 360. Explications diverses : . sur la première "technique" de knyx pour lancer des backups : ne pas oublier qu'à chaque reset, la console remet en place un contexte initial. Il n'y a pas de "restes" de la session d'utilisation précédente. C'est une des bases de ce genre de programmation : si vous devez gérer les "restes" des sessiosn précédentes, le processus de gestion devient très vite très complexe. Sur un PC (et à fortirori un serveur), cette prise en compte de l'existant est plus que nécessaire, sur une console elle est complètement superflue. . sur le disque dur : le fait que les DD soient interchangeables de console en console laisse trois possibilités. La première est que le DD est locké avec un code commun à toutes les consoles. La présence de ce code permet de vérifier que le DD est bien un DD de 360. Pour être plus précis, il est très probable (si c'est cette première voie qui a été choisie) que ce code soit généré en fonction de la taille du DD (ce qui empêcherait fortement de mettre un DD de plus grande capacité, non vendue par Microsoft dans la 360). Deuxième solution, le DD n'est pas lockée et Microsoft ne pense pas que la DD soit un point sensible de la 360 et nous laissera alors le parcourir (le système de fichiers est certes propriétaire mais sera forcément dans un laps de temps plus ou moins long lisible via Linux : le projet free360 en est la preuve). Les sécurités de bases (fichiers cryptés, ...) ont probablement été incorporées histoire de nous faire perdre du temps mais ne sont qu'un obstacle largement surmontable. Troisième et dernière solution : Microsoft a vraiment envie de nous embêter et a combiné les deux premières solutions. Et c'est cette solution que je privilégie. Mon avis perso : . l'objectif de Microsoft n'est pas de fournir une console inviolable : ce n'est pas humainement et finacièrement possible (le coût de développement d'un tel système serait bien trop exhorbitant). Leur objectif est tout simplement de laisser la console inviolée le plus longtemps possible. A ce jeu, c'est Nintendo qui a gagné avec la précédente génération. Ce sont eux qui ont développé la console qui a mis le plus de temps à être modifiable. Elle ne l'est réellement que depuis quelques mois en réalité (les techniques avec PSO et le Broadband Adapter n'ont jamais été à portée de monsieur tout le monde). . le point fort de la protection de la 360 est le superviseur intégré dans le processeur et qui vérifie en permanence la cohérence du système (kernel, lecteur DVD, ...). Pour le tromper deux solutions sont possibles. La première parait la plus simple : le désactiver. Mais quand on y réfléchit de plus près, ça se complique... Mettre une puce dans le processeur ? Je suis pas convaincu Lancer un exploit pour désactiver le superviseur ? Nécessiterait que le superviseur soit déjà désacivée pour réussir un buffer overflow : on se mord donc la queue... Seconde solution : controler les entrées du processeur (en particulier du superviseur) pour ne laisser filtrer que des informations valides et ainsi lui faire croire que tout est cohérent. Ca reste bien plus facile à dire qu'à faire. Pour finir, je suis tout à fait d'accord avec legueux : essayons d'être solidaire et de ne pas nous mettre sur la gueule. Je suis aussi d'accord avec je-sais-plus-qui qui disait qu'il faut être réaliste et cohérent. Avant de poster une solution "miracle", réfléchissez y 5-10 minutes, essayez de faire un test chez vous et ensuite seulement prenez la direction du forum. Sur les 17 pages de ce topic, on pourrait virer facilement 15 pages de posts inutiles et qui ne font pas avancer le schmilblik (comme disait l'autre ). XboxFontPatcher ne nécessite qu'un fichier de conf et un default.xbe. Il serait très facile (le code ne doit pas faire plus de 30 lignes ) de se passer de ce fichier de conf pour un test mais je ne crois vraiment pas à la réussite de ce test pour les raisons que j'ai évoquées plus haut.

Et on ne peut pas imaginer que se ne serais qu'un premiere niveau de protection ? Ben disons que si le lecteur dvd envoi une information comme quoi le media est original,le reste du hardware reagira comme si c'etait un original. Le lecteur dvd,c'est la base ,et le modifier reviendrait a se passer de puce,du moins pour les backups. Par contre on peut imaginer que les jeux integreront des protections anticopie. Le lecteur peut aussi envoyer le code de protection sur le DVD et c'est alors au processeur de vérifier si ce code est bien correct. Dans ce cas, le hack du firmware n'aurait que très peu d'intérêt. Et si j'y ai pensé instantanément, je doute très fort que les dizaines d'ingénieurs qui ont bossé pendant 2 ans sur la sécurité de la 360 n'y aient pas pensé...

Salut à tous, je cherche un module me permetant de rajouter un bloc sur mon site web. Ce site est basé sur XOOPS (comme l'est Gueux) et se veut être un site personnel me servant à centraoliser mes contacts, mes bookmarks, mes rendez-vous, ... Dans ce cadre là, j'aimerai bien pouvoir ajouter des blocs contenant les fils RSS proposés par mes sites web préférés (dont Gueux ) et ainsi disposer d'un portail web complètement personnalisé. Je n'arrive pas à trouver un module qui me fasse ça directement et sans toucher une ligne de code (je ne fais que ça de toute la journée déjà alors j'essaie de prendre un peu de recul le soir ). Tout ce que j'ai trouvé, c'est une classe PHP qui prend un fil RSS en entrée et me retourne son contenu de façon paramétrable. C'est déjà pas mal mais il faudrait que j'intègre ça à un module et si je peux éviter de passer par cette étape, ce ne serait pas pour me gêner ! Merci d'avance à tous ceux qui pourraient me metter sur une piste.

Tu peux m'expliquer où tu as vu que la 360 avait un "madiacenter intégré" ? Est-ce qu'il t'est venu à l'esprit que c'est le Media Center qui détecte qu'il est connecté à une 360 et qui adapte donc son affichage en fonction ?

Bonsoir Voila bug corrigé ah le copié collé :) une belle invention C'est clair que c'est beau ! Ca a dû resservir pour le concours PSP aussi : la sortie pointe sur le site ngc Saleté de Ctrl+C / Ctrl+V

Tu sembles oublier que Windows (et non winprout, windaube : un peu de respect à ceux que ça fait vivre ne fait pas de mal ) n'est pas le seul OS du marché. Linux et MacOS sont loind d'être des OS mineurs. Linux devrait même voir ses parts de marché s'élever au détriment du système de Microsoft. Pour Quarentin : Quant aux consoles et à leur convergence avec la télé, je ne suis pas du tout d'accord avec cette idée ! Certes, l'informatique a tendance à faire converger les concepts proches (audio/vidéo/photos donnent des appareils multimédia, MemoryStick/SDCard/... donnent des lecteurs multiformats, ...) mais a aussi tendance à dissocier les services. Or une télévision et une console de jeux offrent des services complètement différents. Imaginer de devoir racheter une télé pour changer de console. Non seulement le public ne serait pas d'accord avec celà mais les fabricants de télévision n'ont ni les compétences ni les moyens financiers et techniques pour développer des consoles de jeux. Et quand tu dis que ce sont les fabricants d'Asie du Sud-Est qui vont s'imposer et se baser sur des systèmes Linux, celà me parait être très "folklorique"... Je ne vois vraiment pas ce type de constructeur (note l'usage du mot constructeur et pas développeur : ils ne le sont pas. Sony, Toshiba, LG, ... peuvent l'être, les autres non) se mettre à faire de la recherche.

Au tout début, ça a commencé comme la Xbox360. On a très rapidement eu des isos de différents jeux, puis une puce pour les faire passer (la première enigmah si mes souvenirs sont bons) avec juste un bios de base non flashable dessus. Et puis la bombre est arrivée : le dashboard EvolutionX ! Il permettait de mettre ses jeux sur le DD, d'avoir un accès au ftp, de lancer les premiers émulateurs, de créer facilement des skins avec uniquement 2 images à mettre dans un répertoire, .... Ensuite, tout s'est emballé : début de XBMP (fusion rapide avec Yamp, un autre lecteur multimédia), présentation de NexGen (jamais réellement sorti), premières puces flashables, possibilité de changer le DD par un d'une taille plus grande, nouveaux dashboard avec des possibilités supplémentaires, ... Au tout début, gueux n'existait pas et la majorité des "anciens" de gueux se retrouvaient sur le site xbox-hacks.net (un site qui vivote plus qu'il ne vit aux dernières nouvelles) ou sur le forum d'ominfo (pour ma part). Rapidement legueux a créé son site qui se focalisait uniquement sur la Xbox et sur son forum. Ensuite, gueux s'est aggrandi avec de nouveaux membres puis de nouvelles consoles traitées (NGC puis mobiles et enfin Xbox360), accompagné d'une réorganisation des forums pour prendre en compte les nouvelles consoles traitées.

Je le répète encore une fois : la 360 n'exécute aucun code dans le cas où elle est connectée à un media center. elle ne fait office que de périphérique d'affichage. Et puis écrire un troyen pour 360 sans avoir de kit de développement pour le compiler, ça risque de pas être évident : il ne me semble pas que les kits de développements (XDK) aient été récupérés et mis à disposition sur les réseaux P2P. J'ai pas cherché mais on en aurait entendu parler...

Je me sens pas si abruti que ça mais je ne vois pas pourquoi Activision et EA, qui ne sont pas liés étroitement ni à Microsoft ni à Sony, baisserait leurs jeux à la sortie de la PS3 ou même de la révolution. Ce serait Microsoft qui sortirait ses jeux à 70 euros, je dis pas. Ils pourraient opérer une baisse si Sony ne s'aligne pas. Mais dans le cas d'éditeurs tiers, je ne vois pas ce qui te permet de dire " n'importe quel abruti le sait ça!"

Ou qu'ils n'ont pas envie de se lancer dans le HD-DVD (ou le Blue-Ray) mais que pas mal de sites espèreraient un changement de situation et n'hésites pas à inventer des informations...

Je suis assez d'accord avec toi jp33. Les exploits ont énormément progressé depuis les premières releases de Bert & Ernie (avec FreeEvox si je me souviens bien du nom de la première release). Les saves automatisées (basées sur Uxe et Ndure) ont énormément simplifié leur mise en place. Néanmoins, je vois encore de petits avantages à la puce (dans le cas bien évidemment où elle est utilisée correctement) : . changement du disque dur simplifié (et là, je ne te vois pas dire le contraire, si ? ) . support des écrans LCD (avantage tellement peu utilisé et utile qu'on peut se demander si s'en est vraiment un) . modification du boot (flubber, texte, couleur, animation, ... : absolument pas utile mais ça peut êter sympa. Perso, j'aime bien) Et pour finir, je dirais qu'il est complètement inutile de faire une guerre entre Puce et Exploit. Ces deux techniques sont complémentaires (la seconde ayant découlé de la première d'ailleurs) et ont chacune leur plus et leur moins. Encore une fois un grand merci à toi pour les avancées que tu as proposé pour les exploits et les explications et corrections que tu peux apporter aux propos de chacun.