Wii Systemmenu hacks

trasguurriellu escribió:*rescue menu patch to boot everything not just diag-discs

¿Ésto exactamente que és, es decir, para qué serviría?

Se que dice algo así como "Parche del menú de rescate para cargar de todo, no solo discos de diagnóstico".

Salu2

Ariath escribió:

trasguurriellu escribió:*rescue menu patch to boot everything not just diag-discs

¿Ésto exactamente que és, es decir, para qué serviría?

Se que dice algo así como "Parche del menú de rescate para cargar de todo, no solo discos de diagnóstico".

Salu2

Con la posibilidad de ser "owneado"... supongo que el menú este es para la gente del SAT y solo carga los discos de diagnostico del SAT, pero con su parche carga cualquier disco.

Aqui esta la noticia en DCemu , es un gran avance

http://www.dcemu.co.uk/wii-systemmenu-hacks-130095.html

No acabo de entender muy bien en que consiste, pero parece interesante ...

Pues consiste en que ha modificado el menu de la wii cosiguiendo por ejemplo el Region free total en wii y GC y un recovery , y ptras chorradas como saltarse la imagen del health del principio

*No healthwarning (the blackscreen is the time it needs to load the channels)
*region free Wii games
*region free GC games
*region free channels
*start the build-in rescue menu when Y is pressed on the first GC controller
*rescue menu patch to boot everything not just diag-discs
*No mainmenu BGM

Lo más interesante es el Canal Disco Region Free Lo de quitar la pantalla de advertencia de salud no tiene mucho sentido si sigue siendo igual de lento cargando, pero bueno, al menos te evita el tener que pulsar un botón.
A lo de quitar el sonido del menú tampoco le veo la gracia. Estaría mejor que se nos permitiese reproducir un sonido personalizado (espero que en un futuro pueda conseguirse).
Además, parece ser que incluye una herramienta de recuperación por si algun futuro parcheo del system menu sale mal. Me recuerda, en parte, al mítico FlashMe de NDS.

Ok ya veo ... dijeramos que es un "Custom SystemMenu" o "Menú de Sistema Personalizado" algo así como un cIOS pero del ejecutable del menú de sistema ... no sabía que las limitaciones de Region Free estuviesen ahí, que curioso, veremos que da de si este tema.

¡¡¡Por fín adiós a esa maldita música del demonio de menú!!!

zarkon escribió:¡¡¡Por fín adiós a esa maldita música del demonio de menú!!!

Pues a mi no me parece tan mal...

quien ha lanzado la aplicación?

Crediar, uno del Team Twiizers (o antes estaba)

Vamos, es el primer custom firmware de wii.

chipan escribió:Vamos, es el primer custom firmware de wii.

el primero que se nota de forma exterior, porque los cios eran tambien como un cf

Al parecer instala los canales de otras regiones (que supongo que se podrán quitar con alguno de los wad unistaller), pero no he podido verlo bien debido a la calidad del video... ojala instale los Canales Tienda USA y Japo para poder comprar los juegos de VC donde no nos timen

Por lo que aparece en la descripción, sale algo así como que es posible revertir los cambios y volver al firmware original. A ver si lo liberan y desde fuentes digamos "fiables" (Team Twiizers) se nos confirma que es seguro de usar, instalar y en caso de que algo salga mal, recuperar.

(Eso sí, cuando lo lancen, que dejen la musiquita puesta, por favor)

Tiene pinta de ser este el CF del que tanto hablaban, viendo que deja activar y desactivar el menu de arranque esto me trae buenos recuerdos.

Esto no ha hecho más que empezar...

crediar no tiene nada que ver con el Team Twiizers (aunque le conocemos, obviamente).

Esto no es un CF (por favor, dejad esa maldita palabra. No hace mas que confundir. Hay que usar términos mas específicos). Son mods del menú del sistema, exactamente como sadmenu, excepto que son cosas mas interesantes. No es permantente y se carga mediante homebrew. crediar lo que ha hecho es similar lo que hicimos nosotros cuando salió IOS37 para comprobar que no causaba bricks (de hecho que yo sepa usa el mismo código unstub que ya he pasteado por ahí), y que ha salido ahora en forma de el sadmenu y otras cosas. A ver si me animo y saco el nuestro, que lo tengo aparcado por aquí pero ya hace bastantes cosas útiles como las que menciona crediar. Lo del parche del menú de diagnóstico es curioso pero inutil, porque estos parches del menú se hacen dinámicamente, y realmente el único uso del menú de diag es si no puedes cargar nada mas, es decir, si tienes la wii brickeada. Lo que si permite esto son cosas como el regionfree, pero siempre a través de homebrew. Las modificaciones sólo se activan al cargar la aplicación, no son permanentes.

