ROM Hack How to make an AP PAtch?

[MMad3.0]

Hey everyone, this isn't another forum wanting to get the latest HG/SS Ap Patch and clogging it up with spam. I'm genuinely interested in how these hackers make AP Patches? What program do you use? What coding do you use? Just a layman's view at Ap Patching.

Thanks

 

[Wabsta]

Well, you will have to have a debugger.
There are hardware debuggers, that you connect to the nintendo DS.
And there are software debuggers, like those found in Emulators.

Using this, you can, for example, see what adresses in HEX are responding to your action.
Like, when you walk out of a room, adress 0x4773F9 get's really active. (for example)
Then it's most likely that that adress is used in the rom, to move you from room to room.
As a rom hacker you could do 2 things, change the adress you are moving too, so you can modify teleports. Or if this adress comes up with is own problems, modify it, so that it works/doesnt have AP anymore.


This is a very undetailed explenation, but yea, this is how it kinda works as far as I know.


EDIT:
And please, don't make this another HG/SS hack patch thread.

 

[tanjiajun_34]

Just asking. How can we get the device to make it? What is it called?

 

[FAST6191]

Some build their own but most use software level stuff (desmume and no$gba debug being the choice applications here), action replays are fairly basic hardware devices though.

http://www.securitytube.net/ has several good videos that describe the basics of hacking which in the case of the DS correspond fairly well (stuff like the PS3 and 360 use a slightly different layout of hardware).

 

[MicShadow]

Have a go at disassembling and cracking a game that uses a CD-check (not a new one, as they are hard)
I got familiar with creating patches and cracks by mucking around with the Painkiller game .exe and removing the initial DVD check
If you can get a copy of IDA Pro 5, check it out, its an amazing debugger

Of course, DS debugging s fairly different and primitive in comparison, but still a good place to start is computer binaries

 

[MMad3.0]

So if a game freezes and address x becomes active, I can attribute x to the freezing problem?

Is it as simple as just removing it, or do I need to be a little more technical?

 

[BabiesMayDie]

So if a game freezes and address x becomes active, I can attribute x to the freezing problem?

Is it as simple as just removing it, or do I need to be a little more technical?

If it was that simple, it would have been fixed seconds after the game was dumped.

 

[Edgewalker_001]

That kind of depends on what x does...

I'm a total n00b though, so I might be wrong...

From what I've understood though, since the actual program code is so heavily encrypted/otherwise very hard/impossible to access, hacking without knowledge of the source code basically consists of looking at what output the ROM provides and changing or modifying it in various ways to get the desired results.

It's sort of trying to get the chinese room to spell HORSE XD

 

[FAST6191]

The program runs in memory which is trivial to snatch from the ram of either a running device or more likely an emulator if it was not already trivial from a unarchiving of the DS rom (the arm9.bin part- that is the first directory is usually* what you want to be looking at and more often than not it is uncompressed or compressed with a basic method). We have had disassemblers for years as well. If anything it is more security by the fact there is a lot there and narrowing it down is a somewhat tricky but definitely time consuming game.

*before I get a smack upside the head from those who focus on AP they can also be in the ARM7 binary or an overlay for either of them. I should also mention THUMB here (a separate instruction set of sorts baked into some ARM processors including the GBA and DS).

Lack of source code does make for a more difficult challenge but far from impossible (it helps that the DS is fairly simple as far as hardware goes) not to mention once you get the basics down assembly gets fairly logical (simple is a bad word here but if you sit there and think it through it is not bad at all). The "reads" memory section is approximately correct. The ability to view and change memory in "real time" and observe it over the course of things is one of the reasons emulators and the like are so valuable to would be hackers.

