I blathered on about it in the past
http://gbatemp.net/t...78#entry1799578
Short version there are two questions you are asking
1) How do DS carts on the dsi and 3ds (those are related)
http://hackmii.com/2...oming-in-3-2-1/ takes it pretty well.
2) How does game level AP work for which there are three methods at present but only two are really used. Sora de Eclaune already took the rough overview- if your cart does not behave exactly as an original then you can be pinged because of that.
In practice this means
i) Below 8000 reads-
http://nocash.emubas...rtridgeprotocol (see B7aaaaaaaa000000h (200h) - Get Data)
Older DS flash cards would quite happily return the actual data/not what is actually done.
ii) Binary (or portion thereof) checksums/hashes- as you probably know the binaries (ARM9, arm9 overlays and ARM7- arm7 overlays do not exist in commercial games) are loaded into ram and so as not to save on EEPROM (or whatever the game originally used) carts will patch them to save on whatever they are rocking save type for. A handful of carts like the original EZ5 that had a savelist (it was not that bad to maintain but the R4 was easier so most dropped such things) and actually emulated the memory type in hardware meaning they were usually far more compatible (and maintained such abilities well into the AP era where the thought of using a 2 year out of date kernel on a R4-a-like would have got you laughed at). Clean mode, special mode, ghost mode or whatever your cart wants to call it aim to have an ultra light touch on the rom to avoid setting off these at the cost of not having soft reset, cheats, in game menus and such.
Both these methods existed for a while and at first they were simple enough that general fixes could happen but later on it turned to hundreds of checks (and with it the end of "cheat" patches) even to the point where they slowed the game down (yep even on the DS the maybe not so legit way often ended up superior if you have a cart that patches these out properly*). Obfuscation also happened so where at first you could reasonably scan a rom with an automated tool (there still exists ones for below 8000 checks) or quickly by eye and catch most of them not to mention games triggering them later in the game (was it C.O.P. - The Recruit that had some later stage trouble with the initial patches?) and not having immediately obvious failure conditions (phantasy star changing drop rates for instance) as a result of games hiding them in overlays not used until late in the game, hiding things in THUMB mode as opposed to ARM (the GBA and DS ARM processors have a 32 bit mode known as ARM and a 16 bit mode (kind of- see GBAtek/arm docs) known as THUMB you switch between and I believe there were a couple that did not do the immediately obvious check and fail but send flags and whatnot for later on.
*most carts owe more than a passing nod to the wood/AKAIO teams so they tend to be properly removed rather than change the result of the if statement (the proper way to bypass is to prevent the check from happening but the quick and easy way is to scan the rom for the checks and change the if result is good carry on but if not then trigger AP failure mode to if it is good then great, if it is bad then also great).
The third has only been seen on a handful of roms ( Houkago Shounen being the best example) was to time the save process and fail it for being too short (flash carts are nothing if not efficient here)
I am not counting new save types and things like pokemon utilising the "save" architecture to also do the IR port and castlevania POR being badly coded and crashing due to something resembling a race condition where flash carts had a bit less speed/more latency.
There are probably a handful of other methods that could be (could have been?) tried based on the idea of a flash cart behaving differently in some small but predictable/detectable manner to original carts but I will leave it to you to cook up ideas here (have a read of GBAtek).