F2/F4 codetype tutorial

Started by Clay10, April 18, 2012, 08:36:45 PM

Previous topic - Next topic

Clay10

The basic use of the F2 codetype is to make a check-sum before an ASM code replaces instructions. If the check-sum is correct, it will replace the ASM at the address with the new ASM. If not, it will not replace any instructions.


According to the codetypes doc, the F2 code will xor YY 16-bit values before or after the address. If the resulting number is equal to ZZZZ, the code will execute NN lines of ASM.

For this tutorial, I will be using a code by DeathAndBack,

Infinite Ammo [DeathAndBack/Various Creators]
F259964C 04048C02
380003E7 94050008
60000000 00000000
--
First, open up gecko.net and head to memory viewer. There, go to your ASM address. In this case I will use 0x8059964C.


The instruction at 0x8059964C is lwzu r0,8(r5), which stands for "load word zero updated". This is not what we will be focusing on, though. In DeathAndBack's infinite ammo code, it states that 0x04 16-bit values after 0x8059964C are xor'd together, and if the result equals 0x048C, 0x02 lines of ASM are inserted into the address 0x8059964C. There are four 16-bit values after 0x8059964C xor'd together. Now, there are two 16-bit values in each address. All you have to do is open up windows calculator, and use the xor function. (in windows 7, switch the view to "programmer". Note, remember to switch to hex mode.)

In DeathAndBack's code, he specifies that 0x04 16-bit values after 0x8059964C are xor'd together.


Highlighted in blue is our address, and in the red boxes are the values we will xor together.

Here I am xoring 0x9086 and 0x4 in windows calculator. The result is 0x9082. Now, that's only two 16-bit values after our address. Next, we xor our result from the first two 16-bits with our 3rd 16-bit, 0x9406. The result is 0x0484. Three down, one 16-bit value to go. We xor our last result with our last 16-bit value, 0x8. Our final value is 0x048C, which also equals the ZZZZ in our original code.


--
The rest functions exactly as a C2 code. NN = number of lines of ASM. But we're not done yet. What is the F4 codetype? The exact same thing as the F2 codetype, but it will use a pointer offset. That pretty much covers the F2/F4 codetypes!


Sent from my iPod touch using Tapatalk

Bully@Wiiplaza

#1
This replaces the use of a 20 compare "if equal" codetype. It will only be senseful to apply when a game has moving assembly at some point, otherwise it´s not needed. It also works quite well with the F6 codetype.
My Wii hacking site...
http://bullywiihacks.com/

My youtube account with a lot of hacking videos...
http://www.youtube.com/user/BullyWiiPlaza

~Bully

dcx2

You can right-click an address in MemView and use the F2 XOR context menu options to simplify this process.

It's still good to know how it works by hand, but the F2 XOR tool in Gecko.NET can handle lots half-words automatically.

Bully@Wiiplaza

#3
@dcx2:
On the downside, the XOR calculator is greyed out when using RAM Dumps.
So we have to connect to a running game to use it.

In my opinion, this codetype somehow isn´t that applicable:
- We need a C2 code
- We need moving assembly

Then, using the F2/F4 codetype, we can save *two* lines (minus the 20 compare, minus the terminator).
In combination with the F6 codetype, it will only find the proper template and not a false one in a sudden, so we probably never need F6 + F4 codetype since our write will most likely at its correct place. Am I right?
My Wii hacking site...
http://bullywiihacks.com/

My youtube account with a lot of hacking videos...
http://www.youtube.com/user/BullyWiiPlaza

~Bully

dcx2

It's not so much "moving" assembly.  Games can use something called an "overlay".  With an overlay, the ASM that can be found at an address will change depending on what game mode is loaded.  For instance, RE4 has a different overlay for each gun.  If you change guns, the old gun's ASM is unloaded and the new gun's ASM is loaded in place of it.

And it's not really proper to compare it to a 20 code type.  The F2 code type can XOR checksum *many* bytes (250-ish bytes, since YY counts half-words).  20 code type will only check four bytes.

In Tales of Symphonia for the GameCube (GQSEAF I think), there is some ASM that is loaded only during fight scenes.  It's always at the same address, but you can't write to this address because when you're not fighting, there is different ASM.  This is where you use the F2 code type.

Using an F4 and an F6 code together can be difficult; for instance, if you applied one of those GQSEAF codes with an F6, it wouldn't find the address because the ASM wouldn't exist when the game is booting.

Bully@Wiiplaza

#5
Is the F6 + F4 usage on here correct?
http://www.geckocodes.org/?c=SM8A52

Note that the "if line" on top detects if we are in the correct game mode (this line is regionfree, too), so that the F6 search result will be true.
I´ve changed the D2 writes into F4 writes including the XOR checksums (I´ve XOR´ed the first 16bit of the following address with it´s second 16bit).

Anyways, the XOR checksum doesn´t seem to be "more" useful than the 20 compare just because it *can* cover and compare with multiple values.
At least in terms of codes. I can imagine that it´s used for savegame protection to detect every non-legitly modified bit in there. :P
My Wii hacking site...
http://bullywiihacks.com/

My youtube account with a lot of hacking videos...
http://www.youtube.com/user/BullyWiiPlaza

~Bully

Fake Code Spammer