great, will not pull back to -130 :)

(This post was last modified: 18/10/2008 12:25 AM by assyrianpimp09.)

(This post was last modified: 18/10/2008 01:09 AM by Bubbletune.)

^ 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

(This post was last modified: 18/10/2008 02:29 AM by ZiNgA BuRgA.)

thanks you guys!

Thanks guys   :D

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

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,.

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