Hacking Understanding and changing Snes VC RPX settings

[the_randomizer]

Well, right now I'm going off of what 87 PSI and ShadowOne333 posted. I've actually switched to TCP gecko, and am dynamically changing instances of 0x1e0 to 0x2d0, and seeing if anything changes.

Ah, still using the RPX format or did you convert it to Elf? Awesome though, glad we're getting more help on this, as I and others want to see what we can change. Keep us posted

 

[shutterbug2000]

Ah, still using the RPX format or did you convert it to Elf? Awesome though, glad we're getting more help on this, as I and others want to see what we can change. Keep us posted

I converted it to elf, but seeing as ram modification is quicker, I'm just using it as a guide for what to look for in ram(values nearby and such), and modifying it there.

 

[the_randomizer]

I converted it to elf, but seeing as ram modification is quicker, I'm just using it as a guide for what to look for in ram(values nearby and such), and modifying it there.

Nice, I don't think I've used TCP Gecko before, but I assume it works by remotely launching the game in conjunction with Loadiine? I'll need to look into that as it sounds a lot simpler to alter addresses than using a hex editor. I feel that we're
getting closer and closer.

 

[shutterbug2000]

Nice, I don't think I've used TCP Gecko before, but I assume it works by remotely launching the game in conjunction with Loadiine? I'll need to look into that as it sounds a lot simpler to alter addresses than using a hex editor. I feel that we're
getting closer and closer.

Yeah, it allows for ram modification. So we don't have to repack and all that.

 

[the_randomizer]

Yeah, it allows for ram modification. So we don't have to repack and all that.

Even better, that makes it infinitely easier for testing, not sure why I didn't think to use it, hopefully there's a decent tutorial that I can follow.

 

[shutterbug2000]

Even better, that makes it infinitely easier for testing, not sure why I didn't think to use it, hopefully there's a decent tutorial that I can follow.

Actually, don't use it. Seems to crash the game no matter what, even if writing back the exact same value... Might not be 5.5.1 compatible?

Anyway, back to the RPX method.

 

[the_randomizer]

Actually, don't use it. Seems to crash the game no matter what, even if writing back the exact same value... Might not be 5.5.1 compatible?

Anyway, back to the RPX method.

Damn, this isn't looking good because I have no means of converting Elf to RPX, I only have the means to convert RPX to elf, so yeah, that means I'm screwed unless there's a way to convert back and forth without requiring the SDK. *sigh*

I'm on 5.3.2, spoofed to 5.5.0 (haven't spoofed to 5.5.1 yet), so, I don't know -_-

There has to be a way for this to work.

 

[QuarkTheAwesome]

Thought I'd just throw in some more info.

• RAM modification (at least for now) is probably the way for you to go. You can probably start poking and changing values before they are sent to GX2 with a bit of effort.
• 640x480 = 480p/i, 720x576 = 576p/i etc. That code, since it's right after GX2Init, is probably setting up GX2 to know stuff about how big the screens are. You can see something similar in most GX2-enabled homebrew (here's an example).
• All those functions names are likely for OSDynLoad. Basically the program will run OSDynLoad and the Wii U will tell the program where in memory to find the function it wants. Make of it what you will - IDA will probably still recognise these functions correctly.
• By the way, strings in C have 00 (a null character/full stop in HxD) at the end of them. This is so the program can tell where the end of a string is - If it wasn't there, we'd have no idea where a string stops and another bit of data starts.
• Most compilers will also lump all the strings into one spot at the start or end of a program, so it's unlikely that the code that uses a string would be near the string itself. However, IDA will tell you where a string is used.

Oh, and here's the real meat of what you're looking for... PowerPC Calling Conventions! (yaaaay)

When you're poking around in IDA you'll notice that functions are called like so:

bl    mySuperCoolFunction

That means:

• break (b) the program over to the function I've provided
  
• Also remember where the program is now in the link register (l) so we can come back once the function is done
  
• The function we wanted is mySuperCoolFunction

You'll probably notice that this doesn't leave room for us to give information to functions. This is solved by using the registers.
Every computer has little bits of super-fast space called registers. Some are used for special things (like the link register, which we saw before) and some are used for anything and everything. One of the uses for these general-purpose registers is passing arguments (data) into functions. This is done like so:

