Kodewerx

I contemplated whether I should post this. I was worried that it would be too clunky to be worth it, but King suggested that the real issue lay in whether Rune would steal it.

(1:55:19 PM) King Rhyono: depends
(1:55:24 PM) King Rhyono: do u want rune to have it?
(1:55:28 PM) hectorofchad: HA
(1:55:33 PM) hectorofchad: Rune won't even be able to use it!
(1:55:40 PM) hectorofchad: Assuming he even has a TT
(1:55:51 PM) King Rhyono: he didn't use your aimbot either
(1:55:56 PM) hectorofchad: If you use it wrong it fucks up and crashes
(1:56:00 PM) King Rhyono: and I think he was still able to piss you off w/ it
(1:56:06 PM) hectorofchad: that's different
(1:56:11 PM) hectorofchad: the people he gave it to could use it
(1:56:19 PM) hectorofchad: if he gives this to anyone they'll have no use for it
(1:56:35 PM) hectorofchad: to anyone else it's a big long useless code

Indeed, it's entirely useless to anyone who is from GSC (if you go to GSC, die in a fire please).

In order to retain the code's uselessness to douchebags, I'm going to be a bit vague on what it does. That, and it doesn't need a whole lot of description.

Basically you plug this monster into your TT Run List, fill out the "XXXXXXX" areas, and watch it go. You're supposed to use it to find assembly instructions that load from or store to a specified address; when an instruction is found (it can only find one at a time) it will dump the register state post-execution of that instruction (the instruction is emulated in the "debugger" routine). Refer to ARM documentation to determine the values to use for the AND/CMP masks used to identify instructions. Currently only supports loads and stores of the byte, short, and long sizes (block loads and stores as well as signed loads of non-words, as well as double load/stores are not supported).

The code is intended to function for any game that the TT can boot on assuming that the TT's runlist is stored at 0x8800924 in the TT area. If your TT is modded such that 0x8800924 is NOT the start of the runlist, this code will not work. Also note that I have only tested this successfully in an emulator, and that it was not in the TT area during execution then. I plan on testing it myself soon. I thought it was too cool a script to wait until later posting. If it turns out to fail, I can always post the game specific version that works...

[Removed (outdated)]

It's a bit slow to search because it checks instructions in the range one at a time. The timer has shown to give each instruction about 5 checks before moving on to the next; you can increase the timer mask if you need more. If you want it to go faster, though, I recommend you simply shorten the search range to a more reasonable area.

Edit: In case it wasn't obvious (from the part about the TT runlist area), the code, up to the D2 line, must be the first code on the runlist, or it will not work (and then bad stuff will happen!).

Edit: I've fixed some mistakes I've found, but for some reason when I hook the game to the area at 0x8800938 (the beginning of the actual assembly of this code), it crashes every time. Looking through the disassembly hasn't suggested any programming errors, and the TT has to be executable because that's what it's used for. What the hell.

_________________

There must be some way to avoid having those all-zero lines.

Re: crashing, you probably checked this already, but are the hook and return setting ARM/Thumb mode correctly and does the right CPU have access to GBA ROM?

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

The hooks enter in ARM and exit to ARM like they should (I used ldr pc style hooking). The hook that is planted to lead to the debugger uses mov pc, #0x8800000 to absolutely jump to the TT, which I believe is done by the same CPU that uses the ldr r1, bx r1 combo to reach the TT normally.

The 0 lines would need to be 0 anyway because that's where my stack and the reg dump go; It might look ugly in the code, but as far as saving code space goes, the lines don't hurt. Well, I suppose they do "hurt", but the alternative is to have to find your own area to stack to on a per game basis, adding to the amount of work and defeating the idea of "portability".

Also, for some reason, writing to the TT area past the 8 Kb allocated for the runlist seems to screw stuff up, but my program doesn't write that far anyway. It might, however, be screwing up when I modify the runlist (when the program uses its stack) which is probably illegal if not handled by the TT PC application. That might be the cause. I'm thinking of booting my TT again and modifying the runlist directly in RAM rather than in the runlist window and seeing if it borks again. If it does, then I'll just have to move the stack.

The DS might also be doing some silly manual stacking like the N64 and [sp-4], which is overwritten by the debugger push, might be corrupted. I could write some test code that doesn't fudge up [sp-4] and see if it runs correctly after.

