A large number of secure protocols depend on random or secure pseudo-random numbers. Even the session ids created by most web applications for keeping track of which web request belongs to which user depends on random strings which are generated using random numbers.
If, for example, I could predict the next session id generated by a web application, I could hijack this session.
Random numbers are used to create session keys in various protocols (ssl, ssh, ...). If I could predict these keys, I could decrypt the data sent in these sessions. They are also used as nonce values, and if I can predict these, I can break a number of protocols that depend on nonces not being predictable.
how to get at the state
To guess the state of a random number generator, you usually need to observe a lot of numbers generated by the RNG.
This doesn't mean that you have to observe the application that requests these numbers. If you have access to the same RNG (which is possible if you have access to the physical server where your victim application resides), you can simply request a million or ten million numbers yourself, using another program. But usuallly you don't have direct access to the RNG, so you'd either need to passively observe ommunications for a long time or trick the server side into providing more of these numbers (for example, by connecting as a regular user and requesting encryption key rotation 100 times a second in a badly designed protocol that allows for this).
One quality of good random number generators is that they have very long periods, e.g. it takes a huge number of invocations before they start repeating themselves.
Assume for example that you have a really bad generator that starts repeating its sequence of numbers after only 256 invocations. Now if you can observe a few of these random numbers, you can easily pinpoint at which point in the sequence the random number generator is, and correctly predict all future numbers generated.
A good generator should also output numbers that pass various statistical tests. That means that for example all numbers in the output space should be generated with roughly the same frequency, that there shouldn't be detectable patterns (e.g. the RNG always alternating between even and odd numbers) etc.
If you do manage to detect a specific pattern in a RNG, apart from being able to predict parts of a future "random" number, you might figure out that this pattern always occurs when the least important 8 bits in the RNG are in a certain configuration. If you managed to identify a few such patterns that let you infer parts of the RNG's state, you could combine these observations to yield a larger part of the whole state.
Good RNGs should take into account the whole state for each output bit they produce. But say you have one that doesn't do this. For example, assume that you have an RNG that produces numbers whose lowest bit only depends on a single bit of RNG state. This means that the RNG leaks part of its internal state with every number it produces. And if the lowest bit depended on two bits of internal state instead, the RNG would still leak important probabilistic information about the state of these two bits with every number produced.
