try initiating the race attack from within the IOS

[GoogleCodeExporter]

since I'm told you can't actually access the necessary registers from ES in 
order to do the race attack (I'm assuming this refers to the ones to reset PPC 
since that's the only ones we really need to use) I was wondering what would 
happen if we tried to use the syscall 0x59 (load_PPC) instead ... or even 0x41 
( ppc_boot(const char *path) ) and see if it can help us achieve the same 
thing. It would have to be asynchronous and give us enough time. We might also 
have to have it reload the whole DOL from the entry point again ... but 
something to play around with

The idea would be to make something useful for the "number crunching" concept 
from a LiboGC app as mentioned by Marcan since for that, the IOS would still 
have to be intact. We would possibly also have to put back the code we had 
patched once we're done with the race attack. That could be done either from 
within the IOS itself or by PPC once it's started up again. PPC might be 
simpler but ARM would be safer.

Original issue reported on code.google.com by maxternal on 1 Aug 2013 at 11:58

[GoogleCodeExporter]

Just adding some details as to my thought processing, further contemplating 
this issue:

I think the think that can't be done from user mode here would be cache related 
stuff. (and I understand the kernel code is in a memory area that only ARM can 
access even WITH AHB access)
If we can't invalidate the cache, no race attack can take place unless we just 
time it REALLY well.

Solutions to this:
- patch in code to the IOS that in turn patches code into the kernel and runs it
- just get the timing right and wait for the right moment to overwrite the 
entry point
- I'd assume the normal IOS user mode code has a way to ask the kernel to 
invalidate the cache, figure it out and use it
- prepatch the kernel of the IOS before reloading the IOS

Original comment by maxternal on 29 Aug 2013 at 7:59

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think I thought of another idea. It's to try to pre-load the IOS .BIN file 
from NAND before loading Mini and then have Mini jump to the .BIN file's ELF 
loader entry point when finished, thus hopefully reloading the IOS AFTER having 
unlocked all 3 cores.
http://wiibrew.org/wiki/ARM_Binaries

Hopefully, the core init could be right at the beginning of the boot.dol code 
and then jump back to the entry point of the DOL again after PPC has been 
restarted with some flag set so it knows to skip the core init code the second 
time around.

Original comment by maxternal on 26 Sep 2013 at 8:54

[GoogleCodeExporter]

http://wiibrew.org/wiki/IOS/Syscalls

I just realized that syscall 3f and 40 are to invalidate and flush the cache. 
That's just what I had been wondering. This should definitely be doable. Now 
just need to brush up on my ARM assembly >.<

Original comment by maxternal on 9 Oct 2013 at 2:05

[GoogleCodeExporter]

What you're attempting (patching ES code) is not going to work, by the time 
syscall 0x41 finishes it's too late to perform the race attack. You need fine 
level control of the ppc reset lines which only the kernel has access to.

Original comment by tue...@hotmail.com on 29 Oct 2013 at 3:28