drumtronicpw01011110 escribió:paxama escribió:drumtronicpw01011110 escribió: Si ya hay xploit desde 5.3.2 a 5.5.1 porque con lo que se ha liberado no hay acceso a iosu?
Saludos
No debería tardar mucho en salir. Antes de poder acceder al IOSU, había que acceder al kernel. Al IOSU se accede por otro sitio diferente. Teniendo en cuenta que no lo va a sacar hykem si no otros, se demorará un poco en lo que desarrollan el acceso y hacen pruebas de que es estable y se corre poco peligro.
Los xploits actuales son kernel no?osea que sólo les faltaría escalar privilegios?
Saludos
Correcto. Ya lo próximo es el IOSU. Por lo que he leído en la documentación, el bug lo corrigieron en la versión 5.2.0, pero han encontrado el mismo bug, en otra parte diferente (no es exactamente así, pero bueno. El punto de entrada es el mismo. Simplemente, es otro camino.). Una vez tengamos eso, ya podremos hacer lo que queramos.
Me intentaría meter con ello, pero es mala fecha. Se aproximan todos los finales de la universidad.
,danos acceso a los usb!!!!!!!paxama escribió:Vengo compi haz un esfuerzo
Saludos
egarrote escribió:Elliot99 escribió:pregunta se sabe algo del iosu algun avance? algun team trabajando en el? luego de la "fltracion del kernel xploit 5.5.x como que la scene se detuvo
No hay nada nuevo, lo que sí puede interesar a los programadores es este tutorial para compilar las herramientas de Smea, aunque no hay forma de usarlas sin el IOSU Exploit:
https://gbatemp.net/threads/guide-how-t ... ax.426066/
Salu2!
gracias por responder saludos ![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
mauroxp69 escribió:No se liberara. Por el solo hecho de que si tenemos iosu tendremos acceso a jugar online con copias y usar dlcs con copias para todos los juegos. Hablando con los 4 cabezillas de loadiine .. ellos liberan capada las versiones de loadiine. Ya que segun sus poprias palabra no estan de acuerdo con la pirateria.. si quieren mas informacion de lo que pasa y pasara me avisan
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
Thought i'd share this here
Just a quick explanation of the whole PPC=/=IOSU thing for the uninformed among us. This is heavily oversimplified.
In essence, the Wii U has two processors (well, technically three but the third one is boring and has to do with emulating a specific, obscure bit of the vWii). Anyway! Two processors - The PowerPC (what we can run code on using browserhax/take full control of with kernel) and the ARM (IOSU). These are completely separate entities, but they can communicate. This isn't like the Wii, however - the IOSU watches the PowerPC like a hawk and halts the system if the code falls out of line. This is done through a permissions system - The IOSU "knows" what app is running (Mii Maker, Internet Browser, retail disc etc.) and changes the conditions appropriately. For example, the Internet Browser has limited memory, so if we try to use memory that the Internet Browser can't use under browserhax the IOSU rather firmly stops that. Loadiine works by loading Mii Maker and quietly replacing it with a game. The IOSU still thinks Mii Maker is running (and applies limits as such - No USB, limited internet etc) while the PowerPC is actually running something completely different. The point of all this is that while we can fool the IOSU, there's no simple way to modify it. Mii Maker will never need to fiddle with system settings or poke around the system's boot code, so the IOSU doesn't allow it. Since most homebrew runs under Mii Maker now, these restrictions apply to us as well. (And no, there isn't another app we can inject into to get around this. Someone public would have figured it out by now.) There's another thing worth noting: Yes, the PowerPC can directly communicate with the IOSU (IPCK_ functions for all you aspiring developers). In fact, we even got a nice example of such communication straight from MN1 himself (https://github.com/darksideos/darkside-kernel/blob/wiiu/bal/src/platform/wiiu/ios.c). However, this does not immediately give us full access - Communication is not control. I can communicate with one of Google's servers, but I can't take control of it. The server decides which of my instructions it obeys or denies based on my access rights. The same principle applies to the IOSU - It decides whether it follows my commands based on which app I am (Mii Maker most of the time).
So, the IOSU is stopping us from hacking the IOSU. Even though we have full control of the PowerPC via the kernel, the IOSU still expects it to stay within certain boundaries and any attempts to get out of them (modifying the IOSU for instance) are quickly stopped.
What do we need then? Simply put, we need an exploit which appears normal enough to the IOSU right up until we take control of it. Whether that means covertly doing stuff it doesn't notice or abusing existing, perfectly normal functions, I don't know. It may even involve something unimaginable right now (Say what you will about the more infamous devs, but there's no denying that abusing the graphics card (!) to write to protected memory to replace a syscall with one that allows unrestricted PowerPC code is absolute genius).
If you're up for it, grab yourself a copy of fw.img from the NUS and the files that will literally tell you everything about it (https://gbatemp.net/threads/how-to-make-an-IOSU-exploit.424786/). If you show interest, you'll soon find out about the place where the progress is being made (not GBATemp!) and hopefully we can all move towards getting a public exploit out there. There's a few awesome people working on this and they'd be damn happy to have another person on the team (You know who you are, we really appreciate all your work and the time you've sacrificed towards this!)
Original post by QuarkTheAwesome on gbatemp
).egarrote escribió:Explicaciones y aclaraciones sobre el funcionamiento del kExploit y el IOSU Exploit:Thought i'd share this here
Just a quick explanation of the whole PPC=/=IOSU thing for the uninformed among us. This is heavily oversimplified.
In essence, the Wii U has two processors (well, technically three but the third one is boring and has to do with emulating a specific, obscure bit of the vWii). Anyway! Two processors - The PowerPC (what we can run code on using browserhax/take full control of with kernel) and the ARM (IOSU). These are completely separate entities, but they can communicate. This isn't like the Wii, however - the IOSU watches the PowerPC like a hawk and halts the system if the code falls out of line. This is done through a permissions system - The IOSU "knows" what app is running (Mii Maker, Internet Browser, retail disc etc.) and changes the conditions appropriately. For example, the Internet Browser has limited memory, so if we try to use memory that the Internet Browser can't use under browserhax the IOSU rather firmly stops that. Loadiine works by loading Mii Maker and quietly replacing it with a game. The IOSU still thinks Mii Maker is running (and applies limits as such - No USB, limited internet etc) while the PowerPC is actually running something completely different. The point of all this is that while we can fool the IOSU, there's no simple way to modify it. Mii Maker will never need to fiddle with system settings or poke around the system's boot code, so the IOSU doesn't allow it. Since most homebrew runs under Mii Maker now, these restrictions apply to us as well. (And no, there isn't another app we can inject into to get around this. Someone public would have figured it out by now.) There's another thing worth noting: Yes, the PowerPC can directly communicate with the IOSU (IPCK_ functions for all you aspiring developers). In fact, we even got a nice example of such communication straight from MN1 himself (https://github.com/darksideos/darkside-kernel/blob/wiiu/bal/src/platform/wiiu/ios.c). However, this does not immediately give us full access - Communication is not control. I can communicate with one of Google's servers, but I can't take control of it. The server decides which of my instructions it obeys or denies based on my access rights. The same principle applies to the IOSU - It decides whether it follows my commands based on which app I am (Mii Maker most of the time).
So, the IOSU is stopping us from hacking the IOSU. Even though we have full control of the PowerPC via the kernel, the IOSU still expects it to stay within certain boundaries and any attempts to get out of them (modifying the IOSU for instance) are quickly stopped.
What do we need then? Simply put, we need an exploit which appears normal enough to the IOSU right up until we take control of it. Whether that means covertly doing stuff it doesn't notice or abusing existing, perfectly normal functions, I don't know. It may even involve something unimaginable right now (Say what you will about the more infamous devs, but there's no denying that abusing the graphics card (!) to write to protected memory to replace a syscall with one that allows unrestricted PowerPC code is absolute genius).
If you're up for it, grab yourself a copy of fw.img from the NUS and the files that will literally tell you everything about it (https://gbatemp.net/threads/how-to-make-an-IOSU-exploit.424786/). If you show interest, you'll soon find out about the place where the progress is being made (not GBATemp!) and hopefully we can all move towards getting a public exploit out there. There's a few awesome people working on this and they'd be damn happy to have another person on the team (You know who you are, we really appreciate all your work and the time you've sacrificed towards this!)
Original post by QuarkTheAwesome on gbatemp
Fuente
Fuente original
Cuenta que Wii U tiene dos procesadores (PowerPC y ARM), en el primero podemos correr código en modo kernel mediante el BrowserHax y el segundo es el encargado del IOSU que tiene el control total de la máquina y autoriza al otro a correr el sistema, juegos, etc. Es decir que el IOSU es como si fuera el encargado de seguridad, dejando funcionar ciertas cosas solo bajo su supervisión en el PowerPC. También comenta que la memoria que maneja el navegador de internet es limitada, por lo que en el momento que queramos utilizar mas memoria de la permitida el IOSU lo desautoriza y la consola se cuelga (no os suena de algo
Loadiine funciona gracias a que el IOSU cree que sigue usando el Editor de Mii, cuando en realidad estemos usando un backup, por lo tanto cuenta con las limitaciones de la propia aplicación, es decir no se pueden usar los USB, tenemos un internet limitado, etc, es por eso que con el kExploit nunca podremos tener esos privilegios.
Y no, no es posible utilizar otra aplicación que tenga esos permisos ya que esto es posible en el Editor de Mii porque no pide ciertas configuraciones del sistema o modificar el código de arranque para que pueda funcionar bajo la vigilancia del IOSU.
Salu2!
egarrote escribió:@PokesYt Esa cuenta atrás no significa nada, lo más lógico es que el IOSU Exploit no lo saquen por lo menos hasta que NX este en el mercado.
Salu2!
![[tomaaa]](/images/smilies/nuevos2/tomaa.gif "toma")
Hay muchos fakes pero no podemos descartar que todo lo sea. ![[plas]](/images/smilies/aplauso.gif "Aplausos")
egarrote escribió:Nuevos progresos con IOSU Exploit:
Shiny Quagsire, componente del team SALT, muestra el navegador de archivos del "Installer Package" utilizando IOSU Exploit.
Salu2!
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
SoteBcn escribió:@egarrote Yo la verdad es que el tema de carga de backups, me da un poco igual, todo lo que me interesa lo tengo fisico, así que con una sd de 32gb me sobra para probar algun juego que otro (de echo, de los 5 juegos que tengo puestos en la SD, 4 los tengo físicos, y el quinto me lo compro este viernes xD), pero si liberaran IOSU, y con esto se pudiera utilizar un disco duro sin que la WiiU lo formateara con su propio formato, y poder jugar emuladores desde el gamepad, yo ya sería feliz xD
![[comor?]](/images/smilies/nuevos/interro_ani1.gif "comor?")
