store everything, reconstruct it all later by trying to work out which part of the heap each request is from. there is likely some sort of efficiency calculus y

store everything, reconstruct it all later by trying to work out which part of the heap each request is from. there is likely some sort of efficiency calculus you can do here (i'm not good at math so I have no idea what i'm talking about) where you could calculate for heap size x and probabilities y and z etc. just how many requests and what size they should be to cover the entire process heap. edit: OpenSSL wraps malloc, so it is different on different systems. You could find out what the probabilities are by looking at the source. For some reason FreeBSD's malloc gave up private keys with the default exploit length and not much effort. It was only a matter of time before other platforms were also figured out. Note that the FreeBSD exploit worked on a fresh server after boot, which might have also been the case here. Note that in the heap there are the intermediate values that and are used when constructing the connection and doing the encryption, you aren't exactly looking for '------BEGIN PRIVATE KEY------' or base64 string, you'd be looking for those - each which have a unique data type.