If all that fails, I can throw my code into No$GBA and see if it really was a programming error.

_________________

Don't be so damned worried about thieves! This is what the GPL/LGPL is for.

_________________
I have to return some video tapes.

Feed me a stray cat.

Well I don't think it matters a whole lot in this case, because I wanted this to be for the public (I'm hoping it will be useful for people who have computers that don't run No$GBA fast enough to debug outside the hardware itself). I don't know much about disclaiming, but I doubt it's no more difficult than making this post.

Stuff that potentially ruins WiFi isn't supposed to be thrown about carelessly, though. With all the people running around who don't give a crap about legal matters, it's too difficult to share anything with more than one person at a time on the web.

I nedz to fix tihs program now bbl kthx

_________________

I don't see anything capable of ruining WiFi play.

_________________
I have to return some video tapes.

Feed me a stray cat.

I was referring to the last thing that was stolen from me.

Anyhow, I've confirmed that the TT application that runs on your PC gets grumpy when you modify the area allocated for the run list in the Trainer Board's memory.

I can't simply move the stack, though, because lots of the variables rely on the executable area being volatile in order to skip lots of unnecessary ldr instructions. Looks like I'm going to have to waste my time rewriting this thing to not write to itself at all (gross).

Edit: Here we are.

58800938 00000000
E8800938 00000108
E92D0001 E59F00F8
E2800064 E9207FFE
E240002C E590100C
E3510000 0A000008
E2802024 E4923004
E5924000 E5935000
E59F60C8 E3C5520F
E1550006 05834000
EA000028 E5901008
E2811001 E211103F
E5801008 1A000023
E2806024 E4963004
E3530000 0A000007
E5964000 E3540000
0A000004 E5935000
E59F1080 E3C5520F
E1550001 05834000
E5901010 E5903018
E590401C E5905014
E1510005 AA000011
E4912004 E0022003
E1520004 1AFFFFF9
E2415004 E59F6048
E1550006 0AFFFFF5
E2806024 E4865004
E5801004 E5955000
E5865000 E59F6024
E205520F E0255006
E5015004 E5801010
E280002C E8B07FFE
E8BD0001 E92D4FF0
E51FF004 08800004
03A0F402 0YYYYYYY //Replace Y with the address of a free area 0xA4 in size; left of Y is mov pc op
D2000000 00000000

//0XXXXXXX 08800938 //Replace X with the address of the value loaded by the TT hook from AR handler

EAAAAAAA 00000238 //Replace A with the address of a free area 0x238 in size
E92D0001 E59F0228 //This code may be deleted after it is set
E2800064 E9207FFE
E240002C E2801024
E5912004 E202380F
E1A03823 EB000069
E2123301 0A000034
E2123401 0A000018
E2123402 03A05A01
02455001 00025005
0A000010 E202300F
E1A05004 EB00005D
E1A06005 E1A05004
E1A04006 E2023D3E
E1A063A3 E2023060
E3530000 01A05615
E3530020 01A05635
E3530040 01A05655
E3530060 01A05675
E2123502 00444005
10844005 E5905020
EB000056 E2123501
03C44003 03C55003
1A000009 E2123601
15947000 15867000
1A000030 E5967000
E2808004 E1560008
0287700C E5847000
EA00002A E2123601
15D47000 15C67000
1A000026 E5D67000
E2808004 E1560008
0287700C E5C47000
EA000020 E2123401
0A000011 E2123501
13A05A01 12455001
13C550F0 10025005
11A06225 13C55C0F
10855006 1A000005
E202300F E1A05004
EB000024 E1A06005
E1A05004 E1A04006
E2123502 00444005
10844005 E5905020
E3C44001 E3C55001
EB000026 E2123601
11D470B0 11C670B0
1A000004 E1D670B0
E2808004 E1560008
0287700C E1C470B0
E1540005 1A00000B
E3E06000 E580600C
E59D1000 E5801064
E5901004 E58010A0
E280002C E8B07FFE
E280003C E28DD004
E9207FFE E2400068
E280002C E8B07FFE
E8BD0001 E59FF060
E353000F 05904024
02844008 0A000006
E3530000 059D4000
0A000003 E2433001
E1A03103 E283302C
E7904003 E12FFF1E
E2023A0F E1A03623
E3530000 01A0600D
0A000006 E353000F
02806004 0A000003
E2433001 E1A06103
E0866000 E286602C
E12FFF1E 0YYYYYYY //Replace Y with the same address as the previous Y
D2000000 00000000

