ducckke escribió:alvaro200 escribió:Yo tengo la versión 4.0.2E ¿que hago? ¿Actualizo a la 5.0.0E?
nooooo....
buscate un juego para la 4.1 o quedate ahi, que se supone que el exploit llega a la 4.1
alvaro200 escribió:ducckke escribió:alvaro200 escribió:Yo tengo la versión 4.0.2E ¿que hago? ¿Actualizo a la 5.0.0E?
nooooo....
buscate un juego para la 4.1 o quedate ahi, que se supone que el exploit llega a la 4.1
El problema es que no los hay, ademas han dicho que modificando algunas cosas del exploit tan bien va en 5.0.0 xD
Lord_Gouki escribió:
El MK8 lleva la actualizacion 4.1.
Lo que dicen que en 5.0 esta parcialmente tapado, es verdad o no?
Lirathyra escribió:Lord_Gouki escribió:
El MK8 lleva la actualizacion 4.1.
Lo que dicen que en 5.0 esta parcialmente tapado, es verdad o no?
no.
Licen escribió:Actualizar o no actualizar, that´s is the question
kikuko escribió:No sigo mucho el tema, pero os veo a todos muy emocionados, se prevé algo inminente?
Scene y copias de seguridad?
No tengo wii u, pero la tengo en el punto de mira?
SCREAM25 escribió:Interesante luego miro que versión tengo, pero vamos al estar por Wifi como la desactivais de internet digamos? Desconfiguráis la contraseña del router?
De todas formas la Wii U siempre te pregunta antes de actualizar la consola no? Con lo cual no habría problema con decirle que No.
Lord_Gouki escribió:SCREAM25 escribió:Interesante luego miro que versión tengo, pero vamos al estar por Wifi como la desactivais de internet digamos? Desconfiguráis la contraseña del router?
De todas formas la Wii U siempre te pregunta antes de actualizar la consola no? Con lo cual no habría problema con decirle que No.
A partir de el firm 5.0 no pregunta y lo instala sola.
Lordpsycho escribió:Por ahora lo único que tienen es un ataque ROP del navegador que te permite ejecutar código no firmado en el userspace.
Lo que queda pendiente es sacarle el jugo al userspace para poder escalar privilegios y acceder al starbuck y kernel, de manera que se puedan obtener las keys necesarias y/o el método para hacer algo relativamente más interesante que un Hello World.
Official Wii U Browser Exploit is released from Marionumber1 (via bitbucket.org/Marionumber1/wiiu-userspace/src)
Following the earlier leak, an official release has been posted with more info on its proper usage.
This release contains a way to run code inside the Wii U's web browser. It provides a means to execute arbitrary code in the Cafe OS userspace on the Espresso processor.
A few days ago, unofficial files for 'browser exploit' on the Wi U was getting passed around, and we got a copy of it via random-generated email and we decided to post it as news, and this started alot of 'scene drama' as usual, but now an official release has been posted up on BitBucket with a complete 'readme' on what it is and how it works and what you can and can not do with it on your v4.1.0 Nintendo Wii U console.
This repository contains a way to run code inside the Wii U's web browser. It provides a means to execute arbitrary code in the Cafe OS userspace on the Espresso processor. It does not allow running code in Espresso kernel-mode or provide any access to the Starbuck. We hope to implement this in the future, but the exploit is currently limited to userspace only. Right now, the only Wii U system software versions supported are 4.0.x and 4.1.0. 5.0.0 has the WebKit bug, but there is no exploit for it yet.
What's inside?
Inside this repository, you will find a set of tools that allow you to compile your own C code and embed it inside a webpage to be executed on the Wii U. There are also a few code examples doing certain tasks on the Wii U. Most notably, there is an RPC client which allows your Wii U to execute commands sent over the network from a Python script. Nothing in this repository is useful to the general public. You will only find it useful if you are a C programmer and want to explore the system by yourself.
How do I use this?
C build system
This repository contains a C build system, which allows you to compile your own C code and embed it inside a webpage to be executed on the Wii U. The webpage contains some Javascript code that triggers the WebKit bug and passes control to your C code. Running your own C code on the Wii U gives you full access to the SDK libraries. Any function's address can be retrieved if you know its symbol name and containing library's name (more on this below). Before using the C build system, you must have the following tools:
Unix-like shell environment (use Cygwin to get this on Windows)
devkitPPC (needed to compile and link the C code)
Python 3.x
Navigate to the root of the repository in the shell. Then enter the following command at the command line:
./build.sh [filename] [version]
where [filename] is the name of a C file inside the "src" directory, and [version] is the Wii U system software version you're building for. Supported version strings are 400 (for 4.0.x) and 410 (for 4.1.0). Not supplying a version string will cause it to default to 4.1.0.
Accessing the SDK libraries
When you're writing C code on a PC, you have the standard library, a set of useful functions that you can call without caring how they work. For writing code on the Wii U, there's something similar: the SDK libraries. The SDK libraries provide access to graphics, audio, input, filesystem, and network functions. The SDK libraries are accessible from any application, including the web browser, which means that code running inside it using an exploit also gets access. All SDK libraries have full symbols available for every function. Aside from making reverse engineering easier, this means that you can get the address of any function by its library and symbol name.
Before using the SDK, it's important to understand the Wii U's linking model. Some of these details were provided in comex's part of the 30c3 talk, but it only touched on it. Each executable on the Wii U uses the ELF format, with slight modifications (this format is called RPX). RPX files contain a list of imports, which specify a symbol being imported from an external library along with the name of the library itself. The libraries referenced by imported symbols use the same modified ELF format, but are named RPL instead. When an RPX is loaded, the executable loader will also load its RPL dependencies.
Every SDK library is an RPL file. For example, gx2.rpl is the name of the graphics library, vpad.rpl is the name of the Gamepad input library, and nsysnet.rpl is the name of the BSD sockets library. There is also a special RPL called coreinit.rpl, which is quite interesting. coreinit provides direct access to many core Cafe OS services, including memory management and threading. coreinit was also quite useful for providing the functions we needed in our ROP chain.
Now that I've spent 3 paragraphs telling you how the SDK works, let's actually get around to using it. So how do you use it? The SDK libraries expose many functions, but how do you get their addresses? You could just hardcode them, obviously, but that's both lame and not portable to later exploit versions. Plus how do you find the address to hardcode in the first place? There's a much better method available, which allows you to get symbol addresses dynamically, in the form of the coreinit OSDynLoad functions. You can access these functions by including coreinit.h in your C file.
There are two functions involved in getting a symbol, splitting the process into two parts. The first function is OSDynLoad_Acquire(), which loads the RPL you specify. OSDynLoad_Acquire() takes two arguments: the RPL name as a string and a pointer to an integer. The RPL name is pretty straightforward, the pointer to an integer is where coreinit will store the library's location. OSDynLoad_Acquire() can also be used to get the location of a library that's already loaded. The second function is OSDynLoad_FindExport(), which finds a symbol given a library's location. It takes four arguments: the integer (not the pointer to it) used in OSDynLoad_Acquire(), just zero, the symbol name as a string, and a pointer to where the symbol address should be stored. Here are the function prototypes:
void OSDynLoad_Acquire(char *rplname, unsigned int *handle);
void OSDynLoad_FindExport(unsigned int handle, int always0, char *symname, void *address);
Just as an example, let's say I wanted the VPADRead() symbol from vpad.rpl. If I have an integer called "handle", I first call OSDynLoad_Acquire("vpad.rpl", &handle); to get the RPL's location. Next, if I have a function pointer for VPADRead() called "VPADRead", I call OSDynLoad_FindExport(handle, 0, "VPADRead", &VPADRead); to retrive VPADRead()'s address. Simple. For more examples, look at rpc.c.
RPC system
In addition to letting you write your own C code to run on the Wii U, this repository also includes an RPC system to interactively experiment with the Wii U. It allows you to send commands over the network for your Wii U to execute. The two components of the RPC system are the server, a C program running on the Wii U listening for commands, and the client, a Python script that sends the commands.
To use the RPC system, first ensure that your PC and Wii U are connected to the same network. Once they are, find out your PC's IP address using the "ipconfig" command (Windows) or "ifconfig" command (Linux and OS X). Modify PC_IP in socket.h to be your PC's IP address (rather than 192.168.1.4, which it currently is). Build rpc.c and it will go in your htdocs.
Next, start rpc.py in an interactive Python session (IDLE or IPython is a good choice). Once you've started rpc.py, navigate to the browser exploit you just made on your Wii U. It should appear to finish loading the page, and the UI will continue to be responsive, but web browsing will be disabled. At that point, the Python shell should say something along the lines of "Connected by" followed by your Wii U's IP. Now you can control your Wii U with these commands:
rpc.read32(address, num_words) - Read num_words words starting at address, returning a list of words
rpc.write32(address, words) - Write each word in the list words to memory starting at address
symbol(rplname, symname) - Get the symbol symname from RPL rplname and turn it into a callable Python function
rpc.exit() - Exit the browser and go back to the menu
Credits
Marionumber1 - ROP chain design/implementation
TheKit - WebKit bug finding, ROP chain implementation
Hykem - Finding ROP gadgets
bubba - Testing WebKit bug candidates
comex - Access to the coreinit and WebKit binaries
README
This repository contains a way to run code inside the Wii U's web browser. It provides a means to execute arbitrary code in the Cafe OS userspace on the Espresso processor. It does not allow running code in Espresso kernel-mode or provide any access to the Starbuck. We hope to implement this in the future, but the exploit is currently limited to userspace only. Right now, the only Wii U system software versions supported are 4.0.x and 4.1.0. 5.0.0 has the WebKit bug, but there is no exploit for it yet.
What's inside?
Inside this repository, you will find a set of tools that allow you to compile your own C code and embed it inside a webpage to be executed on the Wii U. There are also a few code examples doing certain tasks on the Wii U. Most notably, there is an RPC client which allows your Wii U to execute commands sent over the network from a Python script. Nothing in this repository is useful to the general public. You will only find it useful if you are a C programmer and want to explore the system by yourself.
How do I use this?
C build system
This repository contains a C build system, which allows you to compile your own C code and embed it inside a webpage to be executed on the Wii U. The webpage contains some Javascript code that triggers the WebKit bug and passes control to your C code. Running your own C code on the Wii U gives you full access to the SDK libraries. Any function's address can be retrieved if you know its symbol name and containing library's name (more on this below). Before using the C build system, you must have the following tools:
Unix-like shell environment (use Cygwin to get this on Windows)
devkitPPC (needed to compile and link the C code)
Python 3.x
Navigate to the root of the repository in the shell. Then enter the following command at the command line:
./build.sh [filename] [version]
where [filename] is the name of a C file inside the "src" directory, and [version] is the Wii U system software version you're building for. Supported version strings are 400 (for 4.0.x) and 410 (for 4.1.0). Not supplying a version string will cause it to default to 4.1.0.
Accessing the SDK libraries
When you're writing C code on a PC, you have the standard library, a set of useful functions that you can call without caring how they work. For writing code on the Wii U, there's something similar: the SDK libraries. The SDK libraries provide access to graphics, audio, input, filesystem, and network functions. The SDK libraries are accessible from any application, including the web browser, which means that code running inside it using an exploit also gets access. All SDK libraries have full symbols available for every function. Aside from making reverse engineering easier, this means that you can get the address of any function by its library and symbol name.
Before using the SDK, it's important to understand the Wii U's linking model. Some of these details were provided in comex's part of the 30c3 talk, but it only touched on it. Each executable on the Wii U uses the ELF format, with slight modifications (this format is called RPX). RPX files contain a list of imports, which specify a symbol being imported from an external library along with the name of the library itself. The libraries referenced by imported symbols use the same modified ELF format, but are named RPL instead. When an RPX is loaded, the executable loader will also load its RPL dependencies.
Every SDK library is an RPL file. For example, gx2.rpl is the name of the graphics library, vpad.rpl is the name of the Gamepad input library, and nsysnet.rpl is the name of the BSD sockets library. There is also a special RPL called coreinit.rpl, which is quite interesting. coreinit provides direct access to many core Cafe OS services, including memory management and threading. coreinit was also quite useful for providing the functions we needed in our ROP chain. :)
Now that I've spent 3 paragraphs telling you how the SDK works, let's actually get around to using it. So how do you use it? The SDK libraries expose many functions, but how do you get their addresses? You could just hardcode them, obviously, but that's both lame and not portable to later exploit versions. Plus how do you find the address to hardcode in the first place? There's a much better method available, which allows you to get symbol addresses dynamically, in the form of the coreinit OSDynLoad functions. You can access these functions by including coreinit.h in your C file.
There are two functions involved in getting a symbol, splitting the process into two parts. The first function is OSDynLoad_Acquire(), which loads the RPL you specify. OSDynLoad_Acquire() takes two arguments: the RPL name as a string and a pointer to an integer. The RPL name is pretty straightforward, the pointer to an integer is where coreinit will store the library's location. OSDynLoad_Acquire() can also be used to get the location of a library that's already loaded. The second function is OSDynLoad_FindExport(), which finds a symbol given a library's location. It takes four arguments: the integer (not the pointer to it) used in OSDynLoad_Acquire(), just zero, the symbol name as a string, and a pointer to where the symbol address should be stored. Here are the function prototypes:
void OSDynLoad_Acquire(char *rplname, unsigned int *handle);
void OSDynLoad_FindExport(unsigned int handle, int always0, char *symname, void *address);
Just as an example, let's say I wanted the VPADRead() symbol from vpad.rpl. If I have an integer called "handle", I first call OSDynLoad_Acquire("vpad.rpl", &handle); to get the RPL's location. Next, if I have a function pointer for VPADRead() called "VPADRead", I call OSDynLoad_FindExport(handle, 0, "VPADRead", &VPADRead); to retrive VPADRead()'s address. Simple. For more examples, look at rpc.c.
RPC system
In addition to letting you write your own C code to run on the Wii U, this repository also includes an RPC system to interactively experiment with the Wii U. It allows you to send commands over the network for your Wii U to execute. The two components of the RPC system are the server, a C program running on the Wii U listening for commands, and the client, a Python script that sends the commands.
To use the RPC system, first ensure that your PC and Wii U are connected to the same network. Once they are, find out your PC's IP address using the "ipconfig" command (Windows) or "ifconfig" command (Linux and OS X). Modify PC_IP in socket.h to be your PC's IP address (rather than 192.168.1.4, which it currently is). Build rpc.c and it will go in your htdocs.
Next, start rpc.py in an interactive Python session (IDLE or IPython is a good choice). Once you've started rpc.py, navigate to the browser exploit you just made on your Wii U. It should appear to finish loading the page, and the UI will continue to be responsive, but web browsing will be disabled. At that point, the Python shell should say something along the lines of "Connected by" followed by your Wii U's IP. Now you can control your Wii U with these commands:
rpc.read32(address, num_words) - Read num_words words starting at address, returning a list of words
rpc.write32(address, words) - Write each word in the list words to memory starting at address
symbol(rplname, symname) - Get the symbol symname from RPL rplname and turn it into a callable Python function
rpc.exit() - Exit the browser and go back to the menu
Credits
Marionumber1 - ROP chain design/implementation
TheKit - WebKit bug finding, ROP chain implementation
Hykem - Finding ROP gadgets
bubba - Testing WebKit bug candidates
comex - Access to the coreinit and WebKit binaries
Geonemesis escribió:luego no tenga mas remedio que malvender y comprarme una nueva que sirva a toda prisa.
SoteBcn escribió:Mas remedio que??? Comprar una nueva que Sirva??? Es verdad, que una consola que no se puede piratear es totalmente inservible...
AntoniousBlock escribió:Pues para mi lo es, y soy mas pro-nintendo que nadie y me dejo gran parte de mis ingresos en productos de Nintendo desde que tengo uso de razón.
No me mola que las empresas hagan lo que le sale de las pelotas con MI hardware. La libertad para hacer lo que me salga de MIS pelotas con el hardware que he pagado religiosamente es importantísimo para mi y me parece vital que exista algun exploit (sobre todo porque Nintendo le mola capar sus consolas y aprovechar el 1% de lo que ofrecen...).
Asi que no vengais con flanderismos, que cada uno haga lo que le salga de los cojones. Si a ti no te mola "exploitear" tu hardware, pues no lo hagas. A mi me mola exploitear, piratear, crackear, flashear, rootear y todo lo que sea posible porque es MI DERECHO y me divierte.
weselp escribió:¿Dejar de jugar al MK8 online y no poder descargar nada de la eShop? No, gracias
Y si, me gustaría poder disfrutar también de un Homebrew en la WiiU, pero no a ese precio
SCREAM25 escribió:weselp escribió:¿Dejar de jugar al MK8 online y no poder descargar nada de la eShop? No, gracias
Y si, me gustaría poder disfrutar también de un Homebrew en la WiiU, pero no a ese precio
Pero puedes seguir jugando a MK8 online y descargar de la eShop pero sin actualizar no? Vamos a mi en 360 o Xbox One me saltan y son actualizaciones obligatorias, si no las aceptas no haces nada. Aquí por lo visto como mucho se descargan pero son opcionales si quieres entras e instalas la actualización y si no quieres no? No se si estoy en lo correcto o no pero por lo menos a mi me pasa esto ahora tengo la 4.1.0 y sigo jugando a MK8 etc. La 5.0 la tendré descargada pero no instalada.
AntoniousBlock escribió:SoteBcn escribió:Mas remedio que??? Comprar una nueva que Sirva??? Es verdad, que una consola que no se puede piratear es totalmente inservible...
Pues para mi lo es, y soy mas pro-nintendo que nadie y me dejo gran parte de mis ingresos en productos de Nintendo desde que tengo uso de razón.
No me mola que las empresas hagan lo que le sale de las pelotas con MI hardware. La libertad para hacer lo que me salga de MIS pelotas con el hardware que he pagado religiosamente es importantísimo para mi y me parece vital que exista algun exploit (sobre todo porque Nintendo le mola capar sus consolas y aprovechar el 1% de lo que ofrecen...).
Asi que no vengais con flanderismos, que cada uno haga lo que le salga de los cojones. Si a ti no te mola "exploitear" tu hardware, pues no lo hagas. A mi me mola exploitear, piratear, crackear, flashear, rootear y todo lo que sea posible porque es MI DERECHO y me divierte.
weselp escribió:¿Dejar de jugar al MK8 online y no poder descargar nada de la eShop? No, gracias
Y si, me gustaría poder disfrutar también de un Homebrew en la WiiU, pero no a ese precio
Geonemesis escribió:AntoniousBlock escribió:SoteBcn escribió:Mas remedio que??? Comprar una nueva que Sirva??? Es verdad, que una consola que no se puede piratear es totalmente inservible...
Pues para mi lo es, y soy mas pro-nintendo que nadie y me dejo gran parte de mis ingresos en productos de Nintendo desde que tengo uso de razón.
No me mola que las empresas hagan lo que le sale de las pelotas con MI hardware. La libertad para hacer lo que me salga de MIS pelotas con el hardware que he pagado religiosamente es importantísimo para mi y me parece vital que exista algun exploit (sobre todo porque Nintendo le mola capar sus consolas y aprovechar el 1% de lo que ofrecen...).
Asi que no vengais con flanderismos, que cada uno haga lo que le salga de los cojones. Si a ti no te mola "exploitear" tu hardware, pues no lo hagas. A mi me mola exploitear, piratear, crackear, flashear, rootear y todo lo que sea posible porque es MI DERECHO y me divierte.
+1000
esto es como si tuvieras una novia o esposa y no puedas hacer nada con ella a no ser que sea pagando, es un ejemplo tonto pero mas o menos .
PD: no desviemos este temazo que es bastante interesante haber como avanza todo esto.
superfenix2020 escribió:weselp escribió:¿Dejar de jugar al MK8 online y no poder descargar nada de la eShop? No, gracias
Y si, me gustaría poder disfrutar también de un Homebrew en la WiiU, pero no a ese precio
¿y si gracias a la scene tienes todo lo que salga en la consola virtual y gratis?
porque pagar 10 eurazos por juegos de 1991-1996, que ya has pagado en su época de SNES, por ejemplo, tiene delito.
El Online de la Wii U no es lo mejor precisamente, que no estamos hablando de la PS3/Ps4 o de la Xbox 360 que ahí si que tienes mucho contenido.
Yo quiero la Wii U para emuladores, reproductor que pille el formato MKV y a 1080p (la Wii U ya tiene potencia para eso, no como la Wii que no podía con pelis de 720p) y más cosas. Nintendo capa sus consolas. Para empezar, tienen bloqueo regional en sus juegos. No puedes disfrutar de juegos japos que en España no salgan.
Yo creo que vale mucho la pena la scene en una consola. Y más en las consolas de Nintendo.
¿qué sería de la Wii, de la xbox original o de la PSP sin la scene?
esto le daría mucho vida a una consola moribunda como es la Wii U. Porque después de MK8, ya veremos de aquí a 2015, cómo va la Wii U, porque hasta 2015, no sale el nuevo Zelda.
Y esto servirá para que las ventas de la consola Wii U se multipliquen por 30.
De otra forma, esa gente no se pensaba comprar una consola Wii U.
Sale ganando Nintendo y el usuario final, lo mires por donde lo mires.
a nintendo lo que le conviene es vender software y no hardware.
astarothbcn escribió:¿Soy yo o el hilo esta degenerando?
SoteBcn escribió:astarothbcn escribió:¿Soy yo o el hilo esta degenerando?
Poder, pareces nuevo
Todos los hilos degeneran xD xD xD xD xD
SATANASSS escribió:El xploit puede ser interesante pero si por ello te expones a que te baneen la consola, no poder jugar on-line o no poder entrar en la tienda pues es un precio muy alto.
Sinceramente para emuladores, reproductores de video ya hay otros aparatos destinados a ello, obviamente si la WiiU lo pudiese hacer pues mejor, pero de manera oficial no será posible.
zantzue escribió:SoteBcn escribió:astarothbcn escribió:¿Soy yo o el hilo esta degenerando?
Poder, pareces nuevo
Todos los hilos degeneran xD xD xD xD xD
Los hilos son como la entropía. Según pasa el tiempo, ya no son lo que eran.
superfenix2020 escribió:una consola con sólo 5 ó 6 juegos en que merezcan realmente la pena en toda su vida... para algunos, merece la pena, pero queremos aprovecharla más. Es sencillo de entender.
Me refería a scene de verdad, no a lo que se ha filtrado ahora, claro.a nintendo lo que le conviene es vender software y no hardware.
pero si tienes 2 consolas, ¿no es mejor tener 40 consolas?
más juegos venderás, más desarrolladoras externas traerás, y al final será mejor para todos.
Siempre compras algún original y accesorios. No sólo es comprar la consola y ya está.
A Nintendo le ha ido muy bien con consolas como Gameboy, NDS, Wii... y las más pirateadas de la historia. Con la Wii anda que no han dado facilidades para piratearla.
Petiso Carambanal escribió:Todos los juegos llevan actualización, solo que dependiendo la que tengas instalada puede saltarte o no.
El zelda lleva la 2.1.0 si tienes la Wii U en la 4.1.0 no dirá nada. El donkey lleva la 4.0.0 creo y el mario kart la 4.1.0
De todas formas el exploit sugue estando en la 5.0.0
Tmv_Josue escribió:No sé por que tanto alboroto de la gente, el exploit publicado es solamente algo conceptual, no sirve de nada en este momento. Y ya había comentado antes que de aquí a ver carga de copias falta muchísimo, muchos hablan como si fuera fácil o estuviera próximo, no lo entiendo. Afortunadamente es mas factible que el verdadero homebrew legal llegue.
Y hablando de la filtración, ya les digo que fue la peor tontería que pudo haber pasado... lo filtro Garyopa administrador de maxconsole, y es algo que no sirve a nadie mas que a él para atraer visitas a su sitio de miarda... ahh y para hacerle llegar la noticia a nintendo mas fácilmente si es que no lo sabía desde antes. La filtración no sirve de ninguna forma al homebrew ni el hacking, todas las personas capaces de hackear/programar y están interesados ya están y saben en que lugares enterarse de todo y platicar con otros hackers sobre la consola.