[PROYECTO] SOFTMOD

ArangeL escribió:...

No habia leido que la encriptacion en los juegos era de curva eliptica, fallo mio. En cualquier caso sigue siendo simple. Si no vamos a leer del DVD el sistema esta a nuestro cargo, y podemos desencriptar las ISO, eliminar las partes no usadas, dividir el resto en dos archivos y hacer las llamadas desde nuestra interfaz. Las llamadas a IOS serian las mismas, el modulo en vez de leer el DVD y desencriptar nada, directamente leeria del HD.

technik escribió:

ArangeL escribió:...

No habia leido que la encriptacion en los juegos era de curva eliptica, fallo mio.

¡O MIO! No se que encriptaciones usaban los discos, simplemente no me interesa saberlo. CREO que será elíptica por el hecho de que cambio un byte en un fichero que no es necesario para iniciar el juego; y la consola se niega a cargar el main.dol
Mira el código fuente de zeiger, que está muy simplificado (pero sin documentar).

Wiibrew escribió:Game discs
Game discs are encrypted to avoid analysis, and signed to avoid modifications.
The encryption is a symmetric cipher, 128 bit AES-CBC. Each disc usually contains two or more partitions. Each partition has its own AES key, referred to as a "title key". This key is stored on the disc, inside of a "ticket", but it is encrypted with the master AES key. So, with the master AES key you can decrypt the title keys, and with the title keys you can decrypt the partitions. Lucky for us, the master AES key was extracted by the Tweezer hack.

Nosotros aqui pensando como saltarnos la curva eliptica y resulta que usa Cifrado por bloques de 128 bits xDD

Lo que hace la wii es encriptar solo los datos utilies, es sencillo. Podemos partir el archivo siempre que se respeten los bloques de cifrado y utilizar el ultimo bloque del primer archivo como vector del segundo. Además podemos eliminar las partes no usadas sin problemas.

venga chicos reconozco que cada vez es mas imposible seguir el hilo si no tienes suficiente conocimientos,per animo, PODEMOS.

Que nadie se confunda, yo no me meto en mas proyectos xDD, yo doy las ideas que se me van ocurriendo. Lo que pasa es que como me gusta el tema pues acabo hablando xD.

technik escribió:

Wiibrew escribió:Game discs
Game discs are encrypted to avoid analysis, and signed to avoid modifications.
The encryption is a symmetric cipher, 128 bit AES-CBC. Each disc usually contains two or more partitions. Each partition has its own AES key, referred to as a "title key". This key is stored on the disc, inside of a "ticket", but it is encrypted with the master AES key. So, with the master AES key you can decrypt the title keys, and with the title keys you can decrypt the partitions. Lucky for us, the master AES key was extracted by the Tweezer hack.

Nosotros aqui pensando como saltarnos la curva eliptica y resulta que usa Cifrado por bloques de 128 bits xDD

Lo que hace la wii es encriptar solo los datos utilies, es sencillo. Podemos partir el archivo siempre que se respeten los bloques de cifrado y utilizar el ultimo bloque del primer archivo como vector del segundo. Además podemos eliminar las partes no usadas sin problemas.

Pues vaya puta mierda de sistema de seguridad. Encriptando en RSA puro con una llave de 1024bits privada [Tamaño de la clave= 1024 | tamaño Index del RSA = 11 | tamaño del bloque de datos = ((1024/8)-11) | tamaño del bloque index+data = 128].

Pues vaya puta mierda de sistema de seguridad.

Esto lo he oido antes .... que esperabas ¿un condensador de fluzo? No la tienen muy bien protegida, pero tampoco parece interesarles, solo mira la pedazo de actualización que hicieron para capar el twilight hack.

Ya que se esta hablando de temas técnicos, alguien me podria explicar como hace la Wii para saber que un dvd es estampado (original) o grabado (backup)?

Es lo que tiene ser curioso... grácias

Creo que es con el código de barras que tienen los dvd originales de nintendo. La idea que se barajaba hace tiempo es que el lector busca ese código de barras, y si no lo encuentra pues se niega a leer el dvd. Los modchips se encargan de hacerle entrar en razón. Es una operación hardware y hasta hace poco se decía que no se podía cambiar usando software, aunque se supone que con las instrucciones de DVDLowEnableDvdVideo es posible saltarse esa restricción.

