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

Zeld's Lame App + Project 64 Hack
https://www.kodewerx.org/forum/viewtopic.php?f=11&t=4359		 Page 1 of 1
Author:  Hextator [ Thu Sep 27, 2007 8:32 pm ]
Post subject:  Zeld's Lame App + Project 64 Hack
kenobi already made a tool that does this and more, but I just got done having Darksin test a code I made with mine using a single RAM dump he obtained, and he says it's working great.

The best part is, it's not only from just one dump, but it's a triple pointer (I just reused my program over and over on a few of the results I was getting and made a chain :D):

The game was

Zoo Keeper (U) DS

And the code was

Score Modifier:

B2062214 00000000
B0000024 00000000
B000000C 00000000
DC000000 FFFFFF8C
00000000 XXXXXXXX
D2000000 00000000

And the dump he dumped (XD) is here:

http://king.dscoders.com/gamedumps/Gamedumps.zip

There's two dumps in there because he was intending to use kenobi's tool, but I told him to just try the first one and used the program myself to ensure it was used properly.

The program and source is here:

http://www1.freewebs.com/uberzeld/appsandeditorz.htm

Edit: Here are the output files of the program that were generated:

Search Results 1:

File searched: "zookeeperdump1"
Mask used: 0xFFFFFF00
Pointer searched for: 0x021DA12C

001D63AC 021DA1A0 -116
001D63C0 021DA180 -84
001D8C44 021DA180 -84
001D8C60 021DA1A0 -116

Search Results 2:

File searched: "zookeeperdump1"
Mask used: 0xFFFFFF00
Pointer searched for: 0x021D63AC

001C5EE4 021D63A0 12
001C6024 021D6320 140
001D6300 021D6340 108
001D6344 021D6300 172
001D6360 021D6320 140
001D6380 021D63C0 -20
001D63C4 021D6380 44
001D63E0 021D63A0 12
001D8B80 021D6300 172
001D8C68 021D63E0 -52
001D8CE4 021D6340 108
001D9EA8 021D6360 76
001DA060 021D6380 44
001DA184 021D63C0 -20

Search Results 3:

File searched: "zookeeperdump1"
Mask used: 0xFFFFFF00
Pointer searched for: 0x021C5EE4

00062214 021C5EC0 36
001C5764 021C5E60 132
001C57E8 021C5E80 100
001C5920 021C5EA0 68
001C5D60 021C5E60 132
001C5F04 021C5EA0 68
001C5F20 021C5EC0 36

Format of output is

Address Found At, Value Found, Offset from Expected Value

Edit: ARM BL Search tool added. It helps you figure out where the BL is that links to the subroutine you're at, if you're unable to get the PC to that area to dump LR. As the name implies, it was lazily coded and only works for ARM BLs.
Author:  Darksin [ Thu Sep 27, 2007 11:58 pm ]
Post subject:  Re: NDS Pointer Search Alternative
Since dump2 was unnecessary for Zeld's tool, I removed it and replace it by dump3. dump3 is for a different code.
Author:  Hextator [ Fri Sep 28, 2007 3:38 pm ]
Post subject: 
This program is mostly for speeding through the nasty pointer process, but without a second file to validate the results with like kenobi's program does, coincidental offsets will really throw you off.

An offset as large as 0xA48 was needed for the last code I tried to hack, and searching through all sorts of pointers with much smaller offsets yielded a hard coded ASM pointer. But from there I didn't know how to get back to the actual data because none of the pointers I got there from were intact after reset.

kenobi's program can probably do a better job of making the pointer codes need less lines, too.

It's mostly just luck. It'd probably be a good idea to try it the fast way first just in case you can, and if all that craps up, use two dumps.