En cuanto a lo del menú de recuperación... Resulta que hay un dispositivo de hardware que al enchufarse en la Wii, hace que el menú del sistema salte toda la inicialización normal y directamente pase a cargar discos autoboot. Con esto podríamos recuperar Wiis que hayan sido brickeadas pero que todavía empiecen a mostrar el menú del sistema, por lo menos, siempre y cuando no tengan 3.3 y siempre y cuando tengan chip. Bueno, lo de la 3.3 es salvable mediante zelda y twilight hack, pero sigue siendo necesario tener chip. Algunos lo compararían a la batería de pandora de la PSP, aunque esto opera a un nivel mucho mas alto y no sirve para nada si el menú en sí está mal instalado, o si IOS o boot2 están mal. Sin embargo, es probable que se pueda usar para reparar bricks de los que sacan un error de opera nada mas arrancar, y en general todo brick que al menos llegue a mostrar algo en pantalla.

Estoy diseñando el dispositivo ahora mismo, a ver si rula. Bueno, no, no rula porque el periférico SPI de los PICs es una puta mierda, a ver si me agencio algún micro mas decente...

Resumiendo, que la técnica no es nada nueva (nosotros lo hacíamos en abril por lo menos ), aunque crediar es el primero en demostrar parches útiles con ella (nosotros la usamos para cambiar el IOS y para sacar información de debug por el USBGecko).

¿Entonces la region free se basa en parchear el menú de sistema al vuelo con un programa homebrew cargado desde el HBC? Al menos así parece que se hace en el video de Youtube. No sería muy distinto del GeckoOS, pero por lo menos tendríamos seguridad 100% de que el juego va a funcionar antes de estar gastandonos los dineros con incertidumbre.

Tal y como lo pones, parece que todavía falta bastante hasta ver un mod del sistema que no requiera tantas florituras para la region free total.

Edit: parece que ya lo he pillado. Primero se carga un dol que reinicia la Wii con el System Menu modificado y trucado (de manera temporal) para posteriormente, cargar dentro de él otro dol que permite cargar juegos de cualquier región. Dicho System Menu también permite ejecutar canales de otras regiones, y cuando apagas la consola, ésta vuelve a su estado original. ¿Estoy equivocado?

beje escribió:¿Entonces la region free se basa en parchear el menú de sistema al vuelo con un programa homebrew cargado desde el HBC? Al menos así parece que se hace en el video de Youtube. No sería muy distinto del GeckoOS, pero por lo menos tendríamos seguridad 100% de que el juego va a funcionar antes de estar gastandonos los dineros con incertidumbre.

Correcto.

beje escribió:Tal y como lo pones, parece que todavía falta bastante hasta ver un mod del sistema que no requiera tantas florituras para la region free total.

Se puede parchear directamente, pero también es peligrosísimo.

Nuestra idea es hacer lo mismo que hacemos ahora, pero meter el sistema de parcheo dentro de IOS (a su vez parcheado desde boot2, a su vez parcheado desde nuestro cargador). Así es lo mismo, pero funciona desde que arrancas, y sigue siendo 100% reversible.

beje escribió:Edit: parece que ya lo he pillado. Primero se carga un dol que reinicia la Wii con el System Menu modificado y trucado (de manera temporal) para posteriormente, cargar dentro de él otro dol que permite cargar juegos de cualquier región. Dicho System Menu también permite ejecutar canales de otras regiones, y cuando apagas la consola, ésta vuelve a su estado original. ¿Estoy equivocado?

Lo que hace es identificarse como el menú, cargar el DOL del menú en memoria, y luego lanzarlo. No hay que truchear nada ni guardar nada, se hace todo en RAM. Esto solo funciona porque el menú se carga de forma especial, manualmente, con lo que se tiene el control sobre el. Lo normal es que lo cargue IOS y no puedas hacer nada (y eso es lo que pasa al reiniciar).

Muchas gracias por la aclaración, y respecto a esto:

