bitonio6 Posté(e) le 11 juillet 2009 Posté(e) le 11 juillet 2009 Bon maintenant que c'est plus calme... Il faut poser les questions et voir les possibilités futures... Ok on peut hacker la console, firmware, faille, etc.... Le truc habituel = Jeu, sauvegarde, contenu sur la SD = installation ou flashage de la console! Maintenant, vu que pour le moment aucun jeu sur support physique ne se sert de la SD, pour le moment pas moyen pas ce biais! L'avantage actuel, c'est surtout que les linkers existent, mais à quoi bon hacker la console, si on acheté un linker pour la hacker?! Ensuite imaginons qu'ils ont trouvés un truc pour lancer des jeux depuis la SD, c'est génial, mais il faudra à nouveau le patcher spécifiquement pour qu'il sauve ensuite sur la SD elle-même! Je suis comme badablek, si c'est pour permettre à certains de programmer des trucs dessus = génial Si c'est encore et toujours, pour aider des gens à ne pas donner un franc pour la programmation de logiciel = La merde!
Shakin Posté(e) le 11 juillet 2009 Posté(e) le 11 juillet 2009 Salut, Maintenant, vu que pour le moment aucun jeu sur support physique ne se sert de la SD, pour le moment pas moyen pas ce biais! il suffirait de lui injecter une Save Hackée ( comme le Twilight Hack ) qui irait lancer le code présent sur la SD. Si il est possible de le faire avec les jeux DSi comme c'est le cas avec les jeux DS actuels, alors tu as ta réponse et ils y arriveront. L'avantage actuel, c'est surtout que les linkers existent, mais à quoi bon hacker la console, si on acheté un linker pour la hacker?! La vrai question sera plutôt : "A quoi bon acheter un Linker si jeu peux hacker ma DSi sans ?" Avoue que ça te fait tourner le ravioli !! Ensuite imaginons qu'ils ont trouvés un truc pour lancer des jeux depuis la SD, c'est génial, mais il faudra à nouveau le patcher spécifiquement pour qu'il sauve ensuite sur la SD elle-même! Ca c'est le boulot du loader garcon ! Je suis comme badablek, si c'est pour permettre à certains de programmer des trucs dessus = génial Si c'est encore et toujours, pour aider des gens à ne pas donner un franc pour la programmation de logiciel = La merde! +1 @+
dégueux Posté(e) le 12 juillet 2009 Posté(e) le 12 juillet 2009 (modifié) Maintenant, vu que pour le moment aucun jeu sur support physique ne se sert de la SD, pour le moment pas moyen pas ce biais!L'avantage actuel, c'est surtout que les linkers existent, mais à quoi bon hacker la console, si on acheté un linker pour la hacker?! L'avantage, c'est de ne pas devoir acheter de linker justement. Ensuite imaginons qu'ils ont trouvés un truc pour lancer des jeux depuis la SD, c'est génial, mais il faudra à nouveau le patcher spécifiquement pour qu'il sauve ensuite sur la SD elle-même! C'est la même chose pour presque tous les linkers actuels. Il faut patcher spécifiquement la ROM pour qu'il sauve ensuite sur la micro SD elle-même (c'est le lanceur qui s'en charge). Parmi les linkers actuels seul la Supercard peut lancer des ROM sans devoir patcher. Par contre, il y a une rumeur qui dit qu'il est impossible de sauvegarder quoique ce soit sur la SD depuis la DSI. Ça serait la raison pour laquelle DS browser ne gère pas la SD. Modifié le 12 juillet 2009 par dégueux
bitonio6 Posté(e) le 12 juillet 2009 Posté(e) le 12 juillet 2009 C'est là, à mon avis que se trouve tout, le port SD... L'adressage, comment écrire dessus, si le contenu qui y sera écrit sera filtré, etc... Un peu comme lancer un jeu GBA depuis le slot 1... Pour moi le slot SD c'est un peu l'équivalent du slot 2, doit y a voir un mode spécifique dans la DSi pour qu'elle s'en serve, maintenant est-ce que nintendo va offre du jeu GBA en téléchargement payant jouable depuis le slot SD, on verra bien! A mon avis, s'ils le font, ils vont modifier le jeu en lui-même, pour qu'il ne ressemble plus à l'original au niveau code histoire que l'on ne puisse pas comparer et trouver les modifications! Mais c'est dommage que nintendo fasse toujours des conneries de ce genre s'ils ouvraient la porte du homebrew de manière direct... Les hackers les laisseraient sans doûte un peu plus tranquille!
Badablek Posté(e) le 12 juillet 2009 Posté(e) le 12 juillet 2009 C'est la même chose pour presque tous les linkers actuels. Il faut patcher spécifiquement la ROM pour qu'il sauve ensuite sur la micro SD elle-même (c'est le lanceur qui s'en charge). Parmi les linkers actuels seul la Supercard peut lancer des ROM sans devoir patcher. dans le sens strict du terme, aucun linker ne fonctionne sans patch, pour la simple riason que les jeux DS sont semi-cryptés ( de l'adresse $4000 à $8000 d'un dump), et qu'il faut impérativement que cette zone soit préalablement décryptée pour que ça fonctionne. Aucun linker 1:1 n'existe vraiment. sans compter que la moindre option nécessite obligatoirement un patch (que ce soit sur le backup ou en ram). Rien que le soft reset, qui doit intercepter la combinaison de touches et redémarrer quand elle est détectée. Si un loader venait à voir le jour, ça serait comme n'importe quel autre loader : une sorte d'emulateur (au sens très large du terme) qui interprète les opérations de lecture/écriture des jeux et les redirige vers le slot SD. Quant à de possibles jeux GBA ou autre, c'est le principe de la virtual console et du wiiware : le contenu est crypté grâce à une clé unique, propre à chaque console. Sauf qu'on peut compter sur Nintendo pour ne pas avoir fait 2 fois la même (très) grosse erreur de la faille trucha. Donc même avec la common-key, impossible de resigner correctement les données, et impossible à lancer. bref, l'avenir nous dira si c'est viable ou pas. En tout cas le jour où une Homebrew channel DSi apparait, je fonce acheter la console.
dégueux Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 dans le sens strict du terme, aucun linker ne fonctionne sans patch, pour la simple riason que les jeux DS sont semi-cryptés ( de l'adresse $4000 à $8000 d'un dump), et qu'il faut impérativement que cette zone soit préalablement décryptée pour que ça fonctionne. Aucun linker 1:1 n'existe vraiment. Si le DSone peut démarrer les ROM sans patch. Dans ce mode, pas de softreset, ni RTS, etc... Quant au décryptage, on ne peut pas considérer ça comme un patch. Les ROM originales aussi sont décryptées pareil.
Badablek Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 Les ROM originales aussi sont décryptées pareil. c'est là que tu te trompes. les dumps crées actuellement ne sont pas des dumps 1:1, tant que la zone $4000 à $8000 n'est pas cryptée. Les dumpeurs copient la version décryptée de cette zone, simplement parce que cryptée, les jeux seraient inutilisables. C'est bien pour ça que je précise "dans le sens strict du terme"... les backups que l'on peut faire sont une image des jeux une fois exécutés par la console, et donc décryptés. Essaie de faire manger un dump pur, crypté, à n'importe quel linker, le résultat sera toujours identique. y'a aucun linker 1:1, pour la simple et bonne raison que les dumps cryptés ne fonctionnent pas dessus.
dégueux Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 (modifié) Et comment expliques-tu que lorsque je prends un éditeur hexadécimal pour ouvrir un fichier de ROM, ben tout est crypté et que pour appliquer le patch arm7, il fait décrypter le fichiers ? Modifié le 13 juillet 2009 par dégueux
Badablek Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 rien à voir... un dump 1:1 est crypté au niveau de l'entête, je ne sais pas mieux l'expliquer que ça. Pourtant très clair. toi tu me parles de la structure de fichiers, qui, bien évidemment, n'est pas en "clair" en l'ouvrant avec un éditeur héxa. Moi je te parle de la zone de sécurité RSA, propre aux jeux DS, de l'offset $4000 à $8000. Sur un vrai dump 1.1 d'un quelconque jeu, cette zone est cryptée et aucun linker, quel qu'il soit, n'est capable de gérer ça. Alors le SC est peut être capable de lancer un clean dump, mais pas un dump 1:1. Même si au final, ce n'est que pure sémantique étant donné qu'un jeu, une fois exécuté, est la copie conforme d'un dump clean. Il n'empêche que sans ce décryptage préalable (par les logiciels de dumps), rien ne serait exploitable. je t'accorde que d'un point de vue global, dans le fonctionnement, on se contrefout qu'un linker ne puisse pas exécuter des dumps cryptés. Mais c'était juste pour nuancer le fait qu'aucun linker n'est parfait, pas même le SC Onei...Après, bien sûr, le fait qu'il soit discret au niveau de l'exécution d'un jeu (identique à l'original au bit près) pourrait être un avantage le jour où Nintendo veut vraiment devenir très méchant (sur le online par exemple, avec un contrôle systématique des données exécutées par rapport à une base de données....ce qui éviterait les tricheurs déjà).
dégueux Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 (modifié) rien à voir...un dump 1:1 est crypté au niveau de l'entête, je ne sais pas mieux l'expliquer que ça. Pourtant très clair. Tu veux dire qu'un original n'est crypté qu'au niveau de l'entête ? Ça me semble peu probable puisqu'un dump est crypté dans sa totalité. Rien n'est en clair lorsqu'on l'édite. C'est ce que je voulais dire. Modifié le 13 juillet 2009 par dégueux
Badablek Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 ouvre n'importe quel fichier (autre qu'un fichier txt), si tu arrives à y voir quelque chose de clair, tu es fort la zone de sécurité est située de $4000 à $8000. C'est tout. Le reste c'est le système de fichiers propre à la DS qui donne un "aspect crypté". Ce n'est pas parce qu'après édition héxa ça ne te semble pas cohérent que c'est crypté pour autant. C'est juste le paquetage qui donne cette impression. regarde sur supernes par exemple, pour le romhacking (traductions plus spécifiquement). Ce n'est pas crypté, pourtant en ouvrant un quelconque dump snes, y'a rien de lisible ou cohérent...mais dès que tu héxa edites avec un outil capable d'utiliser des tables de transposition, tout devient limpide.
dagostino Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 nintendo ont vraiment du soucis a ce faire, en tout cas leurs boulot est fantastique, il doivent vraiment s'amuser a faire sauter toutes ses protections
dégueux Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 (modifié) ouvre n'importe quel fichier (autre qu'un fichier txt), si tu arrives à y voir quelque chose de clair, tu es fort Les ROM MSX, NES, SMS, SNES, etc, etc... sont en clair. On peut remplacer les textes à l'intérieur sans problème avec éditeur hexadécimal. Il y a eu plein de jeux traduits de cette façon "autrefois". Ls homebrews NDS aussi sont en clair. Modifié le 13 juillet 2009 par dégueux
Badablek Posté(e) le 13 juillet 2009 Posté(e) le 13 juillet 2009 bon on tourne en rond, donc on va faire court, tu as raison ,j'ai tord. maintenant je te mets eu défi de traduire zelda III, rien que celui-là, un des plus anciens jeux supernes, et pas en clair pour un sou ! mais c'est vrai que des programmeurs codent des outils de traduction inutiles comme les éditeurs hexa avec tables... quant aux homebrews, je te rapelle qu'ils n'utilisent pas le SDK Nintendo, donc ils ne sont clairement pas l'exemple à donner. bref, je préfère me taire maintenant, ou je vais encore m'enerver à essayer de faire comprendre quelque chose. ps : j'ai eu plusieurs projets de traduction (et d'améliorations de traduction), et si y'a une chose qui est certaine, c'est que les jeux avec textes en clair ne sont las légion. Et vu que tu ne sembles pas vouloir me croire pour les dumps DS, je t'invite à te renseigner un minimum sur les sites de hack, et tu verras que seule la zone que j'ai maintes fois citée est cryptée.
bitonio6 Posté(e) le 14 juillet 2009 Posté(e) le 14 juillet 2009 Non j'ai trouvé tes explications impressionnantes, c'est sympa de faire partager!
dégueux Posté(e) le 14 juillet 2009 Posté(e) le 14 juillet 2009 bon on tourne en rond, donc on va faire court, tu as raison ,j'ai tord. Je ne cherchais pas à avoir raison. Je disais seulement que rien est en clair donc j'ai supposé que tout est crypté. Après, j'ai seulement contredis tes arguments vaseux. Une simple citation de ce que tu affirmes aurait été mille fois mieux que de monter sur tes grand chevaux. quant aux homebrews, je te rapelle qu'ils n'utilisent pas le SDK Nintendo, donc ils ne sont clairement pas l'exemple à donner. Je le sais très bien. Et cette remarque montre que tu n'as rien compris à mes explications. Tu as raison sur un point et reste bloqué dessus. bref, je préfère me taire maintenant, ou je vais encore m'enerver à essayer de faire comprendre quelque chose. C'est clair. Pas la peine de continuer à discuter avec quelqu'un qui s'énerve à chaque fois pour un rien. La parenthèse est close.
bitonio6 Posté(e) le 15 juillet 2009 Posté(e) le 15 juillet 2009 Chaque fois ça fini comme-ça et au final, on apprend plus rien! Tout cela à cause d'un problème de tempérament, c'est nul quand même!
dinozore Posté(e) le 16 juillet 2009 Posté(e) le 16 juillet 2009 (modifié) Lu, Super news ! Ca risque d'être encore autre chose le hack sur DSi s'ils parviennent à leur fins (et à mon avis il y a de grandes chances pour que ça soit le cas). Merci pour l'info. @bitonio> Toi plus personne t'explique quoi que ce soit, tu reposes les mêmes questions deux semaines après comme si on avait rien dit. Edit: @Badablek et dégueux> Je lisais un peu le début du topic, et je n'avance rien parce que je n'ai aucune idée de comment peuvent bien fonctionner les rom snes, mais je pense que votre conflit vient d'une incompréhension due à la confusion entre cryptage et codage. A mon avis comme sur la plupart des systèmes embarqués ou même plus largement des contextes d'éxécution où l'espace de stocage est limité, on va tendre à coder l'information sur un minimum de place, surtout si celle-ci revient souvent. Par exemple pour du texte uniquement en majuscule on ne va souvent utiliser que 5 bits, etc. Il y a une infinité de combinaisons possibles en fonction du besoin. Après : - Soit c'est une norme et c'est le compilateur qui se charge du transcodage pour le texte du code et les ressources, puis le packeur pour les données, le système éxécutant étant à la norme - Soit c'est libre et dans ce cas chaque fichier de données ou plus globalement chaque jeu possède une ou des tables de spécification de son ou ses codage pour que le système éxécutant conçu pour prendre en charge cette fonctionnalité s'y retrouve - Soit c'est un mélange des deux solutions pour permettre des utilisations plus spécifiques au besoin Comme un éditeur hexadécimal n'est pas devin, il se contente d'afficher les bits dans la correspondance la plus utilisée/standard, c'est à dire avec une interprétation par groupement de 8 bits (donc par octet) avec en plus un transcodage sur la table ascii de ces octets. Les caractères système ainsi que les caractères de la table ascii étendue (qui pour rappel eux ne sont pas universels) étant représentés par des points. Alors on peut dire qu'essayer d'aller lire directement ne serait-ce que le texte contenu dans une rom avec un éditeur hexadécimal c'est presque peine perdue d'avance. Donc rien n'empêche que les données de la rom soient simplement codées et qu'une portion de la rom soit en plus cryptée. ++ Dino Modifié le 16 juillet 2009 par dinozore
bitonio6 Posté(e) le 16 juillet 2009 Posté(e) le 16 juillet 2009 Je dis que c'est dommage de s'engueuler pour ce genre de chose et toi tu viens me critiquer moi... Il fait trop chaud par chez toi ou quoi?!
mellika Posté(e) le 17 juillet 2009 Posté(e) le 17 juillet 2009 Sa suffit les enguelades là, vous etes pas ici pour ça! Quoi qu'il en soit, la team twiizer nous montre une fois de + son talent! D'ailleur je vous propose de venir donner votre avis sur le hack dsi en venant répondre a ce sondage: Que pensez vous, et surtout qu'attendez vous du hack dsi?
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant