Monster Farm 2 Change log 2-Marvelous ability Song

---restore content starts---

Next, Monster Farm 2 modify log 1-firstblood

OK, here is the bgm!

In the previous article, we found the location where the name "Unigauld" was stored and successfully modified the string. However, it seems that there is no egg to use, I am not ready to Chinese this game.
As mentioned before, the text is usually one of the breakthrough points, but the current findings of the previous article seem to be of no use.

So what should I do now? Actually I don't know, so take a stroll.

I tried to create a monster, Hopper and Ice Wolf's monster クリック with a fantasy legend disc.

Look at the monster book, there are now 2 monsters, respectively, the number of the モッチー 278. Here's a monster handbook, like a Pokemon, when you spawn a new monster, the Monster's Handbook updates the monster's card.

There are also the クリック children numbered 169.

As you can see here, on the monster card, the monster's number will be displayed, "169". If I could find the "169" text in memory, I could figure out where 169 of the data was obtained.

Simple reasoning can tell that this "169" is obviously from a list. This list records the mob numbers currently collected by the player, and there should be "169,278" in this list.

When the player generates a new monster, the game program updates the list, for example, you create a new monster, assuming the number is "222", the game program will update the list to "169,222,278".

When the player opens the Monster book, it will read the list to list all the monster cards currently owned by the player.

If we can find this "Collected Monster ID" list. Then we can set a memory breakpoint, break the time when generating a new monster, and then roll back the data from where the monster was generated.

So finding the string "169" has become our starting point.

So how to find the string "169", first I need to know what kind of data the string will be stored in memory.

I tried to generate a new monster named "Unigaul8". Using the previous method, we can already find a string in English, so we search for "unigaul" so we can find the location of "Unigaul8" and know the 8 encoding in memory. Open the Monster data interface, The found name is displayed above "Unigaul8".

We saved a storage snapshot, pulled out my ugly python script and searched for "Unigaul". 4 matches were found.

Open the Binary editor, first look at the first address, 613849, which is 0x95dd9, corresponds to 2E. You can see that the data here starts with 0X95DD8.

The last character is the AA FF. We try to modify the data here, 0X95DD8 is the address in the snapshot, and the address in memory is 0x95dd8-0x2b0=0x95b28.

Arbitrarily make some changes, found "AA ff" corresponds to "8", "A4 FF" corresponds to "2".

So we can roll out, "169" in memory the representation should be A3 FF A8 FF AB ff. " 278 "In-memory representation should be A4 FF A9 FF AA ff.

Open the Monster Handbook again, save the storage snapshot, and try searching for "278". That is, "A4 FF A9 FF AA FF".

A match was not found. Trying to find A4? A9? AA?, found 2 matches.

The obvious 0x765d8h looks more reliable. We try to modify the memory directly, or the old method, modify the value at 0x765d8-0x2b0=0x76328.

Found no matter how to modify, the value here will be written back to A4 A9 to AA 00, that is, "278". Toggle Monsters, where the value will change to A3, A8, AB 00, corresponding to "169".

So we need to know where the program reads the data (169 or 278), which is used to update the address string. It is obvious that the data should come from the illusion that we have in front, preserving an array of all the monsters collected by the player.

Well, to start debugging, first we need the next memory breakpoint to see what code is writing data to 0x76328.

Press F9 execution, found that this memory address is written many times, we continue until debugging to write A3 A8 ab time. For example, the A3 and A8 are now written, and AB is about to be written.

The written instruction is sh r3.0x0000 (R2), which is to write the value of the R3 register A8 to R2. SH means store 0x7632a, That is, 2 bytes. The PlayStation CPU uses the MIPS instruction set. Specifically, you can see the MIPS directive.

We look at the above two sentences, found that the value of R3 from R16 the address specified, Lbu r3.0x0000 (R16). LBU means load Byte Unsigned. Here you can tell that the R3 data comes from the address 0x76809.

We look at the data at 0x76809.

You can see that the A3 A8 AB FF is stored here. Where did the data come from? Or the old method, the next memory breakpoint.

You can see whether the data is flowing from the R3 to the R8 specified address (0x76809). So where did R3 come from? Look up, 0xb3088, Lbu r3.0x0000 (R4), it seems to be read from the R4. Let's take a look at the next breakpoint in the 0xb3088.

At the end of the breakpoint, the 0xb3088 becomes the illegal, which means the breakpoint succeeds.

It is found here that the A3 is read from 0x767eb and stored in R3, which can infer that the data comes from the FF AB A8 A3 at 0x767e8. We add a memory breakpoint at the 0x767e8.

Continue debugging until 0x767e8 is written to FF AB, and you will know that the next thing to write is A8 and A3.

Here from SB r2.0x0000 (R4) can know the data ab from the R2 register. We look again at Addu R2.r9.r2, this instruction is to put r2 = R2 + R9. This time R9 is A2.R2 for AB and can be reversed before performing Addu R2.R9.R2 The value of R2 is 9. That is, the number of AB represents 9. " 169 "of the 3rd digit.

Then the code should write the A8 and A3 0x767ea and 0x767eb. We step forward.

Bne r7.r0.0x000b3028, meaning R7 not 0 jumps to 0x000b3028. Here is 0x10, so jump to 0x000b3028 to execute.

Skips irrelevant instructions and continues execution until it is specified to Addu r2.r9.r2. R2 is 6. " 169 "of the second number.

