Kodewerx
https://www.kodewerx.org/forum/

NDS AR Code Type Information
https://www.kodewerx.org/forum/viewtopic.php?f=11&t=98		 Page 4 of 6
Author:  kickenchicken57 [ Thu Mar 22, 2007 5:28 pm ]
Post subject: 
If any of you think some of my codes are just plain awesome, thanks the users who make these type of threads. Without them, I wouldn't be able to make the types of codes I love to make most. The button on/off is also very handy and i may use it in the future.
Author:  nickvv [ Wed Apr 18, 2007 3:25 am ]
Post subject: 
Can anybody explain exactly how the AR hooks into the game code; how the default "master codes" work. Is it something like the ARM7 vblank IRQ handler? Also has anybody decoded how the game-specific AR master codes work yet (like the one for Animal Crossing)?
Author:  chishm [ Wed Apr 18, 2007 5:28 am ]
Post subject: 
AR hooks the ARM7 IRQ dispatcher. See previous page in this thread for master code discussion.
Author:  nickvv [ Wed Apr 18, 2007 6:22 pm ]
Post subject: 
Ok, so is the AR code handler executed every time there is an interrupt or only for certain periodic interrupts such as vblank? It would be useful to know just how often the code handler is actually executed.

As for the master codes, I saw the brief discussion on the previous page however it didnt appear to have been fully understood. It seems as though its main purpose is to relocate the AR engine in the case of any conflicts, is this correct?
Author:  chishm [ Wed Apr 18, 2007 6:31 pm ]
Post subject: 
The master code relocates the cheat engine in memory and has the potential to change the way the game is hooked. I'm not sure whether the AR cheat engine only runs on VBlank or not.
Author:  nickvv [ Wed Apr 18, 2007 8:26 pm ]
Post subject: 
Ah ok, thanks for the info. I'm going to assume for now that the engine only runs on vblanks, it would seem terribly in-efficient if cheats got processed every timer interrupt etc. 60 times a second would seem to be adequate.
Author:  nickvv [ Thu Apr 19, 2007 3:55 am ]
Post subject: 
Hrm, another question - does anybody know why you actually need to relocate the AR engine for games such as Animal Crossing? I thought the memory region where the engine sits was reserved for ARM7 and shouldnt be touched by the game?
Author:  Parasyte [ Thu Apr 19, 2007 4:04 am ]
Post subject: 
Some games do some weird things. AC is one of them. It places ARM code into VRAM and executes it, for example.
Author:  nickvv [ Thu Apr 19, 2007 5:13 am ]
Post subject: 
That doesnt explain why the engine would need to be relocated in this case. If anything, with the code moved out of main RAM and into VRAM there should be even more room for the engine.
Author:  Parasyte [ Thu Apr 19, 2007 7:03 am ]
Post subject: 
No, it wasn't meant to explain why the relocation is necessary. It was meant as an example of the game doing unexpected things; For a proper 'explanation' you only need to realize that the game DOES use the ARM7 arena, regardless of what it's used for.
Author:  nickvv [ Wed May 02, 2007 1:25 am ]
Post subject: 
One more question, how is the gameid for AR codes created? I assume that its some sort of checksum however as for the exact algorithm and the parts of the games includes in the checksum I'm at a loss..
Author:  chishm [ Wed May 02, 2007 2:50 am ]
Post subject: 
4 character Game ID and the bitwise inverse of the CRC32 of the 512 byte NDS header.
Author:  nickvv [ Wed May 02, 2007 3:32 am ]
Post subject: 
Excellent, thank you for that information!
Author:  Parasyte [ Wed May 02, 2007 12:53 pm ]
Post subject: 
Technically it's just standard CRC32 without reflection-out. A step is skipped, rather than added.
Author:  jacktaylor73 [ Sun May 20, 2007 5:33 pm ]
Post subject: 
Hey, how would you do something like start+select or a+b?
Author:  kenobi [ Mon May 21, 2007 4:41 am ]
Post subject: 
Para explained it here.
Author:  kenobi [ Sun May 27, 2007 4:01 am ]
Post subject:  Re: NDS AR Code Type Information
Fyi I added in my first post some infos/hacks on the TT posted here and there in the forums (yeah, it's getting quite big...).
Also ported the AR hacks to the TT.
Author:  kenobi [ Mon May 28, 2007 11:43 am ]
Post subject:  Re: NDS AR Code Type Information
Here are some infos I gathered on the AR (m) codes for anyone interessed (chishm mainly?).
I'm still working on it, but as I've gone far enought for now, I decided to post it.
I'm still missing infos on line #1 (and possibly #9), I haven't looked at all at the automatic hook search, didn't looked at the TT, and I'm not quite sure if the AR is only capable of hooking ARM7.
Once it'll be finalized, I'll add these infos in the first post.

And sorry if some explanations/words seem a bit strange...
If you have any trouble to understand them, don't hesitate to ask !

Code:
AR (m) codes decrypted ! (still wip)

1 : 00000000 023F0000
2 : 00000000 02380868
3 : 00000000 037F8700
4 : 00000000 00000001
5 : 00000000 E51DE004
6 : 00000000 023FD000
7 : 00000000 023FE000
8 : 00000000 023FF000
9 : 00000000 00000001

This (m) code has been made for and tested on SM64 v1.01 US.


Line #1 : ? (used prior to launching game ?).
--------------------------------------------
Might be used to put some routines that clean the ram and softresets the NDS to actually launch the game (at least there is the reset subroutine at address+0x1314 to address+0x136C, which also means there must be some free space at that address).


Line #2 : address to write the hook at (inside the ARM7 executable).
--------------------------------------------------------------------
Also acts as a Hook mode selection, if line # is set to 0.
00000000 : no hook (?)
00000001 : automatic hooking
anything else : address to write to.


Line #3 : hook final address.
-----------------------------
It's the address at which the hook, ie. the bl instruction, will be executed.
This address is used by the AT to actually create the bl instruction.
Used as a mask in automatic hooking is set (default mask, if line #3 0ed, is 0x0380FFF8 ?).


Line #4  : Hook mode selection.
-------------------------------
0 : automatic hooking.
1 : loads the hooked instruction and writes bl at the same address, ie. line #3's address.
    (means the instruction should not be moved at all, else it'll crash)
2 : load the hook from line #3's address, and write the bl at line #4's address.


Line #5 : if <>0, this will be the ARM instruction that replaces the hooked one.
--------------------------------------------------------------------------------
Replace, as in 'the original instruction is destroyed, and this one is executed instead'.
Can be used to hook a bx r14 that is after a pop {..r14}. Set that instruction to E51DE004 in that case.
But as this intruction (or the original instruction, if line #5 is 0ed), is executed before the code handler, it seems a bit limited (ie. you can't hook a bx r2, unless you destroy r14 by moving r2 to r14 (E1A0E002), as bx r14 will be the instruction that will jump back to the game).
Might be useful for other things I guess...


Line #6 : address to store important stuff (hooking and hook execution routine).
--------------------------------------------------------------------------------
If 0ed, 0x023FE000 will be used by default.
Total size is 0x74 bytes.
The bl of the hook will point to address + 0x38.
There you have the hooked instruction (or line #5's intruction), then a nop (?), then a bl to the code handler.
For the TT, the size is 0x98. The added stuff is a routine that checks if L+R is pressed, and one that will check if the ARM7 has the right to access the GBA slot.And it'll jump to the TT's program (at 0x08800000). The hook's bl still points at address+0x38.


Line #7 : address to store the code handler.
--------------------------------------------
If 0ed it'll be put right after the routines written at the address of line #6 (if 0ed = 0x023FE074).
Total size is 0x4F0 bytes.
Knowing this, porting the ar hacks while the code handler is moved is just an easy operation.
Works the same for the TT, however, the code handler that is at this is a copy of the AR code handler (!= TT code handler) which will NOT be executed, the routines at line #6 jumping directly to the TT's program... So it's just wasted space.

Line #8 : address to store the code list.
-----------------------------------------
If 0ed it'll be put right after the routines written at the address of line #7 (ie. default = 0x023FE564).
It begins with the ((size of the code list in bytes) >> 2) (=# of codes' lines * 2).
Then follow all the codes that have been entered.
For the TT the code list will be copied there during game bootup, but it'll not be actually used, the code list inside the TT will is actually used. So it's just wasted space.

Line # 9 : Must be 1 ?
------------------------
If not set to 1 the (m) code will not be recognized as an (m) code (and will not be 'executed').
Author:  chishm [ Mon May 28, 2007 11:20 pm ]
Post subject:  Re: NDS AR Code Type Information
That is very useful, thanks. I didn't realise they used a BL to hook rather than a hardcoded return address.

I wonder which games besides Animal Crossing actually require a master code. So far I haven't had to implement anything more than moving the cheat engine location.
Author:  kenobi [ Sun Jun 17, 2007 7:26 am ]
Post subject:  Re: NDS AR Code Type Information
I put the updated (m) code informations in the bottom of the first post. Some informations about the ARDS auto-hooking can also be found there.
Author:  Hiei-YYH [ Tue Jun 19, 2007 7:29 am ]
Post subject:  Re: NDS AR Code Type Information
kenobi, can you explain if i can do this (pointer to pointer)

023FE424 E08AA003 < Your hack to add value to offset (d4)
6212BA14 00000000
B212BA14 00000000 < load the pointer
D4000000 000002E4 < add 2E4 to the next pointer
B0000000 00000000 < load the pointer from the same base address
100000C8 00000000 < store at +0xC8
D2000000 00000000
Author:  kenobi [ Tue Jun 19, 2007 9:26 am ]
Post subject:  Re: NDS AR Code Type Information
Sure, that's exactly how it's meant to work.
Moreover, I tested your exemple with the TT, and it worked without any problem.
Author:  Hiei-YYH [ Tue Jun 19, 2007 3:07 pm ]
Post subject:  Re: NDS AR Code Type Information
ok kenobi, look at this

source.s: Assembler messages:
source.s:7: Error: branch out of range


.text 0x0204ECD8
b sub

.text 0x02376000
stmfd sp!,{r0,r1}
ldr r0,pointer
ldr r0,[r0]
ldr r1,offset1
add r0, r0, r1
ldr r0,[r0]
ldr r1,offset2
add r0, r0, r1
mov r1,#0x0
str r1,[r0]
ldr r1,maxhealth
str r1,[r0,#0x04]
ldmfd sp!,{r0,r1}
bx lr

pointer:
.long 0x021299AC
offset1:
.long 0x00000014
offset2:
.long 0x000000B8
maxhealth:
.long 0x00004E20
sub:
.long 0x02376000


in ARMStrong this is assembled normally...

@textarea 0x0204ECD8
b 0x02376000
@endarea

b 0x02376000 = EA0C9CC8
your assembler return EA000011

anyone can say it to me what i'm doing wrong?
Author:  bobbyDSM [ Tue Jun 19, 2007 5:53 pm ]
Post subject:  Re: NDS AR Code Type Information
Hey...I've noticed that instead of the button codes you posted, you can also add 2FFh to the back of the line:
94000130 000002FF

I'm not that skilled with hex, so could somebody edit the wild pokemon modifier to press 'R' to get 493 Masterballs and hold Y while running to find the pokemon? All help is appreciated..:-)
Author:  kenobi [ Tue Jun 19, 2007 10:03 pm ]
Post subject:  Re: NDS AR Code Type Information
@Hiei-YYH :

That's normal, it's because the tool is only made for asm code that are using the ARDS hack.
That means it doesn't support the 'custom branches' (from out of AR code handler to code handler), as your code will be executed each time the code handler is executed ; and the address where the asm will be stored is already defined (it's in the code handler) however this address changes, depending on how much codes have been enabled.

As you're not using any in-game register, I don't see why you need a custom hook for your asm routine. So try your code without the

.text 0x0204ECD8
b sub

.text 0x02376000
...
sub:
.long 0x02376000


ie. try this AR code :
023FE074 012FFF11
E0000000 00000048
E92D0003 E59F002C
E5900000 E59F1028
E0800001 E5900000
E59F1020 E0800001
E3A01000 E5801000
E59F1014 E5801004
E8BD0003 E12FFF1E
021299AC 00000014
000000B8 00004E20
023FE074 E3520003

And if you only want it to be executed at the certain point in the game, try using some conditional codes before it.

If you still want to use your custom branching, and put your asm to 02376000, then just assemble them separatly, and create 'normal' codes (=not using the ar hack) out of it.
ie.
0204ECD8 EA0C9CC8
E2376000 00000048
E92D0003 E59F002C
E5900000 E59F1028
E0800001 E5900000
E59F1020 E0800001
E3A01000 E5801000
E59F1014 E5801004
E8BD0003 E12FFF1E
021299AC 00000014
000000B8 00004E20

(of course, that means the instruction at 0204ECD8 was a bx lr, else it'll not work).
Author:  Hiei-YYH [ Wed Jun 20, 2007 10:19 pm ]
Post subject:  Re: NDS AR Code Type Information
kenobi wrote:
@Hiei-YYH :

That's normal, it's because the tool is only made for asm code that are using the ARDS hack.
That means it doesn't support the 'custom branches' (from out of AR code handler to code handler), as your code will be executed each time the code handler is executed ; and the address where the asm will be stored is already defined (it's in the code handler) however this address changes, depending on how much codes have been enabled.

As you're not using any in-game register, I don't see why you need a custom hook for your asm routine. So try your code without the

.text 0x0204ECD8
b sub

.text 0x02376000
...
sub:
.long 0x02376000


ie. try this AR code :
023FE074 012FFF11
E0000000 00000048
E92D0003 E59F002C
E5900000 E59F1028
E0800001 E5900000
E59F1020 E0800001
E3A01000 E5801000
E59F1014 E5801004
E8BD0003 E12FFF1E
021299AC 00000014
000000B8 00004E20
023FE074 E3520003

And if you only want it to be executed at the certain point in the game, try using some conditional codes before it.

If you still want to use your custom branching, and put your asm to 02376000, then just assemble them separatly, and create 'normal' codes (=not using the ar hack) out of it.
ie.
0204ECD8 EA0C9CC8
E2376000 00000048
E92D0003 E59F002C
E5900000 E59F1028
E0800001 E5900000
E59F1020 E0800001
E3A01000 E5801000
E59F1014 E5801004
E8BD0003 E12FFF1E
021299AC 00000014
000000B8 00004E20

(of course, that means the instruction at 0204ECD8 was a bx lr, else it'll not work).


Nah, i was just testing jumping from a bx lr, well it worked lol, but since the data changes too much, i guess is preferably via ards/cbds it self with your hacks.

kenobi do you know if to add a support for cbds in an emulator it needs the decryption key? damn, cmx is away... :/

someone needs to make a tool that attach to emulators like "hasteds" but that support those cheat devices cheats so we can test faster all the codes... since viper doesn't seems to update renegade64 anymore i guess i'm out of luck (yes, i don't have an NDS :P ) -_- damn... all that we can do is wait the experts (kenobi, parasyte anyone? lol ) to do that...
Author:  kenobi [ Thu Jun 21, 2007 11:31 am ]
Post subject:  Re: NDS AR Code Type Information
Well, to decrypt encrypted CBDS codes, you need the 'keys', so that apply to everything(decryption tool, emulator). However I'll not expand on that subject, nor give any hints/advices.

Also, I don't have the knowledge to make a 'emulator attached' tool, nor the time to learn how to do it.
Author:  Hiei-YYH [ Thu Jun 21, 2007 8:56 pm ]
Post subject:  Re: NDS AR Code Type Information
kenobi wrote:
Also, I don't have the knowledge



ok, that was funny :P
Author:  HyperHacker [ Fri Jun 22, 2007 9:07 pm ]
Post subject:  Re: NDS AR Code Type Information
I don't think Renegade needs to be updated for that, just find the address emulated RAM is stored at and update emulators.cfg.
Author:  Hiei-YYH [ Sat Jun 23, 2007 8:52 am ]
Post subject:  Re: NDS AR Code Type Information
HyperHacker wrote:
I don't think Renegade needs to be updated for that, just find the address emulated RAM is stored at and update emulators.cfg.


if you're talking about the search functionality maybe not, but in geral it needs updates, i can't find any pointer that point to the start of the nds ram (in no$gba) that didn't change after i closed the emulator, i just found pointers that point to the start of the data block (like -10000h of difference) which by the way, all the emulators give me memory allocation errors so all the pointers (and the ram specific addresses) that is in emulator.cfg may be fixed for who wrote the file. but not for me and the others... "RAM is not the same for everyone" only if the emulator coding has a specific address for pointer in the coding. And for ards support, just 2 ards code types that are supported, and just the normal 8/16/32bit are working without any bugs, the pointer codes just write in 32bit mode, it doesn't matter if you use 2 1 or 0 as code type and this sometimes is big problem.


but anyway, forget about it... looks like next ideas version will be added support for AR and CB raw codes




kenobi, can you explain something to me

94000130 FCFF0000
B21C4D28 00000000
B0000004 00000000 < this line, i don't get it, it loads from the same offset +4 ?
0000AA3C EDB88320
2000AA68 00000007
D2000000 00000000
Page 4 of 6 All times are UTC - 8 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/