IV PS3 Debug Discussion

Printable View

Show 50 post(s) from this thread on one page

01-16-2013, 12:19 AM
ribonucleic

Quote:

Originally Posted by HuN

thanks ... :) but really i dont know if thats a good thing or not , my knowledge is limited in that matter .

btw , i did that deposit on the 80gb ps3 today ... i tested it in-store and evreything seems to work fine :cool:

basically only EID0_0 is changed, in essence only one byte determines whether your consoles TargetID is CEX or DEX, but to change that byte alone would break a signature or hash of some sort, there is some encrypted data in EID0_0 and assumedly the unencrypted part (including the TargetID byte) is used in the encryption/decryption of this encrypted part, so if we were to just change just the TargetID the encryption algo would gather the data and attempt to decrypt the encrypted part but instead of being successful will most probably spit out garbage, so the encrypted portion of EID0_0 needs to be decrypted then the TargetID can be changed, then the previously encrypted data can be re-encrypted and seeing as the TargetID will be different this time around then the encrypted data will be different than the original (obviously the underlying data is unchanged).

obviously this means all of EID0_0's 192 bytes has to be flashed as i have already given one reason why we can't just flash the one byte, of course the other reason is that if we could change just that one byte then it would be incredibly easy to go from CEX to DEX and as a guess i would think that would also lessen the chance of a brick by quite a large amount, sadly the truth of the matter is that encryption schemes sit in our way, however on the bright side this does stop a lot of idiots out there that only want to ruin other peoples fun.

