You do it the same way exploit writers do. Attach a debugger to the process, find the memory address of the resource you want to modify, overwrite the address with the address of the modified resource you want to execute. You could also just use the debugger to force the program to execute functions with arguments you specify, that way you don't have to worry about mucking with the memory.

Usually you'd create a dynamic library that interposes a function, so you don't have to much around with using a debugger. This way you have a persistent modification that's much more resilient to changes caused by app updates. Exploit writers generally have different goals: their thing only really needs to work once, and only with the current configuration, since usually the bug they're relying on gets patched in the next version.

Nope. There are ways to reverse engineer closed source apps and inject code into them.

Also, depending on the platform, if a native application is following the platform guidelines, then quite a lot of things you want to change might be located in data files or "resource" section of the executable.

I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.