Threaded Mode | Linear Mode

matchung · 17/10/2008 11:53 PM

great, will not pull back to -130 :)

XanderChaos · 18/10/2008 12:03 AM

And here Sony thought that they won... :P

assyrianpimp09 · 18/10/2008 12:24 AM

wow thanks guys good work also thanks xander for the gui really simple to use im not good with command prompt:P

ay schmilk u thinkin of makin a prx converter? sometime?

Bubbletune · 18/10/2008 01:07 AM

ZiNgA BuRgA Wrote:Oh okay - I only just took a quick look at your source.
The problem with loading upper immediates would be that you can't really determine if something's been loaded before that. Checking immediates gets hard coded values, but with code execution, anything could really happen...

Probably impossible to get the lower 16 bits without writing some hell complex algorithm (which probably still won't work most of the time). Only real way would be to disassemble in each case.
But still, nice work you guys did :)

Wee read the file backwards, and once wee find a co-processor instruction on the $at register, wee go further up till wee see either a 'lui $at' or an 'ori $at, $at'. Once wee find a 'lui' (which wee'll find last seeing wee're reading backwards), wee mix it with the value in the 'ori' just before that (if any), store the float, and start searching for another co-processor instruction. Note how 'lui' clears the entire register before it fills the upper bits ;)

As far as wee are concerned, this method should be able to find all floats without any trouble, and so it has been confirmed by several theme developers.

ZiNgA BuRgA · 18/10/2008 02:25 AM

^ Yeah, it probably works in these cases because I'd guess that Sony probably just modified the compiler (or compilation flags/whatever) to store the floats in the opcodes.

I was just mentioning (in response to Super Sheep's post) that getting values where no ORI operation was found (just a LUI), means that either it's not an "offset", or otherwise would be nigh impossible to write an algorithm to determine. (floats are all 4 bytes anyway) If there's just a LUI without an ORI, it's probably just something else (though again I state that I don't know the MIPS architecture), but it's always good to keep everything though ;)
(By the way any particular reason why it's always the $at register, or just some random thing?)

But still, great find there! :D

Bubbletune · 18/10/2008 02:44 AM

ZiNgA BuRgA Wrote:^ Yeah, it probably works in these cases because I'd guess that Sony probably just modified the compiler (or compilation flags/whatever) to store the floats in the opcodes.

I was just mentioning (in response to Super Sheep's post) that getting values where no ORI operation was found (just a LUI), means that either it's not an "offset", or otherwise would be nigh impossible to write an algorithm to determine. (floats are all 4 bytes anyway) If there's just a LUI without an ORI, it's probably just something else (though again I state that I don't know the MIPS architecture), but it's always good to keep everything though ;)
(By the way any particular reason why it's always the $at register, or just some random thing?)

But still, great find there! :D

Well, seeing wee search for an coprocessor instruction before a 'lui' instruction, it must be a float, as floats are the only thing that is ran through the coprocessor. It seems to be always the $at register, so wee've decided to make use of that. In the future, if Sony randomizes it, wee can always rip the register from the coprocessor instruction, and then search for lui's and ori's containing it.

I'll try to illustrate it better:

Code:

	0x00004968: 0x3C0142C8 '.B.<' - lui        $at, 0x42C8
	0x0000496C: 0x44816000 '.`.D' - mtc1       $at, $fcr12

Seeing the file is read backwards, the first thing wee locate is the coprocessor instruction, so wee switch to 'find lui and ori mode'. Then, wee go further up, and wee find a 'lui', wee write the value to the output file and return to 'find coprocessor instruction' mode.

Code:

	0x000088BC: 0x3C013ECC '.>.<' - lui        $at, 0x3ECC
	0x000088C0: 0x3421CCCD '..!4' - ori        $at, $at, 0xCCCD
	0x000088C4: 0x44810000 '...D' - mtc1       $at, $fcr0

Here, wee locate the coprocessor instruction, switch to the different mode, and find the 'ori' first. Wee store it's value in a seperate variable, and continue searching, finding a 'lui' instruction. Then, wee mix the 'ori' variable into there, and write the value to the output file.

Vegetano1 · 18/10/2008 02:57 AM

thanks you guys!

Mr. Shizzy · 19/10/2008 08:27 AM

Thanks guys :D

And thanks xander for the GUI, command prompt is a pain in the arse... :p

Vegetano1 · 22/10/2008 04:47 PM

when using with common_gui.prx:
Common_gui.prx got scrambled and non scrambled floats,.. so if i descramble>> edit a float,. say 100 to 1200>> scramble>> then also all "non scrambled floats 100" will be changed to 1200,. :( could this be true,. i am not sure but i think this is whot happens,.

ZiNgA BuRgA · 22/10/2008 05:56 PM

Bubbletune Wrote:
ZiNgA BuRgA Wrote:^ Yeah, it probably works in these cases because I'd guess that Sony probably just modified the compiler (or compilation flags/whatever) to store the floats in the opcodes.

I was just mentioning (in response to Super Sheep's post) that getting values where no ORI operation was found (just a LUI), means that either it's not an "offset", or otherwise would be nigh impossible to write an algorithm to determine. (floats are all 4 bytes anyway) If there's just a LUI without an ORI, it's probably just something else (though again I state that I don't know the MIPS architecture), but it's always good to keep everything though ;)
(By the way any particular reason why it's always the $at register, or just some random thing?)

But still, great find there! :D

Well, seeing wee search for an coprocessor instruction before a 'lui' instruction, it must be a float, as floats are the only thing that is ran through the coprocessor. It seems to be always the $at register, so wee've decided to make use of that. In the future, if Sony randomizes it, wee can always rip the register from the coprocessor instruction, and then search for lui's and ori's containing it.

I'll try to illustrate it better:
Code:
	0x00004968: 0x3C0142C8 '.B.<' - lui        $at, 0x42C8
	0x0000496C: 0x44816000 '.`.D' - mtc1       $at, $fcr12
Seeing the file is read backwards, the first thing wee locate is the coprocessor instruction, so wee switch to 'find lui and ori mode'. Then, wee go further up, and wee find a 'lui', wee write the value to the output file and return to 'find coprocessor instruction' mode.
Code:
	0x000088BC: 0x3C013ECC '.>.<' - lui        $at, 0x3ECC
	0x000088C0: 0x3421CCCD '..!4' - ori        $at, $at, 0xCCCD
	0x000088C4: 0x44810000 '...D' - mtc1       $at, $fcr0
Here, wee locate the coprocessor instruction, switch to the different mode, and find the 'ori' first. Wee store it's value in a seperate variable, and continue searching, finding a 'lui' instruction. Then, wee mix the 'ori' variable into there, and write the value to the output file.

Oh okay, thanks for the explanation :P

Threaded Mode \| Linear Mode 5.00 VSH Module Descrambler.
Author	Message