EZ-Flash USA Forum

hi does someone knows how to fix the problems on this games?
because when im playing on my ds with the ezvi it looks great, but sometimes the game just gets frozen and i cant continue playing is there any patch or something like that to fix this problem?? thank you i hope you can help me and sorry by my bad english

no i dont think so. i have been using ez flash vi for alot of while and it worked fine but when the nintendo anti piracy started then everything went wrong. flash cart have only limited power to run the game only for 10 minutes. the anti piracy has just started. they are gonna make it so strong that flash carts are gonna become useless. thats good the ez flash team hasnt given up hope and are trying to bypass the anti piracy. i thank them for not giving up hope. just wait for rc6 maybe it will work on rc6. if it dosnt then ez team will make a patch soon enough. just be patient. i have been waitin for alot of time too. it just makes the game more exiting!

How exactly does this new anti-piracy work?

As I understand it to make a rom work on a cart we need to patch things.
Patching things changes the hash of the file (assuming you use a good hash method which is not that hard to do)
The are functions within the code to hash the file or parts thereof; if a hash does not match then things can happen (in some cases the game will not run (developers are shying away from triggering it at the start of the game as it is then quite easy to plough through the first few instructions) while in others they are a bit more covert and in others you effectively get a demo of the game, a similar idea can be found in making cheats for "encrypted" values if that is more your thing).
By similar token this patching is why the earlier EZ5 kernels that use a savelist (emulating the save type in hardware) instead of patching work where others do not and why some games will run without cheats, soft reset and the like although a lot of time it is just that the onboard soft reset/cheat engine messing something up (why we have the odd soft reset update) so you should by no means immediately jump from game does not work with soft reset to must be anti piracy.

Basic checks (which if memory serves were included with an update to the nitroSDK that all official developers use) are possible to detect with relative ease hence the auto checking features seen a few months back.
Today however various developers embed numerous checks (81 were in Combat of dragons the other day) of varying complexity so hackers/and or the flash cart teams have to find and squash every single one of these, I am not sure if we have seen checks on checks yet but I would not discount it as impossible.
Of course you have the main ARM9 binary, the overlays, the ARM7 binary (not the reason for the "ARM 7 patch" but not far off) and on top of that you have many methods by which to hash, the possibility of dealing with compression (not such a problem as you can snatch the uncompressed overlay code from ram).

I would love to join in this patching/workarounds game but it seems when the choice between learning GBA and DS flash cart methods I went with GBA so I am now playing catch up.
Still if you want to join in you will need some tools.

The main idea is to get the game running so you can play with it, easiest way is to get the actual game and start pulling things apart there. Few do this however.

Emulators were the next traditional port of call but some games also feature emulator detection (emulation is not flawless after all), you also have problems, it is often easier to patch a game to run in an emulator however.
The two main emulators are no$gba and desmume, only the developers version of no$gba is good enough and nobody can get hold of the author these days to pay him for such a copy and desmume while good is not as full featured for those playing this hacking game (it has basic memory and disassembly viewers though). You can tack on tools/memory viewers to no$gba but I do not know of anyone who has done this for anything other than basic cheats, still http://www.vghackers.net/wiki/Hacking_NDS if you are interested.

You do however have the option of going manual with a disassembler like that of crystaltile2
http://gbatemp.net/index.php?showtopic=81767&hl=
or the original tool ndsdis2: http://hp.vector.co.jp/authors/VA018359 ... shack.html
IDA has some things but I dare say it has been outgunned by other methods as far as the DS is concerned.

Some of the cheat finding equipment is also quite good as it provides a hook into the game (cheating involves fiddling with things in the ram and detecting changes which can very quickly flag anti piracy stuff).

Anyone wanting to come into this game is probably already familiar with http://nocash.emubase.de/gbatek.htm but if you are not read it, study it, memorise it and you will be in with a chance.

I dare say most checks are of the if-else variety (will correspond approximately branching instructions at the ASM level- official code can be C? based or inline ASM although a few developers have ported or made runtimes or other somewhat high level abstractions for the DS) but if you take a few minutes to think of all the ways you could do it if you wanted to make such protection.
Also worth looking at is how the various anti piracy cheats bypass the problem and how various hacks work (you may only change a few bytes but those few bytes can be a set of several instructions and/or their hardcoded values- remember that cheats deal with the memory and the binary is loaded into the memory).

A simple technique that is worth knowing is to somehow make a save past the point where the detection strikes as well as just before.
It might be problematic in future months but for a while if a region dupe comes out then protection may either be nonexistent on the first game (Japanese game is without protection but seen as the actual binary tends not to change all that much in ) or quite often a direct "port" of the first protection which has usually been worked around by this point.

Also know that most of the people making these bypass hacks are very good at what they do so it is probably not best to expect things to come as easily.
Remember however that not all developers are good at their job/are security experts and that we totally own the DS in terms of what can be done (why most of these methods are more war or attrition type of thing rather than a straight up cryptography gig) so while some of what I said may make it seem like you will be going toe to toe with some of the best programmers out there you are also just as likely to find yourself up against someone who graduated a few months back and whose experience of security up until this point consisted of a single module wherein they learned the basics.