The PokéCommunity Forums  

Go Back   The PokéCommunity Forums > Fan Games > Binary ROM Hacking
Reload this Page Help Thread ASM & Disassembly

Notices
For all updates, view the main page.

Binary ROM Hacking Need a helping hand or just want to talk about binary ROM hacks? Get comments and answers to any ROM Hacking-related problems, questions or thoughts you have here.

Ad Content
Closed Thread
 
Thread Tools
  #226   Link to this post, but load the entire thread.  
Old March 26th, 2015 (6:00 AM). Edited March 26th, 2015 by Blah.
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
It seems that the function at "08008D84" is always called to transfer the string data of item in the ROM to a RAM offset.
Therefore, the RAM offset of the first item should be at "020041F1". You will see that firstly the string of the expanded is written correctly to that offset, but after some time the offset after the 14th byte of the string is overwritten by the next item string (or cancel). If you create a breakpoint on write to this offset, you will find the function at "08008D84" is called again.

This is a screenshot of this. (I modified "burn heal" into "THEITEMNAMEISNEW")
Alright, I took a few minutes to briefly look at how the bag strings are being made. I'm unsure wheather to give you a solution, or to let you try and figure this out yourself. For now, I'll explain some details, and see if you can make it work yourself.

It looks like the bag hasn't malloc'd enough space for the larger strings. It's malloc'd 0x331 space. Given 43 items, that's obviously 0x13 bytes of string space per item. So we would need to malloc a greater amount, say each item string is potentially 0x19 bytes long. Then the malloc needs to be changed to 0x408. By the way, this malloc is happening here like this:

Code:
ROM:08108406                 LDR     R4, =0x203AD1C
ROM:08108408                 LDR     R0, =0x331      @ size
ROM:0810840A                 BL      malloc
ROM:0810840E                 STR     R0, [R4]
In addition to the malloc problem, the game has also hard coded a loop counter similar to this format:

Code:
/*some stuff before this*/

void Bag() {
	//the destination RAM is malloc'd and put in the static pointer
	mallocBagAttributes();
	generateBagStrings();
	//more stuff
	return;
}

