-Zou-

Bon voilà, j'essaye de changer le KV d'une de mes consoles mais pour le moment ça coince, j'obtiens toujours le sapin de noel quand je veux injecter un KV B dans ma console A. Comme un beau dessin vaut mieux qu'un long discours voici ce que me donne FlashTool pour mes deux nand, mon but étant d'injecter le KV B dans la Nand A : Les deux consoles sont des Falcon avec KV type 2 Voici les opérations que j'effectues : * Sur la Nand B: - J'extrais le KV (ça me donne 2 fichiers kv_dec.bin et kv_enc.bin - "enc" pour encrypted et "dec" pour decrypted je suppose) * Sur la Nand A: - J'importe le KV B en utilisant le fichier kv_dec.bin rem : j'ai également essayé en utilisant de extended kv mais j'obtient toujours le même résultat. J'aurai loupé quelque chose?

J'ai une petit question : Donc la règle pour changer de KeyVault c'est : - Si on a une CM Xenon, n'importe quel KV est bon. - Si on a une CM autre que Xenon, on doit regarder le type e de KV. Et là, la règle pour le type de KV c'est quoi? v1 avec v1 et v2 avec v2? Ou v1 avec v1 ou v2 et v2 uniquement avec v2? ou ... ? Merci

Ca aussi c'est pas mal :

Non

Ca peut être pratique aussi pour garder son disque dur 360 clean. Même si pour le moment M$ ne scanne pas le disque dur, on se sait jamais ce que peut encore faire M$.

c'est pas obligatoire mais recommandé Merci, vais peut-être tester alors . A noter que si tu veux absolument le 7371, tu peux replacer la nand 7363 sauvé dans ta console et tu fait la mise à jour 7371 que tu dump ensuite.

Pourquoi forcément un disque dur 250 Go? Maintenant qu'il est possible de faire sois même ses carte mémoire avec des clé usb, M$ se sent encore moins obligé de fournir une unité de stockage. Concernant Natal je vois vraiment mal M$ vendre des console sans Natal, si c'était quand même le cas l'implantation de natal serait moindre vu qu'il est certain qu'une grande partie des gens choisiraient le pack sans Natal. Un pack sans natal me paraît donc peu probable.

300 euro je trouve ça vachement chère pour un "remodelage de console" perso je pense que le bon compromis ce serait la même politique tarifaire que la ps3 slim càd le pack X Slim + Natal au même prix que les pack actuel soit 200 la arcade slim et 250 euro la elite slim.

Bah oui c'est le but aussi, si tout le monde pouvait être prestige 10 sans trimer ça n'aurait pas d'intérêt de l'avoir ...

Pour faire claire la màj intégrait la possibilité d'ajouter des codec pour lire les divx (il n'y a donc aucun codec divx dans la màj!) ensuite il fallait télécharger le pack de codec depuis le market place (en tant que DLC donc signé avec DRM).

http://360.kingla.com/

Bah oui c'est en tout cas ce qu'il est décrit dans la doc (cf mon post plus haut)

En sachant qu'une clé rsa 1024 bit est actuellement jugée incrackable en brute force (certains, par une bidouille, on pu la cracker mais ce n'est pas applicable dans le cas de xex), n'imagine pas pouvoir cracker une clé 2048 bit plus facilement. Et je rappel que doubler la longueur de la clé, c'est pas juste double le temps de crackage, il s'agit d'une échelle exponentielle.

A noter que le système de signature des xex n'est pas un secret, il est dispo dans la doc du XDK (faite une recherche avec le mot xex)

Bah la réponse est dans ta question. Si t'es ban tu peux pas te reconnecter donc tu peux pas mettre à jour ta console ...

Aucun rapport, tu peux toujours dumper ta nand peu importe la version de ton Kernel, c'est la nand hacké (XBR3) qui ne fonctionne pas sur les consoles mise à jour en kernel 8XXX.

Normalement c'est fait pour les consoles qui sont pas encore Jtaguée.

C'est pas faux non plus.

Cool un upload direct en FTP

Bizarre que M$ soit si attentionné :/ Auraient-ils trouvé une autre faille dans la 8955 que nous n'aurions pas (encore) trouvée?

Mais si on a fait la màj ça se voit directement dans les info de la console qu'elle n'est pas compatible. Ca peut servir pour les consoles revenue du SAV qui on un kernel de 7XXX.

Je vais pas jouer sur les mots mais crypté et signé c'est la même chose tu cryptes ou tu signes avec une clef. Quand tu signes ou cryptes tu appliques un algo à partir d'une clef qui crypte/signe un contenu.... Et tu utilises la clef pour pouvoir lire le contenu. Je suis développeur et cette notion est la même sur les programme dotnet...(bizarre c'est du microsoft)... C'est ce qu'on appelle un certificat(qui contient la clef et autres infos). Il faut que l'application soie signée par rapport au certificat. Dans notre cas, ce fameux certificat doit être soie contenu dans la maj ou connue par le système. Ce qui veut dire que soit le microp contient cette information ou contenu dans la nand et que l'algo existe aussi sur la machine.... Ce n'est qu'une supposition... Mais dans le fond, nous disons la même chose en fait... Maintenant avec une xbox JTAG on devrait pouvoir trouver cette info... Au passage le certificat est contenu dans un fichier qui s'appelle .manifest en dotnet (pour ce qui est des déploiements entre autres ClikOnce)... et il y a un system.manifest dans le pachage SystemUpdate Je continue à regarder... Crypté et signé c'est pas la même chose même si les opérations sont les même. Crypter sert à cacher son message, signer sert à certifier que le message n'a pas été altéré. Enfin bon dans notre cas comme tu le dis ça ne change rien mais c'est important de pas tout mélanger. Pour en revenir sur le cas de la signature, je pense qu'il est fort improbable que M$ utilise un cryptage à clé secrète car comme tu le fait remarquer, cela signifierait que la clé secrète serait stockée dans la console et ça se saurait depuis longtemps. Ils doivent certainement utiliser une système à clé privé/public et là on aura beau fouiller la console on trouvera rien pour signer nos applications.

Dans freestyle 360 on peut aussi contrôler les ventilateurs. Mais c'est pas conseillé de toucher à ça.

Merci pour le log. Je savais pas qu'il existait un topix à son sujet, ce serait peut-être mieux de le déplacer en section développement? Pour en revenir à gx-nand 1.7 voici un retour, il y a peut-être un cas qui n'a pas été envisager dans le mode auto. Je m'explique : Le log fait 2 dump d'affilé puis les compare. Si il n'y a pas d'erreur, les opérations continue, si il y a un ou plusieurs block de différent on s'arrête là. Mais que se passe-t-il dans le cas où les différences entre deux bloc se situe tous dans un badblock? C'est ce que j'ai avec une console, pas moyen de faire deux dump d'affilé identique et à chaque fois les différences se situent dans le seul badblock de la nand. Voilà