Nuestra idea es hacer lo mismo que hacemos ahora, pero meter el sistema de parcheo dentro de IOS (a su vez parcheado desde boot2, a su vez parcheado desde nuestro cargador). Así es lo mismo, pero funciona desde que arrancas, y sigue siendo 100% reversible.

Espero que esté listo pronto, sobre todo la parte de que se pueda hacer reversible, más que nada porque los que no tenemos chip, como consigamos un brick por cualquier tontería, nos toca cargarnos la garantía e instalar uno para poder desbrickear.

Eso sí, no hagais caso de los cagaprisas y sacadlo cuando esté 100% testeado. Felicidades y seguid con el buen trabajo.

marcansoft escribió:
Resumiendo, que la técnica no es nada nueva (nosotros lo hacíamos en abril por lo menos ), aunque crediar es el primero en demostrar parches útiles con ella (nosotros la usamos para cambiar el IOS y para sacar información de debug por el USBGecko).

Marcansoft me agrada, es un excelente scener, lo único malo es que cada vez que alguien saca algo, tiene que mencionar:"nosotros lo hicimos antes".

¿Porqué no se limita a decir toda la explicación y dejarnos boquiabiertos como siempre?

Eres un genio marcansoft, solo (con todo respeto) como que te hace falta algo de humildad.

De cualquier forma gracias mano por todo tu gran trabajo.

Es que marcansoft está disfrutando de su momento de gloria en Internet.

Cada día este subforo se parece más al Aquí hay Tomate: primero la carta a Nintendo, luego las peleas con waninkoko al más puro estilo Karmele y Mariñas y ahora el "En breves momentos la librería mágica de marcansoft"

En fin, porque lo pone el nombre del foro...pero haber si alguien serio toma las riendas de la Scene.

atomex escribió:

marcansoft escribió:
Resumiendo, que la técnica no es nada nueva (nosotros lo hacíamos en abril por lo menos ), aunque crediar es el primero en demostrar parches útiles con ella (nosotros la usamos para cambiar el IOS y para sacar información de debug por el USBGecko).

Marcansoft me agrada, es un excelente scener, lo único malo es que cada vez que alguien saca algo, tiene que mencionar:"nosotros lo hicimos antes".

¿Porqué no se limita a decir toda la explicación y dejarnos boquiabiertos como siempre?

Eres un genio marcansoft, solo (con todo respeto) como que te hace falta algo de humildad.

De cualquier forma gracias mano por todo tu gran trabajo.

+ 1.

Muy en lo cierto, y es algo curioso, de que sale algo nuevo de wii el ya lo tenia, lo sabia, estaban trabajando en ello, nosotros se lo dijimos, etc .....
muy curioso realmente.

beyako escribió:

atomex escribió:

marcansoft escribió:
Resumiendo, que la técnica no es nada nueva (nosotros lo hacíamos en abril por lo menos ), aunque crediar es el primero en demostrar parches útiles con ella (nosotros la usamos para cambiar el IOS y para sacar información de debug por el USBGecko).

Marcansoft me agrada, es un excelente scener, lo único malo es que cada vez que alguien saca algo, tiene que mencionar:"nosotros lo hicimos antes".

¿Porqué no se limita a decir toda la explicación y dejarnos boquiabiertos como siempre?

Eres un genio marcansoft, solo (con todo respeto) como que te hace falta algo de humildad.

De cualquier forma gracias mano por todo tu gran trabajo.

+ 1.

Muy en lo cierto, y es algo curioso, de que sale algo nuevo de wii el ya lo tenia, lo sabia, estaban trabajando en ello, nosotros se lo dijimos, etc .....
muy curioso realmente.

+1.
Marcam creo que te tenemos que dar tu regañada los compañeros que te admiramos. Te agradecemos y te necesitamos y sabemos de lo que eres capaz. pero las ideas son de quien las realiza y las demuestra. Si tenemos una idea y nunca la desarrollamos de nada vale. si llega otro y la lleva a la practica, pues nomodo valdra mas colaborar que llorar o criticar.
Sigue adelante, nunca pa traz.
Saludos Idolo

Estoy completamente de acuerdo y no dudo que sea verdad pero si no lo enseñas en su tiempo y te lo guardaste para ti pues no digas que tu lo tenias desde antes... pero creo que se porque no enseñan todo lo que van descubriendo porque despues sale la gente a preguntar que cuando lo liberan, etc, etc.

