ROM Hack ds rom hacking

[Darkshadow1997]

hi deos anybody know how to create a patch/crack for a ds rom if this is illegal iam so sorry thx in advance and also how to create extinfo

 

[Phoenix Goddess]

I'm not even sure what it is you're asking.

 

[Darkshadow1997]

i mean how to get some games to work in dstt and creating extinfo

 

[Totoy_Kamote]

only RetroGameFan knows how to edit the Dat files so games can work properly..

i suggest you download his files...

 

[Phoenix Goddess]

only RetroGameFan knows how to edit the Dat files so games can work properly..

i suggest you download his files...

Actually, other people know how to edit the files, as well.

 

[Totoy_Kamote]

only RetroGameFan knows how to edit the Dat files so games can work properly..

i suggest you download his files...

Actually, other people know how to edit the files, as well.

then why do we only have updates coming from retro?

 

[lolzed]

only RetroGameFan knows how to edit the Dat files so games can work properly..

i suggest you download his files...

Actually, other people know how to edit the files, as well.

then why do we only have updates coming from retro?

You fail to understand phoenix's statement.


ANYONE can edit the files,fixing the games is different.

 

[Totoy_Kamote]

You fail to understand phoenix's statement.


ANYONE can edit the files,fixing the games is different.

ow.. sorry my bad...
but only retro knows how to fix the games using Dat files..

 

[lolzed]

You fail to understand phoenix's statement.


ANYONE can edit the files,fixing the games is different.

ow.. sorry my bad...
but only retro knows how to fix the games using Dat files..

Actually,other people know how to fix the games using the files too.

Japanese hackers usually fix them in a few hours,and upload to their site or to loda.jp...

It's just that retro is the only one of the only who fixes US games,which you guys need.

 

[Phoenix Goddess]

You fail to understand phoenix's statement.


ANYONE can edit the files,fixing the games is different.

ow.. sorry my bad...
but only retro knows how to fix the games using Dat files..

lolzed beat me to it, but they are correct. Just because retro was the last one to do a fix, doesn't mean he's the only one.

 

[ShadowSoldier]

hi deos anybody know how to create a patch/crack for a ds rom if this is illegal iam so sorry thx in advance and also how to create extinfo

And on topic:

It probably takes a lot of knowledge of coding and hex editing.

 

[BlueStar]

hi deos anybody know how to create a patch/crack for a ds rom if this is illegal iam so sorry thx in advance and also how to create extinfo

I'm going to take a wild stab in the dark and suggest you don't have the coding knowledge and understanding of how flashcarts work to even begin to attempt it, even with a bit of advice,

 

[Totoy_Kamote]

^ noob basher!

 

[Phoenix Goddess]

^ noob basher!

Actually, I don't see how you came to that conclusion, he wasn't bashing anyone.

 

[Totoy_Kamote]

for me he is..

 

[Phoenix Goddess]

for me he is..

Maybe for you, but not for everyone else. Stating facts is hardly bashing.
The OP didn't seem like he knew what went into creating files for the DSTT firmware and BlueStar was only taking a guess.
Leave the name calling for the kids.

 

[FAST6191]

Copied from an earlier post of mine

<b>AP and you</b>