5YYYYYYY 00000000 //Replace Y with the same address as the previous Y
EYYYYYYY 00000028 //Replace Y with the same address as the previous Y
E51FF004 00000000
00000000 00000000
02000000 02400000 //Replace 0x2000000 with "Search Start" and 0x2400000 with "Search End"
0C500000 04100000 //Replace 0xC500000 with "Instruction Mask" and 0x4100000 with "Instruction Check"
02000000 00000000 //Replace 0x2000000 with "Access Address"
D2000000 00000000

EZZZZZZZ 00000008 //Replace Z with the address that can be branched to by a mov pc
E51FF004 0AAAAAAA //Replace A with the same address as the previous A

Still need to test it (about to).

Instruction Mask is a bit mask following the patterns in the paragraph below; Instruction Check is a value containing which of those bits are set.

opcode must be 01xx x1xX xxxx xxxx xxxx xxxx xxxxb for st/ldrb instruction
opcode must be 01xx x0xX xxxx xxxx xxxx xxxx xxxxb for st/ldr instruction
opcode must be 000x xxxX xxxx xxxx 0000 1xx1 xxxxb for st/ldrh instruction
"x" is negligable, "X" is the 0/1 for st/ld fork

Rest should be self explanatory.

You might not like all those 0 lines there. If you want, get rid of them. You'll have to do a bit of extra math as a result, though. Right now it's in "idiot friendly" form. I was in a hurry making my changes and failed to make it as efficient as possible; I'll probably go back over the source and fix that later. Right now I just want to be sure it works.

_________________

Allow me to rephrase that.

I don't see anything capable of ruining WiFi play.

_________________
I have to return some video tapes.

Feed me a stray cat.