EStoy seguro que MARCAN va a aparecer y colocar un mensaje:
"perdonen muchachos, no quise sonar PEDANTE", parece muy inteligente como para serlo!!!

Yo no he dicho que crediar no haya hecho nada util ni mucho menos, ni que no haya "descubierto" nada. Tan solo informo de que la técnica no es nueva - es dificil interpretar exactamente qué está pasando desde el vídeo. Y eso no lo digo solo por cualquier tool interna que tuviéramos en abril, que evidentemente no sirve para nada si no la sacamos, sino por sadmenu, que usa exactamente la misma técnica. Una cosa es la técnica y otra es uso que se le de. En este caso, el uso es nuevo, y ahí está la gracia del tema. Pero bueno, ya que crediar no ha sacado nada de momento (solo el vídeo), voy a ver si pulo la tool un poco esta tarde y la saco (con código fuente).

Me disculpo si lo de abril se ha podido malinterpretar.

Por otro lado, acabo de anunciar casi una batería de pandora para la Wii, y habéis pasado olímpicamente de esa parte. ¿Que os pasa?

volviendo al tema....
si logra region free en gc y en wii, fuerza el idioma?
lo pregunto por metroid de wii y juegos de gc que reconocen el idioma nativo de la consola :/ (no el del que uno selecciona en el caso de ntsc-u)

La región de la consola no se cambia, así que el juego sigue viendo la región antigua. La única forma segura de solucionar esto es mediante parches de IOS.

Marcan, ese dispositivo que mencionas, ¿De que forma se conectaría a la consola? ¿Habría que abrir la carcasa?

Slot de Memory card de gamecube.

marcansoft escribió:La región de la consola no se cambia, así que el juego sigue viendo la región antigua. La única forma segura de solucionar esto es mediante parches de IOS.

clarisimo
y ustedes lo tienen considerado dentro de sus proyectos ?

Se me acaba de ocurrir una solución casera para el problema, sin necesidad de tocar IOS (de momento). Pasaría por parchear juegos, pero dinámicamente (igual que se hace aquí con el menú).

¿Exactamente en que momento se comprueba si el dispositivo está conectado? ¿Lo hace el boot0, el 1 o el 2? Lo ideal sería que el "arranque especial" se iniciase ya desde el boot0 para poder recuperar cualquier brick por grave que fuese, pero me imagino que no tendremos tanta suerte...

Una cosa más, en caso de un brick de los que hacen época, digamos corrupción total de los archivos del sistema, ¿Teneis idea de como lo soluciona Nintendo? ¿Consola nueva y a la basura con la antigua? ¿Reprogramación de la NAND con un dispositivo especial?

marcansoft escribió:Se me acaba de ocurrir una solución casera para el problema, sin necesidad de tocar IOS (de momento). Pasaría por parchear juegos, pero dinámicamente (igual que se hace aquí con el menú).

y eso seria como
¿forzar lenguaje antes de lectura de juego? algo asi como lo hace gecko os
o
¿modificar idioma del juego en si mediante varias cargas/modificaciones usando la ram de la wii?

sea cual sea y que sirvan para wii y gc seria increible, asi no se pasan riesgos de brickeos

frontier escribió:¿Exactamente en que momento se comprueba si el dispositivo está conectado? ¿Lo hace el boot0, el 1 o el 2? Lo ideal sería que el "arranque especial" se iniciase ya desde el boot0 para poder recuperar cualquier brick por grave que fuese, pero me imagino que no tendremos tanta suerte...

Claro, pero por desgracia (y esto ya lo dijimos en hackmii) no hay nada de ese estilo en boot0, 1, o 2. La comprobación la hace el menú del sistema. De ahí que sirva para arreglar bricks donde por lo menos se llegue a el (que salga algo en pantalla, aunque sea un error de opera o se quede colgado segundos después), pero no sirve para nada en casos mas graves como una corrupción o mala instalación de IOS o el menú en sí. Sin embargo, la gran mayoría de bricks, que sepamos, son del primer tipo, así que todavía puede tener mucha utilidad.

frontier escribió:Una cosa más, en caso de un brick de los que hacen época, digamos corrupción total de los archivos del sistema, ¿Teneis idea de como lo soluciona Nintendo? ¿Consola nueva y a la basura con la antigua? ¿Reprogramación de la NAND con un dispositivo especial?

