User talk:Monkeyman4412

Mario and Luigi 3 (bowers inside story) AP measures, and others.

There only six known ways of anti piracy on ds game. Three of them seems to be part of the game. Save timing, checksum, Below 8000 hex check. Before I can talk about these, I must bring something important up. obfuscation

These checks were heavily obfuscated. Meaning the developers made it more difficult to find these checks. And it didn't call a function either, but instead wrote in several different locations of the game. In other words instead of just one master copy that says everything, there is a hundred little copies running a muck with their own anti piracy in the game's code. So meaning if you defeated one check, you likely haven't defeated them all. This why there are videos of white screening, in some cases getting to the save menu and getting stuck. And cases where people have gotten past the save menu, but cannot save and battle crashes and ect.

Checksum check; the anti piracy and anti cheat killer

Yep you heard me right. This actually defeats both. Let me explain, in memory most ds games have a static binary location. Meaning that no matter what, every memory region would be in the exact same place no matter the circumstance. So how did this break piracy? Well flashcards started getting fancy features that would actually move these locations for their own uses. (real time saving. Kernel location.) Which is why the would immediately fail to boot the game. Even if the flashcard had these features not enabled, the other problem is that the checksum would also be modified by the save chip type. Cheat makers also got crafty, instead of just modifying the game sloppily through memory, they often modded that static binary. Which again, breaks the checksum. So Nintendo actually applied this check two (technically more) times. Once at the boot of the game. = And then the second time is when you load the file select screen. And every time you enter a battle, another checksum happens.

save timing

Simply put, flashcards often wrote faster than their original cart counter parts. So this check would often be used. Just so happens that this check is ran every time you hit a save block, and right when you start a new game. So this would again, cause the inability to move on from the save menu at boot up, and incapability to also save. 8000 hex check

So this is more of a accident on rom dumpers and no longer really applies. But! How this check work is if the game was improperly dumped (Which for the time of the game's release, it was) the header of the game and everything below hex value 8000 was filled out with zero's as dumpers didn't realize that was actually a carts header data. This caused issues because if at any point the game itself sent the "get data"command. It can wrap down below hex 8000 and check the games header data.The "checksum" anti piracy check is different from this one, as that only really applied to in game binaries. Which usually didn't have access to below hex 8000. But due to a over sight, the get data command (which was intended to only read bytes above 8000h) can read bytes starting at 1000h. Was likely used at the very beginning of the game, which is known as the white screen of death.

Some of this is conjuncture, I don't know every exact ap location. (like if the 8000hex check is responsible for the white screen of death) But if you want to read more about ds anti piracy. (as it is a lot of material. And I believe I may have made some mistakes) https://gbatemp.net/threads/open-ds-antipiracy-bug-fixing-and-hardware-removal-database-project.355223/ check here