At this time R7 is 1, still jumps back to 0xb3028 place, continues to circulate. Executes to Addu R2.R9.R2, at which point R2 is 1, corresponding to the first digit of "169".

As you can see, the 9,6,1 three digits are written to the specified location in turn. Restore the code, it should be.

int id = 169;

while (ID)

{

int num = id% 10;

char C = num+0xa2;

id = ID/10;

}

We went back to the beginning, when we were just writing to FF.

Here's a bunch of swl SWR instructions, emptying the memory behind the 0x767e8 to 0. Observe the register carefully, and find that R7 is A9 at this time, that is, 169.

Continue to press F9, when AB and A8 are written, the value of R7 becomes 10, which is 16.

Continue to press F9 execution, R7 becomes 1. Validates the code that was restored above.

Then we need to find out where the R7 is coming from. Go back and find that the value of R7 should come from R4.

We have the next breakpoint at the 0xb2f9c. The success was broken in here.

You can see that the value of R4 is A9. We need to know where the value of the R4 comes from, try to go back up, and navigate to the 0xb2e10 through the breakpoint. Now R4 is A9.

Continue to trace upward. 0xb2e08, Addu r4.r6.r0, you can know that the value of R4 is from R6. We have the next breakpoint in some of the above, 0xb2dec.

At this time R6 has been equal to A9, continue to trace, found unable to find out where to jump to 0xb2dec. We step through until 0xb2dec returns to the previous layer of function.

Here you can see Lhu r6.0x0000 (R2), after which the JAL 0x000b2dec.jal is the jump and Link, which jumps to the address specified later and saves the return address to the R31 register. Can be seen as a function call.

We point to the next breakpoint and find that the value of R6 is read from R2, which is 0x15d000.

Look at the memory at the bottom 0x15d000.0xa8 and 0x115, exactly 169-1 and 278-1. This is the list I'm looking for, "169,278".

Modify directly, try to change A9 to A3, and find the displayed text updated. The monster number changed from 169 to 164.

Turn off the monster, then open it again, and the data goes back.

As you can see, this list is not the most original source of information, and when you open the Monster's Guide, the program updates the list of 0x15d000 here. We can place the next memory breakpoint at 0x15d000 and reopen the monster Guide to see where the data came from.

We broke down at the 0x186930, SH r4.0x0000 (R2), and the data came from R4. Look up the code and find the most recent, operation on R4 here.

We tried the next breakpoint at the 0x1858f0, and found that it would not pass. Then the breakpoint at 0x18592c.

It was found that the breakpoint was cleared when the menu was opened. Illegal again changed back to Addu R2.r2.r3. It seems that the breakpoint is not known for what reason was cleared.

At this time, the breakpoint is re-edited and applied, and it is found to be broken in this position. We use the same method to re-0x1858f0 the breakpoint at the same place.

The success was broken here. Before we go on, let's find out why the breakpoint is cleared.

After the breakpoint is finished, we look at the memory of the 0x1858f0. Found here was changed to a 4C, which should represent a normal breakpoint. So the instructions will show illegal.

Open the menu, found here the 4C was changed back.

We 0x1858f0 the next data breakpoint, reopen the menu, and find that the memory breakpoint will not be triggered, and it will be changed back. Well, let's go ahead and find the data we need. At least we can tell if the breakpoint is cleared or not.

You can see that R4 is emptied to 0, we step down and see how R4 becomes A8.

Perform the discovery, jump directly to the 0x185934, skip the 0x185930, and we continue to perform a look.

After the execution, found here is a loop, R2 is not equal to R0, will jump to 0x185904. Each time a loop is executed, the value of R4 is added 1. Let's have a loop.

For example, first move the R4 logic to the right 0x10, and save to R2, which is R2 for 0x00050000. Then R2 arithmetic right shifts 0x10 bit, into 0x00000005.

It is not clear that the intention to do so, for the time being to save the value of R4 to R2. Next, add the R2 plus R5, which is 0x9703c+5, and take the value out and save it in R2.

You can see that 0x9703c+5 is 0, so R2 reads a value of 0.

The next sentence beq r2.r0.0x00185934,beq is branch on equal meaning, that is, R2 equals 0 (R0 is always 0), jumps to 0x185934.

Looking closely at this code, if R2 is not 0, it will be executed to 0x185930, which is the instruction that wrote the data before.

Simple analysis, you can probably introduce the following code.

 char  *base  = 0x9703c  ;  for  (int  i = 0 ; i < xx; I++ if  (* (base  +i) = = 0   //  continue the loop.    //  0x9703c+i is not 0.   { //  The value is stored to 0x15d000.   

We'll look at the data at 0x9703c.

As you can see, 0x970e4 and 0x97151 are at 1, others are 0.

0x970e4-0x9703c=a8=168=169-1.

0x97151-0x9703c=115=277=278-1.

As you can see, all the data comes from this byte array, and each byte represents whether the specified number of monsters have been collected. Here +a8 is 1 for 169th monsters have been collected, +115 for 1 for the monster of number 278 has been collected.

Let's try to change the value here, assuming we want to make the 3rd monster a collection, we should modify the location of the 0x9703c+3-1. That is 0x9703e. We'll change the 0x9703e to 1 and then re-enter the Monster's Handbook.

Here it is.ユニコ, you can call her uni son.

It's been a long walk, and finally we've found the list of "collected Monster IDs". Next we can see if we can get the data from this list to be used when generating monsters, and make changes at run time.

To be Continued ...

Monster Farm 2 Change log 2-Marvelous ability Song