_glook
Got a Passion for Smashin'
Howdy y'all.
SD Remix 3.2 LITE for v1.02 is out now. Please help us out by distributing it, but make sure people know that it only works with v1.02 for now. v1.00 is in the works. Also, they'll probably want to know that this will overwrite their existing SSBM save file.
More details in this blog post: http://wp.me/p5Pc4z-eV
If you're interested in the inner workings of SD Remix Lite, I've included some information about it here. I've also attached my raw notes and source code as a zip file to this post.
Edit: I should mention that SD Remix Lite is NOT meant to run on Dolphin. If you want to run SD Remix on PC/Mac, please use the full version ISO of SD Remix. The full version of SD Remix 3.2 is still in the works, but that is the preferred way to play on PC. There are no plans on supporting Dolphin because the point of SD Remix Lite is to bring SD Remix to non-hacked consoles, and it's quite easy already to play modified ISOs on PC.
SD Remix 3.2 LITE for v1.02 is out now. Please help us out by distributing it, but make sure people know that it only works with v1.02 for now. v1.00 is in the works. Also, they'll probably want to know that this will overwrite their existing SSBM save file.
More details in this blog post: http://wp.me/p5Pc4z-eV
If you're interested in the inner workings of SD Remix Lite, I've included some information about it here. I've also attached my raw notes and source code as a zip file to this post.
First off, I should say that this is not the most effective way of doing things. In the future, I would consider some improvements and I'll point them out where I can.
The starting point for doing memory card exploits is to understand wParam's methods, and he has a nice webpage for that. The second thing is to get a base save file with which to work with. I've gone with a save file I found online with everything unlocked, so I don't have to worry about that.
The next thing is altering the save file. There is probably an easy way to manually alter the save file, like via a hex editor. I haven't really done any research on this and I already have a method I use, which is to convert everything to a series of AR codes, using 04 codes, which are 32 bit writes. These all go into under the same code header, so I can turn the code on and off in Dolphin with one checkbox. I then run SSBM in Dolphin, go to the cheat manager, and at the main menu screen, I toggle the cheat on, which will write all the data I want to memory (and eventually to the memory card). The game only saves to the memory card at certain points, and I've found going from the main menu to CSS and back until Dolphin proclaims "Memory Card Written To" is sufficient.
Manually doing all of this is a bit annoying, so I have a main file where I put all of the memory overwrites I want to do. In the zip file, it is contained in 2_codes_2.txt, which is the stuff for version v1.02. I've written a compiler for myself which takes the data in this file and creates a GALE01.ini in the Dolphin user directory with one action replay code with all of the memory overwrite code lines in it.
The way 2_codes_2.txt works is:
If it sees a '#' character, it ignores everything after it until the end of the line. This allows me to write comments.
All whitespace is ignored.
The string "XXXXXXXX" means the next 8 characters represent the memory address to start writing from. It sets the "address" variable.
All other characters are interpreted as the memory to overwrite. Every 8 characters turns into a line in GALE01.ini as "04[address] [word to write]", and then the address is incremented by 4.
The last two bits are pretty easy, but the first two can be difficult if you don't use regexes, so you should use regexes.
readme.txt is simply the readme that I include with the SD Remix Lite game save.
free_space.txt is the free space I have to use in the SSBM memory space.
The rest of the files are basically notes researching various codes and features for SD Remix Lite.
This doesn't really explain what 2_codes_2.txt actually contains. The comments aren't completely explanatory, so:
The file starts off with the garbage. SD Remix Lite actually has a message as the first name tag, which is why it isn't all "DDDDDDD", though it eventually does turn into that.
After the garbage is the payload, which is the code that is run after the stack overflow exploit is exploited. If you look at Finished/payload.txt, it has the source code assembly for what the payload is actually doing. I have a concept of "Direct Overwrites" and "Array overwrites", which are the first two things in the payload. Direct overwrites overwrite some value into a memory address. These go into an array In 2_codes_2, which you can see starts at 8045DA00. The format is just [address] [value] repeated over and over, until it hits an address of 00000000.
Right after the direct overwrites, the array overwrites table starts. This is similar to direct overwrites, but the format is [start address] [number of words to write] [the words to write], until it gets to a [start address] of 00000000. This writes [the words to write] starting at [start address] for [number of words to write].
The direct overwrites and array overwrites table is a way for me to convert 04 and C2 gecko codes to memory overwrites. Direct overwrites are a easy translation of 04 codes. I have a script that takes in a code cave address, a C2 code, and returns the branch command at the C2 injection address and the bytes that make up the asm code for the C2 code, including the branch command to go back to the injection address (plus 4 of course). I make a direct overwrite for the branch command, and I use an array overwrite for the actual asm code. The better way to handle this would probably just to do direct overwrites have another file with a bunch of gecko codes and write a script that handles the space management. If there is any data required, like the FSM data and the patch codes, that can likely by handled with variable names so I don't have to hard code anything. That way I don't have to write anything to memory and I can just use the data directly from the memory card instead of writing to memory, but that's an optimization for another time.
The payload continues with code that plays the "Success" sound effect and code that sets the game modes and such. It ends by branching back to the name entry code.
The huge chunk of the data is taken up by patch files. The way this works has already been explained in a separate post I've already made in the Melee Workshop.
The starting point for doing memory card exploits is to understand wParam's methods, and he has a nice webpage for that. The second thing is to get a base save file with which to work with. I've gone with a save file I found online with everything unlocked, so I don't have to worry about that.
The next thing is altering the save file. There is probably an easy way to manually alter the save file, like via a hex editor. I haven't really done any research on this and I already have a method I use, which is to convert everything to a series of AR codes, using 04 codes, which are 32 bit writes. These all go into under the same code header, so I can turn the code on and off in Dolphin with one checkbox. I then run SSBM in Dolphin, go to the cheat manager, and at the main menu screen, I toggle the cheat on, which will write all the data I want to memory (and eventually to the memory card). The game only saves to the memory card at certain points, and I've found going from the main menu to CSS and back until Dolphin proclaims "Memory Card Written To" is sufficient.
Manually doing all of this is a bit annoying, so I have a main file where I put all of the memory overwrites I want to do. In the zip file, it is contained in 2_codes_2.txt, which is the stuff for version v1.02. I've written a compiler for myself which takes the data in this file and creates a GALE01.ini in the Dolphin user directory with one action replay code with all of the memory overwrite code lines in it.
The way 2_codes_2.txt works is:
If it sees a '#' character, it ignores everything after it until the end of the line. This allows me to write comments.
All whitespace is ignored.
The string "XXXXXXXX" means the next 8 characters represent the memory address to start writing from. It sets the "address" variable.
All other characters are interpreted as the memory to overwrite. Every 8 characters turns into a line in GALE01.ini as "04[address] [word to write]", and then the address is incremented by 4.
The last two bits are pretty easy, but the first two can be difficult if you don't use regexes, so you should use regexes.
readme.txt is simply the readme that I include with the SD Remix Lite game save.
free_space.txt is the free space I have to use in the SSBM memory space.
The rest of the files are basically notes researching various codes and features for SD Remix Lite.
This doesn't really explain what 2_codes_2.txt actually contains. The comments aren't completely explanatory, so:
The file starts off with the garbage. SD Remix Lite actually has a message as the first name tag, which is why it isn't all "DDDDDDD", though it eventually does turn into that.
After the garbage is the payload, which is the code that is run after the stack overflow exploit is exploited. If you look at Finished/payload.txt, it has the source code assembly for what the payload is actually doing. I have a concept of "Direct Overwrites" and "Array overwrites", which are the first two things in the payload. Direct overwrites overwrite some value into a memory address. These go into an array In 2_codes_2, which you can see starts at 8045DA00. The format is just [address] [value] repeated over and over, until it hits an address of 00000000.
Right after the direct overwrites, the array overwrites table starts. This is similar to direct overwrites, but the format is [start address] [number of words to write] [the words to write], until it gets to a [start address] of 00000000. This writes [the words to write] starting at [start address] for [number of words to write].
The direct overwrites and array overwrites table is a way for me to convert 04 and C2 gecko codes to memory overwrites. Direct overwrites are a easy translation of 04 codes. I have a script that takes in a code cave address, a C2 code, and returns the branch command at the C2 injection address and the bytes that make up the asm code for the C2 code, including the branch command to go back to the injection address (plus 4 of course). I make a direct overwrite for the branch command, and I use an array overwrite for the actual asm code. The better way to handle this would probably just to do direct overwrites have another file with a bunch of gecko codes and write a script that handles the space management. If there is any data required, like the FSM data and the patch codes, that can likely by handled with variable names so I don't have to hard code anything. That way I don't have to write anything to memory and I can just use the data directly from the memory card instead of writing to memory, but that's an optimization for another time.
The payload continues with code that plays the "Success" sound effect and code that sets the game modes and such. It ends by branching back to the name entry code.
The huge chunk of the data is taken up by patch files. The way this works has already been explained in a separate post I've already made in the Melee Workshop.
Edit: I should mention that SD Remix Lite is NOT meant to run on Dolphin. If you want to run SD Remix on PC/Mac, please use the full version ISO of SD Remix. The full version of SD Remix 3.2 is still in the works, but that is the preferred way to play on PC. There are no plans on supporting Dolphin because the point of SD Remix Lite is to bring SD Remix to non-hacked consoles, and it's quite easy already to play modified ISOs on PC.
Last edited:
