Thread: New idea for multiple exploits..
i have read some pdf files ($dk)... and see this.
Updating Flash Memory on Reference Tool Target System
(1) Power off the motherboard by pressing the "POWER" switch, if it is powered on. (Refer to the
instruction manual for the Reference Tool.)
(2) The provided flash memory image file for the Reference Tool target system, ebootrom.100.0xx
(where 0xx represents the build number digits), is normally installed in
$CELL_SDK/target/bootrom/. Move into the directory and check the presence of the file in the
directory, and then start up the logical console server with the -rom option from the directory,
specifying the IP address set for the debugging Ethernet port of the Reference Tool as shown
below (where xx.xx.xx.xx represents the IP address). Note that the -at option is also mandatory.
(Refer to "Logical Console Server" in Section 7 for details of the command and its options.)
$ cd $CELL_SDK/target/bootrom/
$ lcnslsrv -at –ip xx.xx.xx.xx -rom ebootrom.100.0xx
(3) Press the "POWER" switch to supply power to the motherboard.
It causes the Reference Tool target system to boot and several windows to open. It also causes the
program for updating the flash memory to start, read the remote flash memory image file, and
execute updating of the flash memory. Messages of the updating program will be output to the
window titled "lcterm lpid:1 lcid:10".
(4) When the following text is displayed, power to the motherboard will be automatically turned off.
System update: SUCCESS
Now you have completed the updating procedure. The updated flash memory will be used from the next
but my intention of reply is, if you can see all that data posted above.
maybe you can see what are the first request of boot time by your method.
give it a try...
We'd all need to have the SDK for that kind of work.
Wonder where to get it?
Also, the "$CELL_SDK/target/bootrom/" directory of the SDK isn't included in the easily available version of 1.60 that you find at your favorite torrent sites.
Must be in the full release that still never got much of a leak to the general public.
The one I've seen available is "PS3 SDK and Tools v160.008" but needs the devkit and contains the outdated cell sdk only. No idea about the rsx sdk.
Retail boxes don't update via lcnslsrv. And new SDK firmware only appears as a .PUP format image too, so lcnslsrv isn't used anymore (unless you happen to have a really old devkit).
If you don't have any luck, there is always IRC. Those who have demonstrated via Forum posts a serious effort (you guys know who you are) should get in touch with CJPC there. He may be able to guide you in the right direction... of course, this doesn't apply to those with 1 post who are just looking to acquire such materials for "bragging rights."
I have been trying to gather some information to help you guys out but my spare time is limited.
I have my PS3 using the wireless connection so Im going to set my PC wireless card up and see what kinda information I can capture. I have lots of experience with wireshark from taking msce security courses and if there is anything useful I should be able to pick it out.
Question is does the PS3 download the category_psn.xml everytime you connect to the store (or as soon as the PS3 gets online) or does it look for an update file every Thursday knowing there should be an updated file soon.
Well, this one is the easy part.
I know for sure it connects and downloads on EVERY boot.
Even if it's already online.
I couldn't figure out how to get wireshark to sniff wireless packets so I just didn't try. (Google wasn't loading for me at the time).
The wired packet capture method is out of the question (no router, besides wireless router).
But I'll keep working around wireshark and posting if I get anything good.
As I thought, this DNAS Certificate when you log in, confirms to the server it's a valid PS3, and IS editable. We could definitely "hot-edit" this packet if we can get a program for it. (Working on mine, but no progress really).
We could replace "*.*.*.dl.playstation.net" with 192.168.0.100 or another IP or server. Without disconnecting the PS3 from the server!
Instant win? I believe so.
This is by far the most obvious exploit no one seemed to catch.
Now that the proof is there (hopefully), this will work if we can edit it.
I.E, Create a server with SSL capabilites to use as a proxy for everyone's PS3, also bypassing firmware updates, etc.
The server will "change" the *.*.*.dl.playstation.net to anything we want.
I'm thinking a site should be made, where a user has a custom Control panel, and can edit the server of their choice. Allowing everyone to be able to redirect their ps3, to a file anywhere.
I'm thinking this would be a great idea for everyone.
Any ideas guys?
What is your expectation of this? Similar thing with hot replacement of files has been done with proxies before (for example I did something very similar to what you describe using Proxomitron: http://www.ps4news.com/forums/ps3-on...f-h-93618.html ).
Even when you redirect it elsewhere you only will be able to give PS3 proper packages (i.e. signed from Sony) and from what I remember about proxied methods PS3 somehow is able to detect your attempts so last time I checked you were unable to install and actually use full games.