Sospechamos que lo primero (o al menos la placa base). Pero puede que haya algun backdoor de hardware, aunque desde luego no hemos visto nada en el software. Se baraja la posibilidad de que haya un boot0 alternativo que se carga cuando se hace "algo" con el hardware, pero no tenemos pruebas de ello. Quizás haya un puerto JTAG, en forma de testpoints o multiplexado por ahí (hay quien dice que puede que el puerto de conexión con el DVD, el DI, sirva para algo mas que para eso si consigues ponerlo en ese modo, pero hasta ahora todo es especulación).

koji nanjo escribió:y eso seria como
¿forzar lenguaje antes de lectura de juego? algo asi como lo hace gecko os
o
¿modificar idioma del juego en si mediante varias cargas/modificaciones usando la ram de la wii?

Yo mas bien diría parchear el juego en RAM para convertir "setting.txt" en otro archivo, crearlo con los datos que quieras, y de esa forma conseguir que el juego vea la configuración de la consola que quieras sin tener que cambiar la real. Lo mismo con SYSCONF para temas de idioma etc.

Para GameCube la cosa es bastante mas fácil. Lo que hay que hacer es conseguir hacer un cargador de juegos de gamecube homebrew, y luego editar los settings en la SRAM, que normalmente se copian directamente desde la NAND en el menú del sistema.

marcansoft escribió:Por otro lado, acabo de anunciar casi una batería de pandora para la Wii, y habéis pasado olímpicamente de esa parte. ¿Que os pasa?

[modo broma/ironía-on] ¿Esto va a servir para cargar mis backups sin chip? [modo broma/ironía-off] jajajaja

marcansoft escribió:

frontier escribió:Una cosa más, en caso de un brick de los que hacen época, digamos corrupción total de los archivos del sistema, ¿Teneis idea de como lo soluciona Nintendo? ¿Consola nueva y a la basura con la antigua? ¿Reprogramación de la NAND con un dispositivo especial?

Sospechamos que lo primero (o al menos la placa base). Pero puede que haya algun backdoor de hardware, aunque desde luego no hemos visto nada en el software. Se baraja la posibilidad de que haya un boot0 alternativo que se carga cuando se hace "algo" con el hardware, pero no tenemos pruebas de ello. Quizás haya un puerto JTAG, en forma de testpoints o multiplexado por ahí (hay quien dice que puede que el puerto de conexión con el DVD, el DI, sirva para algo mas que para eso si consigues ponerlo en ese modo, pero hasta ahora todo es especulación).

Se que es muy evidente, pero ¿Alguien ha intentado hacer una marca en la placa, causar un brick "serio", enviar la consola al SAT y comprobar si la placa devuelta es la misma? Aunque no me imagino quien iba a querer gastarse 70€ de su bolsillo para comprobarlo...

Las especulaciones acerca de una segunda ROM con un boot0 alternativo, ¿Se basan en alguna evidencia por minúscula que sea? Si boot1 se puso en la NAND en parte por ahorrar costes me extraña que Nintendo se haya gastado dinero en una segunda ROM, cuando seguramente sería más barato enviar una consola nueva, teniendo en cuenta el reducido número de bricks que se producen por causas "naturales".

marcansoft escribió:Yo mas bien diría parchear el juego en RAM para convertir "setting.txt" en otro archivo, crearlo con los datos que quieras, y de esa forma conseguir que el juego vea la configuración de la consola que quieras sin tener que cambiar la real. Lo mismo con SYSCONF para temas de idioma etc.

Para GameCube la cosa es bastante mas fácil. Lo que hay que hacer es conseguir hacer un cargador de juegos de gamecube homebrew, y luego editar los settings en la SRAM, que normalmente se copian directamente desde la NAND en el menú del sistema.

marcan, el setting.txt supongo que se lee usando funciones de IPC... tal vez puedas pinchar dinámicamente esas funciones, tal y como yo hacia en PS2 para tomar el control de ciertos dispositivos y así suministrar el setting.txt a la carta.

marcansoft escribió:Por otro lado, acabo de anunciar casi una batería de pandora para la Wii, y habéis pasado olímpicamente de esa parte. ¿Que os pasa?

Entiendeló son demasiadas noticias en muy poco tiempo.

De ser así los que van a hacer el agosto son las tiendas de reparación. Ya lo estoy viendo "30€ y te desbrickeamos tu wii" igual que pasó con la pandora de la psp.

Espero que los componentes sean faciles de encontrar ya que con la pandora se agotaron las baterías de psp en 2 días.

