Hacking The protection in NSMB ...

[Neversoft]

In more detail about the patch. I heard that it patches the error function in the game, where it already knows that something is "wrong", to just continue the game instead of throwing the error message. The game is not an IOS Reloading game! It really looks like nintendo did not see that this would make playing backups at least more difficult.

And about future patching. We could even be lucky that the same patch code that is implemented in the most recent loaders would work on new games.(if it would try to do them, NeoGamma checks for the disc id) Even if not, if it's the same protection, there will always be somebody finding how to patch it the same way as NSMB and all loader teams will be able to put that patch in within 10 minutes.

Yep, I'm not too knowledgeable on Wii stuff but I used to crack "back in the day" and know a fair bit of assembler on various systems so I've got a little insight into this stuff which meant I could at least understand the crack a little after some fevered Googling

The hex edit basically injects a "BLR" instruction ("4e 80 00 20" in hex) into the code at an offset of 0x1ab750 in the main.dol file. A BLR is a Branch to Link Register in PPC assembler (I think). Basically, it modifies a instruction so that when the code branches to the error routine, the BLR means it jumps straight back to the code that called the error routine in the first place (the address that called the routine is stored in the Link Register).

Basically, a good old-fashioned patch and EXACTLY the same shit that's been cracking games since the 1980s and almost as common as a "NOP"

 

[cwstjdenobs]

Neversoft, where did you find the PPC opcodes? I've been trying to find them for ages but can only find ppc asm references.

 

[Jacobeian]

http://opensource.apple.com/source/cctools...as/ppc-opcode.h

and more accurately at the source: https://www-01.ibm.com/chips/techlib/techli...525699600719DF2

and yes, game protection routines are usually hacked by patching a conditionnal branch ("continue only if test succeeds") into an unconditional branch ("continue whatever the result of the test" is)

the thing nobody knows is what does the game tests exactly ? The strange thing is that it does not seems to be only related to what loaders are doing (compared to legit Disc Channel loader) because copy of the game won't either work with modchips or full-softmod solutions (like cioscorp) so it's something deeper, maybe hidden in the new IOS53, I don't know

 

[Neversoft]

At the time I just Googled the opcode and managed to work out from the results what the instruction was but the PPC is MIPS based isn't it? So looking for MIPS opcodes would probably be a good start

::EDIT:: Jacobeian's first link is stellar! It's exactly what you're looking for by the look of things (thanks Jacobeian).

 

[cwstjdenobs]

Yep. You're right. But TBH both links are fantastic. The one from apple is a good quick reference. Thanks a lot Jacobeian.

 

[boondoklife]

In more detail about the patch. I heard that it patches the error function in the game, where it already knows that something is "wrong", to just continue the game instead of throwing the error message. The game is not an IOS Reloading game! It really looks like nintendo did not see that this would make playing backups at least more difficult.

And about future patching. We could even be lucky that the same patch code that is implemented in the most recent loaders would work on new games.(if it would try to do them, NeoGamma checks for the disc id) Even if not, if it's the same protection, there will always be somebody finding how to patch it the same way as NSMB and all loader teams will be able to put that patch in within 10 minutes.

Yep, I'm not too knowledgeable on Wii stuff but I used to crack "back in the day" and know a fair bit of assembler on various systems so I've got a little insight into this stuff which meant I could at least understand the crack a little after some fevered Googling

The hex edit basically injects a "BLR" instruction ("4e 80 00 20" in hex) into the code at an offset of 0x1ab750 in the main.dol file. A BLR is a Branch to Link Register in PPC assembler (I think). Basically, it modifies a instruction so that when the code branches to the error routine, the BLR means it jumps straight back to the code that called the error routine in the first place (the address that called the routine is stored in the Link Register).

Basically, a good old-fashioned patch and EXACTLY the same shit that's been cracking games since the 1980s and almost as common as a "NOP"

Heh, that is exactly what I thought, good old cracking. I started laughing when I seen what the fix was and that I would get to break out my hex editor again.

 

[Slimmmmmm]

We will all need to wait and see if other games use this protection before loaders etc start adding code. I mean they could add it for this one game just now, but if it is the same string in other games then the fix "should" be easy for the future.

imho the .gct seem a really simple fix for now anyway so no one should be worried.

