Interesting, but i don't see how this can really help (unless it can be forced to send specific memory addresses etc).
Basically what we're saying here is that you can sniff small amounts of completely random data using this method. So you presumably have absolutely no idea where this data actually originated (as in disk or memory addresses) so cannot possibly hope to combine any larger sets of data.
I guess the only use would be if you sat there long enough you might discover some previously unknown function calls or something - but that's gotta be like looking for a needle in the worlds largest haystack.
Or am i missing the point on this one?
Have to say - still an interesting news item, but seems a bit pointless to me (but then i'm no PS3 arcitecture expert!).
PSPSwampy.
Basically what we're saying here is that you can sniff small amounts of completely random data using this method. So you presumably have absolutely no idea where this data actually originated (as in disk or memory addresses) so cannot possibly hope to combine any larger sets of data.
I guess the only use would be if you sat there long enough you might discover some previously unknown function calls or something - but that's gotta be like looking for a needle in the worlds largest haystack.
Or am i missing the point on this one?
Have to say - still an interesting news item, but seems a bit pointless to me (but then i'm no PS3 arcitecture expert!).
PSPSwampy.
It would be awesome if we could somehow dump the Encryption keys from the PS3.
If you tried it with No HD, would it only dump from RAM?
If you tried it with No HD, would it only dump from RAM?
Well, assuming you could boot without a HDD - the system would be quite unstable to say the least, in theory it COULD pull from ram - then again, it might only pull from application area of that PRX, there are just too many variables and not enough data to make a conclusion - even testing would not answer the problem, due to the amount of randomness!
Oh I see. I'm still gonna dump a few times just to confirm this works on 3.0.
Quote:
|
Originally Posted by Ihatecompvir
Oh I see. I'm still gonna dump a few times just to confirm this works on 3.0.
|
Could it possibly be related to uPnP? :confused:
I just hope a big NO!
I just hope a big NO!
What about sending calls or commands to the console via LAN. Maybe, during the testing, instead of sending usual answers to the PS3, one can send different codes to PS3 and look what happens. (I am sure it was already done though.)
Humm.. I'm not sure if I should trust this.. has it been confirmed by anyone else?
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 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 will answer (since nobody else has :p) as this is what SKFU said on IRC in reply to your post:
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.
Quote:
|
|
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.