ArangeL escribió:

technik escribió:

Wiibrew escribió:Game discs
Game discs are encrypted to avoid analysis, and signed to avoid modifications.
The encryption is a symmetric cipher, 128 bit AES-CBC. Each disc usually contains two or more partitions. Each partition has its own AES key, referred to as a "title key". This key is stored on the disc, inside of a "ticket", but it is encrypted with the master AES key. So, with the master AES key you can decrypt the title keys, and with the title keys you can decrypt the partitions. Lucky for us, the master AES key was extracted by the Tweezer hack.

Nosotros aqui pensando como saltarnos la curva eliptica y resulta que usa Cifrado por bloques de 128 bits xDD

Lo que hace la wii es encriptar solo los datos utilies, es sencillo. Podemos partir el archivo siempre que se respeten los bloques de cifrado y utilizar el ultimo bloque del primer archivo como vector del segundo. Además podemos eliminar las partes no usadas sin problemas.

Pues vaya puta mierda de sistema de seguridad. Encriptando en RSA puro con una llave de 1024bits privada [Tamaño de la clave= 1024 | tamaño Index del RSA = 11 | tamaño del bloque de datos = ((1024/8)-11) | tamaño del bloque index+data = 128].

Estoy seguro que no sabes de lo que estas hablando.

Salu2.

Edit: El "GRAN FALLO" no esta en el cifrado ni en las firmas RSA: El fallo esta en la comprobación de las firmas, por lo demás el sistema es una "MARAVILLA" y muy seguro.

Aquí hay más información acerca de los discos, y algo de información sobre como desencriptar los datos:

http://wiibrew.org/wiki/Wiidisc

Pifia escribió:[...]

Te he enviado un MP para tí. Aparte añado aquí que usar RSA para encriptar en bloques de 128 no es buena idea. El sistema RSA no está diseñado para encriptar grandes cantidades de información. Pues en cada bloque de 128, se usan 11 para uso interno de RSA. Además, si se quiere "mejorar" la llave, usando por ejemplo, una longitud de 2048; ya no sería lógico encriptar en bloques de 128; sino en 256, pues así tan sólo gastamos (nºbloques_totales/2*11) de lo que hubiésemos gastado en caso de usar bloques de 128. Para mi, es algo muy deficiente. Así pues, una clave de 1024bits puede encriptar (128-11)bytes; una de 2048bits encriptará (256-11)bytes; etc. Y usar encriptación RSA en bloques de 128bytes fijos... no es lo más apropiado. Por supuesto que es seguro ¬¬, pero no es apropiado; pues no es una encriptación adaptada para grandes cantidades de información; se desperdician 11bytes por cada bloque y encriptar TARDA BASTANTE; y desencriptar también (mucho menos, pero también); por no hablar de lo inseguro que será en el futuro (cercano, pues ya es posible ¬¬) desencriptar bloques de 128bytes fijos. Mucho más seguro es usar RSA para encriptar una clave, y luego usar otros algoritmos más rápidos y con soporte a longitud variable usando la clave encriptada por RSA.

nuvalo escribió:Aquí hay más información acerca de los discos, y algo de información sobre como desencriptar los datos:

http://wiibrew.org/wiki/Wiidisc

Los datos de la partición están cifrados con AES128 utilizando la Titlekey que a su vez está cifrada con la commonkey.El patrón de cifrado que se sigue es el siguiente :
Grupos de 2 megabytes:
Cada grupo contiene 8 sub grupos de 32768bytes * 8 cad uno :
Cada sub subgrupo esta formado por 8 clusters de 32768 bytes cada uno:
Cada Cluster de 32 kbytes de tamaño esta cifrados con la clave del titulo y un Vector de inicialización (IV) conseguido a partir de la tabla de verificación de hash H2 (usando los 16 últimos bytes).
Antes de cada cluster existe una cabecera que contiene 32 hash sha1 por cada bloque de 1024 bytes que conforma el cluster, la tabla h1 y la tabla h2.
La tabla de Hash h1 se consigue a partir de hacer sha1 a la suma de las 8 tablas de un subgrupo.
La tabla de hash h2 se consigue a partir de hacer sha1 a la suma de las 8 tablas de hash de h1.