I once suggested ocarina type patching (for some other similar type things) to a coder around here and was laughed at for the idea, but it's been used to bypass needing a disc in the drive for some usb loaders and games and some other things that were never released.

just speculating, but surely IOS reloads can be taken care of in the same ocarina type patching manner (I wouldn't know for sure though)

 

[Neversoft]

I can't see a generic patcher for this being possible because it's jumping back from the subroutine and the memory location of the subroutine will change from game to game and Gecko codes (for example) target specific memory addresses. It should be easier to locate as time goes on but I doubt generic patcher is possible because you'd have to load the dol, scan it then patch it at boot time.

I could envisage the loaders getting an auto-patch option for individual games, like the alt-dol loaders do on some USB loaders already (USBLoader GX springs to mind) but it's largely pointless as by that point there would be pre-patched main.dols and Gecko codes available.

 

[WiiPower]

Well that's the patch NeoGamma is using:
CODEbool NewSuperMarioBrosPatch(void *Address, int Size)
{
ÂÂÂÂif (memcmp("SMN", (char *)0x80000000, 3) == 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂu8 SearchPattern[32] = ÂÂÂÂ{ 0x94, 0x21, 0xFF, 0xD0, 0x7C, 0x08, 0x02, 0xA6, 0x90, 0x01, 0x00, 0x34, 0x39, 0x61, 0x00, 0x30, 0x48, 0x12, 0xD9, 0x39, 0x7C, 0x7B, 0x1B, 0x78, 0x7C, 0x9C, 0x23, 0x78, 0x7C, 0xBD, 0x2B, 0x78 };
ÂÂÂÂÂÂÂÂu8 PatchData[32] = ÂÂÂÂÂÂÂÂ{ 0x4E, 0x80, 0x00, 0x20, 0x7C, 0x08, 0x02, 0xA6, 0x90, 0x01, 0x00, 0x34, 0x39, 0x61, 0x00, 0x30, 0x48, 0x12, 0xD9, 0x39, 0x7C, 0x7B, 0x1B, 0x78, 0x7C, 0x9C, 0x23, 0x78, 0x7C, 0xBD, 0x2B, 0x78 };

ÂÂÂÂÂÂÂÂvoid *Addr = Address;
ÂÂÂÂÂÂÂÂvoid *Addr_end = Address+Size;

ÂÂÂÂÂÂÂÂwhile(Addr

 

[spotanjo3]

Well, supposedly the wii2 is coming out in about a year from now, and only Nintendo released games have had AP Protection... so I'm not too worried.

Nope. The Wii2 will be out in 2011 but not next year as previously thought.

 

[WalkerD]

Well, supposedly the wii2 is coming out in about a year from now, and only Nintendo released games have had AP Protection... so I'm not too worried.

Hey, since everyone else is just kind of skirting around this I thought I'd point out to you that your a dipshit.

 

[Slimmmmmm]

Rather than updating the code of loaders maybe loaders can read a txt file that has the ID of this (and future games) that use this type of protection, if the game is found it auto loads a .gct file.

So it would search the game ID in this txt, and if it was one of these games load a .gct file.
This would mean that loaders wouldn't need constantly updated if this starts to happen with more games. Instead the user would just download a new updated .txt and .gct for thre new problem game.

Maybe the string will be the same for all new games using it or maybe this will be the only game to do this....only time will tell. The brains out there will find a way around it anyway imo.

I do suspect that SMG 2 will have something like this but maybe harder to patch.

Is there a way to use this type of on-the-fly (ocarina) patching for IOS reloading games WiiPower ?
So if IOS reload ## then change to 249 ? As far as I can see this should be possible and I think people would prefer that to cioscorp and patching game discs. If it didn't work then these games should in theory work on usb loaders too then. Plus it would then offer higer compatability, if not 100%.
Maybe ocarina codes can't change they type values in memory, but I've been told in theory they vcan a few times.

 

[WiiPower]

Go away with those Ocarina patches, all ones i saw do nothing more than the patch i implemented. But for Ocarina you need the code handler, and patching a hook. Do you have any idea how much effert and risk that is compared to just patch the .dol?

A file that tells which patch to do an which title could be implemented, but that would be more work than the patching that is done now.