Ski-lleR

La fonction de chargement des xex existe dans le sdk, mais ne permet pas de lancer un xex : - dans un dossier spécifique - sur un périph usb - qui se trouve sur le disque dur Seulement si le fichier à chargé se trouve à coté du fichier lanceur (ou dans un sous dossier) Donc par exemple, en codant un xex qui charge un autre xex, et en mettant les 2 sur un dvd ça marche (chose inutile car les backup fonctionne maintenant sans sécurité) On pourrait se dire je met le xex launcher dans un fichier live, et on met les jeux dans le dossier Content>000000000000>57848521>0000D0000, mais non, car tout xex lancer depuis un fichier live, se retrouve confiner dans celui ci (il se créé un genre de "disque dur virtuel" suivant le contenu du fichier live) Pour moi, la solution, c'est un patch assembleur pour freeboot qui modifie le comportement de la fonction "charger les xex" qui se trouve dans le dash (à l'instar du patch qui permet le lancement de xex non signé) Sa permettrait de coder un lanceur xex très très facilement, sachant que le sdk est vraiment complet (avec 1 appel de fonction on peux lancer un xex)

Donc borderland fait moins de 4 Go, parce que c'est la limite de taille des fichiers fait avec xlast J'ai voulu le faire avec Dragon Age, mais 6 go de fichier

D'ailleurs le gars a mis un lien pour le télécharger, pour ceux qui veulent tester

C'est ce qui me semblait, du coup j'ai supprimer mon lien dans le topic "xbreboot v0.05", page 3

Tu parle au niveau légalité ? Microsoft à embêter xorloser pour son xextool, qu'il a donc retiré de son site. On le trouve partout ailleurs (sur xbins notamment), il ne l'ont pas poursuivit pour autant

Live en tout cas c'est nickel. Je sais pas si ça marche pour les trucs développeur indépendant, car il me demande d'être connecté au live pour ceux là. Peux être une fois modifié, ou alors il faut faire un patch freeboot

