Hacking Understanding and changing Snes VC RPX settings

[the_randomizer]

This is getting interesting! I moved on from N64 VC stuff, but this caught my attention now

If others can join in and help, that'd be most helpful, as I'd rather not do this by myself, I mean, those who feel like they're up to the challenge anyway, IDA pro has a free version, just be sure you open the .elf as a binary file and then load it as 32-bit

 

[ShadowOne333]

I will be posting some sort of summarized version of all the lines:

GX2CalcTVSize
Segment:017FF84B
Line:211216 of 211646
Length:000000E

GX2CalcTVAspectRatio
Segment:017FF9D4
Line:211267
Length:0000001A

GX2CalcTVScanMode
Segment:017FF9EE
Line:211268
Length:00000017

GX2InitSamplerXYFilter (possible filtering)
Segment:017FFAA4
Line:211277
Length:00000017

GX2InitSamplerZMFilter (possible filtering)
Segment:017FFABB
Line:211278
Length:00000017

GX2SetTVGamma
Segment:017FFF1B
Line:211335
Length:0000000E

GX2CalcDRCSize
Segment:071FF7EA
Line:221242
Length:0000000F

GX2SurfaceSizeAndAlignment
Segment:017FF82C
Line:221245
Length:0000001F

GX2CalcTVSize
Segment:017FF84B
Line:211246
Length:000000E

@the_randomizer, I'm somewhat confused as to which one of the three described parts is the actual offset for the lines? Is it Segment?

 

[the_randomizer]

I will be posting some sort of summarized version of all the lines:

GX2CalcTVSize
Segment:017FF84B
Line:211216 of 211646
Length:000000E

GX2CalcTVAspectRatio
Segment:017FF9D4
Line:211267
Length:0000001A

GX2CalcTVScanMode
Segment:017FF9EE
Line:211268
Length:00000017

GX2InitSamplerXYFilter (possible filtering)
Segment:017FFAA4
Line:211277
Length:00000017

GX2InitSamplerZMFilter (possible filtering)
Segment:017FFABB
Line:211278
Length:00000017

GX2SetTVGamma
Segment:017FFF1B
Line:211335
Length:0000000E

GX2CalcDRCSize
Segment:071FF7EA
Line:221242
Length:0000000F

GX2SurfaceSizeAndAlignment
Segment:017FF82C
Line:221245
Length:0000001F

GX2CalcTVSize
Segment:017FF84B
Line:211246
Length:000000E

@the_randomizer, I'm somewhat confused as to which one of the three described parts is the actual offset for the lines? Is it Segment?

