Ok, let's talk about what it takes to develop a patch. Anyone who has an XDK can improve/correct this. I'm a software engineer and I've poked around the XDK but I don't own one, so this is a combination of my experience with other software, as well as my small exposure to the XDK.
One of the reasons this question gets glossed over is because if it is obvious you are not an experienced software developer with a working XDK, then you won't be able to develop a patch, and therefor it's not worth answering. But I'm giving you the benefit of the doubt here...
The first thing you will need is the XBOX software development kit (XDK) so you can compile native XBOX applications. You'll also need the debugging tools included, as well as the debugging XBOX hardware.
The high level overview of patch development is like this:
1) Run the offending application on your debugging hardware
2) Trace through the offending application to the line of code that causes the issue (remember it'll be in assembly since you don't have the source code)
3) Identify what the code is doing that causes the error.
4) In parallel (if you can't think in assembler, which I can't) develop identical source code in your programming language.
5) After developing code that compiles to the same assembly and behaves the same, start modifying the code (as little as possible) to change or bypass the offending command.
6) After compiling the changed code, compare the hex, and develop a patch that modifies the original code to your new code.
If you can work in native assembly (a big help, and my guess is most XBOX hackers who develop patches can) you get to bypass steps 4 and 5.
More details.
You'll need to be able to step through the offending software. This is done easily if you have the source code, however, since you are working with a compiled binary, you won't have any source code. Instead you'll need to attach a debugging process remotely to the code running on the debugger XBOX hardware so you can pause and step through the lines of compiled assembly. As you step through, you should be able to identify the line of code causing the problem. It won't necessarily be the last line of code before execution stops as that may well be error handling code, so you will have to do this multiple times to identify where the root of the problem is an not simply where the error causes you to end up.
Once you've isolated the line of code that throws and exception, errors out, triggers an event, etc. you need to figure out what that is doing. It could be a media check. It could be any number of things. Once you've identified what it is doing (either by reading the assembly code, or by decompiling the app (I'm not actually aware of decompilers for the XBOX, however, they are handy if they exist)) you can start to debug what the actual problem is and a possible work around.
For example, if you find that the assembly (remember I don't read assembly much) equates to an if(a==x) statement, and it crashes if it returns false, you could rewrite the statement to read if(true). Of course, to develop the actual patch, you'll need to understand the difference between the hexadecimal representation of the assembly code within the binary executable. Once you know that, you can easily create a patch.
Ok, so your question has been answered. Anybody who has more hands on experience with the XDK could fill in some details or correct any assumptions I made.
Now, let me know when you've got that patch developed, and I'll buy you a beer.
