ZiNgA BuRgA
Smart Alternative
Posts: 17,024.1882 Threads: 1,174
Joined: 19th Jan 2007
Reputation: -1.71391
E-Pigs: 446.1887
|
RE: 5.00 VSH Module Descrambler.
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:
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.
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
|
|
| 22/10/2008 05:56 PM |
|