Sorry yeah, comparing the segment to the actual offsets in hex mod A (in IDA pro's interface), gonna be getting the offsets and which bytes they begin, where they end, sorry for confusing ya.

Edit: Aren't those the addresses as well? It looks like a four byte address.

Ugh, I'm gonna really need outside help, as I can't seem to find the same offsets that I can see in IDA.

 

[ShadowOne333]

Sorry yeah, comparing the segment to the actual offsets in hex mod A (in IDA pro's interface), gonna be getting the offsets and which bytes they begin, where they end, sorry for confusing ya.

Edit: Aren't those the addresses as well? It looks like a four byte address.

Ugh, I'm gonna really need outside help, as I can't seem to find the same offsets that I can see in IDA.

Hex Mod A?
Damn, I gotta take a look at that IDA shit to see how that works haha.
Just focus on the Segment value, 017FFF1B for example, and try to go to that very offset in a Hex editor like HxD with Ctrl+G.
I suppose the Line number is nothing but the actual number of the line in the complete ode of the RPX file.

 

[the_randomizer]

Hex Mod A?
Damn, I gotta take a look at that IDA shit to see how that works haha.
Just focus on the Segment value, 017FFF1B for example, and try to go to that very offset in a Hex editor like HxD with Ctrl+G.
I suppose the Line number is nothing but the actual number of the line in the complete ode of the RPX file.

Oh my holy crap, I've been finding the offsets wrong all along on HxD, I forgot about control + G

Okay, so for GX2CalcDRCSize, the offset in HxD is exactly the same as it is in IDA's Hex viewer, so they do in fact match up 1:1

The address is 017FF7E0 starting at byte 47 and continuing on to the next address, 017FF7F0, ending at byte 65, right in the middle of that offset

http://i.imgur.com/XglthWh.png

Wow, I think we're getting closer


So in essence, the code we want to change is in those two offsets with those corresponding bytes Gonna document these GX2 functions, their addresses, which bytes they begin and end, that I find as I go perusing in the code.



017FF7E0 65 72 41 75 78 49 6E 66 6F 00 47 58 32 43 61 6C
017FF7F0 63 44 52 43 53 69 7A 65 00 47 58 32 43 61 6C 63

Those fourteen bytes control that function.

 

[ShadowOne333]

Oh my holy crap, I've been finding the offsets wrong all along on HxD, I forgot about control + G

Okay, so for GX2CalcDRCSize, the offset in HxD is exactly the same as it is in IDA's Hex viewer, so they do in fact match up 1:1

The address is 017FF7E0 starting at byte 47 and continuing on to the next address, 017FF7F0, ending at byte 65, right in the middle of that offset

http://i.imgur.com/XglthWh.png

Wow, I think we're getting closer


So in essence, the code we want to change is in those two offsets with those corresponding bytes Gonna document these GX2 functions, their addresses, which bytes they begin and end, that I find as I go perusing in the code.



017FF7E0 65 72 41 75 78 49 6E 66 6F 00 47 58 32 43 61 6C
017FF7F0 63 44 52 43 53 69 7A 65 00 47 58 32 43 61 6C 63

Those fourteen bytes control that function.

Oh wait HxD is showing off the functions too in actual ascii text.
That's not really what we want.
If you notice, at the end of each line we have the same value for all of them... 00.
I thin this might just be a separator of some sort, I'm not sure, but I don't think that single byte might be the one.
I could be wrong though.

In any way all this info sure is handy, at least we know now what functions are the ones that might in charge of the things we want to change.

 

[the_randomizer]

Oh wait HxD is showing off the functions too in actual ascii text.
That's not really what we want.
If you notice, at the end of each line we have the same value for all of them... 00.
I thin this might just be a separator of some sort, I'm not sure, but I don't think that single byte might be the one.
I could be wrong though.

In any way all this info sure is handy, at least we know now what functions are the ones that might in charge of the things we want to change.

Cripes, gonna look more into this, as I told HxD to display/view as hex, *takes a deep breath* this is one of the few times I ever delve into programming/code-related stuff, so I need to take this slowly

Yeah, I chose view, then grouped the bytes together in eight-byte lengths.



Edit: Wait a minute..!

If I choose those range of bytes, on the bottom of the screen, it tells me
Block: 17FF7EA to 17FF7F7 as the bytes that make out the function's name, is that the actual info of the range we need?

I really hope more people join in.

 

[ShadowOne333]

Cripes, gonna look more into this, as I told HxD to display/view as hex, *takes a deep breath* this is one of the few times I ever delve into programming/code-related stuff, so I need to take this slowly

Yeah, I chose view, then grouped the bytes together in eight-byte lengths.



Edit: Wait a minute..!

If I choose those range of bytes, on the bottom of the screen, it tells me
Block: 17FF7EA to 17FF7F7 as the bytes that make out the function's name, is that the actual info of the range we need?

I really hope more people join in.

Try to see if there's any other portion of the ELF that includes such functions.
You can do a basic Text search with Ctrl+F and typing the actual text like GX2SetTvGamma

 

[the_randomizer]

Try to see if there's any other portion of the ELF that includes such functions.
You can do a basic Text search with Ctrl+F and typing the actual text like GX2SetTvGamma

Hmm, okay I'll do that and then highlight the bytes that make up the command, would this be more useful to type it out like so?

GX2CalcDRCSize
Offset: 017FF7E0 (starting off at byte EA)
Block: 17FF7EA to 17FF7F7

I can see all the text lumped together but with periods, so that helps too.

 

[ShadowOne333]

Hmm, okay I'll do that and then highlight the bytes that make up the command, would this be more useful to type it out like so?

GX2CalcDRCSize
Offset: 017FF7E0 (starting off at byte EA)
Block: 17FF7EA to 17FF7F7

I can see all the text lumped together but with periods, so that helps too.

Oh so that's the only part where the text is found, only in 017FF7E0?

 

[the_randomizer]

Oh so that's the only part where the text is found, only in 017FF7E0?

No no, there's more text, that's just part of the text. Those character make up the characters called "GX2CalcDRCSize". before and after, there are other GX2 functions listed and separated by periods. If you look at the image I posted, you can see the other text beyond the portion I highlighted. But as for only that particular command, yes, those are the bytes that make up that particular string, I hope that made sense lol.

 

[ShadowOne333]

No no, there's more text, that's just part of the text. Those character make up the characters called "GX2CalcDRCSize". before and after, there are other GX2 functions listed and separated by periods. If you look at the image I posted, you can see the other text beyond the portion I highlighted. But as for only that particular command, yes, those are the bytes that make up that particular string, I hope that made sense lol.

Oh yeah I know there are other GX2 functions in there, but I wanted to see if, let's say "GX2CalcDRCSize" specifically is only found once in the entire elf file.
If it is found in other places too, then it's worth checking those too.

That way we might find other snippets of code where the actual value might be set.

 

[the_randomizer]

Oh yeah I know there are other GX2 functions in there, but I wanted to see if, let's say "GX2CalcDRCSize" specifically is only found once in the entire elf file.
If it is found in other places too, then it's worth checking those too.

That way we might find other snippets of code where the actual value might be set.

Yeah, I searched for it and it only found it once, it's safe to say that the other GX2 functions are only found in that portion of the code. *Sigh* I fear this is gonna to be hellacious to figure out where to set values, I wish I knew more about programming. If this has all been a bust, I apologize to everyone.

I don't know what else I can do other than showing the offsets, where the bytes start and end for the functions, I mean, I don't know.

I need a break for a few hours at least, my brain has been fried trying to figure this out.

 

[ShadowOne333]

Yeah, I searched for it and it only found it once, it's safe to say that the other GX2 functions are only found in that portion of the code. *Sigh* I fear this is gonna to be hellacious to figure out where to set values, I wish I knew more about programming. If this has all been a bust, I apologize to everyone.

I don't know what else I can do other than showing the offsets, where the bytes start and end for the functions, I mean, I don't know.

I need a break for a few hours at least, my brain has been fried trying to figure this out.

The next step would be to fuck around with the ELF.
Changing those 00 values after a particular function to something like 01, then convert the ELF to RPX again and try it out in Loadiine and see if anything changed.
Trial and error.

 

[the_randomizer]

The next step would be to fuck around with the ELF.
Changing those 00 values after a particular function to something like 01, then convert the ELF to RPX again and try it out in Loadiine and see if anything changed.
Trial and error.

I have the RPX2elf converter, just don't know if it would work properly, I suppose I can test something out, IDK Is it really such that more people can't help with testing though? I mean, this seems a bit daunting to do on my own.

Don't RPX files need to be compressed too? I've no means of doing that.

Edit: Turns out I'd need makerpl64.exe but since that is part of the Wii U SDK, I'm stuck with RPX to ELF, but not ELF back to RPX -_-

 

[ShadowOne333]

I have the RPX2elf converter, just don't know if it would work properly, I suppose I can test something out, IDK Is it really such that more people can't help with testing though? I mean, this seems a bit daunting to do on my own.

Don't RPX files need to be compressed too? I've no means of doing that.

Edit: Turns out I'd need makerpl64.exe but since that is part of the Wii U SDK, I'm stuck with RPX to ELF, but not ELF back to RPX -_-

Huh really?
I thought it would be a matter of using rpltoelf too but with different flags.
Let's rest for today and continue tomorrow.

 

[the_randomizer]

Huh really?
I thought it would be a matter of using rpltoelf too but with different flags.
Let's rest for today and continue tomorrow.

I don't know, I didn't see any guides for converting it back to rpx, and yeah, I need to rest, I hope more people jump on and figure things out, this is a bit much for me to do by myself

Edit: According to this https://gbatemp.net/threads/tutorial-how-to-decompress-and-repack-rpx-rpl-files.399934/

I need makerpl64.exe, which is part of the SDK to repack them back to RPX files, yeah, that's a problem XD

 

[daxtsu]

Indeed, there's no open source tool to convert ELF back to RPX or RPL. SNES and NES injections are still a pain because of it.

 

[asper]

What you found out are strings (function names) and yes, 00 is probably a separator; you need to find out how the functions are managed/called insidie the elf To find where their parameters are stored/managed = you need To know how to asm-debug.

Have you tested the possibility that those values are stored in an external xml or other kind of file?

 

[the_randomizer]

Indeed, there's no open source tool to convert ELF back to RPX or RPL. SNES and NES injections are still a pain because of it.

There is a tool, but it's part of the Wii U SDK and downloads do exist, just very very shady and obviously I won't be asking for links to avoid issues. That being said, I really don't want this to end here, like, because I feel like I'm getting close, you know?

What you found out are strings (function names) and yes, 00 is probably a separator; you need to find out how the functions are managed/called insidie the elf To find where their parameters are stored/managed = you need To know how to asm-debug.

Have you tested the possibility that those values are stored in an external xml or other kind of file?

So what do you suggest we do? I really don't want to get this far and then have to stop, and I was hoping others could join in and help, but if I have to learn ASM... *sigh* maybe, just maybe, I'm way in over my head and that all this was just a big waste of time...just like everything else I had hope in with the Wii U scene -_-


Edit: The only XML files I see for Kirby's Dream Land 3 are apps and cos.xml, nothing else I can see. I really was hoping people could help me and have others join in, but I guess that's not happening anytime soon.

Edit 2: Ugh, IDK what to do from here.

Edit 3: No where they could be stored in another file, maybe these are just pointers, as to where the values are actually stored, I don't know. IDA pro I'd assume has a means of debugging.

For the record, I apologize for this tone, I'm not used to doing this and it will take time for me to acclimate.