ROM Hack Acquiring offsets?

[sniper_zero]

Um...I've got a question. I'm trying to change base stats in a game. I can find the RAM address of the stat but how do I find the ROM address based on the RAM address? Thanks in advance.

 

[andibad]

well hex offset writen on RAM is not real address of ROM offset, because arm table file is for finding offset on ROM and send to RAM, so is hard to finding it.... because all stuff was mixed on RAM... Hex offset is can 4 - 6 byte ....

sorry i can't help for this, in my mind RAM offset and ROM offset is different ... if hex offset is stored on RAM, i think is not, since on ROM have table file so is no need offset ROM on RAM....

 

[rastsan]

use an emulator to play the game. preferably one with a memory viewer. then go to that address in the memory view and hopefully you will be able to find the file its in. You may need to search up or down in memory. but so long as you find the file in question and have a screen shot software you should be fine.

Why do you need a screen shot software? so when you go to the spot in memory you know what to look for in the file (when you find out which file it is), exactly what to change and where...
(take a screen shot of that)...

 

[sniper_zero]

Thanks for the reply. Then how do I use ARM to find the ROM offsets I want?

 

[rastsan]

All you are looking for is the hex values for the beginning stats. If you can make the code then you know what those stats are. if you didn't make the code and you are basing this off of a 999 stat code then you could still dis-assemble the code to get loacation. Kodegarage should be able to help you with that.
kodegarage is a ar/cpdebreaker code manipulator. change the buttons etc...
Why ddo you need arm?

 

[FAST6191]

You have a couple of options- the first is the basic palette search style where you grab a selection of memory and assume it is the same in the rom. Often it is but equally it could be a derived method, compression was used or data otherwise shifted around (atk stats in one section, def in another but one after the other in the rom or soemthing) so such a method is far from foolproof.

After this it is kind of reminiscent of tracing on the GBA, so much so that I am going to link you to a tracing guide for it http://www.romhacking.net/documents/361/ (poke around some of the pokemon guides/hack sites as well as they have some other guides that might be nicer to follow
Unlike the GBA the cart is not mapped to memory so it is not quite as easy as waiting for a read/DMA to the cart in memory and as such not many people do it on the DS- if the above failed most instead opt to look around the rom and do a kind of reverse text finding method (certainly I can do tracing all day on the GBA but it is rare I reach for such things on the DS).
eliminate the text (assuming it is not text based stats), sound and graphics and not only would you normally have eliminated half the rom (graphics and sound not being known for their small size) what is left is likely to be what you want or enough to be pushing forward. You can do this with names, extensions, looking at file data in hex editors, tile viewers and such and corruption (changing the file so that does not work and seeing what breaks in a game).
Still
http://nocash.emubase.de/gbatek.htm#dscartridgeprotocol and http://nocash.emubase.de/gbatek.htm#dscartridgeioports detail the cartridge read methods. You are looking for these commands and overlaying their destinations with the file system
You might have to trace it back/around a few times if it loads to ram, decompresses it and then sends it to where it needs to be or if it loads the file location, loads the file header, does some maths on the info in the header and then fires more commands.
Also being pointer driven there is a kind of elimination method you can do- change the locations of the files in the binary and watch the changing commands that result. Such things are not that useful as you are almost all the way to pulling it apart properly
Tools of the trade. The no$gba dev version if you could find it should work although it does not play well with newer roms, raw desmume dev I am not sure about but give it a go and if you flanked it with some of the cheat creation tools you could do well.

Exception- the ARM binaries (in the case of commercial roms almost certain to be the ARM9 as the ARM7 is not usually touched by the actual developers) and to a lesser extent overlays are in memory when they run/get things pulled from them so if you find the stats coming from the ARM binary or actually being contained within it (any half decent header viewer will tell you where the binary sits in ram) you can then turn to edit the binary itself (remember they can be and quite often are compressed but that is easy to handle with something like http://code.google.com/p/dsdecmp/ or crystaltile2) without worrying about this.

A note- it does not happen often but we do sometimes see values held in the stack. It arguably bad form for programming but that does not change that it is still happening and you will have to deal with it.

You can mix this with some programming abilities- devs are unlike to employ a full database format and instead opt for a binary table, c struct, matrix/set of matrices or similar. If you know how this look in programming languages and how they turn out after a compiler sees them you will have a very valuable skill.
http://www.pipian.com/ierukana/hacking/ds_evos.html has some nice stuff to look at and looking at the file formats known on the DS is also a good thing (a start on such things http://www.romhacking.net/?category=&P...itle=&desc= )

I should also say sometimes save games come into play and stats are only loaded from the rom at the start of the game. Editing is almost always easy once you know how but the knowing how part is what takes the time and effort.