Anyhow if you have narrowed down your checks then deleting it outright will do nothing for you. Usually checks are of a "branch/jump if" variety so you can either skip to the "good" outcome (I linked security tube for a reason- it has a nice video of this on there) or sometimes the checks will be in a line so you can "NOP" (no operation is one of the most basic instructions that quite literally means do nothing for a instruction length- most of the time it is for things like this but on occasion it can be nice to work around bugs in silicon) the bad instruction and then hope it carries on.
You also have to remember freezing is not everything- lately we have seen developers more to more covert methods (late game freezing, different drop rates (phantasy star), a considerable amount of checks (many games- indeed as we "own" the DS this is probably one of the better ways).

 

[Katuo]

There is also an alternative in removing the effects rather than the causes. This is effectively treating the symptoms, but it works and might be much easier depending on how the application was coded. This has been frequently seen in trial versions of software where some patches remove the timer and auto-hide nag dialogs rather than causing the application to be properly registered.

The HG/SS version of this would be freezing the "event counter" rather than removing the actual checks. Of course, HG/SS is a very special mess making this really hard to do (and from what I've heard, it's more of a forced memory leak then a simple counter - I'm eagerly awaiting a technical "what HG/SS did" article).

Of course, neither approach is easy on recent games; there's checks on everything if you can even find the code. I'm only mentioning it because it is viable at times.

 

[Searinox]

Treating the symptoms is FAR worse than solving the causes. Symptoms are much easier to find, but oftentimes AP code is made in such a way that it's intertwined with other code, and thus dependant on it. A simple example would be making the data for loading areas always pass through the AP, in which case tampering the AP breaks the area loading too. Nintendo is smart enough to do that and proof was that attempting to tamper with the AP counter destabilized the game.

The best place to start is the root cause, the moment when the game checks something, and decides that - yes, it's working as intended, or no, it's working suspiciously. Based on that one decision the whole complex AP scheme triggers. THAT decision has to be patched. It is one very discrete moment, and you have to know where and what to look for, so it's impossible to find unless you have proper knowledge.

Another problem with treating symptoms is that the symptoms themselves may be hidden, like some AP penalties may only take effect later in the game, and until then they remain dormant, not signaling anything suspicious to the would-be hacker.

All these things are reasons why hacking AP from the most obvious direction is near impossible, or would take ridiculous amounts of time(years!) and LOTS of addreses patched.

 

[Katuo]

That's true most of the time, but not always. I've seen at least one app that made absolutely sure that the actual key check wasn't tampered with... while the actual crack was as simple as using Windows Enabler to press the Next button (the app auto-enabled the button if you entered the correct key and didn't even check the key box on click).

Of course, like you said, there's plenty of times where fixing the symptoms won't work or may complicate matters further. Earthbound (and I believe that recent C.O.P game as well) is a classic example here. In general, it is better to fix the cause. Still, you shouldn't discard the possibility of just hiding the symptoms outright.

 

[Olly]

You might need this.



What We Think We Know
last update: 9:57 PM CST March 18


IMPORTANT:

Spoiler

OMG WHEN WILL THE WORKING PATCH BE OUT?
As soon as the people working on it stop being spammed and can concentrate for long enough to find one.

RARELY CRASHING DOES NOT MEAN WORKING PERFECTLY.
THOSE "RANDOM" CRASHES TYPICALLY FOLLOW THE 24 EVENT PATTERN.

CURRENTLY WORKING:

Spoiler

(These do have occassional freezes, but very rare.)

- Acekards work most of the time.
- CycloDS.
- EDGE.
- Supercard.
- Latest version of Desmume can play the game.
- No$GBA has a fix which makes the game playable.

THE PROBLEM:

Spoiler

- The Open on No$Zoomer or simply press F12.
6. Open your game again. RESET function won't work, as you will get a rom image crash.
7. Choose your game just like you would do it on a real DS.

*For no$gba to recognize a save, the save must be in the "BATTERY" folder.

PEOPLE WORKING ON A FIX:

Spoiler

- M3 Team
- R4 Ultra Team
- Other R4 Clone Teams
- Supercard Team
- Xenophobia (Maybe)
- Pong (for R4 with YSmenu)
- Many Forums
- ...and countless others.

CREDIT:

Spoiler

From Various Sources.
Most recent editting and organizing by Olly.

Something wrong? Something new? PM Olly to add it.