08-30-2010 #101sassacontrol Guest
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 ..
08-30-2010 #102DarkNeo Guest
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.
08-30-2010 #103Karl69 Guest
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.
08-30-2010 #104thijzzy Guest
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.
08-30-2010 #105proskopina Guest
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.
08-30-2010 #106tripellex Guest
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.
08-30-2010 #107mushy409 Guest
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.
08-30-2010 #108GrandpaHomer Guest
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)
08-30-2010 #109Karl69 Guest
[Register or Login to view code]
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:
[Register or Login to view code]
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.
08-30-2010 #110proskopina Guest
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.