For whatever reason developers of the newer DS games include methods to try and detect if their code is running on a flash cart or the real cart. Cart makers and other people will usually try to bypass this but if they are not quick enough for you then you could always try your hand at it yourself.
Before going on this is an advanced technique and you will find yourself getting into assembly level coding, while it is not necessarily advised you can skate by with a level of knowledge on/appreciation for how DS roms work (covered in this thread), how to make cheats ( <a href="http://cheats.gbatemp.net/forum/general-hacking-discussion/" target="_blank">http://cheats.gbatemp.net/forum/general-hacking-discussion/</a> ) and how to hack roms ( <a href="http://gbatemp.net/t73394-gbatemp-rom-hacking-documentation-project-wip" target="_blank">http://gbatemp.net/t73394-gbatemp-rom-hack...ion-project-wip</a> ).

What a game does when it detects a flash cart varies- saves can get wiped, a "thanks for trying the demo" screen can be loaded, the game can lock up (either right at the start or further into the game), the game can move in circles (unbeatable level/boss or something) or something more subtle (phantasy star changed drop rates of certain items) so while you can see a working game do not assume all is well. This the author leaves to you to determine although usually a mix of user observations, your own observations and machine level checks (it locks at level 2 but you check for similar instructions/sections and see that it would also lock at level 7) are what is called for. You should always assume developers/AP makers are creative people in this regard when hacking a rom.
This guide will not cover the more advanced things like making downloadable content work and fixing it for a given cart (saves and the like) but that should not bother too many people.


There have been many different ways to try and detect if a game is running on a flash cart or not [this is where I am going to fall down a bit as I have not paid as much attention as I might like] but in general to do things like have saving, cheats and soft reset the developers will alter the game code (this is also part of the reason why clean mode/stealth mode can often run a game that has yet to be patched) and these alterations can be detected.
The simplest way to check if a change has been made is to do a checksum of the binary (or section thereof) in memory,.
A simple checksum might be to add the values of the binary up and a change should change this result- change detected. Some of the more modern games can have well over 100 of these checks (occasionally even to the point where it induces a bit of a slowdown in the game even). While checksums are a method there are other options (a nice example relayed a few weeks back concerns Houkago Shounen (a Japanese game from early 2008) that timed how long it took for a save to occur vs the same thing on an original.) while others make use of a peculiarity with DS flash carts reading below 8000 hex in the memory (indeed if you disassemble a game and see a read to below 8000h this is probably what is happening also the debug output of an emulator will often have this) compared to what happens on an original cart.

The DS can receive code (and thus perform checks) via 4 methods
ARM9 binary (this is the arm9.bin you will see if you pull a rom apart)
ARM7 binary (this is the arm7.bin you will see if you pull a rom apart)
ARM9 overlay (usually stashed in the overlay directory)
ARM7 overlay (does not usually exist beyond 0k files).

In commercial DS roms the ARM7 is usually very similar from game to game (to the point where you can swap them without issue for many games which is a quite a feat for a system like the DS) and ARM7 overlays are quite rare. As the ARM7 controls saving for many games this gave birth to the ARM7 swap fix but as the last few paragraphs should have shown just trying an ARM7 fix is probably not going to solve your problem.

The ARM9 is what does the bulk of the work in commercial DS roms as far as calculating damage from an enemy, fiddling with text, shuffling things in memory and the like. While the translation process will usually involve editing the game data the binary is almost always changed as well (indeed it is not unknown for the text to be in the binary along the with the game code but from a more pragmatic stance the Japanese game might use a fixed width font while the US release will want a variable width one) and this is why swapping it with the already patched Japanese release or trying to use is also a bad/pointless idea. Most hacker translations will avoid changing the binary to the point of changing locations as it means everything after it is now wrong (why having a file system vs something like the GBA or SNES with everything piled into one big file is awesome for hackers) but as the commercial translations will have source code all bets are off here as far as assuming things will stay the same between regions (of course there are several examples of things remaining near enough the same but never assume it will).

Overlays are blank patches of memory that a game can add a section of code to (overlay if you will) for temporary use for whatever reason and then overwrite it with another one later but still keeping the core of the game loaded- a crude somewhat outdated method of expanding the capabilities on limited memory but about the only one that is available to programmers of commercial DS games (they do not have a nice ?SD card to play with and pull data from/write data to). Checks can be in here as well (quite troublesome too as they may not be loaded for several hours after starting a new game).

In addition to the two processors the DS versions of the ARM7 and 9 have an additional instruction set/mode called THUMB ( <a href="http://nocash.emubase.de/gbatek.htm#thumbinstructionset" target="_blank">http://nocash.emubase.de/gbatek.htm#thumbinstructionset</a> ) which broadly speaking is a 16 bit instruction set that can run on a 32 bit system (it gets a bit more complex that than but it makes for smaller code and helps if you are limited in bus size if used correctly). Developers will occasionally hide checksums in THUMB code- your disassembler is a dumb tool and will blindly disassemble everything you feed it in the manner you tell it (with the exception of some of the more automated functions of emulators) so in your haste you might skip over one buried in THUMB code.

It should also be noted that the binaries as found in a DS rom might be compressed (or worse sections of them might be compressed). You can usually snatch these from the ram viewer of an emulator

So you have read all this, understood it, ploughed into your rom and found an instruction you now know causes your headaches. Chances are if you have this is redundant but ultimately one thing happens at the end of a check and that is a branch depending on the outcome of the check, if you are feeling nice (or better a game runs slow courtesy of checks- always nice to know you not only made a rom work but work better) you can catch it before it ever checks but assuming you did not then the main course of action is to change the branch from well branching to a straight jump to the "good" outcome.

Cheat bypasses- not so viable for the many hundreds of checks option but still possible for some games. Here rather than targeting the rom image you target the binary in memory with a cheat (the payload of the cheat being the opcode(s) to bypass the AP). Most of the same ideas regarding locations apply so simply trying Japanese cheats on a US release is not likely to work either (although it may well just be a shift so if you redirect some of the locations then you can fix the game sometimes).

<b>Tools of the trade</b> vary from hacker to hacker but in general you will want
<b>A method of pulling DS roms apart</b>- ndstool (frontend in DSbuff and DSlazy) will do but something like NDSTS (which also includes some choice info on the binaries/header as well) is well worth having around <a href="http://www.no-intro.org/tools.htm" target="_blank">http://www.no-intro.org/tools.htm</a> . Your standard rom hacking tools for this sort of thing are all that is really needed.

<b>A disassembler</b>- even if it is only in the emulator the last thing you need to be messing with is raw machine code.
Several exist including
ndsdis2- the oldest one still in common circulation. Not favoured by some in the hacking community but works well enough most of the time.
<a href="http://hp.vector.co.jp/authors/VA018359/ndsdis/" target="_blank">http://hp.vector.co.jp/authors/VA018359/ndsdis/</a>
crystaltile2- while the actual tool is a great general purpose hacking tool it does feature a simple editor
<a href="http://gbatemp.net/t73394-gbatemp-rom-hacking-documentation-project-wip?view=findpost&p=2641950" target="_blank">http://gbatemp.net/t73394-gbatemp-rom-hack...t&p=2641950</a>
IDA pro- a commercial disassembler used by many top flight hackers of all systems. <a href="http://www.openrce.org/downloads/browse/IDA_Plugins" target="_blank">http://www.openrce.org/downloads/browse/IDA_Plugins</a> has plugins.

Both desmume and no$gba (developers version) feature a level of "live" disassembly which can be very useful. They are also the two chosen <b>emulators</b> for most ASM level hacking work.

<b>An assembler</b> can be useful but more often than not you can boil it down to a single instruction which you can inject/modify by hand in a rom ( <a href="http://nocash.emubase.de/gbatek.htm#thumbinstructionset" target="_blank">http://nocash.emubase.de/gbatek.htm#thumbinstructionset</a> has the encodings for the ARM and THUMB instructions- it can be as simple as changing one bit in the entire rom but the trick is knowing how to get to that point). Still <a href="http://crackerscrap.com/" target="_blank">http://crackerscrap.com/</a> has some documentation you might want to read and in the tools section there is ARM ASM kit (originally made for cheats but works very well for things like this). Devkitarm has an assembler though.

<b>Hex editor</b>- there are hundreds of these and most hackers will have several on standby.
XVI32: <a href="http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm" target="_blank">http://www.chmaas.handshake.de/delphi/free...xvi32/xvi32.htm</a>
<a href="http://mh-nexus.de/en/hxd/" target="_blank">http://mh-nexus.de/en/hxd/</a>
naturally crystaltile2 has one.
<a href="http://www.romhacking.net/" target="_blank">http://www.romhacking.net/</a> has many in the tools section.

On the commercial side of things
hex workshop: <a href="http://www.hexworkshop.com/" target="_blank">http://www.hexworkshop.com/</a>
winhex: <a href="http://www.x-ways.net/winhex/index-m.html" target="_blank">http://www.x-ways.net/winhex/index-m.html</a>


If you fancy a few examples of patching try reverse engineering patches (say some of the rudolph's patches).

 

[twiztidsinz]

only RetroGameFan knows how to edit the Dat files so games can work properly..

i suggest you download his files...

Actually, other people know how to edit the files, as well.

then why do we only have updates coming from retro?

Well.. there's a few reasons why:
1). Many of them are from Japan/China and only care to release fixes for games in their regions.
2). Some of those who have done (U) and (E) games are sick of people taking their work and calling it their own.
3). The hobby of game hacking has become too much like a job.
4). Others who can have just plain left the scene for whatever reason.
5). Can't/No longer making money off of it.