-Zou-

En fait tu n'es pas assez précis quand tu dis augmentation. Quand tu parles d'une augmentation (sous entendu "augmentation des vente par rapport au mois précédant"), c'est le nombre de consoles en plus par rapport aux nombres de console du mois précédant, ok? Donc en prenant les chiffres de l'article : nombre console du mois précédant = 127.206 nombre de console de plus par rapport au mois précédant = 403.831 - 127.206 = 276.625 maintenant en % ça te fait une augmentation du nombre de vente de 276.625/127.206 = 2,1746 = 217,46% (et non pas 317,46% comme dis dans la news) et donc dans ce cas, oui +100% = doublé,... . Mais ce n'est pas ce qui a été calculé dans la news dans la news ils ont calculé le gain de console par rapport au mois précédant (càd "ce qu'on avait avant" sur "ce qu'on avait après") : 403.831/127.206 = 3,1746 = 317,46% et là on dit bien qu'on a triplé (en fait un peu plus que triplé puisque c'est 3.17) le nombre de ventes (et non pas quadruplé). Oo ! t'as aprit ou les maths ? peux etre a la meme école que moi ou j'ai apprit l'orthographe Quand on dit + 100% sa veux dire qu'il y a eu n+n*100/100 donc 1+1=1*2 Pour la 360 pas besoin d'info faut juste voir comment MS a fait avec la 1er xbox car faut pas oublier que 692,751 pour sont 3eme noel ce qui est vraiment tres peux pour un console avec un gros catalogue et surtout dans ce pays de prédilections et ça montre que la 360 va pas fair bcp mieux que la 1er xbox (25M en 4 ans la 360 14M en 2 ans) donc l'arrivée d'une nouvelle xbox d'ici 2 ans ne fait pas trop de doute et surtout que j'ai l'impretion que la 360 a de mal a reduir sont prix ce qui est un tres gros handicape. Bon alors pour ceux qui sont pas fort en Math on va faire simple : 4*127.206 = 508.824 et 3.1746*127.206 = 403.831 bref la ps3 a bien triplé et non quadrupler. Cours de rattrapage spécial pour Doss, on va reprendre ta formule qui est correcte: Tu vends 10 pommes en une semaine la semaine suivant tu en vends 20 quel est le multiple qui correspond à l'augmentation de tes ventes? 20/10 = 2 (doublé) = 200% n représente le nombre de pomme lors de ta première semaine n + n*100% = 20 (tu remarquera que c'est +n*100% et non pas + 100%) tu mets nen évidence, ça te fait: n*(1+100%) = n*(200%) = 10*200% = 20 (cqfd) Dans la news, les 317,46% c'est bien le nombre de console du mois d'octobre sur le nombre de novembre, c'est donc bien ce pourcentage là qui a été calculé et donc 300% c'est bien triplé et non pas quadruplé PS: maintenant que je sais que tu tiens tes info de là où tu as appris tes math, je me sens plus rassuré quant à l'avenir de la 360

On en est qu'au debut (meme si on s'aproche de la fin de la 360) la PS1 avait mi du temp a decoler et ça l'as pas empecher d'etre leader sur le marché ou la SNES qui avait un gros retard sur la MD et au final elle s'est vendu 1,5 foix plus. Ah bon? Si tu a des info à nous faire partager ...

Ben justement, pour plus de clareté il faut procéder méthodiquement et pas tout prendre en vrac et finalement perdre de vue ce que l'on cherche.

Mouai il y a de la confusion dans les nombres. Encore une fois il faut se méfier des chiffres et bien comprendre ce qu'ils signifent. 403.831 / 127.206 = 3,1746 soit 317,46% Il y a donc eu une augmentation de 317,46% des ventes de ps3 par rapport à octobre. une augmentation de 100% = status co, les chiffres entres octobre et nomvembre sont identiques. une augmentation de 50% = régression des ventes entre octobre et novembre (même si on parle d'augmentation, c'est comme additioner un nombre négatif, ça correspond à une soustraction même si on a effectué une addition). une augmentation de 200% = double de ventes entre octobre et novembre. Maintenant si on parle en pourcentage uniquement ça revient au même. Si octobre correspond à 100%, le mois de novembre a augmenté en pourcentage de 200% (100%+200% = 300%) dans ce cas là on +200% = triple des vente etc Donc dans la news pour plus de clareté ils auraient dû écrire PS3= 403,831 (+207.46%)

Comme je l'ai déjà dis, il vaut mieux s'attarder sur les témoigniage de gens banni que ceux non (enocre) banni. La question c'est bien de savoir pourquoi M$ ban et non pas pourquoi M$ ne ban pas.

Voilà la liste de tous les jeux compatible : http://www.xbox.com/fr-BE/games/backwardco...tygameslist.htm

300% = quadruple ?!?! il faudrait qu'il m'explique comment il est arrivé à ça!

Normalement lors de l'utilisation de autofix (dans l'ongle CRC Chek), il vérifiera automatiquement sur internet. Pas besoin de remplir les chanp que tu montres, ils devraient automatiquement s'ajoutée. Ou sinon pour ceux qui n'ont pas internet, il est possible de dl leur base de donnée http://360patches.com/forums/index.php?board=18.0