Es que todavía queda la pregunta: ¿cómo se programa la NAND inicialmente?

Hasta ahora la mejor explicación que tenemos es que las preprograman externamente, pero no acaba de convencernos. Normalmente es mucho mas barato soldar la NAND tal cual y luego programarla desde algún puerto especial.

Hermes escribió:marcan, el setting.txt supongo que se lee usando funciones de IPC... tal vez puedas pinchar dinámicamente esas funciones, tal y como yo hacia en PS2 para tomar el control de ciertos dispositivos y así suministrar el setting.txt a la carta.

Eso al final supondría parchear el juego de todas formas (los juegos traen todas las libs de acceso al hardware), o parchear IOS. Por IOS se podría, pero habría que hacer un driver aparte de IOS que impersone al setting.txt, lo cual es bastante mas complicado que simplemente hacer un search+replace del ejecutable del juego, cambiar setting.txt por setting.tx2, y luego crear el archivo con el contenido que nos de la gana.

Las piezas del dispositivo este no son difíciles de encontrar, pero me gustaría poder venderlos (a un precio justo, eso sí) para por lo menos sacar un dinerillo para poder comprar alguna cosilla para ayudar al desarrollo. Si la cosa se desmadra, y como no creo que tarden en clonarlo de todas formas, pues se saca el código fuente y los esquemas y punto.

marcansoft escribió:

Hermes escribió:marcan, el setting.txt supongo que se lee usando funciones de IPC... tal vez puedas pinchar dinámicamente esas funciones, tal y como yo hacia en PS2 para tomar el control de ciertos dispositivos y así suministrar el setting.txt a la carta.

Eso al final supondría parchear el juego de todas formas (los juegos traen todas las libs de acceso al hardware), o parchear IOS. Por IOS se podría, pero habría que hacer un driver aparte de IOS que impersone al setting.txt, lo cual es bastante mas complicado que simplemente hacer un search+replace del ejecutable del juego, cambiar setting.txt por setting.tx2, y luego crear el archivo con el contenido que nos de la gana.

Entonces supongo que la idea es crear tres archivos setting.txt en el dispositivo para cada una de las regiones y proceder a renombrar en la carga del ejecutable setting.txt por por ejemplo, setting.usa en la cadena del ejecutable.

marcansoft escribió:Las piezas del dispositivo este no son difíciles de encontrar, pero me gustaría poder venderlos (a un precio justo, eso sí) para por lo menos sacar un dinerillo para poder comprar alguna cosilla para ayudar al desarrollo. Si la cosa se desmadra, y como no creo que tarden en clonarlo de todas formas, pues se saca el código fuente y los esquemas y punto.

Buff, te van a llover palos por pretender venderlo: eso si, si lo sacas gratis y las tiendas se forran por vender el dispositivo ya hecho o los chipeadores cobran 30E por recuperar una consola, eso está bien

Hermes escribió:Entonces supongo que la idea es crear tres archivos setting.txt en el dispositivo para cada una de las regiones y proceder a renombrar en la carga del ejecutable setting.txt por por ejemplo, setting.usa en la cadena del ejecutable.

Yap. Aunque bueno, en el archivo van mas opciones, así que también se puede crear dinámicamente uno solo cada vez que cargues un juego. No me vale el argumento de que la NAND se desgasta, porque la Wii ya crea y borra archivos en la NAND varias veces cada vez que la enciendes.

Hermes escribió:Buff, te van a llover palos por pretender venderlo: eso si, si lo sacas gratis y las tiendas se forran por vender el dispositivo ya hecho o los chipeadores cobran 30E por recuperar una consola, eso está bien

Se pensarán que me van a llover billetes o algo, y por eso quieren compensarlo con los palos

marcansoft escribió:

Hermes escribió:Entonces supongo que la idea es crear tres archivos setting.txt en el dispositivo para cada una de las regiones y proceder a renombrar en la carga del ejecutable setting.txt por por ejemplo, setting.usa en la cadena del ejecutable.

Yap. Aunque bueno, en el archivo van mas opciones, así que también se puede crear dinámicamente uno solo cada vez que cargues un juego. No me vale el argumento de que la NAND se desgasta, porque la Wii ya crea y borra archivos en la NAND varias veces cada vez que la enciendes.