Ahora viene h3 o tabla maestra de hash que está formada con los hash sha1 de cada una de las tablas h2, esta tabla se guarda en una zona del disco (ver wiibrew) y no esta cifrada.
Luego viene h4 o hash de comprobación para la firma. H4 es un único hash que resulta de aplicar sha1 a la tabla maestra. Aplicando RSA y la clave privada de Nintendo sobre el TMD donde esta guardada h4 se consigue la firma original para todos los datos, la wii al inicio verifica el hash sha1 de la tabla maestra contra el hash cifrado en la firma, obtenido mediante la clave pública y comprueba ambas para verificar que son iguales.

Hoy por hoy es imposible romper este sistema de protección, a menos que se meta la pata en el código de comprobación de firmas como sucedió en el caso de la WII.

Es obvio que si se cambia un solo byte de los datos validados por las diferentes tablas de hash se deberán modificar todas para validar los datos y deberá aplicarse nuevamente el metodo trucha para validar el nuevo h4 en el tmd.

Espero que con estas explicaciones os resulte comprensible, este genial sistema.

Salu2.

P.d. Debo añadir y no podía ser de otra manera, que esta información que expongo está basada en los datos que publicaron el "Team Twizers" y que son los mismos que utilizé para desarrollar varias aplicaciones para cifrar y descifrar particiones de la WII, así que mi único mérito fue entender su funcionamiento y aplicarlo

nuvalo escribió:Aquí hay más información acerca de los discos, y algo de información sobre como desencriptar los datos:

http://wiibrew.org/wiki/Wiidisc

Gracias! Mira que no mirar en wiibrew x"D

Pues la verdad, se me escapan bastante cosas del texto

...lo que habia pensado inicialmente era reescribir y remplazar por cumpleto el modulo DI.. haciendo un wrapper como mencionaba Nuvalo.. pero ahora con toda esta discusion acerca de la encripcion.. que pasa si simplemente, NO encryptamos el disco, (escribimos los datos en bruto en el), habilitamos el modo DVDvideo y luego cambiamos DVDRead, por DVDRead dvd video? (esto ya sea al main dol, o en ios (yo diria mejor en IOS))

kikekakik escribió:...lo que habia pensado inicialmente era reescribir y remplazar por cumpleto el modulo DI.. haciendo un wrapper como mencionaba Nuvalo.. pero ahora con toda esta discusion acerca de la encripcion.. que pasa si simplemente, NO encryptamos el disco, (escribimos los datos en bruto en el), habilitamos el modo DVDvideo y luego cambiamos DVDRead, por DVDRead dvd video? (esto ya sea al main dol, o en ios (yo diria mejor en IOS))

Seguiría sin funcionar, pero ese es el camino. La solución la encontró marcan.

Salu2.

Nuvalo,
respecto a lo de crear una interfaz con el tool de 'custom ios module', estoy contigo, al principio del hilo propuse exactamente eso.

Pero creo que no haria falta parchear las isos para que usen otro dispositivo, en teoria bastaria con reemplazar el mismo /dev/di para que se comporte igual que el modulo original. (un wrapper como acabais de decir)
Respecto a lo que acaba de decir kikekakik:

que pasa si simplemente, NO encryptamos el disco, (escribimos los datos en bruto en el), habilitamos el modo DVDvideo y luego cambiamos DVDRead, por DVDRead dvd video? (esto ya sea al main dol, o en ios (yo diria mejor en IOS))

Lo de la encriptacion y las lecturas de backups sin chip son problemas que deberiamos tratar por separado, o se podria acabar con un lio de narices .
Aqui cual es nuestra prioridad? habilitar backups sin chip a traves del exploit que esta por descubrir en su totalidad, o de otro dispositivo tipo una SD ?
A mi me interesa lo segundo, reescribiendo el modulo /dev/di. El problema del tamaño es solo algo temporal. Y la parte de leer de SD o USB esta documentada.

Lo que habria que descubrir es:
1) Que funcion usan normalmente los juegos para leer datos?
2) si hacen LowRead, entonces ellos mismos hacen las llamadas respectivas a /dev/aes ?(que es donde supongo que se realizan las tareas de encriptacion/desencriptacion)
3) Sin tener documentado http://www.wiibrew.org/wiki//dev/aes lo llevamos un poco mas chungo, no he mirado aun si esta en el cvs de la libogc. Por lo tanto habria que plantearse la opcion de usar isos desencriptadas, al menos de momento (mi meta esria usar isos sin tener que cambiar nada).

