Thread Status:
Not open for further replies.
  1. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    Hey guys...


    So last night i coulnd´t sleep well. Because i just thought about the question what last protection the WiiU still might have, that we have not yet overcome.

    And then i looked at that newly released tool "Dumpling" and then it stroke me like a lightning! It`s an .ELF-file!

    So why is this important? Simple. 99% of WiiU-homebrew (currently) is run as a WiiU-RPX file. And RPX is a WiiU-OS-fileformat.

    And so i thought and thought and finally found out that RPX-files are encrypted by WiiU`s OS (by standard) as well!

    But: ELF-files are not encrypted, since they are simple created homebrew-files without official WiiU-SDK. .ELF-files are files directly produced from a linker on your PC/laptop or notebook.


    Thanks to "Mocha CFWs" recently released USB-patch which allows to run data directly from USB with full speed, it came to me how we crack that last protection.

    Simple. We start Mocha & then run our .ELF-files directly from there. Boom! No WiiU-OS. No encryptions. Full USB-speed!

    So again here´s what we should consider doing next:

    1) Create a linux-loader WITHOUT making use of RPX-files or trying to circumvent the WiiU`S OS! We simply have to create an .ELF-linux loader IN a CFW to boot it from there (best solution is Mocha since it has full USB support)! We can e.g. use Wii-creator-tools.

    2) Each homebrew we create has to be in .ELF format (or .dol but i dunno if we can run that yet, we`d have to program a .dol-loader first lol)

    3) For example: If we want RETROARCH @ full speed we have to compile it as an .ELF-file guys! No RPX! You can´t use the "WiiU Homebrew development-kit" since that implements all encryptions again. So taht is the FIRST thing you can do to try this instruction-guide here. Re-compile "Retroarch" and use the .elf-format. Do NOT use WiiU-converting-tools! Then your software- assuming you run it from Mocha CFW´s unlocked USB will run at MAX possible speed!

    4) A lot of software has to be converted from .dol to run as an .ELF-file. But without programming a .dol-launcher we might not be able to use .DOL-format (exception Nintendon`t but that has to be newly compiled as an .elf file as well since currently it´s RPX as well!)

    5) In the future we might want to use the WiiU´S GX2-shaders. And this will one day be possible. BUT: We have to have suitable drivers for that. Which we currently don`t have. Which is why we have to use the official tools to compile our software. And THIS is where encryption of WiiU-created files start!


    So now- i want to trigger a SERIOUS warning for everybody following my instructions here. IT´s DANGEROUS. You do this on your OWN risk. You can compile .elf-files & execute them on this machine on your OWN RISK!

    Nobody knows what happens to a WiiU-console if you do run a homebrew-file without encryption for long periods of time! It´s your own risk. The WiiU might overheat. The processor can fail and/or the VRM can fail especially if your environment is HOT. So i stronly advise you to make sure, your environment is NOT hot and that you consider cooling the box well! Use air-condition if necesary!

    Personally i think Nintendo has considered this and the WiiU won´t fail in this process. But who knows? There is allways a tiny risk. If the WiiU gets damaged it won´t be because of a brick. Since you just run Homebrew .elf from Mocha CFW`S USB-drive. But overheating is no simple issue and sometimes leads to severe hardware-damage.


    So now that you know how it´s done...please be careful. If you have questions about it, then i`ll be here to hear you.

    One last thing. I made guesses as to how much cpu-bandwidth the WiiU`s processor is using to implement the software-AES-encryption of WiiU´s OS.


    And my guess is: 18 Gbytes/second (which is about roughly 90% of free cpu-ressources) are being used to implement that heavy encryption. So theoretically things like "Retroarch" should run like ~10x faster after it´s being recompiled into an .elf-file and not using GX2! Since instead of 2 Gbyte/Second you will now gain a boost of 900% more bandwidth, that should equal a 9x improvement.

    The WiiU`s espresso-chip can do a bandwidth of about 20 Gbytes/second. Which equals roughly 70 Tbytes/hour of bandwidth. This is about ~10x faster than what the Wii´s old cpu did. But: when you enable heavy encryption, a lot of that bandwidth is lost, and that´s why i said, 18 Gbytes/second is lost, and only 2 Gbyte/second can be used for stuff you wan to execute.
    Please be aware that this bandwidth is used for everything though & is only possible in theory and will in real life applications depend on what you use and what you want to calculcate/do. That means (theoretically) if you use one USB-port, you do lose about ~3% of cpu-ressources (roughly 600 Mbyte/Second of WiiU´s cpu-bandwidth) for communication. In this case, only 97% of cpu-bandwidth is free to do calculations.

    So nothing is for free. The more USB-devices you might use or hog, the more bandwidth is lost! E.g. you use 2 devices, that equals 6% bandwidth-loss (that´s the case when you e.g. copy from one USB to another). And then there´s allways the possibility to want to use mouse/keyboard via USB simultanously as well, which will consume additional 1% for each too.

    So now that i gave you a solution for PERFECT homebrew on WiiU...GOOD luck everybody! may the revolution begin. And you can show your results here if you want. You can make a video on Youtube to show if your compiling worked!

    Happy compiling!



    Btw: Did you guys here about "3DS-sourcecode leaked" allready? Oh boy. Nintendo´s on a run with their "security" it seems.
     
  2. depaul

    depaul GBAtemp Advanced Fan
    Member

    Joined:
    May 21, 2014
    Messages:
    815
    Country:
    France
    Hi my friend. Good luck with your project.
    Just my humble thought:
    -There is a hardware limitation due to Wii U USB 2.0 interface. So even if we break the encryption and use SSD reading speed will be limited to 50 MB/s in best cases. We can't expect a miracle the hardware is limited.

    - there are indeed Elf and Rpx versions of retroarch. Elf version is still as fast (or as slow) as rpx.
     
    CORE, E1ite007 and alexander1970 like this.
  3. GerbilSoft

    GerbilSoft GBAtemp Addict
    Member

    Joined:
    Mar 8, 2012
    Messages:
    2,333
    Country:
    United States
    ELF vs. RPX is a non-starter. Using ELF won't allow you to "bypass" the Wii U OS unless you have a completely different OS running, e.g. Linux, in which case you effectively have a PowerPC Linux box.

    RPX files aren't encrypted, either: https://github.com/Relys/rpl2elf
    The only differences are some changes to headers and compressed sections.

    EDIT: Oh yes, I remember now. You're the guy who claimed that the reason several Wii U games ran poorly, e.g. Sonic Boom, was because they were compiled for the ARM CPU. This isn't just wrong; it's a flat-out lie. The ARM CPU is 100% reserved for the OS, and the game development SDK doesn't allow access to it. (The ARM CPU doesn't have access to the GPU, so ARM programs can't show anything onscreen anyway.)

    Never mind the fact that you seem to think "porting" a game from one CPU to another is super difficult. Most games are written in C or C++, not low-level assembly. C and C++ programs can usually be recompiled for "any" CPU as long as they don't use system-specific functionality.

    EDIT 2: Found the old post: https://gbatemp.net/threads/planning-on-making-ports-and-some-other-good-stuff-for-wiiu.487316/
     
    Last edited by GerbilSoft, May 23, 2020 at 10:33 PM
    Brawl345, V10lator, CORE and 6 others like this.
  4. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    Keep on your dreams, at least you'll eventually learn some things.
    We all gone through this phase when we think everything is possible, but then we realize reality is the most valuable lesson.
     
    Last edited by iyenal, May 23, 2020 at 10:49 PM
    alexander1970 and depaul like this.
  5. depaul

    depaul GBAtemp Advanced Fan
    Member

    Joined:
    May 21, 2014
    Messages:
    815
    Country:
    France
    Well good luck releasing your idea in real life. Maybe it's doable... Maybe not..I remember developer Exzap saying here on this forum that he's writing a Wii U emulator. Everybody said it was near impossible (2014)... But he proved us wrong later and released the emulator
     
    CORE and alexander1970 like this.
  6. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    Definitely, we can get great surprises sometimes

    — Posts automatically merged - Please don't double post! —

    Well wait this is just hurting my eye too much, why on hell "non-encrypted" code would cause your Wii U to overburn lmao
    If we follow your logic, no encryption means potentially less decryption instructions, and so more IPC on actual code nah
    Performance 1000
     
    alexander1970 and depaul like this.
  7. GerbilSoft

    GerbilSoft GBAtemp Addict
    Member

    Joined:
    Mar 8, 2012
    Messages:
    2,333
    Country:
    United States
    He doesn't know what he's talking about. Among other things, RPXes *aren't* encrypted in the first place, aside from the usual "entire NAND and disc is encrypted". Those are decrypted once on loading; once in memory, it's no longer encrypted.
     
  8. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany

    Well and that is why i said you have to use a CFW, which is USB-unlocked. Currently i think only Mocha has that feature. It might be possible that Haxchi can get it as well. But it wasn`t implemented.

    Also interesting is, that Mocha works a bit different dude.

    And so if you run Mocha yout not only have unlocked USB...but then if you run an .elf file on it it should really be running at max possible speed.

    Except if there´s another protection. lol. But it doubt there are more protections. We have 3 now, if i assume right:

    a) The USB-limit (which you can patch = unlock)
    b) The supervisor-mode (which seems to work in Mocha-CFW since the security is broken before the WiiU´s ARM-cpu can react with communicating with the PowerPC to encrypt all shit)
    c) the ecnrypted exe-files (RPX) themselves. If you use your own code, it´s not encrypted.

    But you`re correct. The Limit of USB 2.0 is about 50 Mbyte/Second. But it seems you didn`t understand what i said:

    The USB is not really limiting. It´s just that when you use more USB-ports (with mouse, keyboard, HDDs, SSDs etc) you simply LOSE bandwidth.

    So what happens is, all remaining cpu-bandwith will be used for calculations dude.

    So using one USB with HDD/SSD = about 600 Mbyte/Second (on the cpu-bus-side, since assuming you do a 10 Hz-bus-refresh) equals about 97% cpu-bandwidth left. If you use more USBs, you lose more bandwidth...
     
    kfrfansub, CORE and depaul like this.
  9. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    600mb/s
    You should work for Sony

    Well without irony please do a proof of concept before posting anything because we're reaching negative science and misinformation otherwise

    And not sure if you wanna feed the CPU with 600mb/s of instructions but then you fucked all the engineerers working on L1, L2 or L3 caches
     
    Last edited by iyenal, May 23, 2020 at 11:31 PM
  10. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    And that´s what i speak about ;) The whole thing is an encryption-box.Why do you say "just"? lol.

    Btw: I allready apologized for being wrong with the ARM-stuff. That was a few days/months ago. I simply assumed the WiiU would use an ARM-cpu to do all sorts of stuff since many webpages told that years ago. And now? Well, we know these webpages were wrong. Does it really matter? No. Not at all.

    Point i want to make is: It doesn´t matter how "small" your encryption is. The second you use it means you lose (most likely) 90% of cpu-bandwidth here, if it´s all done in software. And that would perfectly-well explain why the OS is running so slow. And how exatly they were able to "improve" it all these years ago...They simply adjusted their stupid encryption-mechanism.

    And proof for all is: You just need to run a thing like "Dumplign" and everything runs like it should at full speed. No limits (Except those which you naturally have): and Dumpling is not an RPX, but an .elf-file.

    Currently my laptop isn´t ready to do compiling for PPC. I have to reinstall all stuff again (especially PPC Devkit). Meh. And that took me like one day many months ago to just do the adjustments, when i first did that.

    But i´m sure some of you can try it. You have your machines ready. Create an .elf.file for Retroarch & use Mocha (it won`t work with other Cfw since they don´t have unlocked USB/SD-speed)...and then you will know. To be honest. Compiling was never my stuff.

    — Posts automatically merged - Please don't double post! —

    You know i´m talking about USB 2.0 here, right? If you assume an USB 2 reaches about (theoretical max) 60 Mbytes/second (480 Mbits)...and then you assume, you want to do 10 Hz (which is enough for USB-transfers/HDD/SSD etc)...then you have exactly 600 Mbytes/second of bandwith used up by your cpu.

    That´s just how it works, buddy.

    USB 3 consumes less bandwith because it has more wires. USB 2.0 though is old and uses up more bandwidth, because it has fewer wires.

    So assuming you do 100 Hz polling on a 60 Mbyte/Second (you allways have to take the theoretical max for correct calculations) you get 6 Gbyte/second ;) That is so because USB 2 only has two wires for communication. And 2 wires for power-delivery (max. 500 mA). This is why when you adust 1000 Hz-polling on a USB 2-mouse it´s very cpu-taxing my friend ;)

    I said above i can´t compile anything currently, since i have to reinstall everthing again. My complete PC broke months ago. Could´t repair it. Had to change to laptop/notebook. Nothing installed for programming right now (except minimum basics).

    I even didn´t copy my data since then, since that takes a whole day as well (2000 gbytes). Yeah. Simply didn´t have enough time for that yet. Maybe in 2 months i can compile something again. But like i said:If it weren´t so complicated to adjust all that linking-stuff etc, just to make it working, i would have allready tried it myself.
     
    kfrfansub and CORE like this.
  11. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    "Point i want to make is: It doesn´t matter how "small" your encryption is. The second you use it means you lose (most likely) 90% of cpu-bandwidth here, if it´s all done in software. And that would perfectly-well explain why the OS is running so slow. "

    Any data is decrypted in RAM or caches so actually it's just a one time "slowdown", they're not dumb
    And actually decryption can be very efficient with some algorithms, so I am afraid to tell you this isn't gonna change anything to bypass encryption except maybe 0.2s on the loading page
    And if my memory is good some instructions of the PPC ISA is made on purpose to accelerate decryption tasks
     
    Last edited by iyenal, May 23, 2020 at 11:42 PM
  12. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    Oh and @GerbilSoft:

    Did you even READ what it says on your page of "rpl2lef"?

    It´s USELESS: It can ONLY i post it here "This tool is still unfinished and for now all it can do is decompress the RPL/RPX zlib compressed sections, as well as display important information regarding the ELF headers and data."

    Boom. Nothing else.Decompress some Zlib-sections. Encryption is remaining no matter what you do. All it does is DECOMPRESS certain sections of data, in order for it to run uncompressed. LOL. And THIS is why it says it´s "unfinished".

    Sorry but that´s useless if your exe-file (which as you know is somewhere hidden in that huge RPX-file) is still encrypted. So you can eat your own words? Do you really know i don`t know what i talk about here? LOL SOrry but i know ALL differences between .dol, .elf and .rpx-files.

    To me it seems you don`t even know what an RPX-file is.You simply CANNOT get the UNENRYPTED exe-file right out of that RPX-file.

    Which is why it´s not working. Since a) you don`t know where the exe is located in that file (and there`s no tool which can find it) And this is why i said: "Security is too much put into the WiiU`s OS, you better don´t make any use of it".
     
    kfrfansub likes this.
  13. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    I was probably disassembling the 3DS kernel when loaded RPXes into IDA Pro
    RPX doesn't contain encrypted code, it's just zlib compressed code

    Encryption is actually the signing of full games on cartridges which are decrypted by the console, and dumped after or manually decrypted using console key dumps
    Having an RPX just means it comes from an already decrypted game, to be used on an emulator for example or just for modding and Loadiine
     
    GerbilSoft likes this.
  14. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    And this is the point why you encrypt exe-files WITHIN other files btw (so you make one big RPX-file):

    You hide your exe-file that way!

    And as you know: if you do NOT know where the exe-file starts exactly (header) in that file (and where it ends) you can NEVER decrypt it.
    Since if you want to decrypt it you have to tell a program exactly where it has to start the decryption and it must be a valid, exatly byte-correct addess (Similar to a key).

    Since that´s the POINT why this security is super-super-super protective. NOBODY can decrypt stuff like "Veracrypt" or "Truecrypt" because they work the same. If the exe-file is combined into another file and then you execute that exe-file it not only has to be decryted each time you start it, but also everything which is LINKED to that encrpted exe-file in there has to be constantly decrypted as well.


    "RPX" is a file which only the WiiU uses and it combines EXE together with linkables.

    Well, that`s all i got to say. I can´t try it right now. I have to set-up everthing again. No more linux installed either. I can be glad i even have a 2nd laptop now lol.
     
    kfrfansub and CORE like this.
  15. iyenal

    iyenal GBAtemp Regular
    Member

    Joined:
    Feb 11, 2016
    Messages:
    183
    Country:
    United States
    Nothing is hidden or encrypted in an RPX again, just generic compression
    Otherwise we wouldn't be able to correctly disassemble them without having something incomplete

    And remember that even if it's, volatile memory is used for that to store data we'll reuse, here a decompressed or encrypted data so we don't have to do it again. They already thought about it since decades lol
     
    Last edited by iyenal, May 24, 2020 at 12:06 AM
    GerbilSoft and depaul like this.
  16. depaul

    depaul GBAtemp Advanced Fan
    Member

    Joined:
    May 21, 2014
    Messages:
    815
    Country:
    France
    @TheChosen and I may say this is just theory. In practice things could get much more complicated.

    Results matter more than theory. Hopefully you could make a proof of concept !
     
    CORE and iyenal like this.
  17. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    Eh dude we know how Nintendo ticks. I know how they do. And we know they (typically) aren´t good in security. But this time is different. the old wii didn´t encrypt the whole system. lol

    And i learned how security of Truecrypt/Veracrypt works (Actually i never wanted to do this, but it didn´t take more than 6 months to learn all about security and how it works, what you do in order to break it & which cases CAN never be broken so you better don`t start wasting your time on it). And this is pretty much the BEST-possible security on the planet right now (Software-based).

    Hardware-based security isn`t safe, because it can be circumvented/altered. This is how it works on Steam. Everybod can alter that/circumcent that, nothing special. But software...and even AES 128 bit CBC? Forget it: it takes 100 years to break that encryption by brute-forcing through the file. See? Yes we do have the keys, but this is a 2-step-encrption: You encrypt not just a single file. But every exe is stuffed into a no-exe-file and you need more keys (which seem to be not stored in the WiiU`s hardware) which tells the hardware where to START the decryption-process (in the RPX-file) and where the decryption has to end (deeply communicating with the filesystem).

    Dude i even have a theory, who exactly had the idea to implement this devil "DRM solution" into the WiiU OS. Guess who was it? Yes dude, it was Reggie. Remember Reggie? Not many months ago he was still working for Nintendo.

    I surely can make a PoC of an .elf -file running unlocked via Mocha (using an external Intel SSD) but not before 2-3 months, lol. It took me long enough to find this all out. I need more sleep now for the next weeks. I learned more than enough from the last 3 months.

    Edit: Oh and there`s a good reason you hide Exe-files on such "dangerous" processsors:

    You cannot execute the file without the processor knowing where the exe starts and ends (filesystem).

    See? Normal exe-files can be executed with no problem. And you have seperate libraries (unsafe encryption, raw exe-files can be decrypted). But your exe is put together with libraries & linkables into one big file, which contains everything.

    And this whole package is what you call "WiiU Development". Which is totally useless since you won`t ever decrypt the exe out of the file. You can ONLY decrypt a raw exe-file. But not when it contains a lot of other files & is like 20 mbytes in size.

    Like i said: This time Nintendo made it´S homeworks. Chapeau!
     
    Last edited by TheChosen, May 24, 2020 at 12:39 AM
    kfrfansub, CORE and depaul like this.
  18. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    So you guys get starting now compiling some .elf-files & use Mocha Cfw (and at least an HDD) with USB-support? Please try it...and let me know in 5 days how far you´ve come. We know the "Dumpling"-tool is an .Elf-file and has NO limits guys. THIS is why it runs so fast! Because it has NO encryptions. But running such .elf-files on a slowed-down USB will not result in max speed.


    And no it´s wrong to assume "The WiiU OS will slow down the file".

    Why not? well it depends on the CFW you run!
    In Mocha- which can execute NON-encrypted files...you pretty much CIRCUMVENT the WiiU´s security before it begins (Chain-of-trust-is circumvented, the OS thinks just "Oh nothing happened, ok, go on" not knowing it will be able to execute non-encrypted files the next second. The only thing you cannot use is the OS-RPX-files themselves (or the ones you create via using the Toolkit).

    But i reckon rpl-files could be used assuming they aren´t encrypted. And if my assumption is 100% correct here, and this 2-step-encryption is done like in True/Veracrypt, then the Libaries themselves aren´t encrypted.


    so what happens when you run Mocha Cfw and then run an .elf?

    Simple: a) on Start when booting the processor thinks "oh nothing special happened, go on with booting..."

    Then when the OS is booted up - as you know the IOSU-elf file is PATCHED without the WiiU noticing this!

    This results in you are able to execute files which are non-encrypted (such as .dol or .elf). The WiiU still runs it´s OS, not knowing it´s 1st step of security is broken and it still thinks only RPX-files can be executed.


    So then when you booted b), you go into the Homebrew-Launcher (HBL), which is nothing than a non-encrypted .elf exe file as well.

    What happens in the WiiU OS? It does not notice you run this! Because every non-encrypted file you execute isn´t being noticed by the OS running in the background.

    Then you go on booting Mocha c). Which pretty much re-writes the WiiU-OS functions without it noticing anything since it´s just another .elf-file.

    Which then allows your OS to execute non-encrypted USB-data (assuming you use the Mocha CFW with the USB-support).

    This is when you break the NEXT step of security. You unlock the USB by emulating a SD-card reader via using a USB-device.

    And finally you go back into homebrew-launcher to start your .elf-file from there which then...results in the third security-break: Executing files at full speed on your USB WITHOUT the OS noticing this. Since it´s important that the OS does not know what you do (log file shouldn´t see what you did).


    Because if you execute "Loadiine" the OS KNOWS you run this. That´s why it´s encrypted. And that´s how the OS allways knows what you run, because RPX-data is linked with the "Log-executable".

    This is why the "log" knows you started "Loadiine"...and it tells you played a lot of "Loadiine" lately...

    But the WiiU`s log cannot tell you if you played "cfw-booter" guys ;) Because that´s an non-encrypted file.

    The WiiU´s Log only works with encrypted files. Not with .dol-files or .elf self-created homebrew.

    and THIS is why you have to patch vWii-files in order for the WiiU`s OS to notice this in the log. Which Nintendo did.

    So this means: Even when you create a WiiU-OS-forwarder you create an RPX-file (via injector) and thus the log knows what you played lately. lol- and thus the security is intact.

    And it doesn´t matter if the RPX is non-encrypted on PC/dump-file- but then gets re-encrypted on WiiU again (assuming my assumptions are wrong here and RPX is really not encrypted on PC, but it is on WiiU when you inject it as a "forwarder") if the result is the same, and the WiiU knows what you do.

    The point of security-breach is that the console does NOT know what you do, guys.

    So you guys better kiss the "log" goodbye if you really want to use homebrew @ it`s max speed.

    Since that will be an absolute requirement.

    The WiiU does´t know when we execute our nice homebrews such as "Dumpling" or "FtiPiiU"...
     
  19. GerbilSoft

    GerbilSoft GBAtemp Addict
    Member

    Joined:
    Mar 8, 2012
    Messages:
    2,333
    Country:
    United States
    Wii U's ARM CPU has a hardware encryption engine. There's no software overhead from using it.

    That's not what the "polling rate" is. Polling a 480 Mbps bus 10 times per second doesn't mean you magically get 4800 Mbps; it means that you're checking for incoming data 10 times per second. You're still limited to 480 Mbps.

    https://wiiubrew.org/wiki/RPL
    Not encrypted. The encryption is provided by the outer block device encryption (i.e. on the entire eMMC or USB device for installed titles, or on the disc partition for disc titles). The individual RPL or RPX is plaintext. There's no "embedded" EXE because it *is* an ELF executable, but with different import/export tables.

    For what it's worth, my rom-properties shell extension implements basic RPX viewing using the ELF handler. (Will post a screenshot momentarily.)

    Consider learning what you're talking about and/or show us a proof-of-concept unlocking the "power" of the Wii U.

    EDIT:
    There's no "embedded EXE" because RPX files *are* ELF executables, but with slightly different import/export tables and some other modifications.

    EDIT 2: Here's the screenshot of an RPX executable being displayed by my rom-properties shell extension, using its ELF parser:
    [​IMG]

    Incidentally, if you open up any RPX or RPL file in a hex editor, or use the `strings` tool, you'll be able to see the plain-text strings in the executable or library.
     
    Last edited by GerbilSoft, May 24, 2020 at 2:04 AM
    E1ite007 and VinsCool like this.
  20. TheChosen

    OP TheChosen GBAtemp Regular
    Member

    Joined:
    Oct 20, 2017
    Messages:
    118
    Country:
    Germany
    You don`t know how USB works, may that be? Or you simply don`t understand what i takled about. The point i talked about was the TAX of the cpu-bandwidth when you use USB. Man, please read carefully...then think...and then you can type.

    I said when you poll a USB 2-bus with 10 hz, this makes (as you said) about 600 Mbytes/Second (which is equal to your mentioned 4800 Mbits). And that is the TAX on your cpu. Since the cpu of WiiU is limited to 20 Gbytes/second. And i said that`s the theoretical max bandwidth since in reality you get a few losses because of the overhead and the procotols you use and the type of stuff you want to do.

    So when you do a USB-polling of let`s say 100 HZ you allready lost ~6 Gbytes/Second (10 x 600 Mbytes/second). That´s about 33% of the WiiU cpu´s bandwidth of 20 Gbytes/second max.

    And THIS is why modern Computers/PCs can get severe mouse-stuttering, if you adjust your USB 2-mouse to a 1000 Hz or even higher polling. Because an AMD/Intel processor cannot do unlimited bandwith either.


    So it means, in an example the cpu is taxed about 6-7% on WiiU if you copy from one USB to another @ max speed. Since 3 + 3% cpu-tax equals 6%. That is because about ~1200 Mbytes/Second (roughly 1.2 Gbytes) is used from the 20 Gbytes/Second.

    that´s all. Keep calm dude.

    Did you read your linked text of "rpl2elf"? No encryption can be taken out. Because your AMD/Intel cannot do magic. No such processor can decrypt such a file in...less than ~100 years gerbilsoft.

    Maybe you should learn how security works? And that there isn´t just one security-type only. The WiiU doesn´t use the generic security you find in Wii or Playstation or Xbox.

    It uses software-encryption with the whole OS since the claim you made also makes no sense (no ARM9-cpu supports AES, since hardware AES was implemented in...what? ARM11 earliest? lol). And i explained above how it works. And i also said WHO is responsible for this decision (clearly Reggie, since Satoru Iwata would have never done such a "develish" thing) and why you do it this way.

    True/Veracrypt-security is- because you do not know how the filesystem works the most-safe security currently on earth.

    and the exact same mechanism seems to be used here. and this is why i said "bruteforcing" won´t get you far here. You better don´t start it at all.

    Again: If the WiiU uses an ARM9, like people claimed all these years (same arm-chip as in Wii pretty much)...then you won´t have any AES-accelleration since AES got implemented years later in ARM-cpus lol. No AES-hardware accelleration in an ARM9, buddy. I think even an ARM11 doesn´t have AES-accelleration. See 3DS, which has this problem ;) (doesn´t support hardware-accelleration, uses software AES as well).
     
    Last edited by TheChosen, May 24, 2020 at 2:15 AM
    kfrfansub likes this.
Loading...

Hide similar threads Similar threads with keywords - Revolution, homebrew, begins

Thread Status:
Not open for further replies.