Why Pseudo-Random Number Generators (PRNGs) Aren't Safe

⚠️ Warning: This post is written purely for proactive cybersecurity education and awareness. Our goal is to make our systems safer by understanding how algorithms work and how vulnerabilities occur. Please do not use the concepts explained here for malicious purposes.

We already talked about how computers can't actually "roll dice" and how PRNGs (Pseudo-Random Number Generators) rely on predictable "seeds." We mentioned that guessing the seed or the system time is just one way to trick the system. But what if I told you we could completely break the algorithm just by looking at the generated numbers, even if we never knew the seed?

Yep, you heard that right. The real thing that makes PRNGs insecure is the pure math lying beneath them. Even though these algorithms seem "random," they are actually chains bound by incredibly strict rules. And every chain eventually reveals its secrets to a careful eye watching the output.

Let's step into the hacker's kitchen. How do these algorithms work at the code level, and how are they "hacked" using basic math? Let's take a closer look at the most popular algorithms and their Python codes.

1. LCG (Linear Congruential Generator): The Betrayal of Math

LCG is one of the oldest, most common, and easiest-to-implement random number generators out there. Its formula is basically just a high school math equation:

X_{n+1} = (a \cdot X_n + c) \pmod{m}

• m (modulus): Our limit boundary.

• a (multiplier): Our secret multiplier.

• c (increment): The secret added value.

• X_n: The seed or the previously generated number.

An LCG Example in Python:

Let's say the system uses these secret parameters: m = 256, a = 11, c = 17, and our starting seed is 3.

def lcg_generator(seed, a=11, c=17, m=256, count=3):

numbers = []

x = seed

for _ in range(count):

x = (a * x + c) % m

numbers.append(x)

return numbers

print(lcg_generator(3))

# Output: [50, 55, 110]

How is it Cracked? (A Numerical Example):

An attacker doesn't know the seed (3) or the secret parameters (a, c). They only see the numbers coming out: 50, 55, and 110.

The attacker uses this simple logic:

1. Second number minus the first number: 55 - 50 = 5

2. Third number minus the second number: 110 - 55 = 55

3. According to the formula, the relationship between these differences is directly tied to the multiplier a. So, the remainder of 5 * a should be 55. With a little trial and error in modular math (or using the Extended Euclidean Algorithm), the attacker instantly finds out that a = 11.

4. Once they have a, they go back to the first number: (11 * 50 + c) mod 256 = 55. From there, they easily calculate that c = 17.

Congratulations! The system is completely broken. Now you can calculate the next number (what comes after 110) at the exact same time as the system: (11 * 110 + 17) mod 256 = 203.

2. Xorshift: The Bit-Shifting and XOR Vulnerability

Xorshift works by shifting the bits (1s and 0s) inside the numbers left and right, and putting them through an Exclusive OR (XOR) operation with themselves. The outputs look way more chaotic than an LCG, but its vulnerability comes from the fact that the operations are invertible.

A 32-bit Xorshift Example in Python:

def xorshift32(state):

state ^= (state << 13) & 0xFFFFFFFF

state ^= (state >> 17) & 0xFFFFFFFF

state ^= (state << 5) & 0xFFFFFFFF

return state

seed = 12345 # Our initial state

new_number = xorshift32(seed)

print(f"Generated Number: {new_number}")

# Output: 2686153928

How is it Cracked?

The biggest security flaw here is the nature of the XOR (^) operation. If you XOR a number with another number, and then do the exact same operation again, you revert back to the original number. (It's like putting a key in a lock, turning it twice in the same direction, and the door opens again).

Because these operations are completely "linear," an attacker can simply look at the generated number (2686153928) and write a simple mathematical matrix (an inverse matrix) that applies the left/right shifts in reverse. They feed the number into their machine, and within seconds, they recover the secret seed 12345.

3. Mersenne Twister and the Famous "624" Number

Now, let's talk about the most widely used random number generator in the modern world, found in Python (the random library), PHP, Ruby, Excel, and more: the Mersenne Twister (MT19937).

It gets its name from the massive prime number that determines its period length (2^{19937}-1). It produces incredibly high-quality, statistically flawless numbers. However, for cryptographic (encryption) purposes, it is an absolute disaster.

Technical Background: Why Exactly 624 Numbers?

At the heart of the Mersenne Twister (its internal state) lies a giant array of exactly 624 numbers, each 32 bits long.

When you ask the system for a random number, the algorithm follows these steps:

1. It grabs the next number from this 624-number array.

2. It doesn't give this number to you directly. First, it puts the number through a bitwise (bit shifting and XOR) process called "Tempering" to make the numbers look statistically more random.

3. It hands you the tempered result.

4. When all 624 numbers are exhausted, it internally shuffles the array in a complex way (the "Twist" operation) to create a brand new array of 624 numbers.

How is Mersenne Twister Broken? (State Recovery):

Here is the kicker. That "Tempering" process we mentioned in Step 2 is a completely reversible linear operation, just like in Xorshift.

An attacker silently collects exactly 624 consecutive random numbers from the victim's system.

Then, they write an "Untemper" function for each number. This function wipes off the algorithm's final "makeup," returning that number to its original, naked state as it existed in the machine's internal 624-number array.

What happens when you do this for all 624 numbers? You just built a 100% exact clone of the computer's secret internal state array right on your own machine!

# A conceptual representation of MT cracking

attacker_state = []

for number in collected_624_numbers:

original_state = untemper(number) # Wipe off the makeup!

attacker_state.append(original_state)

# We now have a clone of the target system!

emulate_target(attacker_state)

The brain of the target system is now in your hands. You don't just guess the next playing card the online casino will deal, or the next password reset token; you know it with 100% certainty, even before the system itself does!

This is exactly why you can never trust standard algorithms when it comes to security. The output is always a mirror of the inside!