Bon alors j'ai un peu plus fait de test et finalement, je pense avoir trouvé la solution. En fait le prob viendrait de ImgBunr. En tout cas, j'ai dl la dernière version de ImgBurn (2.3.2) avant j'étais en 2.3.1 et maintenant toutes mes iso sont reconnue en MOD1/2048 même ceux qui étaient reconnue comme MODE1/2448 avant o.O . Comprend pas, enfin bon l'important c'est que tout refonctionne.

Bonsoir, je ne mettrais jamais ta parole en doute mais d'apres ce que je sais, c'est au demarrage du jeu que certaines verifications sont faites..... d'ou le reboot du login..... Bonne soiree Quel est le rapport entre certaines vérification et le reboot du profil? Salut, Tout simplement que le seul moyen pour eux de te faire redemarrer le jeu c'est de te deconnecter ton profil du live. A plus o.O ??? pourquoi auraient-ils besoin de faire redémarrer le jeu pour faire des vérification? Et puis même, quand on a une déco du live dans un jeu, on est pas obligé de redémarrer le jeu. sources, sources,...

Bonjour alors voilà, je fait appel aux connaisseur parce que j'ai un problème pour créer des backups et je ne trouve pas de solution (google, forum gx, forum xb-scene,...). Alors d'abord il faut savoir que j'ai déjà utilisé à plusieurs reprise cette méthode sans aucun problème : 1°) Création du backup avec XboxBackupCreator 2.7 (ou 2.5 ou 2.6 avant) et lecteur PC SHD162C (Kreon 0.81) 2°) Graver l'iso obtenue avec ImgBurn. Mes backup se créaient sans problème. Maintenant un problème est apparu avec certains jeux uniquement (Condemned, Burnout Revenge et Conan pour ma part). La création avec Xbox Backup Creator fonctione très bien, le passage de l'iso créée dans XDVDMulleterne pose pas de prob et me dis que l'iso est parfaite. Mais quand je veux graver avec ImgBurn, celui-ci m'affiche un message d'avertissement au moment de graver alors comme un dessin vaut parfois mieux qu'un long discour voici, le screen : Alors déjà quand je charge l'iso y a qqch qui cloche, je l'ai entouré dans mon image : Vous remarquez que le label, l'Imp ID et le File sys ne sont pas reconnu contrairement aux iso normales. Ensuite si je lance la gravure, voilà le message qu'il maffiche : Et si je click sur oui pout quand même lancer la gravure voilà le message : A partir de là peu importe le choix que je fais, les deux DVD gravés ne tourne pas dans la Xbox (ni même dans un PC d'ailleurs). Ca fait un bout de temps que je cherche sur internet, j'ai refait à plusieurs reprise l'iso avec Xbox Backup Creator ou Schrom360j'ai toujours le même prob avec les mêmes jeux alors maintenant je sais plus quoi faire. Si qqn a une idée? Merc de votre aide.

Bonsoir, je ne mettrais jamais ta parole en doute mais d'apres ce que je sais, c'est au demarrage du jeu que certaines verifications sont faites..... d'ou le reboot du login..... Bonne soiree Quel est le rapport entre certaines vérification et le reboot du profil?

Bon là je viens de faire une recherche sur cette fameuse base de données de XDVDMulleter et je suis tombé sur le forum du programme. C'est bien ce que je pensait, la BD de XDVDMulleter est mise à jour automatiquement avec les envois de chacun via l'option "Batch ISO operation". Autrement dis, tout le monde peut mettre ce qu'il veut dans la BD. Il n'y a apparemment aucun controle sur les données de la BD et certains ajoute des release warez. Bref cette option de XDVDMulleter est très intéressante mais à partir du moment où la BD peut contenir des mauvaises info c'est plus ennuyant. Je comprend pourquoi maintenant la moitier de mes backup n'étaient pas reconnu comme stealth. Une version PAL d'un jeu est différente d'une version NTSC les crc sont donc différents.

C'est quoi la version de ton Kernel?

C'est pas nouveau, tu pense bien que ceux qui ont créé les firmware ont pensé à ce prob. Deux page avant qqn en avait déjà parlé.

