193w ago - Today
SKFU has shared a bug he found in PS3 Firmware 2.8 (although he said it should be present since 2.0 through 3.0) that allows you to dump random data from the PlayStation 3 HDD and RAM.
To quote: There's a little "bug" in the PlayStation3's NAT test which causes that you can dump random data from the HDD and RAM. Why exactly this appears; I don't know, yet. But well, it is interesting.
The way how to do it is pretty simple. Set up
Wireshark on the PC and activate ICS (Internet Connection Sharing).
Connect the PS3 with the PC via LAN and start Wireshark's logging/sniffing feature on the LAN device. Now go to Settings on the PS3 and start a Internet Connection Test in the Network option.
When the PS3 starts the NAT testing it will send default STUN packets together with several IP Fragments. Those both packet types will contain random data which the PS3 grabs from the HDD and/or RAM. There you go.
" is it possible to launch games from a games folder in xmb without using multiman? "
I think there are some programs out there that let yo...
So basically, this hasn't been tested/confirmed by anyone else and even SKFU himself pretty much have "moved on" from it.
He only wanted to make mention of the bug finding itself, but (in my opinion) it's safe to place this on the back burner now as none of the other Devs are interested/plan to follow-up on this either.
If anyone does, feel free to share your findings... but chances are most share the same thoughts as PSPSwampy and kakarotoks stated above on it.
I know STUN (hell, I wrote a full (RFC3489 and RFC5389) STUN library) and I don't see how it could contain any random data.. a basic Binding request (for NAT discovery) would only be 20 bytes long (only the header, no attributes), 4 bytes in there are important (type of request + size of payload), then you get 16 bytes of "cryptographically random" transaction ID.. I would guess that maybe the transaction id is just a random, uninitialized pointer, instead of being filled with /dev/urandom data..
If that's the case, then yeah, maybe it is possible, but I would doubt such a simple RFC would be implemented as badly as this (most library that do not care about the transaction id send "0000000000000000" as transaction id (which is perfectly fine/valid))...
I don't know about the IP (or UDP) layers, but I doubt it would contain uninitialized data...
In any case, this isn't helpful, since you can't predict which memory address will be captured... so you can't really 'reconstruct' the RAM's content or anything like that (and even if you could, 16 bytes at a time is really small), so it's not that useful in itself..
But if it's confirmed true, it's still a nice find
Thanks for sharing.
I just hope a big NO!
That will be appreciated, mainly as he said on IRC he believes it's 2.0-3.0 but couldn't confirm it himself as he's on 2.8 at the moment.