Por lo tanto, solo tenemos que ver desensamblando un main.dol de un juego que llamadas hace y que datos se espera de vuelta, y hacer un modulo /dev/di que devuelva exactamente eso.
Si, por ejemplo, devolviese archivos desencriptados, podemos empezar con isos desencriptadas en otro formato para simplificar las cosas como creo que ya se ha propuesto. Si le llegan encriptadas nos desentendemos de la encriptacion y santas pascuas. Y si usa las 2 (para leer de datos en si, no cabeceras de la iso), estamos jodidos porque habria que implementar desencriptacion.

Por cierto, con respecto a leer "archivos" hay que tener en cuenta que desde el starlet no podemos acceder a cosas tipo libfat, asi que se me ocurrio meter los datos de la iso "a saco" a partir del principio de nuestra sd (dd if=iso of=/dev/tarjetasd ?)
De esta manera nos evitamos tener que implementar lecturas de cualquier sistema de archivos, ni usar programas residentes ni nada. de momento.
(No se si nuvalo sugiere algo parecido con "Me parece buena idea empezar con los discos "en bruto" en la partición." , no se si alguien lo habia dicho antes, no encuentro :S)

No se si me he explicado sorry, he tenido que apurar porque se me hace tarde.
He estado dandole vueltas y creo que funcionaria, el caso ahora creo que es ver que datos piden los juegos. Dadme vuestra opinion

Umm.. creo que con lo de las ISOs en bruto, estais mezclando conceptos.
Los juegos de Wii llevan 2 niveles de "encriptación" de datos, por decirlo así. Uno de ellos es que van scrambleados, es decir, los datos en vez de organizarse como un DVD/DVD-R, se organizan como un WOD, incluyendo sectores cambiados de sitio, etc. Esta es la encriptación que, cuando no sabiamos la ckey, ya se crackeó con el tema del unscrambler.

Y por otra parte, está la encriptación de la ckey, la cual impide que la ISO se pueda leer tal cual (y aunque no tuviera la ckey de por medio, no usa estructura ISO con lo que tampoco se podría).

Los backups, los juegos que carga el chip, ya tienen la primera encriptación quitada, es decir, van unscrambleados (es un paso que hace falta a la hora de dumpearlos).

Y tenemos dos funciones, a bajo nivel, en el IOS: LecturaWOD y LecturaDVD (no son los nombres exactos, pero las llamaré así).
LecturaWOD lee los sectores de los WOD scrambleados, comprobando que no sean DVD-R's sino WODs, y supongo que devuelve la información unscrambleada.
LecturaDVD lee los sectores del DVD, sin unscramblearlos.

LecturaWOD es llamada por otra función que ya desencripta a nivel de ckey, y devuelve los datos, ya desencriptados. Por lo que, en teoría, la cosa seria reescribir IOS para que esta funcion que llama a LecturaWOD no llame a LecturaWOD sino a LecturaDVD. Supongo que esto necesita varios pasos adicionales de por medio, que obviamente habría que programar a nivel de IOS.

Si conseguimos un cIOS (o parchearlo al vuelo) que haga esto, no haría falta crear ningun loader estilo GeckoOS como se dice por ahí, ya que de este modo la Wii leería los discos como si fueran originales -al igual que con chip-. Simplemente haría falta recargar, por ejemplo con el Menuloader de Marcan, el System Menu con el IOS que hemos creado, y con esto en teoría ya cargaría hasta el banner.

Pero claro.. hay que ponerse a hacerlo.

(toda esta información está basada en lo que he ido leyendo. Puede que me equivoque en alguna parte crucial)

la cuestion del cargado del disco, ya se dispone del codigo para hacerlo eso no es un problema .. en realidad ahora la incognita es saber que funciones llaman los dol y como wrappearlas o parchearlas en el IOS... yo en este momento ando que me mato con fechas de entrega de proyectos y tesis... pero cuando logre tener un tiempo libre hare pruebas y dejare de solo andar especulando

La propuesta de los ISOS desencriptados, es si el encargado de la desencripcion (descifrado) de datos es el IOS, esto nos facilitaria bastante la programacion del modulo (nos ahorrariamos toda esa parte).

