So I have determined the best way to do this is to do a 16 bit unknown search. Then hit the enemy (or jump on it) then do less then. If it's still alive another less then search. When it's dead do a not equal search. Then reload the area and repeat it on the same enemy. I get results but none show any sign of enemy health change. So would this be a good way or is this a bad search tactic?
In MH3 when a minion dies the MID shows another monster take it's place. Also when a boss spawns it sometimes takes a minion's spot. Sometimes it doesn't even should, but that's probably a online side effect...
Anyway, maybe it's the same in smg with the baddies. They most likely have 1, 2, or 3 hp. Unless mario gets stronger. Try a equal search to eliminate some stuff before doing any damage. then less than and some more equals. You could also try you luck with specific searches. 3, 2, 1, and 0 before they disappear. Or maybe if there's already a ohko code, you can find out where the hp is at but looking at the asm.
alright that helps. I didn't think of a specific value to put in.
Quote from: toonlink444 on December 22, 2011, 12:29:47 AM
So I have determined the best way to do this is to do a 16 bit unknown search. Then hit the enemy (or jump on it) then do less then. If it's still alive another less then search. When it's dead do a not equal search. Then reload the area and repeat it on the same enemy. I get results but none show any sign of enemy health change. So would this be a good way or is this a bad search tactic?
that´s a bad approach because addresses will change each time the chosen enemy was killed or if you restart the level.
Hehe, try on a strong enemy so that you have many opportunities to search.
I did it like this on ssbb (tabuu battle) and conduit 2 (using a weak weapon). Find the enemies health bar and set a BP write on it.
Write some ASM that makes it always return value 0 and it will be a one hit kill for enemies.
It doesn´t affect yourself, because you´ve a different way of storing health than the enemies.
I´m sure that it will be like this on SMG aswell.
Here are my two example codes:
[spoiler]
One Hit Kill Enemies -TC2- [Bully@Wiiplaza]
C20F102C 00000004
2C0600BD 40820010
39800000 91980000
48000008 D0180000
60000000 00000000
One Hit Kill Enemies -SSBB- [Bully@Wiiplaza]
C31B6A08 00000002
39800000 7D83012E
60000000 00000000[/spoiler]Btw. I don´t think that it will be easy to do on SMG since there´s no common enemy that can take many hits...
maybe you wanna try on Zelda games. There´s still some games who could´ve an easy one hit kill code. :P
Yeah I figured that it would be hard in SMG1 I tried in zelda but my problem was enemy's die to fast. Is there a pointer that has a health value for all enemy's?
oh how about koopas? They might have health. Maybe. Hit them in their shell and do less than. Lets them get up and do greater than. Do some equal searches in between while moving around pushing buttons to eliminate nonsense/movement/buttons.
Or go do a boss fight that takes a few hits.
Hmmm what would be best 8, 16, or 32 bit search. 32 seems a little to much for enemy health but the characters health is usually 32 bit. So what's best 8, 16, or 32?
probably 16bit. Since they take such little hits to die. Is Mario's hp 32 bit? It's like 8hp. I say 16 because in MH3 player hp is 16 bit even though 0x96 is the normal max. And I've seen very small digits being 16 bit too. On the other hand, monster hp can be 32 bit even though the highest normal hp was 0x3A98. You could probably do 32 bit search anyway. Max hp is likely to be right next to it so doing damage it would still be a good less than search. Hopefully.
Make sure that when you find hp, you do a few Read/Write BP and take note of the asm that runs for it. Since it's so difficult to find, if the hp moves, at least you know what asm to BP at to find it.
Here's my code for a one hit kill in twilight princess
[spoiler]C20848FC 00000002
38000000 B01C0566
60000000 00000000[/spoiler]
How would I had on the refill health piece. I have that address.
Quote from: toonlink444 on December 24, 2011, 04:45:33 AM
Here's my code for a one hit kill in twilight princess
[spoiler]C20848FC 00000002
38000000 B01C0566
60000000 00000000[/spoiler]
How would I had on the refill health piece. I have that address.
great :cool:
now you need to include the rest into your assembly.
"Each time it executes, restore health".
Find the position in RAM where health is stored and write some assembly that one hit kills enemies AND also adds 1 heart to your health by loading the health address into a register.
To load the address would I use lis and ori?
to load the address, yeah lis & ori
Example:
lis rX,0x8000 # upper half of address (first four digits)
ori rX,rX,0x1337 # lower half of address (last four digits)
lwz rY,0(rX) # read data from memory (rX + 0), and store it in rY
you could also just store it into rX (instead of rY) after loading the address into the register, if you don't need to use the address again.
you could also just load without ori:
lis rX,0x8000 # upper half of address (first four digits)
lwz rY,0x1337(rX)
I guess for restoring hp, you want to load the current and add some to it. So it'd be good to load into rY instead of rX so that you can
stw rY, 0x1337(rX)
You could also use the whatever they're called to declare the address as a variable so pyiiasmh can take care of the rest.
Quote from: dcx2 on September 30, 2011, 05:35:11 PM
.set CC_ADDR, 0x806593DC
lis r12,CC_ADDR@ha
lhz r12,CC_ADDR@l(r12)
andi. r12,r12,0x800
# cmpwi here if you mask multiple buttons to make sure they are all held
beq- _NO_HACK
# do hack stuff here
_NO_HACK:
---
That will circumvent the sign extension problem in PyiiASMH.
careful stuff. lwz takes a SIMM. so lower half >= 0x8000 will actually change your upper half
ah yeah. I didn't know how to word it. >.< That's why I just quoted the .set, @ha, @l stuff.
if the lower half >= 0x8000, -1 from upper half. So:
lis rX, 0x8066
lwz rY, 0x8000(rX)
this will load from 80658000 because 0x8000 is -something. But if you use the variables, Pyiiasmh knows what to do with it.
Here's my new code.
[spoiler]C20848FC 00000004
38000000 B01C0566
3EC08049 62D6292B
82D60000 92D60004
60000000 00000000[/spoiler]
The assembly
[spoiler]li r0,0 # make r0 = 00000000
sth r0,1382(r28) # Original instruction
lis r22, 0x8049
ori r22,r22,0x292B # load address 8049292B into r22
lwz r22,0(r22) read from r22(8049292B) and store to r22
stw r22,4(r22) add 4 to r22 and store back to r22
nop[/spoiler]
But every time an enemy dies the game freezes. what do the stw and lwz need to contain?
Sorry, but I didn't realize that heath was a 16-bit number, and your stw isn't done quite right.
Try this:
lis r22, 0x8049
ori r22,r22,0x292B # load address 8049292B into r22
lhz r0,0(r22) read from r22(8049292B) and store to r0
addi. r0,r0,4 # add 4 to your heath
sth r0,0(r22) store back to 0x8049292B
li r0,0 # make r0 = 00000000
sth r0,1382(r28) # Original instruction
alright that makes sense.
Can you tell us if it works?
unless you know r22 is safe, you might want to use r12,r11, and I've never used more than 2 so idk what else. If you don't see r22 being loaded to before anything else happens with it, it's probably not safe and would be the reason it freezes.
Quote from: Stuff on December 25, 2011, 06:41:12 PM
unless you know r22 is safe, you might want to use r12,r11, and I've never used more than 2 so idk what else. If you don't see r22 being loaded to before anything else happens with it, it's probably not safe and would be the reason it freezes.
What would make you think that r12 and r11 are more safe then r22? As dcx2 has said many times, there is no "safe" register, it's all depended upon the function that you're hooking.
Btw, the reason why it was crashing was because he was loading a value then,was trying to write that same value to the address of the value + 4
Quote from: dcx2 on July 31, 2010, 07:51:42 PM
the Spectrum of Safety
safest --- safer --- safe --- ?? --- unsafe --- unsafer --- unsafest
r12 r11 r10-r5 r4-r3 r0 r31-r? r14-r31 r1 r2,r13
....
The safest register is r12. r12 is used exclusively (at least to my knowledge) to load the ctr preceding a bctr[l]; this means there's only a one-instruction long "unsafe" window and it's very rare to encounter. Unusual, but quite fortunate for us. You pretty much never have to worry about the contents of r12.
....
r11 is the most safer register. I think I have only ever seen r11 used to cache the stack pointer. It is never used to pass parameters into a function, so it is safe after a bl (i.e. at the entry point of a function). The function called does not have to preserve its contents, so it is guaranteed to be safe after a blr.
The rest of that post is pretty awesome too.
But I understand that writing to (where you loaded from)+4 might be a cause. But if r22 isn't safe atm, it's more likely to be r22. And I lean towards the r22 being the cause because I would imagine current hp and max hp being next to each other followed by other player stats. Why would the game freeze for a change in max hp or stats? The worst that can happen is you'll have 0 of something.
could you link me to that post? I haven't seen it, and that MAY be true, but doing what I said above is the best way of making sure a register is safe (or using a stack frame :P)
And I know for a fact that r22 wasn't the cause of the crash, lets run a little simulation with his code shall we?
I'm assuming that:
0x8049292B is player's HP
the player's HP is 4
li r0,0
sth r0,1382(r28) # set's enemies HP to 0 (kills it)
lis r22, 0x8049
ori r22,r22,0x292B # load HP address into r22
lwz r22,0(r22) # read 0x0004 from 0x8049292B into r22
stw r22,4(r22) # write value of r22(0x00000004) to value of r22 + 4 (0x00000004 + 4 = 0x00000008)
now is 0x00000008 a valid address?
Now my edited code code:
lis r22, 0x8049
ori r22,r22,0x292B # load address 0x8049292B into r22
lhz r0,0(r22) # loads 0x0004 from value of r22(0x8049292B) into r0
addi. r0,r0,4 # adds 4 to r0 (your HP), and store it back into r0
sth r0,0(r22) stores value of r0 (0x0008) back into value of r22 + 0 ( 0x8049292B + 0)
li r0,0 # make r0 = 00000000
sth r0,1382(r28) # set enemies HP to 0
ah. I didn't even notice he loaded to r22. >.<. lol.
you can click the "Quote from:" to go to the post. So far r12 and r11 haven't failed me.
Quote from: Stuff on December 25, 2011, 11:31:23 PM
ah. I didn't even notice he loaded to r22. >.<. lol.
you can click the "Quote from:" to go to the post. So far r12 and r11 haven't failed me.
Odd, earlier the Quote from wasn't a link (or so i thought :S)
Oh and toon, I think Mario's health moves based upon the level you're on. Try to find a pointer for it, and then we can show you what to do from there ;)
Edit: yeah there is a pointer, i got it from:
Infinite Health [dexter0]
48000000 806B7B40
14000380 00000003
E0000000 80008000
so the pointer is [0x806B7B40] + 0x380, so toon, you were actually on the right track... The code would be like this:
lis r22, 0x806B
ori r22,r22,0x7B40 # load address 0x806B7B40 into r22
lwz r22,0x380(r22) # read HP address from pointer
lhz r0,0(r22) #reads actual HP into r0
addi. r0,r0,4 # add 4 to your heath
sth r0,0(r22) store back to HP address stored in r22
li r0,0 # make r0 = 00000000
sth r0,1382(r28) # Original instruction
Quote from: megazig on December 25, 2011, 07:26:50 AM
careful stuff. lwz takes a SIMM. so lower half >= 0x8000 will actually change your upper half
megazig is correct, that's why the template Stuff pasted uses @ha. @ha causes GNU's as assembler to account for sign extension. Note that @ha should NEVER be used with ori! @h is used with ori instead, because ori does not sign extend the immediate.
Quote from: matt123337 on December 25, 2011, 09:10:30 PM
What would make you think that r12 and r11 are more safe then r22? As dcx2 has said many times, there is no "safe" register, it's all depended upon the function that you're hooking.
r12 and r11 are volatile registers that will never be used for passing arguments to functions. That makes them the two safest registers. Since r11 is occasionally doing stack-related stuff, it gives me the heeby-jeebies to mess with it, so I prefer r12. r10-r3 are used to pass arguments to functions. The compiler prefers smaller registers, so if you need more than r12 and r11, you can work with r10 on down. Careful review of the function will show when one of these registers isn't safe. r3 and r4 can return values to the caller, but r5-r10 are input-arguments only, so after returning from a bl you know r10-r5 are safe. I suppose that a compiler looking for maximum efficiency could theoretically use the volatile regs as local variables, but only in-between function calls.
---
toon, if you get a crash, go to the BP tab and press "Step Into". It will show you what crashed. If this happens, you can post the registers and disasm and folks will probably be able to figure out why it crashed.
As far as your goal, I would hook whatever ASM runs when an enemy gets killed. Chances are there's a pointer to Mario somewhere in the registers, because it would want to know who killed the enemy. If not, you'll need a second hook that stores Mario's pointer somewhere. You can try dexter0's pointer, but it's not always valid. =(
I'm not sure how to approach finding the first hook, though. You could try setting WBP on Mario's HP, and then look at the call stack when he gets hurt. Chances are that when Mario hits enemies, some of the call stack will be the same. So try setting XBP's on all the call stack addresses, starting from the top, and try to kill enemies. If one hits, then you might be able to use that.
As far as enemies who can withstand multiple hits, so that you can try repeated searches, I would avoid bosses even though they are a tempting target. Go for those centipede-like common enemies, who lose one body part each time you hit them.
Alright I made a code for zelda tp using these tactics and it worked so I will try again on super mario galaxy.
Been away for a while so would I put the wbp on the pointer?
Quote from: toonlink444 on January 08, 2012, 09:36:07 PM
Been away for a while so would I put the wbp on the pointer?
Include reading from health pointer on your code and find a hook that only runs once when you kill an enemy.
Then, do "add 1" and "store new health" inside your assembly and you´re done. :)
This definitely isn´t an easy code to make, though. Can you do it? ;D
I'm going to make it a 1 hit kill now. Btw where are the enemy's dcx2 is talking about
Quote from: toonlink444 on January 09, 2012, 01:36:15 AM
I'm going to make it a 1 hit kill now. Btw where are the enemy's dcx2 is talking about
what´s the point when you ask but don´t attempt to do the restore health code anyways?
Well you asked if I was up to it and I examined my hacking skills and determined that I keep finding codes that turn out harder to make then it seems.
Quote from: toonlink444 on January 09, 2012, 10:21:46 PM
Well you asked if I was up to it and I examined my hacking skills and determined that I keep finding codes that turn out harder to make then it seems.
But that's the fun in hacking. Every time you do something new, it feels good and your experience goes up. So then you can do that kind of hacking easier next time. And this code isn't as hard as you think. I made one for MH3, but never released it because it works online in a bad way(other player's damage would add to my health as well). And I could never find a difference between my damage and other player's damage. It was vampire attacks instead of kill attack.
Anyway, OHKO is the way to go. You still need to find enemy hp for OHKO. Then you do a WBP on it and hit them to see what it's subtracting. Just make it load 0 to the register and you got OHKO(Unless this same instruction handles damage to you as well).
Next, you'll need to find mario's hp.(hopefully it doesn't move) If what dcx2 said about the registers is true, then that's even better. You'd just need to load mario's hp using the pointer in the register add 1 and store it.
If you want it to only happen on kills, then from ohko, you should be able to see it comparing the hp with 0 and then it should branch if something. Just follow it and do a XBP on that to make sure it doesn't run unless you killed somebody. Then you can load mario's hp, add 1, and store it.
This is pretty much what Bully said. Except I say it's easy. You can do it! XD
Alright I'll continue and what's OHKO?
toonlink,
OHKO is the abbreviation for One Hit K.O. (Kill).
I´ll probably make the code on the weekend, everything has already been said.
Not sure which enemies are best to mess with.
Quote from: Bully@Wiiplaza on January 10, 2012, 07:09:38 PM
toonlink,
OHKO is the abbreviation for One Hit K.O. (Kill).
I´ll probably make the code on the weekend, everything has already been said.
Not sure which enemies are best to mess with.
Well I feel stupid now. And tell me how you go about finding everything.
Not too long ago, I didn't know what OHKO was. >.<
I kind of want toonlink444 to make it. Since he's having trouble with it, he would go through that "OH! Duh!" moment when he figures it out. Which is a good thing, imo.
Something with more than 2 hp would be best. I still feel like a boss would still be good. If anything, it'll occupy the first slot, where a minion would probably be in any slot. And if the hp moves from area to area, it would probably be in the same spot if you fought the same boss. But anyway, the caterpillars would be good too. If they un-red, I'd guess they recovered hp, and 0 would be if you threw a turtle shell at them(unless it doesn't work like that anymore). So < when you hit them, > when they un-red, = in between. If your feeling lucky, they probably have 2 hp regular, 1 hp red, and 0 for dead of course. Or do they loose pieces?
This conversation made me reconsider vampire attacks. It wouldn't be so bad if you gain a few hp when a monster dies.
Quote from: Stuff on January 10, 2012, 10:22:47 PM
I kind of want toonlink444 to make it. Since he's having trouble with it, he would go through that "OH! Duh!" moment when he figures it out. Which is a good thing, imo.
Hmmmm I keep agreeing with you stuff. And dcx2 said not to use a boss, and that's where I first started looking.
P.S. I forgot to say that the health value I found was for LoZ TP.
Well, I should say it's not "don't use a boss", but more like...bosses can be handled quite differently from regular enemies. To that end, hacking at hitting the boss may get you in the vicinity of something else important, but it probably will need some extra work to generalize to the commons; especially if this boss takes a whole map to get to.
That's why I suggested a more common enemy that is easier to find a few times, one that you can gradually murder frame by frame while coldly calculating the remaining amount of life force all in search of a magical ASM address which knows when a certain thing is happening to whom... :D
Well I made a code a went to test it out but all the enemy's are pretty much one hit kill.