Hacking twilight hack technical details

  • Thread starter Thread starter amjad163
  • Start date Start date
  • Views Views 2,021
  • Replies Replies 11

amjad163

Member
Newcomer
Joined
Jun 4, 2011
Messages
6
Reaction score
0
Trophies
0
XP
6
Country
United States
Hi,

As for my understanding, the twilight hack in wii happens because of the overflow caused by the horse name, which then leads to load the program located in SD card.

I guess the horse name consists of instructions to make the processor jump to the program in the SD card. My question is how do you know the address of the program in SD card when you inject the string in the form of horse name?Is it always the same, say X ?If yes, then how do you find X?

Thanks for the reply,
Amjad
 
Thanks PsyBlade for the quick reply. So is this what the twilight hack does? Certainly searching helps, but it's not a simple task given that the code will be in assembly instructions and we need to search whole address space.
 
every time the game runs, it copies its save file to the same spot in memory. there is some executable code tucked away in the save file, and you are assured that each time you play the game, it will copy that executable code to the same spot in memory.
 
giantpune said:
every time the game runs, it copies its save file to the same spot in memory. there is some executable code tucked away in the save file, and you are assured that each time you play the game, it will copy that executable code to the same spot in memory.
Thanks for the reply. I am more interested about the "executable code tucked". If we analyze this code, it has to have an assembly instruction similar to jmp or call to the SD memory location. I agree that the memory location would be the same each time you play the game, but what value would you use for jmp or call instruction?
 
at the end of the horse's name is the address in memory of the executable code. the game overflows the buffer and writes that address over top of the address of the return address on the stack. then it goes on to run like normal for a short bit until it tries to return to the calling function. it gets the address that is planted there on the stack and jumps to team twiizers' code that is in the save file.

from there, it does a couple checks to see which version of the game is actually running. and based on that, it decides which addresses to use from the game itself. it uses the game's own nand_open and nand_read() functions to copy its elf loader from the nand into memory, and then jumps to that code.

it is that elf loader that is the black screen with white text that actually inits the SD card, looks for boot.elf, loads the file into memory, and runs it.
 
It's all pretty impressive
smile.gif
 
A link you might find interesting
http://hackmii.com/2010/01/the-stm-release-exploit/

Also some of the newer exploits use similar methods else are more or less ports of some of the twilight hack code.

As for where that is always the problem with this sort of thing and indeed newer protection methods like DEP make use of this by scatting things around the memory and having the OS keep track of where it all effectively is (it more or less does this anyway in windows as part of how it works) but making it invisible to the program at large. Consoles mainly do this with cheats rather than for some measure of protection; see pointer codes and other such cheat prevention methods.

Still I am not sure it came down to it but there was also the GC version of this game and the GC was more or less entirely hacked when this was going down which would have allowed for some educated guesses. Nowadays the wii is more or less hacked and emulated so you have many options by which to debug things.

Other than that what giantpune said.
 
caaraa said:
every time the game runs, it copies its save file to the same spot in memory.
18.games.jpg
44553433@N00.jpg
Bang on!!So how do I know the 'spot in memory' address?I mean what value of address needs to be encoded in the jmp/call instruction of the loader program?
 
giantpune said:
and jumps to team twiizers' code that is in the save file.
to jump you need to know the address right?what address value will be used?

QUOTE(giantpune @ Jun 5 2011, 06:42 AM) from there, it does a couple checks to see which version of the game is actually running. and based on that, it decides which addresses to use from the game itself. it uses the game's own nand_open and nand_read() functions to copy its elf loader from the nand into memory, and then jumps to that code
From where?You meant after the "jump to team twiizers' code that is in the save file."? If yes, how did you know to which address to jump.
Or did you mean just after the overflow and when the 'return' happens?
 
FAST6191 said:
A link you might find interesting
http://hackmii.com/2010/01/the-stm-release-exploit/

Also some of the newer exploits use similar methods else are more or less ports of some of the twilight hack code.

As for where that is always the problem with this sort of thing and indeed newer protection methods like DEP make use of this by scatting things around the memory and having the OS keep track of where it all effectively is (it more or less does this anyway in windows as part of how it works) but making it invisible to the program at large. Consoles mainly do this with cheats rather than for some measure of protection; see pointer codes and other such cheat prevention methods.

Still I am not sure it came down to it but there was also the GC version of this game and the GC was more or less entirely hacked when this was going down which would have allowed for some educated guesses. Nowadays the wii is more or less hacked and emulated so you have many options by which to debug things.

Other than that what giantpune said.
Thanks for the link..I will go through it..
 

Site & Scene News

Popular threads in this forum