kikekakik escribió:la cuestion del cargado del disco, ya se dispone del codigo para hacerlo eso no es un problema .. en realidad ahora la incognita es saber que funciones llaman los dol y como wrappearlas o parchearlas en el IOS... yo en este momento ando que me mato con fechas de entrega de proyectos y tesis... pero cuando logre tener un tiempo libre hare pruebas y dejare de solo andar especulando

La propuesta de los ISOS desencriptados, es si el encargado de la desencripcion (descifrado) de datos es el IOS, esto nos facilitaria bastante la programacion del modulo (nos ahorrariamos toda esa parte).

yep
gracias por el resumen de mi tocho
yo tambien ando liado hasta la semana que viene

jajajajaja... sip.. la verdad creo que por el momento todos andamos sintonizados... siento como que estuvieramos pensando lo mismo jajajaja.. v(creo que varios de nosotros hemos dicho practicamente lo mismo en varios posts) lastima que ninguno tengamos el tiempo de ponerlo en practica yo la verdad casi no casi no juego wii.. (solo los BUENOS juegos como zelda o mario..) pero me gustan los retos.. en este momento voy a tener 3 semanas super duras.. pero espero tener tiempo para juguetear con esto .. lo tengo trabado desde que dijeron que era imposible

Superken7 escribió:Aqui cual es nuestra prioridad? habilitar backups sin chip a traves del exploit que esta por descubrir en su totalidad, o de otro dispositivo tipo una SD ?

Yo aquí ni pincho ni corto, pero como siempre se ha dicho que la lente de la Wii es bastante mierdecilla seria interesante poder cargar las ISOs de otro dispositivo. Aunque eso seguro que es el camino difícil

Creo que lo primero de todo, si de verdad este proyecto quiere llegar lejos, es conseguir la mayor documentacion posible.

Es decir, llenar el grupo de google de toda la documentacion al respecto, y luego ir sacando conclusiones...

PD: Por ahora 9 miembros...

-

ZeNiTRaM escribió:Umm.. creo que con lo de las ISOs en bruto, estais mezclando conceptos.
Los juegos de Wii llevan 2 niveles de "encriptación" de datos, por decirlo así. Uno de ellos es que van scrambleados, es decir, los datos en vez de organizarse como un DVD/DVD-R, se organizan como un WOD, incluyendo sectores cambiados de sitio, etc. Esta es la encriptación que, cuando no sabiamos la ckey, ya se crackeó con el tema del unscrambler.

Y por otra parte, está la encriptación de la ckey, la cual impide que la ISO se pueda leer tal cual (y aunque no tuviera la ckey de por medio, no usa estructura ISO con lo que tampoco se podría).

Entonces otra solucion no podria ser primero scramblear y luego encriptar con la ckey "manualmente" las ISOs en el PC para transformarlas en WODs?

Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

De momento hasta que se pueda habilitar usb 2.0 (60Mb/s) creo que es inviable la carga desde usb.

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

Te diré cuales son: "A ver si se callan ya esos pesados frikys que no hacen más que pedir chorradas". Las últimas declaraciones dejaron claro que no les interesa un disco duro o semejante, así que a menos que sea algún tipo de medio "volátil" (en el cielo o en la tierra ) o un disco duro en linea, me da que no van a hacer nada.

nuvalo escribió:

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

Te diré cuales son: "A ver si se callan ya esos pesados frikys que no hacen más que pedir chorradas". Las últimas declaraciones dejaron claro que no les interesa un disco duro o semejante, así que a menos que sea algún tipo de medio "volátil" (en el cielo o en la tierra ) o un disco duro en linea, me da que no van a hacer nada.

Lo cierto es que muchas paginas han hecho eco de una noticia "falsa".
Hay por ahi un link en gonintendo.com que es un scan de la entrevista que salio publicada en la revista(en la que se basan las "noticias"), y lo que dicen es que nunca han dicho que sea un disco duro, y que sera algo mejor que lo que tenemos ahora (menos mal, no? ¬¬). Las "news-sites" lo transformaron en: "va a ser algo mejor que un disco duro" o "confirman que no va a ser un disco duro".

Yo espero que o bien habiliten SDHC o USB2.0, muchas mas opciones no les quedan
Lo suyo seria habilitar las 2 a estas alturas, pero como son "Noentiendo" ... xDD ya veremos..