Je pense que si vous voulez avancé dans le critère de détection des consoles hackée, il vaudrait mieux ne tenir compte que des consoles bannies et non pas les console qui ne sont pas (encore?) bannie. La question c'est bien "pourquoi une console est bannie?" et non pas "pourquoi une console n'est pas bannie?". Le simple fait que M$ ne controle pas toutes les consoles fait tomber à l'eau pas mal de théorie. De plus il vaut attendre que des cas "isolé" soit confirmer par d'autres témougniage avant d'essayer de les expliquer.

attention le 480p en mode gamecube ne concerne que les jeux NTSC jap et US, la seule option pour les jeux gc pal c'est le mode 60hz et pas pour tous les jeux (luigi's mansion reste en 50hz par exemple) les jeux gc pal sont en 576i50hz ou 480i60hz à part peut être des exceptions mais je les connais pas alors Bah en tous cas Ikaruga passe que en effectuant la manip' et c'est une version PAL (UK car jamais sortie officiellement en France). Par contre je ne serais pas surpris qu'il soit en 60Hz, c'était déjà le cas pour la version Dreamcast. Ta Wii est transformée au pas? Parmis tes jeux GC tu n'as essayé que Ikaruga? J'ai acheté ce cable et j'ai des problèmes à faire tourner les jeux GC Pal sur ma Wii pal (non transformée). Pourtant sur le site www.hdtvarcade.com il sont bien marqué comme étant compatible 480p.