Je confirme iveri, j'ai testé, j'avais acheté Boom boom rocket, mais il ne fonctionnait plus (comme si je l'avais jamais acheté, Microsoft les voleurs). Depuis, il est bien déverrouillé et complet.

Faut voir comment fonctionne le système de compatibilité 360. S'il est pas trop compliqué, c'est faisable Mais avec le sdk 360, on peut aisément recoder les applications genre émulateur

Merci Ski-lleR, je coderai un mini XexTool Gui qui effectuera tout seul cette petite manip, pour les non initié. La ligne est bien celle en gras, n'est ce pas ? Oui c'est ça, désolé je boss sous linux, et je fais que de la ligne de commande, l'habitude ... D'ailleurs au passage, pour les développeurs, n'oubliez pas qu'une fois compilé (avec visual studio), il faut modifié le xex tout de suite, car il sort crypté.

Réponse dans le readme : Execution of unsigned devkit and retail XEXes is now possible. Encrypted devkit XEXes must be decrypted with XexTool prior to use. Donc direction le très controversé xextool interdit par microsoft xextool -ra -mr -ed default.xex Ce qui aura pour effet : -r = remove xex limitations (a/m/r/b/k/l/c/z) a = remove all limits (same as "mrbtlz") -m = force output xex machine format (r/d) r = force output xex to be retail -e = force output xex encryption format (d/e) d = force output xex to be decrypted Voila voila Et si vous voulez tester un xex autre que mame, j'ai compilé le sample advanced fps (vous le mettez sur rw ça suffit) > [Auto-censure car non autoriser sur le forum -> Application faite avec le SDK officiel]

Sa c'est pour pouvoir désassembler les fichier xex avec IDA, ce qui est, en soit, une bonne chose, mais ça n'est pas un xex faisant office de loader (juste pour info)

Rien n'est disponible, mais sachant qu'on peux lancer des xex non signé, et que le sdk est disponible (leaked), on va vite voir des applications apparaitre (genre loader de xex). Il est temps de sortir visual studio 2005 (j'ignorais qu'un jour je finirais par utiliser du microsft sur du microsoft pour programmer ...)

Pour ceux qui sont en cygnos v2, il faut extraire le smc et le patcher avec Cygnos Tool (le fameux smc.bin que ibuild vous demande), comme ça si vous êtes en cygnos v1.02 (pour le firmware), c'est la puce qui envoi les instructions pour l'exploit et non pas le smc. Si vous ne le fait pas, écran noir Pas vraiment un kernel alternatif, car il utilise tous les fichiers originaux non modifié. C'est juste que freeboot patch la mémoire en direct pour par exemple changer les fuses, ou encore désactiver la vérification des xex ...

Y'a une nand 8955 sur XBH, qui booterais directement sans deuxième nand. A voir si c'est un fake ou pas. Si quelqu'un peux tester, sinon je la testerais en rentrant du taf. C'est possible si freeboot est intégré dedans (sans c'est impossible, rapport au fuse) Sinon pour freeboot et 8955 c'est perfect, surtout le système de patch, ça permet de faire sauter toutes les sécu on-the-fly (genre anti envoi de secdata, ou spoof de la version du dashboard )

C'est bon c'est résolu, pour ceux qui sont en freeboot 8507, il faut modifier le timestamp dans secdata.bin/crl.bin, en utilisant bincrypt pour extraire/réinjecter les dit fichier de la nand généré. Et bien sur avoir modifier freeboot pour pas qu'il fasse le difficile sur les hash/taille de fichier Maintenant mes sauvegardes et profil fonctionne parfaitement.

Salut Histoire de pouvoir jouer au jeu récent, j'utilise freeboot (ce qui ne me plait guère, mais à moins de trouver une solution alternative...) pour démarrer en 8507 Seulement voila, mes saves et profil apparaissent corrompu J'ai essayé de flashé ma nand d'origine (7371), tout marche nickel Y'a t-il une modification à ce niveau entre le 7371 et le 8507 ? (hash, cryptage ...) C'est bizarre car sur le disque dur cohabite un profil pour 7371, et un pour 8507 (actuellement je reflash la nand suivant les sauvegardes dont j'ai besoin)

Normallement pour raw ss c'est toujours différent. Tu as fait 3 dump avec benq/kreon etc..., fait donc 2 dump avec 2 fois le même lecteur et la même méthode (genre 2 fois kreon, même logiciel et tout), le raw ss sera différent

Pourquoi non ? Avec un accès total à la nand, suffit d'effacer ce que la 360 modifie en tant que "backup détecté" Grave 2 / 3 backup pas bonne, tu aura vite fait de trouver les zones intéressante après comparaison de la nand (et en passant plusieurs originaux et plusieurs backup du même jeux)

Non le pilote sata j'en ai développé un moi même avant qu'il release le siens. Le but final est de gérer le système de fichier du disque dur (xtaf) de la 360 avec Xell (ou plus généralement libxenon) Il me faut une synthèse des infos existantes sur le disque dur Pour le moment j'adapte le code, donc quand je serais au détection des partitions, j'aurais plus qu'à récupérer les infos ici

Salut la communauté Depuis quelques temps, je travail sur l'adaptation du code fatx pour linux (celui de la xbox première génération). Mais je suis pas mal débordé, car j'ai plusieurs développement en parallèle, et je boss en plus sur les ban (tout ceux que je connaisse s'étant faire bannir, sauf moi, j'ai décidé de trouvé précisément les raisons du ban pour qu'on arrête de jouer avec des spéculations) Ainsi, si certains ont quelques connaissances en C (c'est pas le plus important), mais davantage en reversing de la 360, il me faudrait des infos détaillés sur la structure du disque dur Ici, vous pourrez trouver le code de fatx : http://xbox-linux.cvs.sourceforge.net/view...x-linux/kernel/ Ici, certains infos sur la structure du disque : http://www.free60.org/Harddrive Tout contribution est la bienvenu

Je sais pas si ça a été posté : <c4eva> fw is not detectable! no eta on liteon fw! Je pense qu'il sait de quoi il parle, c'est lui qu'il le fait. Personnellement je pense plus à une mauvaise gravure des jeux en général. Sur windows, avec la quantité de spyware/virus qui existe, c'est vite fait. C'est sans parler des i/o error. J'ai fais l'expérience sur linux, le jeu est valide à 100% avec abgx360, et une fois gravé, je retrouve des différences en re-dumpant le gravé. Ca fait depuis la sortie des cf que j'utilise des backups, sur le live à outrance, et j'ai jamais été banni. Sachant que j'utilise des verbatim de singapour. Un pote je lui ai flashé sa console, il a fait gravé ses jeux par un type dont les dvd était pas tip top, dont le windows était un échec (même le disque dur, 9 mb/s sur un sata, alors que je suis à 90 mb/s), résultat, banni en 1 ou 2 semaines

Oui je vais mettre les sources en ligne pour Pong quand le son sera ok (j'ai pas avancé, car le support brut du hardware est plus important à mes yeux). Pour le pilote sata, ce sera intégré à la libxenon, donc vous n'aurez qu'à utiliser les fonctions directement. (genre sata_init(); pour initialiser le disque dur) Idem les systèmes de fichiers (xtaf, fat32 et ext2) seront détectés automatiquement avec le sata_init() Des fonctions générique d'écriture seront codés, donc pour programmer ce sera que du assez haut niveau Ainsi le développement d'un dash alternatif sera beaucoup plus facile Edit : jc a posté les sources de son pilote sata sur xbh, pour ceux qui veulent étudier. Un gros gain de temps pour moi qui vais pouvoir attaquer plus rapidement le support de xtaf

Le support du port sata de la console est en marche (plus précisément, le port sata du disque dur) : je fignole, et j'ajoute le support du xtaf (donc, on aura accès au disque dur original depuis xell) Puis comme dit précédemment, le support du ext2 suivra (le fat pourra déjà être gérer, car un pilote existe dans Xell) PS : Programmer pour communiquer directement avec le hardware, c'est hard, mais vachement intéressant

Installe ça et ce sera bon : http://www.microsoft.com/downloads/thankyo...;displayLang=en Après ça sa DOIT marché (j'ai vérifié, flash tool ne marche pas sans) Au cas ou, je t'ai extrais les fichiers : http://www.sendspace.com/file/cd4277

msvbvm60 il me semble Pour être sur, voila je t'ai uppé le fichier : http://www.sendspace.com/file/cjahez Si avec ça ne marche pas, ça vient d'un manque de bibliothèque (car moi meme sur linux il marche avec WINE ) Sinon vérifie la liste des dlls nécessaire par rapport à ton dossier system32 : mfc90.dll MSVCR90.dll ces les 2 seuls qui techniquement ne sont pas fournis dans windows, le reste c'est obligé (genre kernel32.dll etc ... )