Hombre, si eres capaz de detectar las funciones que hacen esa lectura, siguiendo el rastro de la cadena, tal vez pudieras pasarle los datos directamente, aunque claro, eso requeriría conocer todas las librerías a nivel ensamblador y poder parchear las funciones con un código que estuviera fuera del alcance del programa (para que no te lo machaque) y de esa forma, poder tener un settings personalizado sin necesidad de tocar la NAND.

<ironic mode> A pero acaso dudas de Marcan, fue el que le filtro a nintendo la estructura y los planos de construcción de la wii </ ironic mode>

no me he podido resistir

Ups, parece que crediar si que está instalando los parches en la NAND, al contrario que lo que yo pensaba... Algunos lo llamarán "CF".

Para mi lo convierte en algo muy peligroso, pero bueno, cada cual que haga lo que quiera

Yo voy a sacar la versión segura (usando parches en RAM temporales) un día de estos. Inconveniente: tienes que ejecutarla desde homebrew. Ventaja: es totalmente reversible, y además funciona para todos los menús del sistema (el de crediar es específico para una versión en concreto).

marcansoft escribió:Ups, parece que crediar si que está instalando los parches en la NAND, al contrario que lo que yo pensaba... Algunos lo llamarán "CF".

Para mi lo convierte en algo muy peligroso, pero bueno, cada cual que haga lo que quiera

Yo voy a sacar la versión segura (usando parches en RAM temporales) un día de estos. Inconveniente: tienes que ejecutarla desde homebrew. Ventaja: es totalmente reversible, y además funciona para todos los menús del sistema (el de crediar es específico para una versión en concreto).

A ver si lo he entendido bién. Tú propones una especie de Devhook de forma que las aplicaciones se cargen en la RAM y se borren al apagar la Wii ¿No? Mientras que crediar los está ejecutando desde la Nand.

Buff... Fuerte marejada de wii´s brickeadas por occidente.

Elnef escribió:A ver si lo he entendido bién. Tú propones una especie de Devhook de forma que las aplicaciones se cargen en la RAM y se borren al apagar la Wii ¿No? Mientras que crediar los está ejecutando desde la Nand.

Correcto. Solo que yo mas que proponer lo tengo hecho y funcionando, pero me falta limpiarlo un poco y ponerle un menú.

Cuando tengamos el pre-boot2, el siguiente paso es hacer lo mismo con el BOOT2. Y desde ahi se puede controlar que título del sistema se ejecuta al arrancar (en lugar del menú del sistema). Podemos instalar este "devhook" como título, y luego decirle a boot2 que lo cargue al arrancar. El resultado es el mismo que con lo de crediar, incluyendo que sale directamente al arrancar, solo que es 100% reversible (si metemos los parches en una SD, por ejemplo, sería cuestión de sacar la SD).

marcansoft escribió:

Elnef escribió:A ver si lo he entendido bién. Tú propones una especie de Devhook de forma que las aplicaciones se cargen en la RAM y se borren al apagar la Wii ¿No? Mientras que crediar los está ejecutando desde la Nand.

Correcto. Solo que yo mas que proponer lo tengo hecho y funcionando, pero me falta limpiarlo un poco y ponerle un menú.

Cuando tengamos el pre-boot2, el siguiente paso es hacer lo mismo con el BOOT2. Y desde ahi se puede controlar que título del sistema se ejecuta al arrancar (en lugar del menú del sistema). Podemos instalar este "devhook" como título, y luego decirle a boot2 que lo cargue al arrancar. El resultado es el mismo que con lo de crediar, incluyendo que sale directamente al arrancar, solo que es 100% reversible (si metemos los parches en una SD, por ejemplo, sería cuestión de sacar la SD).

Pero entonces tu sistema también implica instalar "cosillas" en la nand. Pero en lugar de instalar los parches que se van a arrancar, vaís a instalar el sistema de arranque de los parches que estarán en la SD. ¿Es eso?

¿Y ese sistema es más seguro?

Desde luego modificas menos la nand y cualquier actualización del sistema la realizarias sobre la SD. A mi me parece mas seguro.

Modificas 1 vez y no tienes que volver a tocar la nand ¿no?. A mi lo que me preocuparía es que fallase al modificar el Boot2 ya que si no he leido antes mal, la tarjeta que tiene en mente Marcan para recuperar los Wii brick se iniciaba desde boot2.

Digo boot2 por que si no entendi mal la conferencia de marcan los Boot0 y Boot1 no se pueden tocar.