Le bannissement ne se passe pas au niveau des trames envoyée. En effet une trame reçue par le serveur XBLive ne contiendra pas toujours l'adresse MAC de la console (à cause du NAT ou bien des proxy). Il est donc claire que l'adresse MAC d'une trame ne peu être choisie comme élément d'identifiaction d'une console MAIS cela concerne bien les trame ethernet. Rien n'empêche l'adresse MAC de la console d'être contenue dans les donnée de la trame. Je ne pense pas que l'adresse MAC soit utilisée pour banir les console, c'est juste pour dire qu'il est tout à fait possible à M$ de connaitre ton adresse MAC via un soft dans la console qui envoie ensuite cette adresse MAC à M$. -------------- Pour en revenir sur le sujet, je me pose une question. Qu'est-ce qui dans une console détermine qu'une console est bien cette console et pas une autre? Autrement dis qu'est-ce qui identifie (de manière unique, oui je sais c'est un pléonasme) une console au près de M$. Il semblerait donc que cela soit la KeyVault mais est-ce la seul information propre à une 360. Il me semble que la clé CPU est aussi unique. Je ne vois pas à quoi ça leur servirait d'avoir l'adresse MAC de la console, ça sert simplement pour la configuration de notre propre réseau local, après ce n'est qu'une supposition c'est peut-être un élément de contrôle supplémentaire. tlm doit envoyer les mêmes trames avec un identifiant unique et crypté contenant le n° de série du keyvault ou autres et plus. Il faudrait ananlyser ce qui est envoyé au moment de l'essai de la connexion sur une console banni et sur une console non-banni. Après analyse identifier et modifier les trames de la console banni par celle de la console non-banni lors de la connexion. Après ça il faudrait voir à quel moment des contrôles sont effectué etc etc... et aussi pendant les jeux et là ça devient vraiment super compliqué à moins que les backups sois vraiment Stealth à 101% ou alors là il n'y aurait aucun souçis. Ca demande énormément de boulot, par la suite il serait possible de coller une puce ethernet au cul de la console updatable en cas de maj du xbl et chargé de modifier les trames, et derrière le cable réseau. Voilà j'ai pas pour habitude d'attiser la flamme avec des suppositions loufoques tout droit sortit de 24h Chrono mais j'avais envi d'ajouter ma petite touche personnelle. Je parle de l'adresse MAC parce que c'est un des élément unique qui est propre à la console (avec le n° de série, avec la clé CPU,... je ne sais pas s'il y en a d'autre). Ce qui est sûr c'est qu'il y a quelque chose dans la console qui permet d'identifier la console auprès de M$. Ce quelque chose est contenu dans la KeyVault. De quoi s'agit-il? Logiquement on doit se tourner vers les éléments qui sont unique à la console donc MAC, num de série, cpu key,... Pour les trame c'est pas aussi simple. Ce n'est pas un système style "la console est identifié elle peu passer dans la zone XBLive" non. Il y a une identification permanante ce qui rend impossible controle des trames, il me semble avoir lu qu'il s'agirait d'un système d'identification kerberos. Et puis même imaginons qu'on arrive à remplacer les trames pour faire passer la console pour une autre, on serait arrivé au même résultat que si on avait remplacé le KeyVault dans la console. Donc pour moi on peut déjà enterrer l'idée de contrôler les trames de la console. L'idée serait plutot d'analyser les trames sortie de la console et de comparé leur donnée avec le KeyVault. Il doit bien y avoir moyen d'isoler l'identifant de la console dans le keyvault

Oui il veut certainement dire que quand on joue ils peuvent vérifier le médiacode du DVD inséré. On en avait déjà parlé avant lors de la 1ère vague de ban. Toutes les info concernant un DVD gravé son blocqué par le firmware. Ca fait un bout de temps que c'est implanté dans les firm hacké (avant iXtreme). Autrement dit le firm se charge de reporter à la console que les DVD est bien un DVD pressé et non un DVD-R ou DVD+R DL ou MKM-001 ... Le fait de lire un firm ne peut en aucun cas endomager le lecteur. C'est l'écriture d'un firm qui peut bricker le lecteur si il y a une coupure de courant pendant le flashage..

Le bannissement ne se passe pas au niveau des trames envoyée. En effet une trame reçue par le serveur XBLive ne contiendra pas toujours l'adresse MAC de la console (à cause du NAT ou bien des proxy). Il est donc claire que l'adresse MAC d'une trame ne peu être choisie comme élément d'identifiaction d'une console MAIS cela concerne bien les trame ethernet. Rien n'empêche l'adresse MAC de la console d'être contenue dans les donnée de la trame. Je ne pense pas que l'adresse MAC soit utilisée pour banir les console, c'est juste pour dire qu'il est tout à fait possible à M$ de connaitre ton adresse MAC via un soft dans la console qui envoie ensuite cette adresse MAC à M$. -------------- Pour en revenir sur le sujet, je me pose une question. Qu'est-ce qui dans une console détermine qu'une console est bien cette console et pas une autre? Autrement dis qu'est-ce qui identifie (de manière unique, oui je sais c'est un pléonasme) une console au près de M$. Il semblerait donc que cela soit la KeyVault mais est-ce la seul information propre à une 360. Il me semble que la clé CPU est aussi unique.

mrblack1134 a fait une bonne réflexion, faudrait ptet pas crier victoire trop tôt. Donc en gros, dans l'hypothèse d'un mouchard se trouvant dans la console, celle-ci risque d'encore se faire bannir lorsque le marteau du ban repassera. Tout dépend, toujours dans l'hypothèse d'un mouchard, comment le mouchard fonctionne : si après le ban, le mouchard est effacé ou bien s'il reste toujours actif et garde les info d'avant le ban. Si cela s'avère exacte, on aura au moins la certitude qu'il y a bien un mouchard dans la console qui va raporter à M$ ce qu'on fait aussi bien online que offline. Sinon, cela signifie que les test de ban (je parle bien des test et non pas du ban) ont bien lieu lors d'une connexion à internet.

Non je pense pas. Dans la mesure où tes deux consoles t'appartienne. Mais si tu vend une des deux console et que tu garde son KV à mon avis là il doit y avoir un problème legal

Dans le principe c'est ça, faut juste avoir sa clé 1BL extraite (pour patcher un .bak de ta nand à restaurer avec une Infectus) du 1BL.bin que tu récupères via la faille hyperviseur et un kernel faillible (timing attack, infectus powa). ++ Dans le principe, je crois que c'est quand même un peu plus. Un numéro de série ne suffit pas, il faut un KeyVault valide. Dans son test4 zouzzz a essayé de juste remplacé le numéro de série du Keyvault par un autre mais la console était toujours ban. Par contre en remplaçant le KV en entier ça marchait. Je pense que décortiquer le KV sera la prochaine étape.

Oui apparemment le KeyVault regroupe pas mal d'info sur la console dont le num de série il semblerait que le Keyvault soit signé numériquement mais pas avec la clé CPU apparemment ou sinon cela n'aurait pas marché vu que les deux consoles ont des clé CPU différents (elle ont bien deux clé CPU différent?). En gros on pourrait faire une analogie entre l'eeprom de la Xbox1 et la KeyVault de la X360. Un générateur me semble impossible à réaliser mais sait-on jamais.

Félicitation zouzz !!! Ceci dis j'émet quand même une petite réserve concernant la création de KV.bin . En effet si on réussit à créer un générateur de KV.bin je n'aimerait pas que le KV.bin de ma console soit généré et puis que celui qui l'utilise se fasse bannir. Du coup ma console devient aussi bannie. Enfin bon ce n'est qu'une hypothèse car je doute qu'on puisse créer un générateur de KV. Une partie du KV est visible mais une autre partie est cryptée et il y a sûrement un système de signature numérique là dedans qui ne sera pas si facilement générable (?ça se dit ça?)