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.