Right...well, back on topic, the code ran fine for a good while, then eventually crashed. I'm guessing that the program was doing its thing, replacing opcodes with jumps and the like, and replaced an opcode that probably wasn't emulated correctly in the debug routine (I'm not entirely sure what all is emulated properly because I only tested some of the more obvious opcodes (including the more obvious tricky ones)). Whatever happened was likely a programming error this time (at least now debugging will actually help me solve the problem).

Edit: updated in my previous post (found the problem...I created a hooking issue when solving the clunkiness of the previous one).

Another Edit: Nope, apparently it still doesn't work. It certainly seems to have something to do with the way it returns from the mov pc, #0x8800000 hook. I told it to start searching from right at the opcode that reads from the address I specified and it crashed immediately.

_________________

What I meant with the zero lines is can't you use a fill or slide instead?
Because Nintendo already did?

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

That's what I thought he meant too.
*waits to see*

_________________

They were there for memory spacing purposes, so putting them in a slider would defeat the purpose.

I rearranged the memory to get rid of that dependency, though.

Edit: apparently even the versions of the code tailored to be debugged in No$GBA, which ran perfectly fine, also don't work with the TT plugged in.

Fuck you Datel. I'm gonna go play Halo.

Edit: Here is the version made especially for Metroid Prime: Hunters that is tested and working. It's very inefficient space-wise, since it doesn't execute from the TT area. Executing from the TT area is not the problem, and the only other controversial difference between the codes is the hook used (one hooks from the game execution and the other hooks from the AR handler). I made sure both hooks were flawless, so really, I have no idea why this version is the only one that works.

52000000 00000000
E2000000 00000348
EA000059 E59AB020
E59A8004 E59F0330
E9207FFE E59F10CC
E3510000 0A000008
E59F20DC E4923004
E5924000 E5935000
E59F60C4 E3C5520F
E1550006 05834000
EA000025 E59F1098
E2811001 E211103F
E58F108C 1A000020
E59F60A4 E4963004
E3530000 0A000007
E5964000 E3540000
0A000004 E5935000
E59F107C E3C5520F
E1550001 05834000
E59F105C E59F3060
E59F4060 E59F5054
E1510005 0A00000E
E4912004 E0022003
E1520004 1AFFFFF9
E2415004 E59F6048
E4865004 E58F1278
E5955000 E5865000
E59F602C E205520F
E0255006 E5015004
E58F100C E8B07FFE
E59FF018 00000000
00000000 0213EE80 //Replace 0x213EE80 with Search Start
02400000 0C500000 //Replace 0x2400000 with Search End and 0xC500000 with Instruction Mask
04100000 03A0F402 //Replace 0x4100000 with Instruction Check
020483A4 02000108
00000000 00000000
E353000F 05914000
02844008 0A000005
E3530000 059D4000
0A000002 E2433001
E1A03103 E7904003
E12FFF1E E2023A0F
E1A03623 E3530000
01A0600D 0A000005
E353000F 059F61E4
0A000002 E2433001
E1A06103 E0866000
E12FFF1E E92D0001
E59F01CC E9207FFE
E51F107C E5912004
E202380F E1A03823
EBFFFFE0 E2123301
0A000036 E2123401
0A000018 E2123402
03A05A01 02455001
00025005 0A000010
E202300F E1A05004
EBFFFFD4 E1A06005
E1A05004 E1A04006
E2023D3E E1A063A3
E2023060 E3530000
01A05615 E3530020
01A05635 E3530040
01A05655 E3530060
01A05675 E2123502
00444005 10844005
E59F5130 EBFFFFCC
E2123501 03C44003
03C55003 1A00000A
E51F3128 E2133601
15947000 15867000
1A000032 E5967000
E59F8108 E1560008
0287700C E5847000
EA00002C E51F3154
E2133601 15D47000
15C67000 1A000027
E5D67000 E59F80DC
E1560008 0287700C
E5C47000 EA000021
E2123401 0A000011
E2123501 13A05A01
12455001 13C550F0
10025005 11A06225
13C55C0F 10855006
1A000005 E202300F
E1A05004 EBFFFF99
E1A06005 E1A05004
E1A04006 E2123502
00444005 10844005
E59F5070 E3C44001
E3C55001 EBFFFF9A
E51F31E0 E2133601
11D470B0 11C670B0
1A000004 E1D670B0
E59F8050 E1560008
0287700C E1C470B0
E1540005 1A00000A
E3E06000 E50F6224
E59D1000 E5801038
E59F1024 E5801074
E8B07FFE E280003C
E28DD004 E9207FFE
E240003C E8B07FFE
E8BD0001 E59FF000
0214C7CC 00000000 //Replace 0x214C7CC with Access Address
0200033C 02000380
D2000000 00000000
520483A0 E59A8004
0204839C E51FF004
020483A0 02000004
D2000000 00000000

Edit: Apparently killing the write that stores over opcodes makes the program run fine, but then of course, its purpose is moot. The problem seems to lie in the debugging routine itself. The branch at 0x8800000 that is breached by the mov pc, #0x8800000 instructions cast throughout the RAM isn't causing the crash (I confirmed this just now), but the mov pc, #0x8800000 instruction itself might be the problem. It seems HyperHacker's mention about the legality of the execution in the TT had more substance to it than I thought. Since the AR hook is meant for the TT to begin with, of course it works for linking to the algorithm. However, the mov pc, #0x8800000 instructions don't seem to have that privilege, because algorithmically, accessing the TT for execution instead of RAM is the only difference between the code that works and the one that doesn't. It seems No$GBA isn't properly emulating the validation procedure that occurs when jumping to Slot 2.

So then, does anyone have any ideas?

Edit: I've confirmed that using mov pc, #0x8800000 just plain won't work. It may have access, but it might be considering 0x8800000 to be a mirror of 0x8000000 and then executing the wrong thing.

Isn't that just dandy. v_v

_________________

Bump.

Fixed the code 3 posts up; it's actually WORKING now.

Everything after the "Replace XXXXXXX" line of the code is able to be removed from the run list after the initial uploading. I left the line commented so that the whole thing could be pasted, set up, and added to the game's execution without immediately hooking (you shouldn't set the hook until you're actually ready to search for accesses; to unset the hook for resetting variables, reset the value from 0x8800938 to 0x8800000).

This thing sure is fun to play with. It's fun watching my reserved RAM area denote the program's activity to me as it scans the RAM, all the while, the game...NOT...crashing. *sigh of relief*

And now, I have to wonder why Datel didn't at least try to come up with something like this to accompany the TT, so that TT purchasers wouldn't feel like they spent a whopping $50 on a RAM expansion.

_________________