PS JailBreak Mod Code Sniffed via USB, Logged and Examined

[sassacontrol]

1 - Intendis wrong, or the code is sent even if the game is not ready to receive? (brute force)

2 - PSJ readings are different on each ps3 (say due to ID) or is it always the same regardless of the console?

For if ever the same, it would be easier to schedule a PIC18Fxx to send this data we already have ..

Rogerio

[DarkNeo]

Does anyone have a link to good documentation on 64bit PPC instructions? For example I'm having a hard time figuring out what the oris opcode would do to 64bit registers, does it still take a 16bit immediate value in 64bit chips? And if so which 16 bits in the 64bit register does it OR the immediate value with?

Btw has anyone checked whether all the programming modes have been disabled? The Atmega series supports JTAG, SPI and high voltage programming (used to reset fuses). I'm not sure if high voltage programming can be disabled, but I've never used it before, so it may also erase the chip.

[Karl69]

Decapping with a 70-pct solution of NFNA heated to 150 degrees C with a blowtorch has worked for me in the past, but you run a major risk of destroying the die's integrity, rendering reading useless. It's a risky venture. If I can get my hands on a few older Atmegas for trial-and-error runs, I'll try testing to see if I can get a read off them after decapping.

And what would you do with an open chip once you have it? Do you have the equipment required to read it out?
If the answers from the PSJ are really static and not dynamic, then there is no need to open anything as sniffing the traffic between the PS3 and the PSJ will give us everything we need. I have no doubt that this is the first thing which is going happen, once the PSJ hits the shops. This is probably also the reason why there are so many clones coming up so fast...

As someone here pointed out earlier, the code in the first packet apparently circumvents the dynamic challenge response JIG-Stick authentication in the PS3, making the PS3 accept a static answer. Since the PSJ has been made for FW 3.41 it would be interesting to see, if that exploit can be modified and used on some older firmware versions.

This is probably also the reason why there are so many clones coming up so fast...

And I don't think that it was really a smart move from ozmod to announce the PSJ three weeks before it could be delivered... But that's just my two cents...

[thijzzy]

well i can test software on psp, iTouch, PC (AA cable)

I know the code is a bit damaged, but maybe wait for the x3Jailbreak maybe is it easier to sniff it.

keep up the great work guys.

[proskopina]

This is the actual shellcode it repeats 32 times and it patches the lv2 (this info is from Rich). It probably tries to make the PC jump to this code sequence, I'm not sure if the same shell code could work on other firmwares.

[tripellex]

And what would you do with an open chip once you have it? Do you have the equipment required to read it out?

Well, I was hoping if I asked the chip nicely, it would give up its secrets lol

I've milled/decapped ICs in the past to varied levels of success for the MAMEDev. I have most everything I need, except a good optical microscope and a logic probe, the latter of which I have already ordered on Amazon as my old DP21 crapped out on me, the prior of which I can borrow from the university. Back in the old days you couldn't read from EPROM using decapping, only MASKROM, but thanks to microprobing thats not the case. And with this sort of MC package, blackboxing is nearly impossible from what I understand. Decapping is a nearly 100% foolproof way of gleaming what we need to know, IF you can do it correctly. The downside is, its super expensive unless you already have/can get for cheap what you need, and I personally don't have a ton of MCU decapping expertise.

The main problem is working with Atmels directly off-the-die, as from what I've discussed with others on IRC, using anything like RFNA (or any fuming acid for that matter) is extremely destructive on the dieset of these types of microcontrollers. I'd hope that this would be a last ditch effort, and you have some good ideas regarding dynamic PSJ-to-PS3 reading. Let's hope that turns out to be the "easy" way of doing it.

Also, if it comes down to it, I think between myself and Mushy that we may be able to pull what we need. I can practice on some older Atmega16s, then after we get ahold of either a PSJB or X3JB, I can decap it (if there's no security mesh in place), grab some high res die closeups, and send it to Mushy to second opinion it, if he's interested.

[mushy409]

As said before, decapping may not be the answer, but will allow us to get a hold of the actual code intact, not a damaged USB log.

And as tripellex said, some of us have the equipment OR have access to it in order to pull this off.

I found my AVR programmer... it's not looking good. Got crushed in a box of junk from when I moved last year. Damnit! Serves me right for not packing it up with the rest of my proggers.

Does anyone know if the Infectus could program/read the atmega? I see JTAG & SPI programming in the list, but the ever-informative creators never listed the device's specs (supported flashes, what the modes are used for etc)

Most of the Actel modes I have never used on my infectus just for the fact there isn't any info/data related to the modes...

Some of us are trying to pull our weight with this, unlike some who are just sat there with their hands out asking for a "free solution". Really annoys me sometimes.

[GrandpaHomer]

Since the PSJ has been made for FW 3.41 it would be interesting to see, if that exploit can be modified and used on some older firmware versions.

Yeah - I'm not really keen to update from 3.15 just to find out this is not exactly what I might have expected ...

The question is how much is it FW version dependend ... if it's using some routines simply not present in previous versions or if it's just about correct addressing of the code in each version ...

I'm sure we're not only ones looking to get this work on 3.15 or older versions This was also one of the reasons I've hesitated to hurry with purchase (apart of the sky high price tag)

[Karl69]

Also, if it comes down to it, I think between myself and Mushy that we may be able to pull what we need. I can practice on some older Atmega16s, then after we get ahold of either a PSJB or X3JB, I can decap it (if there's no security mesh in place), grab some high res die closeups, and send it to Mushy to second opinion it, if he's interested.

I'll stick to the unlooper as my weapon of choice ... But as I wrote...If the challenge/response is static, there is no need for all this

Yeah - I'm not really keen to update from 3.15 just to find out this is not exactly what I might have expected ...

Neither am I... And I stopped updating on 3.00

The question is how much is it FW version dependend ... if it's using some routines simply not present in previous versions or if it's just about correct addressing of the code in each version ...

I would bet on both. But then, I haven't been following the whole thing that much since Geohot's hack.
If you look through the exploit in the first packet, there is relative coding like this here:

 3ac:	fb 81 00 80 	std     r28,128(r1)
 3b0:	fb a1 00 88 	std     r29,136(r1)
 3b4:	fb e1 00 98 	std     r31,152(r1)
 3b8:	fb 41 00 70 	std     r26,112(r1)
 3bc:	fb 61 00 78 	std     r27,120(r1)

this might be a good thing if we want to adapt this exploit to other FWs.

But then there is also "absolute" coding like this:

 150:	00 04 90 e0 	.long 0x490e0
 154:	e8 82 0f 08 	ld      r4,3848(r2)
 158:	00 04 90 e4 	.long 0x490e4
 15c:	e8 7c 00 20 	ld      r3,32(r28)
 160:	00 04 90 e8 	.long 0x490e8
 164:	f8 64 00 00 	std     r3,0(r4)
 168:	00 04 f0 a8 	.long 0x4f0a8

The values after .long are probably addresses which are firmware dependent and would have to be changed depending on the FW version. Again I am guessing here...

Maybe some people with more knowledge of the PS3 internals could help here to analyse the exploit and share the results.

Karl

[proskopina]

this is the usb traffic between the psjailbreak device and ps3. it contains the exploit code but it doesn't contain the binaries on the psjailbreak itself. i.e it won't let you clone the jailbreak but it will give the devs a great heads up on how to use the exploit and deliver it to the ps3 in different ways.