I'm wondering if I should add a feature to optionally use a second dump to compare results to? Hopefully it'd still run fast. I'd estimate only a 100% speed decrease (which I believe would still be much faster than kenobi's tool...his runs very slowly for me, and I think it's because using an offset instead of a bit mask is more accurate but much slower).
Author:  Darksin [ Fri Sep 28, 2007 9:24 pm ]
Post subject:  Re: NDS Pointer Search Alternative
kenobi's takes roughly 5 seconds for me.
Author:  Hextator [ Fri Sep 28, 2007 9:35 pm ]
Post subject: 
I did use to have a much slower computer.

Hm...

Well either way, I just finished another version that optionally supports a second dump.

At the very least, it's a good experiment.

kenobi's has an interface, but when you're the one who makes the program, you get to mess around with it until the output is formatted exactly as you like. For one, kenobi's tool makes you calculate the offset yourself, which is no fun if you're lazy. I find it easier to read the results from a text file, as well.

I wanted to program something that did what kenobi's program did, but with more focus on the sort of output I preferred seeing. I based my program off the way I manually search for pointers...that is, scanning through large amounts of data and looking for hex values that have many common significant bits with the pointer I need.

With a regular RAM search, the closest you could get without being too specific would be to search for the upper two bytes. The results weren't always word aligned. It was ugh.

I suppose kenobi's pointer tool does everything just fine except for appealing to my eyes. Oh well.

Edit: Version dos has replaced the original on my site.
Author:  Darksin [ Sat Sep 29, 2007 11:21 pm ]
Post subject:  Re:
Zeld wrote:
Edit: Version dos has replaced the original on my site.

¡no habla en español!
Author:  Hextator [ Sun Sep 30, 2007 8:31 pm ]
Post subject: 
That was spammy and lame.

Updated first post to include info on another tiny app I added that fails about as much as the last one. Probably more. Oh well. I got some use out of it. :/
Author:  Darksin [ Thu Oct 04, 2007 12:21 pm ]
Post subject:  Re:
Zeld wrote:
That was spammy and lame.

Updated first post to include info on another tiny app I added that fails about as much as the last one. Probably more. Oh well. I got some use out of it. :/


I think everything you do fails equally.
Author:  Hextator [ Thu Oct 04, 2007 2:27 pm ]
Post subject: 
I must be insanely awesome then.

New app, redo of both the other two mixed into one, now on my site. Works much better. Lets you use spaces in your file names, etc.

Edit: Using input files of size 0 won't terminate the program properly. I'll have to fix that later.

Edit: Fixed.

