News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Implementing a hack  (Read 4771 times)

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Implementing a hack
« on: August 13, 2011, 04:08:55 pm »
Hey, I am kind of new to assembly but i have enough knowledge to understand code and write my own code as well.

My question is how can implement a hack for NDS. Say i know the address of where I want my code to run (in thumb mode) and I want it to branch to my code, I think I need to store my code somewhere in memory but I am not sure where. I am kind of frustrated because I developed my hack in no$gba but everytime I put the game on my flashcard it crashes and I feel like it is a waste of time because I cannot get my hack running because the place I put it does not run on flash card but runs on emulator. My goal is translate a game but if I can't even get my hack to run, I don't even think I can do this.

Auryn

  • Hero Member
  • *****
  • Posts: 650
    • View Profile
Re: Implementing a hack
« Reply #1 on: August 13, 2011, 07:03:34 pm »
Are you sure i's your hack the problem??
There are many flashcards and many games...not all work everywhere.
Try "break" the rom into pieces and rebuild it without a change.

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Re: Implementing a hack
« Reply #2 on: August 14, 2011, 12:52:01 am »
The hack works. Right now I am looking a place on memory that is not being written. I cannot find a place within 2d00000-3000000 because it crashes when I try to ldr that location. From 2000000-2d000000 it can be called but some time it will crash because the code overwrites that location.  I am not sure where I can place my code at address. I tried static hooking but that doesn't work either because the address it gets sent to is 8XXXXXX unless I did it incorrectly.

KC

  • Full Member
  • ***
  • Posts: 210
    • View Profile
Re: Implementing a hack
« Reply #3 on: August 14, 2011, 02:04:01 am »
The main ram should be mirrored four times in the 2000000 region, so the only interesting area is from 2000000-23FFFFF as the rest is the same as that anyway.
It's probably easier to search for data that is loaded early on and kept in memory at all times, something that you can easily expand. Fonts are generally pretty well suited for that.

If you can find the functions that the game uses to load a file into memory, you could also put your code into its own file and just implement a small loader function somewhere (overwriting a few strings that you can put into your new file then, for example). That's what I usually do.

What do you mean with "ldr that location"? Loading an immediate (ldr r0,=address) or loading data (ldr r0,[r0])?

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Re: Implementing a hack
« Reply #4 on: August 14, 2011, 03:40:20 pm »
Thanks for the tip.

By ldr I meant I tried to load content from an address and it would crash so...

ldr r0,address ;@ address is like .long 0x2400000
ldr r0,[r0]      ;@ crashes here trying to read from 0x2400000

But doing anything around 2000000-23FFFFF loads.

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Implementing a hack
« Reply #5 on: August 14, 2011, 03:46:32 pm »
There is no 2400000. The bank only goes up to 23FFFFF.
In the event of a firestorm, the salad bar will remain open.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7097
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Implementing a hack
« Reply #6 on: August 14, 2011, 03:55:01 pm »
Thanks for the tip.

By ldr I meant I tried to load content from an address and it would crash so...

ldr r0,address ;@ address is like .long 0x2400000
ldr r0,[r0]      ;@ crashes here trying to read from 0x2400000

But doing anything around 2000000-23FFFFF loads.

According to the GBA docs I read, it's 0203FFFF. (a difference between 256KB and 4MB)
(I'm sure KC know much better than I do what the right amount is, but 4 MB seems like quite a generous amount for a system of the GBA's capability).

EDIT: Never mind my comments, I missed that it's NDS. For some reason I thought he was working on a GBA hack.
« Last Edit: August 14, 2011, 06:57:33 pm by KingMike »
"My watch says 30 chickens" Google, 2018

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Re: Implementing a hack
« Reply #7 on: August 14, 2011, 05:53:09 pm »
I hear expanding the arm7 file would increase memory capacity but I haven't had luck with that (so most likely I am doing it wrong).

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Implementing a hack
« Reply #8 on: August 14, 2011, 06:44:50 pm »
You can expand it up to 0x40000 bytes in size (that is, the entire capacity of the memory bank). If there's any "blank" space after what the game has reserved, you might be able to insert your hacks there.
In the event of a firestorm, the salad bar will remain open.

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Re: Implementing a hack
« Reply #9 on: August 14, 2011, 08:10:30 pm »
If I add padding that means the max I can read is 0x2400000 correct? I could already read up to 23fffff and anything after that fails, so I am guessing padding the arm7 does nothing?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Implementing a hack
« Reply #10 on: August 14, 2011, 09:16:01 pm »
0x23FFFFF, actually (remember, it counts from 0). Padding the ARM7 file will effectively allow you to insert code at the end of the memory bank, assuming the game doesn't use all available space.
In the event of a firestorm, the salad bar will remain open.

matthewn4444

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Re: Implementing a hack
« Reply #11 on: August 14, 2011, 09:29:46 pm »
Ok thanks, so I thought so... I guess there is no guarantee to find an address the game never touches without luck XD. I placed my code near the end of the ram address and hopefully it will stay there (so far looks promising but you never know). The other options I think are placing the code writing over arm9 or arm7 code that runs on start up and never again, though I haven't look at that, it may seem that there maybe very little room.