marcan_troll said:I don't get what you're asking there. Oh wait, you're asking why it breaks when the TitleID changes? Well, the TitleID is hardcoded into the stub (the code doesn't actively read it from the Wii, it's just hardcoded into the binary blob that becomes the stub). The stub is there, it just can't launch the proper title. There's a MY_TITLEID #define used all over HBC, it's a compile-time constant. I bet even the "reload" option of HBC's home menu didn't work when you changed the ID.zektor said:It was not meant to insult. It was meant initially simply to test and see if Nintendo did indeed simply add code to the new system menu to remove the "HAXX" id. Nonetheless, link has been deleted.
Feel free to test whatever, but there's no point in offering a "test" up for everyone else. Heck, I don't even have a problem with people trying to reverse engineer our exploits and even "protections", as long as they don't publish the results.
QUOTE(zektor @ Sep 30 2009, 04:28 AM) But I still have to wonder why the return stub would not be left in memory if the title id had been changed. Protective measure?
By the way, the source for our reload stub isn't public (to my knowledge, I'm not 100% sure). It's nothing out of the ordinary, but if someone's bored, I suggest they try to disassemble and reverse engineer it. It's pretty simple and you might learn something about the wii in the process (and it doesn't use libogc, so no cruft). You can dump it from lowmem from any app launched via HBC.
Very cool. I really appreciate the information regarding the reload stub. I am pretty curious and probably will try to reverse engineer it. Again, my apologies for offering up that test version.