Worth having a scan through
http://wiibrew.org/wiki/Assembler_Tutorial
There are three main approaches to gadgets.
Some seem to want to replicate an almost full instruction set.
Some seem to want to do a baseline instruction set, may not technically even be Turing complete but if your only goal is to do something like set an area of memory as executable (presumably for more conventional buffer overflow type attacks) then who cares.
Some seem to just want to get it done and will take a somewhat abstract approach to get there > mov r1, r4, mov r4, r8 (or I guess it would be mr 4,1, mr 8,4 in rough powerpc equivalent) will get the contents of register 1 into register 8 just as happily as a straight mov r1,r8 or mr 8,1 if we are doing powerpc). The previous example would be an elementary one but if you have a gadget that sticks things in r1 but your next needs them in r8 you can see how things like that get to be useful, even if no sane programmer/compiler attempting to write remotely optimised code would do that in the real world. Aspects of this get blended into the others often enough.
You do also have the return to library/compiler extras thing -- if the code compiles with (and has privileges for) nice function calls then you might not need to bother constructing things piecemeal but this was more easily mitigated and so it has fallen out of favour ever so slightly. What Nintendo's security team have done in this instance I have no idea, half the time they seem to do pretty functional security and other times they make all the kinds of mistakes of someone that read a book and did not quite get it but tried anyway.
The basic approach is get a plaintext dump of the executable section of memory and feed it to a disassembler. You then get to consider what alignment you might use -- if you have 32 bit instructions but can execute on a 16 bit alignment for whatever reason then you potentially have a whole new world of stuff available to you. Otherwise you are more limited to the base encoding stuff, any non executable data in the executable memory section (arrays that might be loaded in, assuming you have not got strings or something in there that you might also play with) and anything related to the instructions -- you might have 32 bit instruction sets but some processors/instruction sets allow for 32 bit instruction and followed by a 32 bit payload, if you can jump to the payload and have the processor instead interpret that as an instruction then fantastic.
Though a nice processor specific gadget finder is useful you can generate this with something basic like objdump (in fact the fewer brains your disassembler has or clever things it tries to do the better), give or take annoyances in the payload sort of things, easily enough. Though basic objdump and getting things to end in a return can make that method annoying, though you can try working backwards and start with seeing all the returns/jumps/branches and what they might do.
You might also have the option to get a bit more dynamic and rewrite small sections of code (assuming you are not up against encrypted memory or some of the aspects of signing/executable modification detection), though by this point you probably have execution at the level you need so not many delve into this, if however a gadget would be perfect but for an 8 bit change to the instruction then this gets easier than trying to load your full executable from a SD card.
Afraid I do not know the wii u stack setup well enough (or at all really) to go into details like I might be able to for X86 for the stack pivot side of things. Depending upon the security setup this can be the chicken and the egg problem, especially if you are trying to do all software rather than some fancy hardware. All this said I am not sure I would want to start out on the wii u if you are only getting to grips with things. There are loads of nice worked examples for X86 and probably quite a few for ARM as well.
