I see no problem with sharing. The only problem is when everyone assumes that this means "YAY, next step, Wii U exploit and backup loaders!!!" (which is far from the truth. This is fun and interesting stuff, yes, but not needed or particularly useful in the process of running homebrew in Wii U mode.)
As long as it's accurate, news is news and news is cool
Nintendo did something right when it comes to security?
This can only mean good things, it means they screwed up elsewhere!
No it's just wrong. SP should only ever be adjusted by a multiple of 8 (largest native datatype, double = 8 bytes), this code would never work because it adjusts SP down by 4 and then adjusts it back up by 8 at the end of the function (Hint: this isn't disassembled bootrom code, it's just a crappy example of "obfuscation" that doesn't exist.)Took me a while to understand what it did..
hmm.. on line 11,22 integers (negative) are doubled because 64 bit memory addresses?
Good job so far
No it's just wrong. SP should only ever be adjusted by a multiple of 8 (largest native datatype, double = 8 bytes), this code would never work because it adjusts SP down by 4 and then adjusts it back up by 8 at the end of the function (Hint: this isn't disassembled bootrom code, it's just a crappy example of "obfuscation" that doesn't exist.)
LR is also meant to be stored at SP+4 e.g. SP[1], not *SP.
Well, can someone guess what those "fixed" values are ?
Why are you so sure? Because extracted offsets overlaps with different instructions? (this should not happen if code would've been disassembled correctly . )They don't mean anything because you've disassembled data as code.
You just activated the WiiU's trap card.Well, can someone guess what those "fixed" values are ?
that fits fine into windows calc ... and when I use it to convert it to hex I get 0xFFFFFFFFFFFFA31F but considering that Wii U is 32bit it's probably just a sign extended 0xFFFFA31F or ~0x5CE00x00003fb8: twi compares r21 contents with 18446744073709527839
...
As for such big value, it doesn't fit the calculator I use, so i'll wildly guess it's an external IC with SEVERAL bits masked externally.
Because the instructions make no sense, the program exception vector is stubbed and the "opcodes" surrounding these are invalid. Your description of twi was also wrong, the first value does not specify a register but a set of flags for the type of compare operation (greater than, less than etc) and swi is an ARM instruction, not PPC.Why are you so sure? Because extracted offsets overlaps with different instructions? (this should not happen if code would've been disassembled correctly . )
Because the instructions make no sense, the program exception vector is stubbed and the "opcodes" surrounding these are invalid. Your description of twi was also wrong, the first value does not specify a register but a set of flags for the type of compare operation (greater than, less than etc) and swi is an ARM instruction, not PPC.
Ya, I tried typing them as decimal and it didn't fit. The last digit didn't make itthat fits fine into windows calc ... and when I use it to convert it to hex I get 0xFFFFFFFFFFFFA31F but considering that Wii U is 32bit it's probably just a sign extended 0xFFFFA31F or ~0x5CE0
(that doesn't mean I've really looked at the rest of it to figure out what that really means in context, though)