void generateBagStrings(){
/*Writes to RAM rather than returning*/

items = sizeof(bag.pocket);
counter = 0;
while (items != counter){
	int temp;
	str *src = bag.pocket[counter]; //src
	
	//Also some math you should definitely think about changing *hint hint*
	//I recommend changing the entire thing rather than a small fix
	/*R6 = counter */
	temp = counter * 4;
	temp += counter;
	temp *= 4;
	temp  -= counter; 

	//The static pointer is  used to generate a "clean pointer"
	temp += *mallocPointer;
	generateString(temp, src);
	}

/*This function also handles the cancel string and a few others which aren't related
to the bag's pocket space. However, they are irrelevant here, so I'm not going to code-ify them*/

return;
Clearly, there's some hard-coded math which is also creating a problem. I suggest that you change this math, either with a hook or by overwriting it, so suit us. Think about when counter = 0, counter = 1, and counter =2, ect.

You will notice the yield is going to be in multiples of 13 +1. Then, all you need to do is make it multiples of the real string length instead. Because strings are 0xFF terminated, we don't need to worry about having unused bytes in-between strings.
__________________
...
  #227   Link to this post, but load the entire thread.  
Old March 26th, 2015 (6:37 AM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Alright, I took a few minutes to briefly look at how the bag strings are being made. I'm unsure wheather to give you a solution, or to let you try and figure this out yourself. For now, I'll explain some details, and see if you can make it work yourself.

It looks like the bag hasn't malloc'd enough space for the larger strings. It's malloc'd 0x331 space. Given 43 items, that's obviously 0x13 bytes of string space per item. So we would need to malloc a greater amount, say each item string is potentially 0x19 bytes long. Then the malloc needs to be changed to 0x408. By the way, this malloc is happening here like this:

Code:
ROM:08108406                 LDR     R4, =0x203AD1C
ROM:08108408                 LDR     R0, =0x331      @ size
ROM:0810840A                 BL      malloc
ROM:0810840E                 STR     R0, [R4]
In addition to the malloc problem, the game has also hard coded a loop counter similar to this format:

Code:
/*some stuff before this*/

void Bag() {
	//the destination RAM is malloc'd and put in the static pointer
	mallocBagAttributes();
	generateBagStrings();
	//more stuff
	return;
}

void generateBagStrings(){
/*Writes to RAM rather than returning*/

items = sizeof(bag.pocket);
counter = 0;
while (items != counter){
	int temp;
	str *src = bag.pocket[counter]; //src
	
	//Also some math you should definitely think about changing *hint hint*
	//I recommend changing the entire thing rather than a small fix
	/*R6 = counter */
	temp = counter * 4;
	temp += counter;
	temp *= 4;
	temp  -= counter; 

	//The static pointer is  used to generate a "clean pointer"
	temp += *mallocPointer;
	generateString(temp, src);
	}

/*This function also handles the cancel string and a few others which aren't related
to the bag's pocket space. However, they are irrelevant here, so I'm not going to code-ify them*/

return;
Clearly, there's some hard-coded math which is also creating a problem. I suggest that you change this math, either with a hook or by overwriting it, so suit us. Think about when counter = 0, counter = 1, and counter =2, ect.

You will notice the yield is going to be in multiples of 13 +1. Then, all you need to do is make it multiples of the real string length instead. Because strings are 0xFF terminated, we don't need to worry about having unused bytes in-between strings.
I'm terribly sorry because I really don't understand your words though I really want to try myself.
Actually I haven't learned C language yet. So could you please try to tell me in something I can understand?

I'm Sorry indeed to waste your time writing the codes but I really don't know even a bit of C.
  #228   Link to this post, but load the entire thread.  
Old March 26th, 2015 (7:41 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Code:
/*some stuff before this*/
Load_bag_function:
	push {r4-rx, lr}
	@some stuff before this
	@Allocate memory in Ram for bag strings
	bl mallocBagAttributes
	ldr r4, =(0x203AD1C) @this is a pointer to free RAM space
	str r0, [r4]  @load the return from the malloc call into the pointer
	
	@generate bag strings at allocated memory
	bl generateBagStrings
	//more stuff
	pop {r4-rx, pc}


generate_bag_strings:
	push {r4-rx, lr}
	@some stuff before this
	....
	@save RAM space pointer in r5
	ldr r5, =(0x203AD1C)
	mov r6, #0x0 @r6 is a counter

loop:
	ldr r0, =(Amount of items in pocket)
	cmp r0, r6
	bhi exit

	@here is the math you're interested in changing
	@make r4 at the end = [max string size -1]
	lsl r2, r6, #0x2
	add r4, r2, r6
	lsl r4, r4, #0x2
	sub r4, r4, r6

	@get item name from ID, takes r0 = item ID
	@once again irrelavent
	bl build_str_item
	....
	....
	@some operations occur for R6 = next item
	...
	...
	cmp r6, Amount of items
	blo loop


exit:
	@This function also handles the cancel string and a few others which aren't related
	@to the bag's pocket space such as the word cancel. But they are irrelevant for this hack
	pop {r4-rx, lr}
This code is not EXACTLY what's there. I've simplified it so it's easier to understand. You're interested in the :

Code:
	@here is the math you're interested in changing
	@make r4 at the end = [max string size -1]
	lsl r2, r6, #0x2
	add r4, r2, r6
	lsl r4, r4, #0x2
	sub r4, r4, r6
portion of the above code. This happens exactly at 08108450.
__________________
...
  #229   Link to this post, but load the entire thread.  
Old March 27th, 2015 (2:20 AM). Edited March 27th, 2015 by jiangzhengwenjzw.
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Code:
/*some stuff before this*/
Load_bag_function:
	push {r4-rx, lr}
	@some stuff before this
	@Allocate memory in Ram for bag strings
	bl mallocBagAttributes
	ldr r4, =(0x203AD1C) @this is a pointer to free RAM space
	str r0, [r4]  @load the return from the malloc call into the pointer
	
	@generate bag strings at allocated memory
	bl generateBagStrings
	//more stuff
	pop {r4-rx, pc}


generate_bag_strings:
	push {r4-rx, lr}
	@some stuff before this
	....
	@save RAM space pointer in r5
	ldr r5, =(0x203AD1C)
	mov r6, #0x0 @r6 is a counter

loop:
	ldr r0, =(Amount of items in pocket)
	cmp r0, r6
	bhi exit

	@here is the math you're interested in changing
	@make r4 at the end = [max string size -1]
	lsl r2, r6, #0x2
	add r4, r2, r6
	lsl r4, r4, #0x2
	sub r4, r4, r6

	@get item name from ID, takes r0 = item ID
	@once again irrelavent
	bl build_str_item
	....
	....
	@some operations occur for R6 = next item
	...
	...
	cmp r6, Amount of items
	blo loop


exit:
	@This function also handles the cancel string and a few others which aren't related
	@to the bag's pocket space such as the word cancel. But they are irrelevant for this hack
	pop {r4-rx, lr}
This code is not EXACTLY what's there. I've simplified it so it's easier to understand. You're interested in the :

Code:
	@here is the math you're interested in changing
	@make r4 at the end = [max string size -1]
	lsl r2, r6, #0x2
	add r4, r2, r6
	lsl r4, r4, #0x2
	sub r4, r4, r6
portion of the above code. This happens exactly at 08108450.
I tried really hard to get but failed...

This is my research:
Firstly, I've changed 0x331 to 0x408 at 08108420 to get more free memory space.

Then I write this to 08108450:
Code:
.thumb

ldr r0, label
bx r0

.align 2
label:
.word 0x08800071
Then I write this to 08800070: (I think the registers I used are safe because they will be refreshed after bx r0)
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
After done these the first item name is right but after that other items are piles of "?" or other item names.
Could you tell me where I made a mistake?

P.S. This is the memory data, after some strings loaded.
You can see that the data are messed up.


The new kind of messing up:
  #230   Link to this post, but load the entire thread.  
Old March 27th, 2015 (10:14 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
I tried really hard to get but failed...

This is my research:
Firstly, I've changed 0x331 to 0x408 at 08108420 to get more free memory space.

Then I write this to 08108450:
Code:
.thumb

ldr r0, label
bx r0

.align 2
label:
.word 0x08800071
Then I write this to 08800070: (I think the registers I used are safe because they will be refreshed after bx r0)
Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
After done these the first item name is right but after that other items are piles of "?" or other item names.
Could you tell me where I made a mistake?

P.S. This is the memory data, after some strings loaded.
You can see that the data are messed up.


The new kind of messing up:
Hey, first of all, if you changed 0x331 to 0x408, then by definition your string sizes are 23 + 0xFF bytes long. Now, if we go over to this:

Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
You've kept the original math. This math basically is a calculation to add 13 to a RAM offset. Since our string is now 23 chars + 1 long, then all we'd need to do is add 0xA to whatever the result of that old math was.

try:

Code:
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA @just increase size of next string by 10
There's also one more thing I forgot to mention. For the cancel string, it's also done in the same function, in the same method. You'd want to edit that part too.
Unedited code:
Code:
ROM:0810848C                 LDR     R5, =0x203AD1C
ROM:0810848E                 LSLS    R4, R6, #2
ROM:08108490                 ADDS    R4, R4, R6
ROM:08108492                 LSLS    R4, R4, #2
ROM:08108494                 SUBS    R4, R4, R6
ROM:08108496                 LDR     R0, [R5]
ROM:08108498                 ADDS    R0, R0, R4      @ dst
ROM:0810849A                 LDR     R1, =0x8452F60  @ src
ROM:0810849C                 BL      strcpy_xFF_terminated
Actually on second look, I now see that this function handles a lot lot more. I'm unsure without proper debugging/research if the remaining code is relevant to the string. It seems like it's for browsing/oam display and basic bag exploration handling. Anyways, try the above fixes and report back.
__________________
...
  #231   Link to this post, but load the entire thread.  
Old March 27th, 2015 (5:54 PM). Edited March 27th, 2015 by jiangzhengwenjzw.
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Hey, first of all, if you changed 0x331 to 0x408, then by definition your string sizes are 23 + 0xFF bytes long. Now, if we go over to this:

Code:
.thumb
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new codes start
mov r1, #0x13
ldr r3, labeltwo @call the divmod function1 in the ROM
bl div
mov r1, #0x6 @For test I have even changed it to 5 instead but also failed
mul r0, r1
add r4, r4, r0
ldr r0, label
bx r0

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
You've kept the original math. This math basically is a calculation to add 13 to a RAM offset. Since our string is now 23 chars + 1 long, then all we'd need to do is add 0xA to whatever the result of that old math was.

try:

Code:
lsl r2, r6, #0x2 @original codes
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA @just increase size of next string by 10
There's also one more thing I forgot to mention. For the cancel string, it's also done in the same function, in the same method. You'd want to edit that part too.
Unedited code:
Code:
ROM:0810848C                 LDR     R5, =0x203AD1C
ROM:0810848E                 LSLS    R4, R6, #2
ROM:08108490                 ADDS    R4, R4, R6
ROM:08108492                 LSLS    R4, R4, #2
ROM:08108494                 SUBS    R4, R4, R6
ROM:08108496                 LDR     R0, [R5]
ROM:08108498                 ADDS    R0, R0, R4      @ dst
ROM:0810849A                 LDR     R1, =0x8452F60  @ src
ROM:0810849C                 BL      strcpy_xFF_terminated
Actually on second look, I now see that this function handles a lot lot more. I'm unsure without proper debugging/research if the remaining code is relevant to the string. It seems like it's for browsing/oam display and basic bag exploration handling. Anyways, try the above fixes and report back.
As I haven't edited the "cancel" function yet, I want to get you a quick report for the first change.
I've done it.

As I have already set a branch, I simply modified my new function (@0x08800070) into

Code:
.thumb
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA
ldr r0, label
bx r0

.align 2
label:
.word 0x08108459
machine code:
Code:
B2 00 94 19 A4 00 A4 1B 0A 34 01 48 00 47 C0 46 59 84 10 08
If it is right, I've found that the text strings are messed up, like in the first case: (As you see not only the "cancel" cause problem)

(I've underlined the problems)

I will update the post after setting the branch in the new function you found.
======================================================================
After that I have done the branch:
@0810848C:
Code:
.thumb

ldr r0, label
bx r0

.align 2
label:
.word 0x08800101
@08800100:
Code:
.thumb
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
add r4, r4, #0xA @As you know you can add before sub
ldr r0, back
bx r0

.align 2
back:
.word 0x08108495
Then the "cancel" problem is solved but the string still get messed up.
  #232   Link to this post, but load the entire thread.  
Old March 28th, 2015 (7:44 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
As I haven't edited the "cancel" function yet, I want to get you a quick report for the first change.
I've done it.

As I have already set a branch, I simply modified my new function (@0x08800070) into

Code:
.thumb
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
add r4, r4, #0xA
ldr r0, label
bx r0

.align 2
label:
.word 0x08108459
machine code:
Code:
B2 00 94 19 A4 00 A4 1B 0A 34 01 48 00 47 C0 46 59 84 10 08
If it is right, I've found that the text strings are messed up, like in the first case: (As you see not only the "cancel" cause problem)

(I've underlined the problems)

I will update the post after setting the branch in the new function you found.
======================================================================
After that I have done the branch:
@0810848C:
Code:
.thumb

ldr r0, label
bx r0

.align 2
label:
.word 0x08800101
@08800100:
Code:
.thumb
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
add r4, r4, #0xA @As you know you can add before sub
ldr r0, back
bx r0

.align 2
back:
.word 0x08108495
Then the "cancel" problem is solved but the string still get messed up.
Would you like a solution? Or should I let you try figure it out?
__________________
...
  #233   Link to this post, but load the entire thread.  
Old March 28th, 2015 (7:51 AM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Would you like a solution? Or should I let you try figure it out?
I‘d prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
  #234   Link to this post, but load the entire thread.  
Old March 28th, 2015 (8:01 AM).
GoGoJJTech's Avatar
GoGoJJTech GoGoJJTech is offline
(☞゚ヮ゚)☞ http://GoGoJJTech.com ☜(゚ヮ゚☜)
 
Join Date: Nov 2012
Location: Earth
Age: 24
Gender: Female
Nature: Jolly
Posts: 2,475
Quote:
Originally Posted by jiangzhengwenjzw View Post
I‘d prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.

Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
__________________
I believe in Jesus Christ my Savior. If you do too, and aren't scared to admit it, then copy and paste this into your signature.
The HGSS Music Patch - The BW/2 Music Patch - ASM: Switch Music Based on Seasons
Romhack.me Profile - Pokecommunity Profile - Youtube Channel

Support me at my site!
Pokémon Platinum Red and Blue
  #235   Link to this post, but load the entire thread.  
Old March 28th, 2015 (12:00 PM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
I‘d prefer the latter, as a solution like "compile XX at XX" does not make sense. But I have no idea now, as the code is too complex and I often do not know what it's doing...... So could you give me some hints so I can continue working on it? That will be really appreciated. :D And I'm very curious about how you get what the code is doing as it's so huge when I'm looking in VBA's disassembler.
Thank you for your help!
I use VBA's disassembler in conjunction with VBA-SDL-H only (or IDA). But IDA is generally many times better than VBA's for most situations. Knowing what the code does at a glance is somewhat from experience of doing it so many times.

For your hints, examine the code inbetween the cancel string generation and the item string loop. You'll notice that R5 is used and the RAM offset is written to again.


Quote:
Originally Posted by GoGoJJTech View Post
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.

Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
VBA's disassembler is best used in conjunction with VBA-SDL-H or some debugger. You can also use it to find faulty branches and such. But, yeah, in general it's not a good idea to use solely VBA (even though that's what I used when I started).
__________________
...
  #236   Link to this post, but load the entire thread.  
Old March 28th, 2015 (6:22 PM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by GoGoJJTech View Post
When looking in VBA's disassembler, you're looking at the entire game in asm. That's not great if you're trying to learn anything, it's great for looking at small pieces of code when you know where they are.

Even still, it's best using a debugger or an idb so you can see the stuff better and you will understand it. Most ASM hackers do not even touch VBA's disassembler. I only use it when I compile C to ASM and something goes wrong.
Thank you, but I have no idea about how to use idb file as I don't know how to use IDA at all and there seems no tutorial.

Quote:
Originally Posted by FBI agent View Post
I use VBA's disassembler in conjunction with VBA-SDL-H only (or IDA). But IDA is generally many times better than VBA's for most situations. Knowing what the code does at a glance is somewhat from experience of doing it so many times.

For your hints, examine the code inbetween the cancel string generation and the item string loop. You'll notice that R5 is used and the RAM offset is written to again.
Thank you for your hint, I will try when I have free time. (Now I have Calculus to do) You have recommended IDA to us newbies several times but there seems no tutorial to teach us how to use that. TAT
  #237   Link to this post, but load the entire thread.  
Old March 28th, 2015 (7:29 PM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
Thank you, but I have no idea about how to use idb file as I don't know how to use IDA at all and there seems no tutorial.



Thank you for your hint, I will try when I have free time. (Now I have Calculus to do) You have recommended IDA to us newbies several times but there seems no tutorial to teach us how to use that. TAT
I'm going to be using IDA in the Workshops, so you'll be able to learn there.
__________________
...
  #238   Link to this post, but load the entire thread.  
Old March 29th, 2015 (2:30 AM). Edited March 29th, 2015 by jiangzhengwenjzw.
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
I'm going to be using IDA in the Workshops, so you'll be able to learn there.
After an hour's research, I've found something really funny.

(I changed 3 item names into pointers, as you can see)
This can be done by using no$gba's function of changing the value of registers.
I will explain what I did:
add breakpoint at 08108450 and 0810848C(for the sake of cancel):
these two places do such math calculations, as you know before.
Code:
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
After calculation r4's value will change each time the 2 functions are called.
If after each calculation I modify r4 to 0, 0x19, 0x19 * 2, 0x19 * 3......
The item will be shown correctly as the image showed.

However when it comes to a routine it all messed up and I really don't know the reason because I think they do the same thing.
This is my routine.

Code:
.thumb
@at 0x08800070, branch from the function you know

lsl r2, r6, #0x2 @original code
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new code start, parameter1
mov r1, #0x13 @parameter2
ldr r3, labeltwo @function pointer
bl div @call the div function
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, label
bx r0 @back to the original code

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
Code:
.thumb
@This code is at 0x08800100 as I did before, branch from the function you know
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4
mov r1, #0x13
ldr r3, label
bl div
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, back
bx r0

div:
bx r3

.align 2
label:
.word 0x081E4019
back:
.word 0x08108497
I'm very confused as I think the function does the same thing as changing value of r4, and I think the registers I use are safe.
Maybe you can find my problem?
  #239   Link to this post, but load the entire thread.  
Old March 29th, 2015 (9:38 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
After an hour's research, I've found something really funny.

(I changed 3 item names into pointers, as you can see)
This can be done by using no$gba's function of changing the value of registers.
I will explain what I did:
add breakpoint at 08108450 and 0810848C(for the sake of cancel):
these two places do such math calculations, as you know before.
Code:
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
After calculation r4's value will change each time the 2 functions are called.
If after each calculation I modify r4 to 0, 0x19, 0x19 * 2, 0x19 * 3......
The item will be shown correctly as the image showed.

However when it comes to a routine it all messed up and I really don't know the reason because I think they do the same thing.
This is my routine.

Code:
.thumb
@at 0x08800070, branch from the function you know

lsl r2, r6, #0x2 @original code
add r4, r2, r6
lsl r4, r4, #0x2
sub r4, r4, r6
mov r0, r4 @new code start, parameter1
mov r1, #0x13 @parameter2
ldr r3, labeltwo @function pointer
bl div @call the div function
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, label
bx r0 @back to the original code

div:
bx r3

.align 2
labeltwo:
.word 0x081E4019
label:
.word 0x08108459
Code:
.thumb
@This code is at 0x08800100 as I did before, branch from the function you know
ldr r5, =0x203AD1C
lsl r2, r6, #0x2
add r4, r2, r6
lsl r4, r4, #0x2
mov r0, r4
mov r1, #0x13
ldr r3, label
bl div
mov r1, #0x19
mul r0, r1
mov r4, r0
ldr r0, back
bx r0

div:
bx r3

.align 2
label:
.word 0x081E4019
back:
.word 0x08108495
I'm very confused as I think the function does the same thing as changing value of r4, and I think the registers I use are safe.
Maybe you can find my problem?
Just do
Code:
mov r4, #0x19
mul r4, r4, r6
@r6 is the item counter, so it should increment by one
@if r6 starts at 1, then sub r6, r6, #0x1
@also, this should overwrite the old math
So replace the old code for the math calcs, with this one
__________________
...
  #240   Link to this post, but load the entire thread.  
Old March 29th, 2015 (3:27 PM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Just do
Code:
mov r4, #0x19
mul r4, r4, r6
@r6 is the item counter, so it should increment by one
@if r6 starts at 1, then sub r6, r6, #0x1
@also, this should overwrite the old math
So replace the old code for the math calcs, with this one
OK, I will try. After that I will update the post.
But why shouldn't my code work? I think there's no problem as it simply changes r4.
  #241   Link to this post, but load the entire thread.  
Old March 29th, 2015 (3:58 PM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
OK, I will try. After that I will update the post.
But why shouldn't my code work? I think there's no problem as it simply changes r4.
Because at this line:
Code:
ROM:08108458                 LDR     R0, [R5]
Is overwritten by the hook.
Code:
ldr rX, =(0xOffset +1)
bx rX
The hook takes 8 bytes. So if you hooked at 08108450 then the hook bytes take upto 08108458 inclusive. Also you've overwritten r0 for the "bx" back to the original routine.

If you examine further down:
Code:
ROM:0810845E                 LDR     R1, [R3]
R1 is overwritten and completely free to use for a bx.
__________________
...
  #242   Link to this post, but load the entire thread.  
Old March 29th, 2015 (9:34 PM). Edited March 29th, 2015 by jiangzhengwenjzw.
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Because at this line:
Code:
ROM:08108458                 LDR     R0, [R5]
Is overwritten by the hook.
Code:
ldr rX, =(0xOffset +1)
bx rX
The hook takes 8 bytes. So if you hooked at 08108450 then the hook bytes take upto 08108458 inclusive. Also you've overwritten r0 for the "bx" back to the original routine.

If you examine further down:
Code:
ROM:0810845E                 LDR     R1, [R3]
R1 is overwritten and completely free to use for a bx.
Thank U very much for Ur help, but I really don't think so...



For the first problem, @0x08008454 is the pointer so it didn't overwrite 0x08108458 as the picture showed.

For the register used, you can find @0x08108458 R0 will be refreshed by the content in the pointer in r5 so I think I can use it to get back to the original routine.

In addition, I modified the second routine in my previous reply (Just to fix some silly mistakes).
P.S. I've added your skype.
Hoping that you will point out my mistake, thank you!
  #243   Link to this post, but load the entire thread.  
Old March 30th, 2015 (3:46 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
Thank U very much for Ur help, but I really don't think so...



For the first problem, @0x08008454 is the pointer so it didn't overwrite 0x08108458 as the picture showed.

For the register used, you can find @0x08108458 R0 will be refreshed by the content in the pointer in r5 so I think I can use it to get back to the original routine.

In addition, I modified the second routine in my previous reply (Just to fix some silly mistakes).
P.S. I've added your skype.
Hoping that you will point out my mistake, thank you!
Well, that's embarrassing. Sorry, I forgot how to count 8 bytes :)

Anyways, if that wasn't it, I don't know! Can I see a screenshot of the compiled version of your code? Just like the one previous where you showed me that those two bytes weren't overwritten.

The registers are safe, and the source code looks correct. The only other possibility I can think of is miscompilation/word alignment in the routine you've said you've added.
__________________
...
  #244   Link to this post, but load the entire thread.  
Old March 30th, 2015 (4:14 AM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
Well, that's embarrassing. Sorry, I forgot how to count 8 bytes :)

Anyways, if that wasn't it, I don't know! Can I see a screenshot of the compiled version of your code? Just like the one previous where you showed me that those two bytes weren't overwritten.

The registers are safe, and the source code looks correct. The only other possibility I can think of is miscompilation/word alignment in the routine you've said you've added.
108450

10848C

800070

800100
  #245   Link to this post, but load the entire thread.  
Old March 30th, 2015 (6:30 AM).
Blah's Avatar
Blah Blah is offline
Free supporter
 
Join Date: Jan 2013
Location: Unknown Island
Gender: Male
Posts: 1,924
Quote:
Originally Posted by jiangzhengwenjzw View Post
108450

10848C

800070

800100
No, no I meant like:
[img]
http://i869.photobucket.com/albums/ab256/jiangzhengwenjz/1_zpsheo4spgm.png
[/IMG]

I can't tell whats going on if it's all just hex ;P
I just want to see the routines you inserted in the VBA's disassembler.
__________________
...
  #246   Link to this post, but load the entire thread.  
Old March 30th, 2015 (6:54 AM).
jiangzhengwenjzw's Avatar
jiangzhengwenjzw jiangzhengwenjzw is offline
now working on katam
 
Join Date: Sep 2012
Gender: Male
Posts: 175
Quote:
Originally Posted by FBI agent View Post
No, no I meant like:
[img]
http://i869.photobucket.com/albums/ab256/jiangzhengwenjz/1_zpsheo4spgm.png
[/IMG]

I can't tell whats going on if it's all just hex ;P
I just want to see the routines you inserted in the VBA's disassembler.
108450

10848C

800070

800100
  #247   Link to this post, but load the entire thread.  
Old March 31st, 2015 (8:10 AM).
Mana's Avatar
Mana Mana is offline
 
Join Date: Jan 2009
Location: UK
Age: 31
Gender: Male
Posts: 10,075
HELLO AGAIN

So I've been trying to implement some (hopefully simple) bits of ASM to my hack to help enhance the FAME mechanics I have. Scripting does well with this, but I'm hoping ASM can help establish some of the mechanics without me having to repeat myself in scripts.

So the first thing I was looking to do was to lower the value of a var by 3 when you lose. To do this I found the loser text and tracked it back to this routine - since my own routine is short and just involves tweaking a variable I figured I could put it before this text was generated(?) so hooked over to my routine before passing it back.

Spoiler:
MAIN CODE:
Code:
.text
.align 2
.thumb
.thumb_func

main: 
	ldrb r1, [r0, #0x0] /*replaced by the hook so rewritten in my routine*/
	ldrh r6, var4080
	sub r6, #0x3
	strh r6, [r6]
	bl $080d83f0 /*linker overwritten by hook so ending script with it, linked routine does not seem to call itself back naturally?*/

.align 2

var4080:
	.word 0x020270B6 + (0x4080 * 2)
HOOK CODE = 08D7884
Code:
.text
.align 2
.thumb
.thumb_func

main: 
	ldr r6, =(0x8752461)
	bx r6


However the battle freezes as soon as the trainer sprite scrolls on to the screen at the start of the battle, rather than when a victor is decided.
__________________
  #248   Link to this post, but load the entire thread.  
Old March 31st, 2015 (8:31 AM).
daniilS's Avatar
daniilS daniilS is offline
busy trying to do stuff not done yet
 
Join Date: Aug 2013
Age: 23
Gender: Male
Posts: 409
Quote:
Originally Posted by Magic View Post
HELLO AGAIN

So I've been trying to implement some (hopefully simple) bits of ASM to my hack to help enhance the FAME mechanics I have. Scripting does well with this, but I'm hoping ASM can help establish some of the mechanics without me having to repeat myself in scripts.

So the first thing I was looking to do was to lower the value of a var by 3 when you lose. To do this I found the loser text and tracked it back to this routine - since my own routine is short and just involves tweaking a variable I figured I could put it before this text was generated(?) so hooked over to my routine before passing it back.

Spoiler:
MAIN CODE:
Code:
.text
.align 2
.thumb
.thumb_func

main: 
	ldrb r1, [r0, #0x0] /*replaced by the hook so rewritten in my routine*/
	ldrh r6, var4080
	sub r6, #0x3
	strh r6, [r6]
	bl $080d83f0 /*linker overwritten by hook so ending script with it, linked routine does not seem to call itself back naturally?*/

.align 2

var4080:
	.word 0x020270B6 + (0x4080 * 2)
HOOK CODE = 08D7884
Code:
.text
.align 2
.thumb
.thumb_func

main: 
	ldr r6, =(0x8752461)
	bx r6


However the battle freezes as soon as the trainer sprite scrolls on to the screen at the start of the battle, rather than when a victor is decided.
Alright, a few notes:

I suppose you're using 080D7884 for the hook, and not 08D7884. :P
A hook like that takes eight bytes, which means you're also overwriting the cmp r1, #0xFD which comes after the bl.
r6 is not safe to use in this routine, since you can see its original value is still needed after you return from your routine.
You can't bl like that from your routine, use a bx instead.
You can't ldrh a label. :/ Also, you're substracting 3 from the var address and trying to store it in itself. :\
Finally, How will this routine react if the fame var contains a value less than 0? Do you want it to become 0xFFFX?

Fix these and you should be fine :b

EDIT: I haven't checked the viability of your hooking offset though, so I hope you got that one right.
__________________
  #249   Link to this post, but load the entire thread.  
Old March 31st, 2015 (8:46 AM).
Mana's Avatar
Mana Mana is offline
 
Join Date: Jan 2009
Location: UK
Age: 31
Gender: Male
Posts: 10,075
Quote:
Originally Posted by daniilS View Post
I suppose you're using 080D7884 for the hook, and not 08D7884. :P
Whoops, typo in my post. ><

Quote:
A hook like that takes eight bytes, which means you're also overwriting the cmp r1, #0xFD which comes after the bl.
Don't you hate it when counting to 8 becomes difficult ;-; my brain. So would it be better to hook from 080d7880? Including the lsr up to the bl/bx in my part of the routine.



Quote:
r6 is not safe to use in this routine, since you can see its original value is still needed after you return from your routine.
Hmm, I was a bit confused as to which ones were viable - since r6 is moved to 0 further up. If I move it back to zero afterwards would it be OK then.

Quote:
You can't bl like that from your routine, use a bx instead.
Ah, me being lazy - should I changed that one. So I need another register clear for this too.

Quote:
You can't ldrh a label. :/ Also, you're substracting 3 from the var address and trying to store it in itself. :\
Ah it should be
Code:
ldr r6, var4080
	ldrh r6, [r6]
etc. I'm not sure why I thought I needed a store. I'd only need that if I were copying it elsewhere right?

Quote:
Finally, How will this routine react if the fame var contains a value less than 0? Do you want it to become 0xFFFX?
I'll sort that one out later lmao.
__________________
  #250   Link to this post, but load the entire thread.  
Old March 31st, 2015 (8:51 AM).
daniilS's Avatar
daniilS daniilS is offline
busy trying to do stuff not done yet
 
Join Date: Aug 2013
Age: 23
Gender: Male
Posts: 409
Quote:
Originally Posted by Magic View Post
Whoops, typo in my post. ><



Don't you hate it when counting to 8 becomes difficult ;-; my brain. So would it be better to hook from 080d7880? Including the lsr up to the bl/bx in my part of the routine.

That one could work.

Hmm, I was a bit confused as to which ones were viable - since r6 is moved to 0 further up. If I move it back to zero afterwards would it be OK then.

It should be.

Ah, me being lazy - should I changed that one. So I need another register clear for this too.

yup

Ah it should be
Code:
ldr r6, var4080
	ldrh r6, [r6]
etc. I'm not sure why I thought I needed a store. I'd only need that if I were copying it elsewhere right?

Of course you do need a strh. You just need not to overwrite the register containing the address of the var so you can store it after substracting three from it.

I'll sort that one out later lmao.

Just don't forget to.
__________________
Closed Thread

Quick Reply

Join the conversation!

Create an account to post a reply in this thread, participate in other discussions, and more!

Create a PokéCommunity Account
Ad Content

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 9:25 AM.