given this it might well be that if you have a healthy CEX dump and brick then you might be able to recover using a hardware flasher (don't hold me to this, this is only an educated guess).

edit: tbh i'm not sure this will alleviate anyones fear of bricking, but for me understanding what is going on is the key to being confident in DEXing a console, i posted this in the hope that others take a similar view, especially 3 and HuN as i'm sure that once you get a grip on IV's code you will blow all of the previous console mods for IV out of the water and i personally believe that it is better to play a game on a console so i actually favor console mods over pc mods

edit2: don't take this post as fact i could well be wrong in exactly what happens, but one thing is certain, the encrypted portion of EID0_0 in some way or another takes into account the TargetID and if it doesn't match what is expected then you have a problem
01-18-2013, 12:53 AM
an0nym0us

Quote:

Originally Posted by Three-Socks

Anyone thought about trying to reverse engineer the GTA EBOOT using IDA?

It should be said, that a general understanding of the EBOOT in IDA is a pre-requisite to any attempts at using the debugger, unless of course you have access to the source code.
01-18-2013, 06:31 AM
ribonucleic

Quote:

Originally Posted by an0nym0us

It should be said, that a general understanding of the EBOOT in IDA is a pre-requisite to any attempts at using the debugger, unless of course you have access to the source code.

the debugger can apparently generate source code, obviously not the original but it should be enough to understand the flow of execution, at a guess i would say IDA is not needed if we can debug the game and i don't know about anyone else but live code is more fun than static plus the changing variables should throw us hints
01-18-2013, 07:20 PM
an0nym0us

Quote:

Originally Posted by ribonucleic

the debugger can apparently generate source code, obviously not the original but it should be enough to understand the flow of execution

If by "source code" you mean the raw PPC64 assembly stream disassembled, yes. Don't confuse the ProDG disassembler for something it is not, without access to the original C/C++ source code, you will be looking at very difficult to understand assembly code. In all honesty, the GTAIV eboots are at the top of my list for difficulty, mostly because it was written in C++. Even once you have an analyzed IDA db, the vast majority of XREFs (cross-references) will be wrong, and manual effort is needed to fix them up. Don't get me wrong here, if you are properly motivated, much can be learned that will have relevancy to just about any RE you do in the future.

Here is a quick example of the biggest issue you will be met with, what I call a "sub-TOC", it probably has a more clever name in actuality but I have not read about this monster in any documents it is merely a by-product of the compiler.

C pseudo-code:

Code:

r30 = *(TOC - 0x7FD0); // 0x11959F8 - 0x7FD0 = 0x118DA28 r31 = *(TOC - 0x7FCC); // 0x11959F8 - 0x7FCC = 0x118DA2C

There are plenty of well-written documents to be found on the 'net explaining the TOC so I will not go into any detail here about it, google is your friend in this case. This happens to be from GTAIV EFLC which has a TOC address of 0x11959F8, in this function there are 2 sub-TOCs utilized: r30 and r31. In the above pseudo-code you can see the value placed into r30/r31 is dereferenced, meaning the value comes from a pointer which is represented in assembly as offset(register), and using a load/store. Here is an example of this in assembly:

Code:

lwz r30, -0x7FD0(r2) # 0x118DA28 -> 0x11CA294 lbz r0, 0(r30) # 0x11CA294 ... lwz r31, -0x7FCC(r2) # 0x118DA2C -> 0x11C36D0 stw r0, 0(r31) # 0x11C36D0

In the above snippet 0x11959F8 - 0x7FD0 = 0x118DA28, so the long-word at 0x118DA28 (0x11CA294) is loaded into the r30 register, and then the byte located at 0x11CA294 is loaded into r0. Often there is an additional offset calculation in the use of r30/r31, but in this case the offset is 0. For r31, 0x11959F8 - 0x7FCC = 0x118DA2C, loads the long-word at 0x118DA2C (0x11C36D0) into r31, and stores the word located in r0 to 0x11C36D0. It is extremely important you grasp this before even thinking any further about looking over the GTAIV assembly code, it is utilized in just about every function. In IDA you can fix up these occurences with CTRL-R, but be sure to adjust the "Base Address" to 32-bits, 0x11C36D00118D9F0 needs to be fixed to 0x11C36D0, once fixed the XREF will be proper. For bonus points, automate this task.

Quote:

Originally Posted by ribonucleic

at a guess i would say IDA is not needed if we can debug the game and i don't know about anyone else but live code is more fun than static plus the changing variables should throw us hints

I wish you luck trying to realize anything meaningful with just the ProDG output, it could be done, but would be extremely time intensive. Both tools have their proper place, utilize IDA to locate locations for breakpoints, and use ProDG to interrogate memory and registers at a particular section of code.
01-18-2013, 08:02 PM
ribonucleic

Quote:

Originally Posted by an0nym0us

If by "source code" you mean the raw PPC64 assembly stream disassembled, yes. Don't confuse the ProDG disassembler for something it is not, without access to the original C/C++ source code, you will be looking at very difficult to understand assembly code.

i know the difference in syntax between, asm and c/c++, but i saw a screenshot of ProDG and it had c/c++ (perhaps pseudo) that was generated from the disassembly, despite my general lack of knowledge about the 3 languages (and btw i know that asm is architecture dependant) and the binarys generated, i know that there are multiple techniques that can be used to accomplish the same tasks, so when the code is compiled and then reverse engineered you'll find you don't get the same code

Quote:

Originally Posted by an0nym0us

In all honesty, the GTAIV eboots are at the top of my list for difficulty, mostly because it was written in C++. Even once you have an analyzed IDA db, the vast majority of XREFs (cross-references) will be wrong, and manual effort is needed to fix them up. Don't get me wrong here, if you are properly motivated, much can be learned that will have relevancy to just about any RE you do in the future.

Here is a quick example of the biggest issue you will be met with, what I call a "sub-TOC", it probably has a more clever name in actuality but I have not read about this monster in any documents it is merely a by-product of the compiler.

C pseudo-code:

Code:

r30 = *(TOC - 0x7FD0); // 0x11959F8 - 0x7FD0 = 0x118DA28 r31 = *(TOC - 0x7FCC); // 0x11959F8 - 0x7FCC = 0x118DA2C

There are plenty of well-written documents to be found on the 'net explaining the TOC so I will not go into any detail here about it, google is your friend in this case. This happens to be from GTAIV EFLC which has a TOC address of 0x11959F8, in this function there are 2 sub-TOCs utilized: r30 and r31. In the above pseudo-code you can see the value placed into r30/r31 is dereferenced, meaning the value comes from a pointer which is represented in assembly as offset(register), and using a load/store. Here is an example of this in assembly:

Code:

lwz r30, -0x7FD0(r2) # 0x118DA28 -> 0x11CA294 lbz r0, 0(r30) # 0x11CA294 ... lwz r31, -0x7FCC(r2) # 0x118DA2C -> 0x11C36D0 stw r0, 0(r31) # 0x11C36D0

In the above snippet 0x11959F8 - 0x7FD0 = 0x118DA28, so the long-word at 0x118DA28 (0x11CA294) is loaded into the r30 register, and then the byte located at 0x11CA294 is loaded into r0. Often there is an additional offset calculation in the use of r30/r31, but in this case the offset is 0. For r31, 0x11959F8 - 0x7FCC = 0x118DA2C, loads the long-word at 0x118DA2C (0x11C36D0) into r31, and stores the word located in r0 to 0x11C36D0. It is extremely important you grasp this before even thinking any further about looking over the GTAIV assembly code, it is utilized in just about every function. In IDA you can fix up these occurences with CTRL-R, but be sure to adjust the "Base Address" to 32-bits, 0x11C36D00118D9F0 needs to be fixed to 0x11C36D0, once fixed the XREF will be proper. For bonus points, automate this task.

I wish you luck trying to realize anything meaningful with just the ProDG output, it could be done, but would be extremely time intensive. Both tools have their proper place, utilize IDA to locate locations for breakpoints, and use ProDG to interrogate memory and registers at a particular section of code.

Thanks for the info btw
01-18-2013, 11:42 PM
an0nym0us

Quote:

Originally Posted by ribonucleic

but i saw a screenshot of ProDG and it had c/c++ (perhaps pseudo) that was generated from the disassembly

what you likely saw was a screenshot of "typical" usage of ProDG, which would be debugging a project that you were in the process of creating. that is to say, a project you have the original source code for. ProDG like gdb has the ability to load debug info (when its present and the ELF is not stripped) and the source code.

If you really want to get a grasp on IDA and ProDG, create a simple "hello world" project using the SDK, be sure to not strip the ELF. That will allow you to be less blind as you learn the interfaces and capabilities, or just continue to stumble around and hope you can make some sense of it all. :D
01-19-2013, 01:39 AM
ribonucleic

is the free version of IDA adequate?
01-20-2013, 05:10 PM
an0nym0us

Quote:

Originally Posted by ribonucleic

is the free version of IDA adequate?

I don't think the 5.0 freeware version supports powerpc at all, its a pretty expensive program, but worth every dollar.
01-20-2013, 07:27 PM
ribonucleic

Quote:

Originally Posted by an0nym0us

I don't think the 5.0 freeware version supports powerpc at all, its a pretty expensive program, but worth every dollar.

well whether its a valuable program or not i don't have money to buy something that i probably won't be using for more than a year, so i'm not paying more than £20 (GBP) and if its more expensive then i'm not buying it and i'll do without
01-21-2013, 06:10 AM
Three-Socks

Something I always wanted to try but never go around to doing

EBOOT_USB.BIN (BLES00229 patch 1.06 CFW 4.21+)

It loads update.img from /dev_usb000/update.img (furthest usb port to the right). But it doesn't work like I wanted it to. I wanted to be able to swap out the usb while in game with a different update.img but the game just crashes when I start a new game. You have to quit and launch game again.

Anyway posting it here because I wouldn't of been able to do it without a little reversing with IDA and it might be useful to someone. For anyone who test their scripts on ps3 it might save you 5mins from transferring the file through FTP/multiman.

Show 50 post(s) from this thread on one page