| Kodewerx https://www.kodewerx.org/forum/ |
|
| Zany TT Hack https://www.kodewerx.org/forum/viewtopic.php?f=11&t=5238 |
Page 1 of 1 |
| Author: | Hextator [ Sat Feb 16, 2008 1:11 pm ] |
| Post subject: | Zany TT Hack |
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. |
|
| Author: | HyperHacker [ Sat Feb 16, 2008 4:43 pm ] |
| Post subject: | Re: Zany TT Hack |
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? |
|
| Author: | Hextator [ Sun Feb 17, 2008 11:22 am ] |
| Post subject: | |
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. |
|
| Author: | Parasyte [ Sun Feb 17, 2008 3:10 pm ] |
| Post subject: | Re: Zany TT Hack |
Don't be so damned worried about thieves! This is what the GPL/LGPL is for. |
|
| Author: | Hextator [ Mon Feb 18, 2008 1:26 pm ] |
| Post subject: | |
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 |
|
| Author: | Parasyte [ Mon Feb 18, 2008 1:47 pm ] |
| Post subject: | Re: Zany TT Hack |
I don't see anything capable of ruining WiFi play. |
|
| Author: | Hextator [ Mon Feb 18, 2008 2:11 pm ] |
| Post subject: | Re: Zany TT Hack |
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. |
|
| Author: | Parasyte [ Mon Feb 18, 2008 3:30 pm ] |
| Post subject: | Re: Zany TT Hack |
Allow me to rephrase that. I don't see anything capable of ruining WiFi play. |
|
| Author: | Hextator [ Mon Feb 18, 2008 3:36 pm ] |
| Post subject: | |
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. |
|
| Author: | HyperHacker [ Tue Feb 19, 2008 7:10 pm ] |
| Post subject: | Re: Zany TT Hack |
What I meant with the zero lines is can't you use a fill or slide instead? Parasyte wrote: Allow me to rephrase that. Because Nintendo already did? I don't see anything capable of ruining WiFi play. 
|
|
| Author: | James0x57 [ Tue Feb 19, 2008 9:45 pm ] |
| Post subject: | Re: Zany TT Hack |
That's what I thought he meant too. *waits to see* |
|
| Author: | Hextator [ Wed Feb 20, 2008 1:56 pm ] |
| Post subject: | |
HyperHacker wrote: What I meant with the zero lines is can't you use a fill or slide instead? 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 |
|
| Author: | Hextator [ Fri Feb 22, 2008 7:34 pm ] |
| Post subject: | |
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. |
|
| Page 1 of 1 | All times are UTC - 8 hours [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|