Also note that the consolidated program is only 21.1 Kb, instead of around a megabyte like both the programs were together prior. This is because <iostream> append about 400 Kb of crap onto your program. I tossed that lib and made do without it, and even did better, obviously, considering that my use of stdio.h guards better against faulty input, and allows more kinds of input (space in filenames; that's probably it, though). So yeah, win.

I hope I can avoid using iostream, because that lib is just so fat.

Edit: Updated again. Took into consideration a bunch of comments HyperHacker made about the source.
Author:  Parasyte [ Thu Oct 11, 2007 12:05 pm ]
Post subject:  Re: Zeld's Lame App
How lame!
Author:  Hiei-YYH [ Thu Oct 11, 2007 2:09 pm ]
Post subject:  Re: Zeld's Lame App
good tool, but now that i got no$gba and ideas debugger i guess i won't be needing this anymore XD i'll just create custom asm subs.

by the way zeld, i did a mini faq on how using cheat engine + no$gba (with pictures) should be easier.

*removed*
Author:  Hextator [ Fri Oct 26, 2007 12:37 pm ]
Post subject: 
Hm. Well, Cheat Engine stopped working for me properly (it no longer lets me use hardware breakpoints, so I can't log instructions that read or write anymore like you can. Thus, your nifty tutorial doesn't work for me).

To combat this, I used IDA Pro, which CAN still log reads and writes. However, it is VERY clunky, and the option to not log instructions that it has already logged isn't working, effectively ruining the trace window.

So instead, I switched Project 64, the emulator I was hacking on (I just hate Nemu, guys), to use an interpreter core for the game I was hacking. The interpreter core only uses two instructions for reading and writing per data type (e.g. L/SW, L/SH, L/SB), so even though the trace window in IDA Pro was overflowed with repeat logs, there were only two I needed.

After logging them, I detached IDA Pro because it was making PJ 64 run at 1/3 speed (that, and IDA Pro and Cheat Engine are programs that can't run at the same time). I opened back up cheat engine and used the information I had gathered to make the hack seen in the attachment to this post. As you can see, that nop in the debugger is only broken on when a read of a specified address occurs, and the value at PJ 64's 0x4d5280 will hold the MIPS PC of the exact instruction that caused that read.

I could even modify it to log PCs instead of breaking on them (Edit: I have now done this :D), to gather the information faster and mess around with those PCs using gameshark codes since I can no longer alter recompiled x86 to test for immediate results (Wrong! As of now I have a way to immediate test results without using gameshark codes, and boy is it awesome!). The interpreter core is slower, yes, but this lap top is more powerful than the computer I originally developed this hacking method on, and I believe it will prove rather effective.

Edit: This hack works even better. It lets you do what the previous hack does...if you use it to record all the PCs that access an address, you can plug those PCs into an address, and figure out if that PC is the one you're looking for.

Edit, again: This version also logs PCs for you. If the area at AllocatedMem+0x50 and beyond is filled with x86 nops (bytes of 0x90), the hack will automatically log all PCs that access the data at the pointer you specify.

org 42a885
jmp AllocatedMem

org AllocatedMem
xor ecx, pointer
jne EIP+0x37 ;make jne into jmp to disable function; this should be a jmp by default because until the game is running Project 64 will act screwy and think it is in an infinite loop. This might be due to me using the stack instead of making my own.
push eax
mov eax, EIP+0x47
mov ecx, [004d5280]
inc eax
inc eax
inc eax
inc eax
cmp ecx, [eax]
je EIP+0xC
cmp [eax], 90909090
jne EIP-0xE
mov [eax], ecx
pop eax
cmp ecx, [EIP+0x29]
je EIP+9
mov ecx, value if false
jmp EIP+0x12
mov ecx, value if true ;Break here to get reg status of correct PC
jmp EIP+0xB
xor ecx, pointer
mov ecx, [ecx+eax] ;Replaced instruction
mov [edx], ecx ;Replaced instruction
jmp 0042a88a

Edit: More info for you bastards:

429ea8 - universal 1 byte read instruction

42a8a8 - universal 1 byte write instruction

429f18 - universal 2 byte read instruction

42a918 - universal 2 byte write instruction

42a885 - universal 4 byte read instruction

42b8d5 - universal 4 byte write instruction

Attachments:
Project 64 Hack.png
Project 64 Hack.png [ 174.54 KiB | Viewed 9438 times ]
Author:  Hiei-YYH [ Sat Nov 03, 2007 12:06 am ]
Post subject:  Re: Zeld's Lame App + Project 64 Hack
speaking in multipointers XD

ldr r0,=0x02172960
ldr r0,[r0]
ldr r0,[r0,#0xDC]
ldr r0,[r0,#0x1A8]
ldr r0,[r0,#0x8]
ldr r0,[r0,#0x4]
ldr r0,[r0,#0x64]

this wouldn't be possible without a debugger lol, first game that i saw something like that.
Author:  Hextator [ Sat Nov 03, 2007 10:08 am ]
Post subject: 
Ew, that's brutal. What game did you draw that from? O_o
Author:  Hiei-YYH [ Sat Nov 03, 2007 7:15 pm ]
Post subject:  Re:
Zeld wrote:
Ew, that's brutal. What game did you draw that from? O_o


jump ultimate stars. and it's just for a flag check lol (see if the character is turned right or left)
Page 1 of 1 All times are UTC - 8 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/