Jump to content

AR Functionability - Homebrew?


Recommended Posts

Unfortunately, I don't think so. The AR seems to freeze for codes that are too big, around the size of 15 Pokemon.

If that problem didn't exist, and if the homebrew could be made to run totally off the DS's RAM, then yes, theoretically it would be possible.

Even then it might be extremely difficult, since the game might have to be intercepted a the right moment.

Theoretically, yes it is possible. Practically, no.

Link to comment
Share on other sites

  • 3 weeks later...
Because the AR changes values in the DS's RAM, would it theoretically be possible to launch homebrew (that dosn't have DLDI support) after converting it to code format?

My trainer toolkit broke long ago, so could someone who has one look into it?

actualy this could be possible... al that we would have to do would be to re-write the AR apploader (runs only once at the start of the DS) to load a homebrew file stored on the cart instead of the main AR file (or re-code the main AR file for homebrew loading and main AR functions) not 100% sure this could work, I normily deal withthe wii, not the DS.

also: I have heard of people who have ripped and reinjected the files on the AR just with the cable and there PC, can someone explain to me how they did this so I can do some "experiments"... :D

Link to comment
Share on other sites

actualy this could be possible... al that we would have to do would be to re-write the AR apploader (runs only once at the start of the DS) to load a homebrew file stored on the cart instead of the main AR file (or re-code the main AR file for homebrew loading and main AR functions) not 100% sure this could work, I normily deal withthe wii, not the DS.

Even though that is a better way to do so, what I meant is Creating an AR code, so that homebrew code is put on the DS's RAM instead of the DS Game.

The AR Code should look something like this:

94000130 FCFF0000 - Optional Line to only run if L+R are pressed

EXXXXXXX YYYYYYYY

YYYYYYYY YYYYYYYY

D2000000 00000000

Where X=Start Location of where Homebrew is put in RAM

and where Y is the HEX Data of the homebrew file itself.

I could write a program to input Y, I only need to what X is in order to make a code to test this.

Link to comment
Share on other sites

Actually, the proper form is

EXXXXXXX ZZZZZZZZ

YYYYYYYY YYYYYYYY

YYYYYYYY .....

Where:

X = Memory location to write the stuff to.

Z = Number of bytes to write.

Y = data

Oh, and did you just have a birthday recently?

*sigh*

Apparently I didn't properly remember what the E operator was...

And yes.

btw, do you just happen to know what memory location homebrew starts at?

Link to comment
Share on other sites

Hmmm, I'm not that experienced at Action Replay Codes but from past experience mine freezes with a simple code occasionally.

However, if this plan doesn't work out (and if the user has a flash cart) in theory a custom DS program could be made that executes a script injected by the AR (one compiled to a basic numerical form), it wouldn't be able to do much though.

I guess it would be a repetitive loop checking a certain memory location, if it is changed to "1" for example, it would then execute the script. (Again, remember i'm not experienced at AR codes :smile:).

Link to comment
Share on other sites

Hey you know when if you have too many codes on and you try to lanch the game and all you get is a black screen? that is because the AR is re-writing the apploader, so what if we used that to make a custom apploader that lanches a file stored at XXXXXX adress? then we could use another code to write the homebrew file there... just an idea.

Link to comment
Share on other sites

*sigh*

Apparently I didn't properly remember what the E operator was...

And yes.

btw, do you just happen to know what memory location homebrew starts at?

Then, Happy Birthday! Back to our regularly scheduled programming (lol, pun, sort of)...

It's not quite so simple as "the location homebrew starts at". Here's a bit of an abstract explanation for how computers work at their lowest level.

Series of instructions are stored in the RAM in chucks called functions. These instructions are loaded in sequence into the processor to be executed. Certain statements indicate a "jump", which tell the processor to start execution at a different location rather than the next instruction. These jumps are the basis for how functions are called and returned from in the operation of the computer.

So from that, it's not just a matter of inserting the right code into the right location in the memory. You also need to hijack the DS's execution sequence.

Fortunately, that might not be that hard. The IV Check code hijacks the function used to view a Pokemon's unencrypted data and temporarily redirects it to a custom function that the code sets up in a normally unused area that extracts the Pokemon's IV data and writes it to the TM bag.

Hey you know when if you have too many codes on and you try to lanch the game and all you get is a black screen? that is because the AR is re-writing the apploader, so what if we used that to make a custom apploader that lanches a file stored at XXXXXX adress? then we could use another code to write the homebrew file there... just an idea.

Is that anything like the infamous "buffer overflow" that seems to be behind every major software security vulnerability?

Link to comment
Share on other sites

Fortunately, that might not be that hard. The IV Check code hijacks the function used to view a Pokemon's unencrypted data and temporarily redirects it to a custom function that the code sets up in a normally unused area that extracts the Pokemon's IV data and writes it to the TM bag.

That might make homebrew in AR codes have a ridiculuos limit (less than 500KB, or something smaller), and also require a button activation.

Is that anything like the infamous "buffer overflow" that seems to be behind every major software security vulnerability?

I had that happen to me once (or more) in one of my programs (unpublished), and I don't remember what I was trying to do.

Link to comment
Share on other sites

just to let you know, a button activator would be useless because the file would overload the game's apploader (not AR's) so the game would crash as soon as GO is pressed on the ar

the AR runs kinda like this (I think):

DS turn on -> AR apploader runs (once), skiping the main menu -> AR boots up -> you select codes (ar overrides junk data before the apploader) then hit go -> game apploader runs (once) -> game loads

if any of that is interupted (ie. too many codes = overrides part of the apploader) it will crash/freeze the DS

if you're wondering the reason why the AR writes data before the apploader, it's because it's always in the RAM (junk data & apploader) so the codes will not be overridine

Link to comment
Share on other sites

  • 4 weeks later...
Maybe we could run ROM hacks, ran in various AR codes, really small codes, maybe it will be annoying, but its possible, at least a storyline change.

The point of this thread is to discuss transforming homebrew into AR codes that will run the homebrew when any game is launched, so those without flashcarts can run some homebrew, not ROM hacks.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...