Next, Monster Farm 2 change log 4-the eve of the battle
BGM, recently the pure bliss of the B station.
In the previous article, we succeeded in finding the location of the monster Race ID and the sub-race ID stored in memory from the data read from the CD.
By modifying the memory location, it is possible to directly determine the last spawn, including special monsters, that can be generated directly.
Next we'll look at how the data is computed from the data read in the CDROM and, by the way, the other initial monster data affected by CDROM.
The following information is obtained by querying the foreign Language guide station.
- The number of minutes in the last track in the CD determines the main race ID of the monster.
- The last track is removed from the CD, and the number of seconds remaining in the total time determines the monster's sub-race ID.
- The monster attribute is corrected based on the number of seconds of the first track in the CD.
- The monster attribute is corrected again based on the number of seconds of all tracks in the CD.
- The main race ID and the sub-race ID of a particular monster appear to be hard-coded based on data and do not use common rules.
It can be extrapolated that the information read from the CD should be these.
We still first use the parasitic Eve 2 of the B-plate to do the test, the external station saw this disk's track data as follows,
0+3667 sec (Full track length 61:07, last track length 61:07)
To continue debugging, look at the next data write breakpoint at the 0x001ffc98, and see how the data is from the CD to this memory location. Found broken in the following position,
From the call stack you can see that the upper function is 0xd9a04, which we perform to return to look.
You can see that the data will be copied from 0x76868 (R6) to 0x76888 (R9) to the memory where the 0X1FFC98 began.
The function then returns to the upper layer.
You can see the above is a JAL 0xda0a4, so the entry address of the function before returning is 0XDA0A4.
We 0xda0a4 the next breakpoint and re-debug it to see what we did.
We can see that we have successfully arrived at the entrance to this function.
First Addiu r29,r29,0xffb0, here the value of R29 reduced 0x50, check the information found r29 is the stack pointer, here opened the 0x50 stack space, from 0x76858 to 0x768a8.
SW r17,0x44 (R29) here to save 0x1ffe70 to the r29+0x44 place.
SW r31,0x48 (R29) here to save the return address to r29+0x48 place.
SW r16,0x40 (r29) Save 0x1ffd30 here to the r29+0x40 place.
LBU r2,0x48 (R17) read here 0x1ffe70+0x48=0x1ffeb8
BEQ r2,r0,0xda120 here R2 for 0, jump to 0xda120. Later found that if the spawn directly using the Monster Farm 2 of the disk, then this R2 is 1, will not jump
0xda120 jump to 0x34228.
0x34228 entrance, where the 0x20 stack space is allocated.
SW r17,0x0014 (R29) saves the 0x1ffe70 to the +0x14 address on the stack.
R4 = 64
R5 = 4
Then save the R31 to r29+14 and jump to 0x3cf08
0x3cf08 It is not easy to see too much information, we go back to the previous layer to continue execution.
Starting from 0x34264 seems to be moving the data from 0x1fcdd0 to 0x76890, and continue to look at it.
At this point in time, return from 0x34228, since R2 is 0, will jump to 0xda188. You can see the memory at 0x76890 at this time as 0x61,0x09.
Came to 0xda188 place.
r2 = R5 = R7 = 0x800c0000 R6 = 0x800c646c R16 = 0
The next step was to make some unspecified assignments.
R10 = 2 R9 = 0x76888 R4 = 0x800c6472 r2 = [0x800c6468] = 0x100
If R16 is greater than or equal to R2, then jump to 0xda2b8. Otherwise, R3 for the previously saved 0x61, this 0x61 looks much like the previous 61 minutes.
Directly change the value of the R3 test, it can change the monster's race, the value will be the same as the external network Strategy station, just this side do not know why the 61 minutes to save into a 0x61.
R2,R3 is not equal, it jumps to 0xda2a8
This adds R4 and R6 8, and jumps back to 0xda1a8. In addition, the following statement is also executed, so R16 will increment by 1 each time.
Again, this loop, found here, is from 1 to 100, looking for matching items based on the data read from the CD. Then the specified data is found as an offset from an integer recorded in the item.
By debugging the discovery of the final data from 0XC80FC to 0x76868 near the memory, 0XC80FC here the data is static, it seems to record all possible monsters data, the length of each piece of data is 0x28, monster attributes can also be found in this data.
We use the Monster Farm 2 plate to do experiments to see the phenomenon,
Using the Monster Farm 2 disk found, here R2 for 1, will not jump, so at this time the process and read the CD data to generate monsters is completely different.
Debug found here is the Monster Farm 2 of the disk, the direct hard-coded generated a race ID of 19 モッチー.
Here in 0xda0ec, we patch the code here, directly to Addiu r2,r0,0x261c, can generate the front of the special liquid Terminator, where 0x26 and 0x1c corresponds to the liquid Terminator's sub-race ID and the main race ID.
Simply made a gold finger for testing, just modify #summon Specified monster The first two lines, without changing the disk can be arbitrarily generated all the monsters, including field training encountered monsters. (Big success?)
#Summon Specified Monster
300da0ec 0011
300da0ed 0027
300da0ee 0002
300da0ef 0024
#Undo Summon Specified Monster
300da0ec 0000
300da0ed 0000
300da0ee 00E2
300da0ef 008C
But this does not guarantee that the generated monster data is correct, and is a direct patch code, first not sure whether the address is the same every time, it is difficult to ensure that no other problems.
Next, be prepared to carefully re-analyze the next side of the several functions, try to find a better point of modification, or make a modifier.
To be Continued ...
Monster Farm 2 Modify log 5-bliss Pure Land