Hacking AES obfuscation on the Wii U bootrom

[harryoke]

source :

source:

 

[Maxternal]

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

EDIT : just wanted to make that clear ... but interesting news nonetheless.

 

[Bobbybangin]

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

HRESET is the next step and it's currently a work in progress. We're getting there.

 

[metroid maniac]

Nintendo did something right when it comes to security?
This can only mean good things, it means they screwed up elsewhere!

 

[the_randomizer]

Nintendo did something right when it comes to security?
This can only mean good things, it means they screwed up elsewhere!

That's the important thing

 

[edwardbirkholz05]

OMG, how utterly devious - they used function pointers! l337 h4xx0rz would never figure that out!

 

[Coto]

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

 

[edwardbirkholz05]

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.

 

[Maxternal]

I remember from f0f's presentation that there's about 12k of the bootROM that's copied into cache at a different memory address and run from there for speed issues. I wonder if this complication has anything to do with that.

 

[Coto]

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.

Yes I knew about SP being a Special purpose register indexed, which could be accesed only as some argument coming from opcodes such MFSPR or MTSPR. And .. I've seen other disassembled code that deals with negative integers (to reserve area, or loop back, re-use etc), but not on PPC.

But the idea is there, I guess.

 

[asper]

Well, can someone guess what those "fixed" values are ?

 

[Ray Lewis]

No clue but Maxternal and others might;-)

 

[edwardbirkholz05]

They don't mean anything because you've disassembled data as code.

 

[Coto]

Well, can someone guess what those "fixed" values are ?

0x00003fb8: twi compares r21 contents with 18446744073709527839 (signed-extended ) , then & (and) performs a logical compare from 5 arguments given (29 seems wrong!). If it is not zero it will cause a program interrupt (could be breakpoint, or an event that halts or interfere with the current code running in PC, with an abnormal return to LR)

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.

Same for twi 15,r19,26086.

Keep in mind this is the same as swi (when usermode code tries to reach kernel,only access area), except it's triggered externally by the value fed

http://publib.boulder.ibm.com/infoc...ic=/com.ibm.aix.aixassem/doc/alangref/twi.htm

They don't mean anything because you've disassembled data as code.

Why are you so sure? Because extracted offsets overlaps with different instructions? (this should not happen if code would've been disassembled correctly . )

 

[Arras]

Well, can someone guess what those "fixed" values are ?

You just activated the WiiU's trap card.

 

[Maxternal]

0x00003fb8: 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.

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 ~0x5CE0
(that doesn't mean I've really looked at the rest of it to figure out what that really means in context, though)

EDIT : also, looking just above and below that at all those .byte's I'd say this is just random data that HAPPENS to line up with a legit machine instruction.
EDIT2 : looks like edwardbirkholz05 already got that concept, though. I'm a little slow sometimes.

 

[edwardbirkholz05]

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.

 

[Coto]

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.

Whatever, I used swi as an example, ARM and PPC at the same time can get confusing (do note i've never said SWI was for PPC anyway...), or you got it all at first? .

And yes, I made that mistake on the first argument (TO), thanks.

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 ~0x5CE0
(that doesn't mean I've really looked at the rest of it to figure out what that really means in context, though)

Ya, I tried typing them as decimal and it didn't fit. The last digit didn't make it

 

[Bladexdsl]

need new option in poll : i don't know what the hell this is

 

[Bug_Checker_]

If legit, It appears the dumper has been released into the wild a few hours ago.

Wii-U bootrom/boot0.bin dumper - Pastebin.com
pastebin.com/Zv6PDZiS

There should be no copyright code violations but Mods feel free to edit if inappropriate.

I'm an idiot (sometimes) totally missed
http://gbatemp.net/threads/vwii-sneek.360615/page-9#post-4936803
Sorry Maxternal