Su solucion podria conllevar
1. soporte usb2.0
2. soporte sdhc
3. sdloader (al estilo del nandloader o del apploader)
4. usbloader
5. netloader ? xD
o alguna mezcla de estas, en cualquier caso sera interesante

Yo me temo que sera un netloader, las demas opciones llevan demasiado curro xD

Nos estamos olvidando de los puertos de GC, lo mismo tiran por algún tipo de periferico conectado a los puertos de GC. ¿Que velocidad tienen las tarjetas de memoria de GC?

Perdonad, pero creo que he sacado el hilo de tema principal

trantran escribió:Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

De momento hasta que se pueda habilitar usb 2.0 (60Mb/s) creo que es inviable la carga desde usb.

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

Según elñ devkit oficial los juegos deben estar preparados para funcionar con una velocidad d lectura de 3mb/s desde el dvd

technik escribió:

trantran escribió:Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

De momento hasta que se pueda habilitar usb 2.0 (60Mb/s) creo que es inviable la carga desde usb.

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

Según elñ devkit oficial los juegos deben estar preparados para funcionar con una velocidad d lectura de 3mb/s desde el dvd

Sabes o alguien conoce la velocidad de la SD ?

De todas maneras, como ya dije la limitacion a dia de hoy es temporal. Para las pruebas es suficiente. En cualquier caso para probar siempre podemos usar para las pruebas iniciales una ISO homebrew que solo tenga un main.dol por ejemplo.
Yo solo estaria interesado en conseguirlo por el reto en si, supongo que como la mayoria de los que participarian en el desarrollo de algo asi. (De hecho, seguro que todos los que participamos ya tenemos chip...)

Oh valla es la primera vez que veo un hilo así.</Ironia>
Solo quería decirlos q aunq un cargador de isos pudiera encontrarle alguna utilidad, por mi parte prefiero que el homebrew no se acerque a estos temas (mas aun cuando hay otra opción).
Y ahora continuar repitiendo hilos y hablando en vano.

según Wikipedia

Superken7 escribió:

technik escribió:

trantran escribió:Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

De momento hasta que se pueda habilitar usb 2.0 (60Mb/s) creo que es inviable la carga desde usb.

A ver que planes tiene N para solucionar el espacio de almacenamiento para Wiiware y Consola Virtual y si es aprovechable para la Scene.

Según elñ devkit oficial los juegos deben estar preparados para funcionar con una velocidad d lectura de 3mb/s desde el dvd

Sabes o alguien conoce la velocidad de la SD ?

De todas maneras, como ya dije la limitacion a dia de hoy es temporal. Para las pruebas es suficiente. En cualquier caso para probar siempre podemos usar para las pruebas iniciales una ISO homebrew que solo tenga un main.dol por ejemplo.
Yo solo estaria interesado en conseguirlo por el reto en si, supongo que como la mayoria de los que participarian en el desarrollo de algo asi. (De hecho, seguro que todos los que participamos ya tenemos chip...)

Aquí se dice mucho que la limitación de velocidad de los USB es temporal... Los datos son los siguientes:
Los puertos USB de la wii usan el protocolo USB 2.0 full-speed.
La velocidad no depende de que sea 1.0, 2.0 o 1.1, depende del protocolo que use. Entonces porque la gente piensa que los 2.0 son mas rápidos que los 1.1? por los protocolos que soportan. 1.1 solo soporta hasta el protocolo full-speed (el de la wii) y 2.0 soporta hasta high-speed (el más rápido por el momento). Esto quiere decir que los más rápidos de los 2.0 son más rápidos que los más rápidos de los 1.1.
Pero los USB de la wii son full-speed, es decir, que no superan la velocidad de los 1.1. Se dice que están capados porque no usan el protocolo más rápido que soporta su especificación (2.0 high-speed)
La duda es si la implementación del protocolo corre a cargo de los IOS o es por hardware. Si es cosa de los IOS se podría reescribir el módulo correspondiente (un montón de trabajo, per es posible), en caso contrario, por mucho tiempo que pase no se podrá liberar. Y por ahora ni siquiera se sabe como está implementado el protocolo, así que podeis descartar la subida de velocidad del USB

Edit: fixed

