17/10/2008, 11:53 PM
great, will not pull back to -130 :)
![[Image: 200810181440390un2.png]](http://img253.imageshack.us/img253/3788/200810181440390un2.png)
18/10/2008, 12:03 AM
And here Sony thought that they won... :P
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?
ay schmilk u thinkin of makin a prx converter? sometime?
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.
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
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
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:
|
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:
|
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.
18/10/2008, 02:57 AM
thanks you guys!19/10/2008, 08:27 AM
Thanks guys :D
And thanks xander for the GUI, command prompt is a pain in the arse... :p
And thanks xander for the GUI, command prompt is a pain in the arse... :p
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,.
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,.
22/10/2008, 05:56 PM
Bubbletune Wrote:Oh okay, thanks for the explanation :PZiNgA 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, $fcr12Seeing 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, $fcr0Here, 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.