![[Main Page]](http://www.eurasia.nu/images/svico_t.gif)
By Parasyte @ http://www.dextrose-forum.com/_forum/showthread.php?threadid=10256&pagenumber=4
As many people know, the Action Replay contains a small piece of memory-resident program code which I call the code engine. The code engine is responsible for taking the AR codes, parsing them, and applying their effects. When the code engine is used with a game, the game must be patched by using a Master Code. The purpose of the master code is to patch the game's main executable before the game is run, and to retain control over games with multiple executables. The patch will simply insert a branch in a part of the executable which will execute many times per second. For example, GCNrd patches the controller reading routine -- which will execute no less than the game's running framerate. Of course, the branch leads into the code engine, where the AR codes will be parsed and applied as necessary. After all AR codes are handled by the code engine, control is released back to the game where it will continue running until the next master code branch (hook) is hit.
Now that you have a pretty good idea of how AR works, I will explain how I used this info to create a universal master code: The most important thing is that the code engine has remained completely unchanged since the original AR v1.06 release. Every upgrade since then has changed the GUI, core, and code list. Since those changes have been made, it would also mean that any master code location within the AR main executable (like the controller reading routines) would have subsequently moved within memory. That's why the old 'Single-Version Master Codes' would require a new master code for each AR version -- The idea was to apply a master code in the same way that is done with a game. To work around this limitation, I decided to scrap that old method for this master code. Instead, I found it better to patch the code engine itself. Remember that the code engine is the same across all AR versions (v1.06 - v1.14 are released, so far. None of them contain any differences in their code engines). As I explained earlier, the master code is handled BEFORE the game is run, but with the main executable in memory. This allows master codes to apply the hooks before control is initially given to the game. This gives my master code the perfect opportunity to take over control from the code engine. ;)
The SD Loader master code uses a standard 32-bit write to patch the code engine at the point where the master code handling is complete, and the code engine is about to finish up and go back to starting the game. That single write by itself is not enough, however. Due to caching, the written instruction will not be executed. To work around this, the master code has a very long "memory set" loop which will overwrite 2 megabytes of unused memory. The writing to memory has nothing to do with working around the cache; it's the loop. The loop is very long (over 2 million loop cycles) which causes the instruction cache to fill with the assembly in the loop. Once the instruction cache contains only the loop, it will then be able to execute the instruction written earlier. (The instruction cache will be forced to reread instructions from memory=)=
Now, back to that instruction which was patched into the code engine. After the cache-clearing loop ends, the code engine will see that there are no more codes to handle, so it will attempt to leave. When it does, it will encounter the patched instruction, which will force it to branch to address 80001928. This address is special; it's the address which contains the entire code list for the code engine to handle. The master code is not stored here, (it's at 80001860) so the master code will not get in the way. The SD Loader code contains no addresses, no AR code types, etc. It ONLY contains assembly. So what it's doing is branching to an assembly program (which was encrypted as a very long AR code). This is where the master code takes over the AR and does whatever it needs to. The result is always the same, no matter which AR version you use (as long as the code engine remains the same). And it also means you can swap the AR with any disc you have. It will still work just the same= As an added bonus, it works with one, single lid open/close cycle. This is as fast as an AR exploit can possibly get.= If you're wondering about the code engine handling the code list, there's no need to worry. When the AR goes to apply the initial master code, it instructs the code engine to ignore the main code list. So at this point, it's only supposed to handle the master code, and then go back to the AR to finish starting the game.
Now then! If you've been paying attention, you may see the huge flaw with the hacked master code that I've been protesting against. The master code causes the gamecube to execute whatever is in the AR code list as PowerPC assembly! With Samson's old bootloader AR code, you've got a mix of AR Code Type/Address/Assembly inside the code list. What's happening is the GameCube is executing those AR Code Types/Addresses as assembly instructions! This could lead to various problems, including overwriting memory, trashing registers, and causing fatal exceptions. It's just a freak accident that it even works at all.=