• Our program puts the first argument into r3 (register 3, the first general-purpose register)
• It then puts any other arguments into registers r4-r10 in ascending order (starting with r4, then r5 and so on until there's no more arguments/registers)
• Last, it remembers where it is in the link register and breaks to the function
• Our function then copies the arguments it wants into the places it needs them and runs.
• Once the function is finished, it puts the return value (a bit of data it wants to send back to the main program) into r3 and breaks back to the link register.

In practice, this looks something like this:

li r3, 1             ;load (l) the first argument (1) into r3
li r4, 5             ;load the second argument into r4
bl addTwoNumbers     ;break to our function
                     ;the return value is now in r3.
mr r5, r3            ;move the value of r3 into r5 (mr=move register)

In the real world this will be much more complex (this code could be completely replaced with li r5, 6) but the end result will always be the same - arguments in r3-r10, return value in r3. Now that you know how data is passed into the GX2 functions you can start tracing these values back - hopefully you can find where they originally came from! Once you know that you'll almost definitely be able to change them.

So yeah, break out IDA and start looking ;D

 

[the_randomizer]

@QuarkTheAwesome Thank you for this information, now, I do have IDA Pro, but it's the free version, so as for me, this poses quite the problem, as my version cannot view or load PPC at all, but forces me to open WUD-JANE.elf as a binary folder. Are there any alternate methods, along with TCP Gecko (which as you can see above, it didn't end well and crashed even when reverting). On the other hand, I may or may not regret making this thread for reasons including my all-too-obvious lack of programming know how, it's extremely rudimentary. I do hope, however, that something will come of this, but the areas that are bad in Snes VC are

Aspect ratio (4:3 is fine, but an option for stretching would be useful), this would be controlled by GX2GetSystemTVAspectRatio
The lack of any kind of bilinear filtering, that seems to be controlled by GX2InitSamplerZMFilter and GX2InitSamplerXYFilter
Last but not least, gamma correction, many games have the wrong color gamma levels, so while we know these functions
exist, it's just a matter of finding which registers they are and toggling the right bytes within them?

 

[QuarkTheAwesome]

it's just a matter of finding which registers they are and toggling the right bytes within them?

Pretty much. Ideally you'll want to find where the functions are called since that allows you to put a name to the values being passed around, then start tracing these values back to their source. Here's how you might go about that:

;I've written this code backwards to give you an idea of what might help you.
;The next line is the LAST line of the sample, the line after is the second-to-last, etc.
;Also, all of this code is fake and none of these functions are real. It's just an example.

bl GX2MakeGraphicsTerrible
;Right, here's the function we want to mess with.
;From the docs available from WiiUBrew and other places, we know that it takes 1 argument - a number.
;For the sake of this explanation, let's call it "level"
;We want to set level to 3.

;At this point, we can say for sure that r3 must have level in it.
;This is because r3 is the first argument to a function, and
;the docs say that the first argument to GX2MakeGraphicsTerrible is level.
;So where is r3 set? Let's look look backwards in the code.

addi r3, r5, 1
;This takes the value in r5, adds 1, and puts the result in r3.
;We know that r3 is level. Therefore, r5 + 1 = level.

;At this point, we don't know what is in r3 and it doesn't really matter to us.
;What we have found out is that level = r5 + 1, OR r5 = level - 1.
;So, what sets r5?

mr r5, r30
;This moves the value of r30 into r5.

;Now we know that at this point in the program, r30 contains level - 1.
;Again, we don't know what r5 is at this point.

;So far we've been pretty lucky and all the related commands have been right next to each other.
;However, this won't happen all the time. Here is a whole bunch of unrelated code that deals with something else.
;What we need to be looking for is r30 (level - 1).
;Keep in mind that functions and whatnot can change a register and it will stay changed afterwards.

beq error_message     ;If the last two numbers we compared are equal (eq), break (b) to error_message
cmpwi r3, 0     ;Compare these two numbers
bl GX2IsEverythingOkay
li r4, 420     ;r4 = 420, technically impossible (the number 420 is too big)
addi r3, r5, r6     ;r3  = r5 + r6

;As I said, completely unrelated.

mr r30, r3
;Ah-ha! It's r30!
;As you know, this moves the value of r3 into r30.

;So, at this point:
;We don't know what r5 or r30 are
;We know that r3 is level - 1

bl OSReadConfigFile
;Here's another function. From the docs, we know it takes a string (char*, but again, for another day)
;and reads a config file from that location, returning what it found.
;So, where did that value it returned go? We know that it should be in r3. This is where it all comes together.
;r3 = level - 1.
;r3 is also the value returned by OSReadConfigFile.
;Since we can't have two values in one register, we can reason that level - 1 = value returned by OSReadConfigFile. We're close!

;At this point, all we know is that r3 contains the location of our config file.

li r3, 0xBABECAFE    ; "/meta/0141/f99e/6969/theyll-never-find-this/notconfig.config.exe.jpg"
;Here's where r3 is set. It's being set to the location of a string, which IDA helpfully finds for us and puts as a comment.
;So, we know that level - 1 is stored at a config file at the path above. We can change a config file!

;Since we wanted to set level to 3, we should put 2 in the config file (remember how the program adds 1?).

