Re-Learning to Hack

Discussion in 'NDS - ROM Hacking and Translations' started by sentinalblade, Dec 14, 2010.

Dec 14, 2010

Re-Learning to Hack by sentinalblade at 6:09 PM (734 Views / 0 Likes) 1 replies

  1. sentinalblade

    Newcomer sentinalblade Newbie

    Nov 19, 2008
    United States
    Hey all!

    Recently, ive gotten alot of spare time, and would like to take hacking back up. I have a good level of knowledge of ASM, from my days of hacking MIPs(PSX Games). I heard that the N64 isnt much different, but i'd like to ask if the NDS is different from that.

    With that said, i'd like to ask for a mentor(i know, its a long shot). It's been about two years since i opened a disassembler, and i have broken my neck since then and had a bit of memory loss. I would feel more driven to get back into it if i knew i had someone who could help me if i get stuck and keep me from getting discouraged. I'm not asking for an msn address or anything(though, that would be nice), PMs would suffice. My first attempt, if the file structure isnt too threatening for a noob, would be to make golden sun harder. I may need help on methods on how to find a few things (like stat growth), but im not asking for anyone to hold my hand through this.

    If anyone has some links to anything helpful, please, post them [​IMG]
  2. Rydian

    Member Rydian Resident Furvertâ„¢

    Feb 4, 2010
    Cave Entrance, Watching Cyan Write Letters
    United States
    DSLazy is a program that can unpack and repack DS ROMs so you can get at all the internal resources (including the ARM9 and ARM7 binaries). The ARM7 binaries are often interchangeable since it's what controls some of the lesser functions (such as saving and wifi and sleep mode), the ARM9 is what contains the main game program.

    Here's a copy-paste from a member of the forums here about hacking a game to remove AP, it might give you a bit more insight into how NDS games work.

    <!--quoteo(post=3289684:date=Nov 26 2010, 10:25 AM:name=FAST6191)--><div class='quotetop'>QUOTE(FAST6191 @ Nov 26 2010, 10:25 AM) <a href="index.php?act=findpost&pid=3289684"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><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="" target="_blank"></a> ) and how to hack roms ( <a href="" target="_blank"></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="" target="_blank"></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="" target="_blank"></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="" target="_blank"></a>
    crystaltile2- while the actual tool is a great general purpose hacking tool it does feature a simple editor
    <a href="" target="_blank"></a>
    IDA pro- a commercial disassembler used by many top flight hackers of all systems. <a href="" target="_blank"></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="" target="_blank"></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="" target="_blank"></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="" target="_blank"></a>
    <a href="" target="_blank"></a>
    naturally crystaltile2 has one.
    <a href="" target="_blank"></a> has many in the tools section.

    On the commercial side of things
    hex workshop: <a href="" target="_blank"></a>
    winhex: <a href="" target="_blank"></a>

    If you fancy a few examples of patching try reverse engineering patches (say some of the rudolph's patches).<!--QuoteEnd--></div><!--QuoteEEnd-->

Share This Page