Oh valla es la primera vez que veo un comentario así.</Ironia>
Solo quería decirlos q aunq a tu comentario pudiera encontrarle alguna utilidad, por mi parte prefiero que no te acerques a estos temas (mas aun cuando hay otra opción).
Y ahora continua repitiendo comentarios y hablando en vano.

X_D solo me ha hecho gracia y no he podido resistirme.

El propósito de mi post anterior era que os dejaseis de hacer ilusiones con el USB porque NO VA A SUBIR DE VELOCIDAD, y seguir por ese camino si que es en vano. Yo dejaría el tema de los USB si dejáseis de pensar que mágicamente un dia vamos a tener high-speed

technik escribió:El propósito de mi post anterior era que os dejaseis de hacer ilusiones con el USB porque NO VA A SUBIR DE VELOCIDAD, y seguir por ese camino si que es en vano. Yo dejaría el tema de los USB si dejáseis de pensar que mágicamente un dia vamos a tener high-speed

No soy ningun "experto en USB", pero segun tengo entendido la wii tiene un controlador USB2.0, pero solamente tiene implementado en las wiis retail el protocolo OHCI mediante /dev/usb/oh0 y /dev/usb/oh1 .
Sin embargo existe un /dev/usb/ehc para hablar con el controlador USB en modo EHCI, que es el protocolo que soporta hi-speed. El modo EHCI no esta implementado en las wiis retail.
Vease: Aunque NADIE lo ha probado aun, teoricamente si se escribe un driver para soportar usb2.0 en modo EHCI, es probable que veamos un incremento en velocidad.

Por eso no entiendo por que estas tan seguro de que ya estamos en el tope, cuando nadie lo ha probado aun en una wii retail
Tampoco podemos decir que si vayamos a alcanzar hi-speed, pero seguramente alcancemos mayores velocidades si se habilita ese /dev/usb/ehc

trantran escribió:Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

A ti nunca se te ha rallado un "deuvede"?

No se, me hace gracia. Si tu wii lee a 10,54 Mb/s, me apuesto lo que quieras a que mi ram y mi hdd tienen la equivalencia de 1 Gb=1024Mb

-

oOoPoZaSoOo escribió:Entonces otra solucion no podria ser primero scramblear y luego encriptar con la ckey "manualmente" las ISOs en el PC para transformarlas en WODs?

Me autocito
No podria ser esta la solucion que queremos?

nuvalo escribió:La SD iba a 2.1 MB/s, al menos según pruebas con wii-linux.

Gracias 2.1 MB/s

Esto vendria bien http://www.intel.com/technology/usb/dow ... i-r096.pdf para el que le interese el tema de USB EHCI
El de linux por supuesto que podria servir como referencia para los interesados.

De todas maneras.. eso yo lo consideraria un proyectazo aparte de este (bastante interesante por cierto).

A mi me gustaria empezar a experimentar escribiendo un modulo que cree un /dev/di , por ejemplo tal y como ha descrito nuvalo antes:

Aparte, se podría hacer un módulo de prueba que sustituya al /dev/di (si alguien se atreve ), y que simplemente saque los ioctls que le llegan, para luego ver que significan.

Me pareceria muy buen comienzo empezar probando algo asi basico, aunque mirando http://www.wiibrew.org/wiki//dev/di podemos hacernos una idea de que entradas le llegan.

Tambien podemos hacerlo al reves. Escribir un programa que haga llamadas al /dev/di y ver que datos le llegan de vuelta al programa desde el modulo.
(Esto no tiene la dificultad que _creo_ que tiene el sacar los datos que le llegan al /dev/di, ya que desde el starlet creo que tenemos poca comunicacion con el mundo exterior, yo ahora mismo no se como se hace, supongo que a traves de IPC..)

Una vez tenemos eso, podriamos intentar implementar la funcion mas sencilla de todas. (Por ejemplo, una que haga un LowRead sin encriptacion ni nada) para que lo realice desde la SD e intentar sustituirla en el modulo original. De tal manera que una de las llamadas acceda a los datos de la SD, mientras que el resto acceden a los datos del DVD.
Si conseguimos que funcione, significa que muy mal no lo hemos hecho (o que el juego no llama a esa funcion), y podemos seguir probando con la siguiente.. etc

No se si esta "estrategia" funcionaria, pero bueno. Tiene inconvenientes como que no estamos reemplazando el modulo entero, estamos parcheando poco a poco el modulo existente. Vease, tenemos que desensamblar el modulo original, localizar las funciones en cuestion y programar a pelo para el ARM, o hacer virguerias mezclando funciones de ambos modulos.
Pensandolo mejor, creo que esta estrategia es un lio de cojones pero no lo borro por si a alguien se le ocurre algo mejor al leer esto.

-

melirober escribió:

trantran escribió:Velocidad del DVD 8x -------- 10,54Mb/s
Velocidad del usb de la wii (capado)--------- 2Mb/s---7Mb/s utilizando caché (con los consiguientes parones hasta el llenado de la cache).

A ti nunca se te ha rallado un "deuvede"?

No se, me hace gracia. Si tu wii lee a 10,54 Mb/s, me apuesto lo que quieras a que mi ram y mi hdd tienen la equivalencia de 1 Gb=1024Mb

Vale aceptamos que son 10,54 MB/s. Pero creo que se ha entendido lo que quería decir ¿no? Que me refería a MegaByte en lugar de a Megabit.

Lo que la wii lleva si no han cambiado las espes:

https://www.esol.co.jp/english/embedded ... asheet.pdf
https://www.esol.co.jp/english/embedded ... asheet.pdf

Y en mi ignorancia, en los apploader en su parte final aparecen los mensajes de error de varias llamadas de dvdlow.....

Saludos.

nuvalo escribió:¿ahora que tienes las 7 bolas no sería más fácil pedirselo al dragon?

jajajajaja!
si, lo he pensado pero este año ya le he pedido un deseo ;-D

Lo que no se, es como se hacen los syscalls en el propio starlet.
Desde el PowerPC se puede abrir/cerrar/leer/escribir/hacer ioctls de dispositivos del starlet mediante IPC , pero desde el propio starlet se puede llamar a funciones de otros modulos? Como?
Reconozco que en eso estoy perdido. No se si mediante SWIs (interrupciones software), o usando el IPC para escribirse mensajes a si mismo :S, o mediante una instruccion especial (tipo int 0x80) o como leches... ?

Alguien que me ilumine? ^_^

EDIT: Asi tal vez?
he encontrado esto, tal vez sean los message_ ?

EDIT2: Acabo de mirar en el ejemplo del custom ios module, ahi vienen directamente las direcciones de los syscalls hardcoded, y salta a ellos mediante la instruccion BX
Me pregunto si hay una manera de hacerlo generico para cualquier version de IOS.....

EDIT3: que message_ ni que niño muerto, son los device_open device_close, etc.. lo pone ahi pero estoy ciego.
Vale, ese problema creo que esta solucionado, son esos syscalls, y esas funciones device_
se usan para comunicarse con otros modulos (analogas a IOS_Open pero para el starlet)

perdon por el tochaco-monologo

oOoPoZaSoOo escribió:

oOoPoZaSoOo escribió:Entonces otra solucion no podria ser primero scramblear y luego encriptar con la ckey "manualmente" las ISOs en el PC para transformarlas en WODs?

Me autocito
No podria ser esta la solucion que queremos?

No. Los WODs llevan sectores de datos en sitios donde los DVD-R's no se pueden grabar. Se puede hacer un WOD, por supuesto, pero te hace falta tener la infraestructura para sacar DVDs "planchados", como hizo Datel.

La encriptación de la ckey.. las ISOs ya están encriptadas con ella, no hace falta volver a encriptar.

Creo que por donde habría que empezar es hacer que, al menos a nivel de IOS, se puedan leer sectores de DVD-Rs. Es decir, lo que hace el DVDX de los Twiizers, pero mediante un cIOS (con el DVDX tal cual no vamos a lograr nada, tendremos que currarnoslo nosotros).

y ahora que pasara con el proyecto softmod???

Respecto al tema de los USB's y su velocidad:
No creo que Nintendo habilite el 2.0 o suba la velocidad del USB si es que puede con el wiiSpeak, porquepara que el micrófono del Boogie funcionaba correctamente sin subir la velocidad, para qué quieren subirlo?
La única forma que veo de que Nintendo lo habilite es si habilitan la lectura de canales y todo eso desde HD's USB y otros dispositivos USB.
Si no, no os quedará más remedio que intentarlo vosotros si quereis un ISO Loader que lea desde USB. (Ojala algun día se llegue a poder)

-