You might want to read up on PowerPC Assembly and maybe C. I admit reverse-engineering is a bad place to start :3

Here's that the right way around:

li r3, 0xBABECAFE    ; "/meta/0141/f99e/6969/theyll-never-find-this/notconfig.config.exe.jpg"
;r3 = path to config, r5 = ?, r30 = ?
bl OSReadConfigFile
;r3 = level - 1, r5 = ?, r30 = ?
mr r30, r3
;r3 = ?, r5 = ?, r30 = level - 1
;UNRELATED CODE
addi r3, r5, r6
li r4, 420
bl GX2IsEverythingOkay
cmpwi r3, 0
beq error_message
;END UNRELATED CODE
;r3 = ??, r5 = ??, r30 = level - 1
mr r5, r30
;r3 = ??, r5 = level - 1, r30 = ?
addi r3, r5, 1
;r3 = level, r5 = level - 1, r30 = ?
bl GX2MakeGraphicsTerrible

Of course, we know it isn't going to be as easy as a config file, but with stuff like TCPGecko and Cafiine it should be relatively easy to start swapping out files and variables - if you can find them. ;D

Anyway, good luck! I'm working on other stuff right now but I can still help out every now and again. It'd be awesome to see this done

 

[the_randomizer]

Pretty much. Ideally you'll want to find where the functions are called since that allows you to put a name to the values being passed around, then start tracing these values back to their source. Here's how you might go about that:

;I've written this code backwards to give you an idea of what might help you.
;The next line is the LAST line of the sample, the line after is the second-to-last, etc.
;Also, all of this code is fake and none of these functions are real. It's just an example.

bl GX2MakeGraphicsTerrible
;Right, here's the function we want to mess with.
;From the docs available from WiiUBrew and other places, we know that it takes 1 argument - a number.
;For the sake of this explanation, let's call it "level"
;We want to set level to 3.

;At this point, we can say for sure that r3 must have level in it.
;This is because r3 is the first argument to a function, and
;the docs say that the first argument to GX2MakeGraphicsTerrible is level.
;So where is r3 set? Let's look look backwards in the code.

addi r3, r5, 1
;This takes the value in r5, adds 1, and puts the result in r3.
;We know that r3 is level. Therefore, r5 + 1 = level.

;At this point, we don't know what is in r3 and it doesn't really matter to us.
;What we have found out is that level = r5 + 1, OR r5 = level - 1.
;So, what sets r5?

mr r5, r30
;This moves the value of r30 into r5.

;Now we know that at this point in the program, r30 contains level - 1.
;Again, we don't know what r5 is at this point.

;So far we've been pretty lucky and all the related commands have been right next to each other.
;However, this won't happen all the time. Here is a whole bunch of unrelated code that deals with something else.
;What we need to be looking for is r30 (level - 1).
;Keep in mind that functions and whatnot can change a register and it will stay changed afterwards.

beq error_message     ;If the last two numbers we compared are equal (eq), break (b) to error_message
cmpwi r3, 0     ;Compare these two numbers
bl GX2IsEverythingOkay
li r4, 420     ;r4 = 420, technically impossible (the number 420 is too big)
addi r3, r5, r6     ;r3  = r5 + r6

;As I said, completely unrelated.

mr r30, r3
;Ah-ha! It's r30!
;As you know, this moves the value of r3 into r30.

;So, at this point:
;We don't know what r5 or r30 are
;We know that r3 is level - 1

bl OSReadConfigFile
;Here's another function. From the docs, we know it takes a string (char*, but again, for another day)
;and reads a config file from that location, returning what it found.
;So, where did that value it returned go? We know that it should be in r3. This is where it all comes together.
;r3 = level - 1.
;r3 is also the value returned by OSReadConfigFile.
;Since we can't have two values in one register, we can reason that level - 1 = value returned by OSReadConfigFile. We're close!

;At this point, all we know is that r3 contains the location of our config file.

li r3, 0xBABECAFE    ; "/meta/0141/f99e/6969/theyll-never-find-this/notconfig.config.exe.jpg"
;Here's where r3 is set. It's being set to the location of a string, which IDA helpfully finds for us and puts as a comment.
;So, we know that level - 1 is stored at a config file at the path above. We can change a config file!

;Since we wanted to set level to 3, we should put 2 in the config file (remember how the program adds 1?).

You might want to read up on PowerPC Assembly and maybe C. I admit reverse-engineering is a bad place to start :3

Here's that the right way around:

li r3, 0xBABECAFE    ; "/meta/0141/f99e/6969/theyll-never-find-this/notconfig.config.exe.jpg"
;r3 = path to config, r5 = ?, r30 = ?
bl OSReadConfigFile
;r3 = level - 1, r5 = ?, r30 = ?
mr r30, r3
;r3 = ?, r5 = ?, r30 = level - 1
;UNRELATED CODE
addi r3, r5, r6
li r4, 420
bl GX2IsEverythingOkay
cmpwi r3, 0
beq error_message
;END UNRELATED CODE
;r3 = ??, r5 = ??, r30 = level - 1
mr r5, r30
;r3 = ??, r5 = level - 1, r30 = ?
addi r3, r5, 1
;r3 = level, r5 = level - 1, r30 = ?
bl GX2MakeGraphicsTerrible

Of course, we know it isn't going to be as easy as a config file, but with stuff like TCPGecko and Cafiine it should be relatively easy to start swapping out files and variables - if you can find them. ;D

Anyway, good luck! I'm working on other stuff right now but I can still help out every now and again. It'd be awesome to see this done

Thank you again, this too will be quite helpful for those involved, and no, you're right, it won't be easy, as with TCPGecko (or was it PyGecko), another user mentioned that doing the editing crashed the Wii U, even after reverting, I don't know how to use TCP Gecko, so I'm gonna have to look into this. Yeah, this is an interesting development, I can't wait to see what comes from this

Where could I found some good documents on PPC asm and C?

 

[87 Psi]

here is some information about GX2GetSystemTVAspectRatio address, offset etc. with the built in patch function in IDA but i can't assemble because ppc ()

 

[the_randomizer]

here is some information about GX2GetSystemTVAspectRatio address, offset etc. with the built in patch function in IDA but i can't assemble because ppc ()

So what do we do then? There has to be a way to do this, because we're so close, are we permanently screwed? Crap >.<

 

[shutterbug2000]

here is some information about GX2GetSystemTVAspectRatio address, offset etc. with the built in patch function in IDA but i can't assemble because ppc ()

If you can send me the patched .elf, I can convert it to .rpx with the SDK.

 

[QuarkTheAwesome]

I'm pretty sure GXGetSystemTvAspectRatio is not the function you're looking for (move along). The code you're looking at is initialisation stuff and shouldn't be messed with. What you need to find is where GX2 keeps the surface that the game video is on. I'm pretty new to GX2 so I can't really help you there (@dimok, any suggestions?)

You may want to look at Dimok's coloured cube to get a better handle on GX2. As for C, try lean-c.org. I find that I can just Google assembly instructions as I find them.

 

[the_randomizer]

I'm pretty sure GXGetSystemTvAspectRatio is not the function you're looking for (move along). The code you're looking at is initialization stuff and shouldn't be messed with. What you need to find is where GX2 keeps the surface that the game video is on. I'm pretty new to GX2 so I can't really help you there (@dimok, any suggestions?)

You may want to look at Dimok's colored cube to get a better handle on GX2. As for C, try learn-c.org. I find that I can just Google assembly instructions as I find them.

I'm gonna be honest and say that I really aren't that good at programming, much less knowing what does what. Is this even feasible to change/improve at all? I made this thread in hopes of rallying others for their feedback and that how my goal was to help change how Snes games work; I was getting sick at how bad Snes VC games look on HDTVs and I wanted to change that for some time, and I still don't know how. But at least we know where we shouldn't look.

I don't know much about his cube test, then again, we all have to start somewhere.

Edit: Sorry about that, I need to absorb this one step at a time. I'll try that learn-c.org

 

[QuarkTheAwesome]

I'm gonna be honest and say that I really aren't that good at programming, much less knowing what does what. Is this even feasible to change/improve at all? I made this thread in hopes of rallying others for their feedback and that how my goal was to help change how Snes games work; I was getting sick at how bad Snes VC games look on HDTVs and I wanted to change that for some time, and I still don't know how. But at least we know where we shouldn't look.

I don't know much about his cube test, then again, we all have to start somewhere.

Edit: Sorry about that, I need to absorb this one step at a time. I'll try that learn-c.org

To answer your question, 99% sure it's possible, just a case of how hard it is.

I suppose if I'm helping out I should throw a SNES VC into IDA... Super Mario Kart a good one?

 

[shutterbug2000]

To answer your question, 99% sure it's possible, just a case of how hard it is.

I suppose if I'm helping out I should throw a SNES VC into IDA... Super Mario Kart a good one?

Yeah, that should work.

 

[the_randomizer]

To answer your question, 99% sure it's possible, just a case of how hard it is.

I suppose if I'm helping out I should throw a SNES VC into IDA... Super Mario Kart a good one?

Awesome, glad to hear it.

Yeah, that should work.

I think before I continue, it might be prudent of me to look into C as well as intro to PPC asm just so I can be of more help

 

[shutterbug2000]

After some work(and nearly ruining the gamepad screen because of flickering) I present: